关于各种某某服务器的含义，比如VPS, 独立服务器，云服务器，Web服务器，应用服务器等

VPS, 独立服务器，云服务器的区别

作者：任旭
链接：https://www.zhihu.com/question/19656397/answer/20560678
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

如果将VPS比作一个水龙头，服务器的计算和存储资源则是一根水管，水管上有很多水龙头。你需要付出租用这个水龙头的费用，而它的水流量是有限的。如果你想获得更大的水流，那么你需要租用更多的龙头，同时，如果所有的龙头都在流水，那么每个龙头的水流量都会降低。
而云计算下的主机，你所获得的是一个流量可大可小的龙头，服务器由一台变成一组，就像一个水管变成很多条水管组成的大水管。当你需要更大的水流时，可以直接控制你的龙头加大水流，同时即便所有的水管都在流水，也不会影响你的水流。更有甚者，你需要付出的费用，不再是租用水管产生的，而是为你所需要的水流量。
至于自己架设或者租用整个服务器，目前来看经济型就差很多了，因为你要连水龙头和水管都买下来，不够用的时候还要再买。我们都知道服务器资源通常使用率也就20%，除非业务非常稳定，不会明显增长，或者特别不差钱，可以考虑自建。
虽然我们知道了云主机和VPS的区别，但如何挑选云主机成为了一个难题，可以说这个市场鱼龙混杂，甚至卖到的云主机，其实就是一台VPS。
于是我们要关注两个要点，第一、这个大水管的质量如何，即所依托的数据中心质量如何。第二、这个大水管和各个水龙头的衔接是否有效，水龙头的流水量和稳定程度能否得到保证。
衡量数据中心的质量，说法很多，其实最简单的方法是看机房的客户，如果一个数据中心的主要客户是银行，你说差的了么？如果一个数据中心的主要客户是私服，你说好的了么？
至于大水管的衔接问题，主要该考虑虚拟化技术（网络也是关键，但云计算背景下网络已经变得次要了），网传很多云主机的应用跑不了，或者容易出问题，这些主要源于虚拟化技术。这块技术可以说还在发展期，相对比较成熟和领先的，应该说VMware首屈一指，国内的阿里云、盛大云等产品也在高速追赶，褒贬不一，可以自己看看网评。
综合来看，想要一个更好的云计算IAAS，还是要衡量你对这个云主机的要求。一般简单的建站需求，阿里云、盛大云都是不错的选择，甚至评价比较好的VPS都能应对要求不高的建站，重点看预算，能接受的话还是推荐云主机，注意别被VPS忽悠了就好。如果是需要企业级应用，公司里面跑ERP，CRM，甚至SAAS厂商，那就必须严格考量上面说的水管质量和衔接问题了，国内银行业数据中心供应商，除了自建外肯定是GDS最有名了，至于VMware的公有云IAAS，在亚太地区只有软银电信和新加坡电信有授权，目前GDS开始和软银合作这块业务，推出了基于VMware的云数据中心业务，应该属于国内中高端云主机（或者该叫云数据中心）的首选解决方案了。另外低端的云主机万国也有，还提供2周免费试用…与其四处浏览，何不申请试试？

web服务器和应用服务器有什么区别？

参考：https://zhidao.baidu.com/question/43745729.html?qbl=relate_question_3&word=%D4%C6%D3%A6%D3%C3%BA%CD%C6%D5%CD%A8%CD%F8%D5%BE

web服务器(web server)

web服务器可以解析(handles)http协议。当web服务器接收到一个http请求(request)，会返回一个http响应 (response)，例如送回一个html页面。为了处理一个请求(request)，web服务器可以响应(response)一个静态页面或图片，进行页面跳转(redirect)，或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如cgi脚本，jsp(javaserver pages)脚本，servlets，asp(active server pages)脚本，服务器端(server-side)javascript，或者一些其它的服务器端(server-side)技术。无论它们(译者注:脚本)的目的如何，这些服务器端(server-side)的程序通常产生一个html的响应(response)来让浏览器可以浏览。
要知道，web服务器的代理模型(delegation model)非常简单。当一个请求(request)被送到web服务器里来时，它只单纯的把请求(request)传递给可以很好的处理请求 (request)的程序(译者注:服务器端脚本)。web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响应(response)的环境，而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing)，数据库连接(database connectivity)和消息(messaging)等功能。
虽然web服务器不支持事务处理或数据库连接池，但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability)，例如负载平衡(load balancing)，缓冲(caching)。集群特征(clustering—features)经常被误认为仅仅是应用程序服务器专有的特征。

应用程序服务器(the application server)

根据我们的定义，作为应用程序服务器，它通过各种协议，可以包括http，把商业逻辑暴露给(expose)客户端应用程序。web服务器主要是处理向浏览器发送html以供浏览，而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个方法 (或过程语言中的一个函数)一样。
应用程序服务器的客户端(包含有图形用户界面(gui)的)可能会运行在一台pc、一个web服务器或者甚至是其它的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反，这种信息就是程序逻辑(program logic)。正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态html，所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。
在大多数情形下，应用程序服务器是通过组件(component)的应用程序接口(api)把商业逻辑暴露(expose)(给客户端应用程序)的，例如基于j2ee(java 2 platform, enterprise edition)应用程序服务器的ejb(enterprise javabean)组件模型。此外，应用程序服务器可以管理自己的资源，例如看大门的工作(gate-keeping duties)包括安全(security)，事务处理(transaction processing)，资源池(resource pooling)，和消息(messaging)。就象web服务器一样，应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。

例子

例如，设想一个在线商店(网站)提供实时定价(real-time pricing)和有效性(availability)信息。这个站点(site)很可能会提供一个表单(form)让你来选择产品。当你提交查询 (query)后，网站会进行查找(lookup)并把结果内嵌在html页面中返回。网站可以有很多种方式来实现这种功能。我要介绍一个不使用应用程序服务器的情景和一个使用应用程序服务器的情景。观察一下这两中情景的不同会有助于你了解应用程序服务器的功能。

• 情景1:不带应用程序服务器的web服务器
  在此种情景下，一个web服务器独立提供在线商店的功能。web服务器获得你的请求(request)，然后发送给服务器端(server- side)可以处理请求(request)的程序。此程序从数据库或文本文件(flat file，译者注:flat file是指没有特殊格式的非二进制的文件，如properties和xml文件等)中查找定价信息。一旦找到，服务器端(server-side)程序把结果信息表示成(formulate)html形式，最后web服务器把会它发送到你的web浏览器。
  简而言之，web服务器只是简单的通过响应(response)html页面来处理http请求(request)。
• 情景2:带应用程序服务器的web服务器
  情景2和情景1相同的是web服务器还是把响应(response)的产生委托(delegates)给脚本(译者注:服务器端(server -side)程序)。然而，你可以把查找定价的商业逻辑(business logic)放到应用程序服务器上。由于这种变化，此脚本只是简单的调用应用程序服务器的查找服务(lookup service)，而不是已经知道如何查找数据然后表示为(formulate)一个响应(response)。这时当该脚本程序产生html响应(response)时就可以使用该服务的返回结果了。
  在此情景中，应用程序服务器提供(serves)了用于查询产品的定价信息的商业逻辑。(服务器的)这种功能(functionality)没有指出有关显示和客户端如何使用此信息的细节，相反客户端和应用程序服务器只是来回传送数据。当有客户端调用应用程序服务器的查找服务(lookup service)时，此服务只是简单的查找并返回结果给客户端。
  通过从响应产生(response-generating)html的代码中分离出来，在应用程序之中该定价(查找)逻辑的可重用性更强了。其他的客户端，例如收款机，也可以调用同样的服务(service)来作为一个店员给客户结帐。相反，在情景1中的定价查找服务是不可重用的因为信息内嵌在 html页中了。
  总而言之，在情景2的模型中，在web服务器通过回应html页面来处理http请求(request)，而应用程序服务器则是通过处理定价和有效性(availability)请求(request)来提供应用程序逻辑的。
• 警告(caveats)
  现在，xml web services已经使应用程序服务器和web服务器的界线混淆了。通过传送一个xml有效载荷(payload)给服务器，web服务器现在可以处理数据和响应(response)的能力与以前的应用程序服务器同样多了。
  另外，现在大多数应用程序服务器也包含了web服务器，这就意味着可以把web服务器当作是应用程序服务器的一个子集(subset)。虽然应用程序服务器包含了web服务器的功能，但是开发者很少把应用程序服务器部署(deploy)成这种功能(capacity)(译者注:这种功能是指既有应用程序服务器的功能又有web服务器的功能)。相反，如果需要，他们通常会把web服务器独立配置，和应用程序服务器一前一后。这种功能的分离有助于提高性能(简单的web请求(request)就不会影响应用程序服务器了)，分开配置(专门的web服务器，集群(clustering)等等)，而且给最佳产品的选取留有余地。