1.3 如何根据服务器应用选购服务器
无论物理服务器是选用IDC托管还是AWS EC2云主机（以下为了简略说明，将它们统称为服务器），我们都要面临一个问题，那就是选择服务器的硬件配置，选购硬件配置时要根据服务器的应用需求而定。因为只通过一台服务器是无法满足所有的需求，并解决所有的问题的。在设计网站的系统架构之前，应该从以下方面考虑如何选购服务器：
服务器要运行什么应用。
需要支持多少用户访问。
需要多大空间来存储数据。
业务有多重要。
服务器网卡方面的考虑。
安全方面的考虑。
机架安排是否合理化。
服务器的价格是否超出了预算。
1.服务器运行什么应用
这是选购服务器时首先需要考虑的问题，通常是根据服务器的应用类型（也就是用途），来决定服务器的性能、容量和可靠性需求。下面将按照负载均衡、缓存服务器、前端服务器、应用程序服务器、数据服务器和Hadoop分布式计算的常见基础架构来讨论。
负载均衡端：除了网卡性能以外，其他方面对服务器的要求比较低，如果选用的是LVS负载均衡方案，那么它会直接将所有的连接要求都转给后端的Web应用服务器，因此建议选用万兆网卡。如果选用的是HAProxy负载均衡器，由于它的运行机制跟LVS不一样，流量必须双向经过HAProxy机器本身，因此对CPU的运行能力会有要求，也建议选用万兆网卡。如果选用的是AWS EC2机器，则推荐使用m3.xlarge实例类型（m3类型提供计算、内存和网络资源的平衡，因此是很多应用程序的良好选择）。另外，AWS官方也推出了负载均衡服务产品，即Elastic Load Balancing，它具有DNS故障转移和Auto Scalling的功能。
缓存服务器：主要是Varnish和redis，对CPU及其他方面的性能要求一般，但在内存方面的要求会尽量多些。笔者曾为了保证预算，在双核（r3.large）机器上运行了4个redis实例，AWS官方也建议将此内存优化型实例应用于高性能数据库、分布式内存缓存、内存中分析、基因组装配和分析，以及 SAP、Microsoft SharePoint 和其他企业级应用程序的较大部署。
应用服务器：由于它承担了计算和功能实现的重任，因此需要为基于Web架构的应用程序服务器（Application Server）选择足够快的服务器，另外应用程序服务器可能需要用到大量的内存，尤其是基于Windows基础架构的Ruby、Python、Java服务器，这一类服务器至少需要使用单路至强的配置；笔者公司线上的核心业务机器选用的AWS c3.xlarge类型。至于可靠性问题，如果你的架构中只有一台应用服务器，那这台服务器肯定要足够可靠才行，RAID是绝对不能被忽视的选项。但如果有多台应用服务器，并设计了负载均衡机制，具有冗余功能，那就不必过于担心了。
c3.xlarge EC2主机属于计算优化型（Compute Optimized），也就是CPU加强型。这种类型的CPU/内存比例比较大，适合于计算密集型业务，它包含c1和c3系列。其实例除了较旧的两个c1系列（c1.medium和c1.xlarge）是采用普通磁盘作为实例存储以外，其他的（也就是c3系列的）全部都以SSD作为实例存储，其中最高档次的c3.8xlarge（32核心108个计算单元）的网络性能明确标注为10G bit/s，c3系列被认为是最具性价比的类型。
特殊应用：除了用于Web架构中的应用程序之外，如果服务器还要处理流媒体视频编码、服务器虚拟化、媒体服务器，或者作为游戏服务器（逻辑、地图、聊天）运行，那么对CPU和内存的需求同样会比较高，至少要考虑四核以上的服务器。
公共服务：这里指的是邮件服务器、文件服务器、DNS服务器、域控服务器等。通常会部署两台DNS服务器以互相备份，域控主服务器也会拥有一台备份服务器（专用的或非专用的），所以对于可靠性，无须过于苛刻。至于邮件服务器，至少需要具备足够的硬件可靠性和容量大小，这主要是对邮件数据负责，因为很多用户没有保存和归档邮件数据的习惯，待其重装系统后，就会习惯性地到服务器上重新下载相应的数据。至于性能问题，则应评估用户数量后再做决定。另外，考虑到它的重要性，建议尽量选择稳定的服务器系统，比如Linux或BSD系列。
数据库服务器：数据库对服务器的要求也是最高、最重要的。无论你使用的是MySQL、SQL Server还是Oracle，一般情况下，都需要有足够快的CPU、足够大的内存、足够稳定可靠的硬件。可直接采用DELL PowerEdge R710或HP 580G5，CPU和内存方面也要尽可能最大化，如果预算充分，建议用固态硬盘做RAID 10，因为数据库服务器对硬盘的I/O要求是最高的。
Hadoop分布式计算：这里建议选用密集存储实例—D2实例，它拥有高频率 Intel Xeon E5-2676v3（Haswell）处理器、高达48TB的本地存储、具备高磁盘吞吐量，并支持 Amazon EC2 增强型联网。它适合于大规模并行处理数据仓库、MapReduce和Hadoop分布式计算、分布式文件系统、网络文件系统、日志或数据处理等应用。
更多关于AWS EC2的实例类型请参考：https://aws.amazon.com/cn/ec2/instance-types/。
2.服务器需要支持多少用户访问
服务器就是用来给用户提供某种服务的，所以使用这些服务的用户同样是我们必须考虑的因素，可以从下面几个具体的方面进行评估：
有多少注册用户。
正常情况下有多少用户会同时在线访问。
每天同时在线访问的最高峰值大概是多少。
一般在项目实施之前，客户方面会针对这些问题给出一个大致的结果，但设计要尽量更充分和具体，同时，还要对未来的用户增长做一个尽可能准确的预测和规划，因为服务器可能会支持越来越多的用户，所以在进行网站或系统架构设计时要让机器能够灵活地扩展。
3.需要多大空间来存储数据
关于这个问题需要从两个方面来考虑，一方面是有哪些类别的数据，包括：操作系统本身占用的空间，安装应用程序所需要的空间，应用程序所产生的数据、数据库、日志文件、邮件数据等，如果网站是Web 2.0的，还要计算每个用户的存储空间；另一方面是从时间轴上来考虑，这些数据每天都在增长，至少要为未来两三年的数据增长做个准确的预算，这就需要软件开发人员和业务人员一起来提供充分的信息了。最后将计算出来的结果乘上1.5左右的系数，以方便维护的时候做各种数据的备份和文件转移操作。
4.我的业务有多重要
这需要根据自身的业务领域来考虑，下面举几个简单的例子，帮助大家了解这些服务器对可靠性、数据完整性等方面的要求：
如果服务器是用来运行一个WordPress博客的，那么，一台酷睿处理器的服务器、1GB的内存，外加一块160GB的硬盘就足够了（如果是AWS EC2主机，可以考虑t2.micro实例类型）。就算服务器出现了一点硬件故障，导致几个小时甚至一两天不能提供访问，生活也会照常继续。
如果服务器是用作测试平台的，那么就不会如生产环境那样对可靠性有极高的要求，所需要的可能只是做好例行的数据备份即可，若服务器宕机，只要能在当天把问题解决掉就可以了。
如果是一家电子商务公司的服务器，运行着电子商务网站平台，当硬件发生故障而导致宕机时，你需要对以下“危言耸听”的后果做好心理准备：投诉电话被打爆、顾客大量流失、顾客要求退款、市场推广费用打水漂、员工无事可干、公司运营陷入瘫痪状态、数据丢失。事实上，电子商务网站一般是需要365×24小时不间断运行和监控的，而且要有专人轮流值守，并且要有足够的备份设备，每天还要有专人负责检查。
如果是大型广告类或门户类网站，那么建议选择CDN系统。由于它具有提高网站响应速度、负载均衡、有效抵御DDoS攻击等特点，相对而言，每个节点都会有大量的冗余。
这里其实只是简单地讨论下业务对服务器硬件可靠性的要求。要全面解决这个问题，不能只考虑单个服务器的硬件，还需要结合系统架构的规划设计。
在回答了以上问题后，接下来就可以决定下面这些具体的选项了。
（1）选择什么CPU
回忆一下上面关于“服务器运行什么应用”和“需要支持多少用户访问”两个方面的考虑，这将帮助我们选择合适的CPU。毫无疑问，CPU的主频越高，其性能也就越高；两个CPU要比一个CPU来得更好；至强（Xeon）肯定比酷睿（Core）的性能更强。但究竟怎样的CPU才是最合适的呢？下面提供了一些常见情况下的建议：
如果业务刚刚起步，预算不是很充足，建议选择一款经典的酷睿服务器，这可以帮你节约大量的成本。而且，以后还可以根据业务发展的情况，随时升级到更高配置的服务器。
如果需要在一台服务器上同时运行多种应用服务，例如基于LNMP架构的Web网站，那么一个单核至强（例如X3330）或新一代的酷睿I5（双核四线程）将是最佳的选择。虽然从技术的角度来说，这并不是一个好主意，但至少能节约一大笔成本。
如果服务器要运行MySQL或Oracle数据库，而且目前有几百个用户同时在线，未来还会不断增长，那么至少应该选择安装一个双四核服务器。
如果需要的是Web应用服务器，双四核基本就可以满足要求了。
（2）需要多大的内存
同样，“服务器运行什么应用”和“需要支持多少用户访问”两方面的考虑也将有助于我们选择合适的内存容量。相比于CPU，笔者认为内存（RAM）才是影响性能的最关键因素。因为在很多正在运行的服务器中，CPU的利用率一般都在10%～30%之间，甚至更低。但由于内存容量不够而导致服务器运行缓慢的案例比比皆是，如果服务器不能分配足够的内存给应用程序，那么应用程序就需要通过硬盘接口缓慢地交换读写数据了，这将导致网站慢得令人无法接受。内存的大小主要取决于服务器的用户数量，当然也和应用软件对内存的最低需求和内存管理机制有关，所以，最好由程序员或软件开发商给出最佳的内存配置建议。下面同样给出了一些常见应用环境下的内存配置建议：
无论是Apache还是Nginx服务器，一般情况下Web前端服务器都不需要配置特别高的内存，尤其是在集群架构中，4GB的内存就已经足够了。如果用户数量持续增加，我们才会考虑使用8GB或更大的内存。单Apache Web机器，在配置了16GB的内存后，可以抗6000个并发链接数。
对于运行Tomcat、Resin、WebLogic的应用服务器，8GB内存应该是基准配置，更准确的数字需要根据用户数量和技术架构来确定。
数据库服务器的内存由数据库实例的数量、表大小、索引、用户数量等来决定，一般建议配置16GB以上的内存，笔者公司在许多项目方案中使用了24GB到48GB的内存。
诸如Postfix和Exchange这样的邮件服务器对内存的要求并不高，1GB～2GB就可以满足了。
还有一些特殊的服务器，需要为之配置尽可能大的内存容量，比如配置有Varnish和Memcached的缓存服务器等。
若是只有一台文件服务器，1GB的内存可能就足够了。
事实上，由于内存技术在不断进化，价格也在不断降低，因此才得以近乎奢侈地讨论4GB、8GB、16GB这些曾经不可想象的内存容量。然而，除了花钱购买内存来满足应用程序的“贪婪”之外，系统优化和数据库优化仍然是我们需要重视的问题。
（3）需要怎样的硬盘存储系统
硬盘存储系统的选择和配置是整个服务器系统里最复杂的一部分，需要考虑硬盘的数量、容量、接口类型、转速、缓存大小，以及是否需要RAID卡、RAID卡的型号和RAID级别等问题。甚至在一些高可靠性高性能的应用环境中，还需要考虑使用怎样的外部存储系统（SAN、NAS或DAS）。下面将服务器的硬盘RAID卡的特点归纳一下：
如果是用作缓存服务器，比如Varnish或redis，则可以考虑用RAID 0。
如果是跑Nginx+FastCGI或Nginx等应用，则可以考虑用RAID 1。
如果是内网开发服务器或存放重要代码的服务器，则可以考虑用RAID 5。
如果是跑MySQL或Oracle等数据库应用，则可以考虑用固态硬盘做RAID 5或RAID 10。
5.网卡性能方面的考虑
如果基础架构是多服务器环境，而且服务器之间有大量的数据交换，那么建议为每台服务器配置两个或更多的网卡，一个用来对外提供服务，另一个用来做内部数据交换。由于现在项目外端都置于防火墙内，所以许多时候单网卡就足够了；而比如LVS＋Keepalived这种只用公网地址的Linux集群架构，有时可能只需要一块网卡即可。建议大家选用万兆网卡。另外，建议交换机至少也要选择千兆网卡级别的。
如果采用的是AWS EC2云主机环境，单纯以EC2作为LVS或HAProxy意义不大。如果经常使用AWS EC2机器，应该会注意到AWS将机器的网卡性能分成了3个级别，即Low、Moderate、 High，那么这3个级别分别是什么情况呢？虽然AWS没有带宽限制，但是由于多虚拟机共享HOST物理机的网络性能和I/O性能，单个虚拟机的网络性能也不是特别好度量，不过大概情况是这样的：Low级别的是20M bit/s，Moderate级别的是40M bit/s，High级别的能达到80M bit/s～100M bit/s。从上面的分析情况可以得知，单台AWS EC2主机作为网站的负载均衡入口，容易成为网站的瓶颈。这个时候可以考虑使用AWS提供的Elastic Load Balancing产品，它可以在云中的多个Amazon EC2 实例间自动分配应用程序的访问流量（大家注意到没，相当于它将网站的流量分担到了多台机器上）。它可以实现更高水平的应用程序容错性能，从而无缝地提供分配应用程序流量所需的负载均衡容量。除了提供负载均衡常见的功能之外，它还具有Auto Scalling功能，关于Auto Scalling的详细介绍，可参见AWS官方文档。
6.服务器安全方面的考虑
由于目前国内的DDoS攻击还是比较普遍的，因此建议给每个项目方案和自己的电子商务网站配备硬件防火墙，比如Juniper、Cisco等硬件防火墙。当然了，这个问题也是网站后期运营维护需要考虑的，这里只是想让大家有个概念性的认识。此外，建议租赁CDN服务，这样万一不幸遭遇恶意的DDoS流量攻击，CDN还能帮助抵挡部分恶意流量，核心机房的业务不至于在很短的时间内就会崩溃。
7.根据机架数合理安排服务器的数量
这个问题应该在项目实施前就处理好了的，选择服务器时应该明确服务器的规格，即到底是1U、2U还是4U的，到底有多少台服务器和交换机，应该如何安排，毕竟机柜只有42U的容量。在小项目中这个问题可能无关紧要，但在大型项目的实施过程中，这个问题就很突出了。我们应该根据现有或额定的机架数目确定到底应该选择多少台服务器和交换机。
8.成本考虑：服务器的价格问题
无论是在公司采购时，还是在项目实施过程中，成本都是非常重要的问题。笔者的方案经常被退回，理由就是超出预算。尤其对于一些小项目，预算更吃紧。之前笔者经常面对的客户需求是为证券类资讯网站设计方案，只要求周一至周日的上午九点至下午三点网站不出问题即可，并不需要做复杂的负载均衡高可用。所以面对这种需求，笔者会将单Nginx或HAProxy设计成负载均衡，后面接两台Web应用服务器作为简单集群架构。如果是做中大型电子商务网站，那么在服务器成本上的控制就尤其重要了。事实上，我们经常面对的问题是，客户给出的成本预算有限，而实际应用又需要比较多的服务器，这时候，就不得不另外设计一套最小化成本预算方案来折中处理。
以上8个方面是我们在采购服务器时应该要注意的因素，在选择服务器的组件时要有所偏重，然后根据系统或网站架构来决定服务器的数量，尽量做到服务器资源利用的最大化。在控制方案成本的同时，要做到最优的性价比。
