构建高可用Linux服务器（第4版）.html.pdf

《构建高可用Linux服务器（第4版）.html.pdf》由会员分享，可在线阅读，更多相关《构建高可用Linux服务器（第4版）.html.pdf（179页珍藏版）》请在三一文库上搜索。

1、前言 运维工程师工作的演变 随着云计算的流行，运维工程师的工作性质在不断地发生变化，很多新的技能点和知识点需要掌握和学习。工作中，大家经常可以看到DevOps这个词汇。最近DevOps为什么这么火？跟最近两年云计 算的快速普及有很大的关系：云计算平台上的各种资源，从服务器到网络，再到负载均衡都是由API创建和操作的，这就意味着所有的资源都可以“软件定义”，这给各种自动化运维工具提供了一个非常好 的基础环境。而在传统的互联网行业，比如CDN行业，由于机器数量众多、网络环境错综复杂，故也需要由DevOps人员来设计工具，提供后端的自动化API，结合公司的CMDB资产管理系统，提供自动化 运维功能。

2、 我在公司的职务是高级运维开发工程师（DevOps）、系统架构师，主要工作是设计、实施及维护本公司的电子商务网站，以及核心业务的代码开发工作。相对于CDN分布式系统而言，公司的电子商 务网站没有节点冗余，对集群技术的要求更高。所以我前期将所有的网站应用都做了双机高HA，包括LVS/HAProxy+Keepalived和Nginx+Keepalived，以及DRBD+Heartbeat+NFS文件高可用，MySQL 数据库用的是DRBD双主多从架构，甚至Redis也使用了主从复制的架构设计。随着特殊业务的需求量越来越旺盛（比如定点抢红包活动），我也在网站的架构设计中引入了RabbitMQ消息队列

3、集群。后期 随着商业推广量的加大，网站流量、UV及并发日益增大，新机器上线也日益频繁，所以我采用了Fabric、Ansbile等自动化运维工具来管理线上机器，避免运维同事们的重复劳动。另外，由于电子商务网 站牵涉支付问题，所以对安全性的要求也非常高，我们平时都会从网络安全（包括硬件防火墙、Linux系统防火墙和WAF应用防火墙）、系统安全、代码安全和数据库安全这些方面着手，尽力避免一切影 响网站安全的行为。此外，我的工作职责还包括使用成熟的自动化工具（比如Ansible、Saltstack等），利用Python或Golang进行二次开发，根据实际工作需求，结合公司的CMDB系统，提供稳定的后端

4、 API，方便前端人员或资产人员进行调用，这样大家可以利用界面来完成自动化运维工作。工作虽然辛苦，但看到自己设计的后端API和网站能够稳定运行，心里还是很有成就感的，这也是我目前工作的主 要动力。 撰写本书的目的 从事系统集成、运维开发、架构设计方面的工作已经有十余年了，在工作期间，我曾有幸担任了一段时间的红帽RHCE讲师，在东北大学等高校推广红帽Linux系统。在教学过程中我发现，很多学生进 入企业后都无法胜任自己的工作，更谈不上正确规划自己的职业道路了。究其原因，一方面是因为企业的生产环境具有一定的复杂性和危险性；另一方面则是由于市场上入门书居多，缺乏能真正指导读者 解决实际问题的书籍。例

5、如，很多书籍都只给出了比较基础的操作及理论，而相对于线上环境，根本没有涉及如何安全操作才能避免误操，以及在PV、UV、并发、数据库压力和高并发环境下消息队列或 任务队列如何设计等相关话题。 之所以写这本书，一方面是想对自己这些年的工作进行一次系统的梳理和总结；另一方面是想将自己的经验和心得分享给大家，希望能帮助大家少走弯路。通过本书中介绍项目实践（包括Linux集群、 MySQL的高可用方案及Python自动化运维工具的使用）和线上环境的Shell脚本，帮大家迅速进入工作状态。书中所提供的Shell脚本和iptables脚本均来自于线上的生产服务器，大家均可以直接拿来用。 关于Linux集群的

6、项目实践和MySQL的高可用方案，大家也可以根据实际项目的需求直接采用，以此来设计公司的网站架构。 希望大家能通过本书掌握Linux的精髓，轻松而愉快地工作，从而提高自己的技术水平，也希望大家通过我分享的内容，了解运维工作的发展趋势，确定以后的学习目标。这是我非常希望看到的，也是 我写本书的初衷。 第4版与第3版的区别 本书是第4版，相对于前3版而言改动比较大，删除了不少过时的内容，增补了当前热门的技术知识点。另外，本书除了项目部署时采用的系统没有升级到CentOS 6.8 x86_64外，其他环境均为CentOS 6.8 x86_64。此外，在写作过程中采纳了读者针对上一版本提出的许多意见和

7、建议，同时修正了第3版的各种错误及其他问题。具体改动如下：删除了第3版中前3章的内容，增补了Vagrant虚拟化软件的应 用，并且重写了生产环境下的Shell脚本；删除了对分布式自动化部署管理工具Puppet的相关介绍，改用了Fabric自动化运维工具；删除了关于开源VPN在企业中部署的章节。附录部分增加了对现在流行 的GitLab应用及强大的编辑工具Sulbime Text3的快捷键方式操作的介绍。出第4版的原因是希望能将现在最流行的开源技术展现并分享给大家，增加大家的职业技能知识。 读者对象 本书的读者对象如下： 项目实施工程师； 系统管理员或系统工程师； 网络管理员或企业网管； 系统开发

8、工程； 高级开发人员。 如何阅读本书 本书的内容是对实际工作经验的总结，涉及大量的知识点和专业术语，建议经验不足的读者一定从第1章读起，本章内容相对来说比较基础。大家在学习过程中根据第1章的讲解进行操作，定会达到事 半功倍的效果。 推荐系统管理员和运维工程师们通篇阅读本书，并重点关注第2章、第4章、第5章、第7章和第8章的内容，这些都与运维工作息息相关的，建议大家多花些精力和时间，抱着一切从线上环境去考虑的 态度去学习。 对于网络管理员和企业网管来说，如果基础不是太扎实，建议先学习第1章和第2章的内容，然后将重点放在第7章和第8章。 对于项目实施工程师而言，由于大多数都是从事系统集成相关工作的

9、，因此建议顺序学习全书的内容，重心可以放在第5章和第6章。 对于高级开发人员来说，由于只需对系统有一个大概的了解，重点可以放在第1章、第3章和第4章。如果希望了解集群相关的知识体系，可学习第5章和第6章的内容。 大家可以根据自己的职业发展和工作需要选择不同的阅读顺序和侧重点，同时也可以对其他相关的知识点有一定的了解。 致谢 感谢我的家人，你们在生活上对我无微不至的照顾，让我有更多精力和动力去工作和创作。 感谢好友刘天斯和老男孩的支持和鼓励，闲暇之余和你们一起交流开源技术和发展趋势，也是一种享受。 感谢朋友刘鑫，是你花了大量时间和我一起研究和调试HAProxy+Keepalived。 感谢朋友胡

10、安伟，感谢你为本书提供的精美插图，并就Linux集群相关内容提出的许多宝贵的意见。 感谢机械工业出版华章公司的编辑杨福川和孙海亮，正是由于你们的信任、支持和帮助，我才能够如此顺利地完成全部书稿。 感谢热心的读者朋友们，没有大家的支持和鼓励，本书也不可能出到第4版。 感谢朋友三宝，感谢你在我苦闷的时候陪我聊天，感谢你这么多年来对我的信任和支持。 感谢在工作和生活中给予过我帮助的所有人，感谢你们，正是因为有了你们，才有了本书的问世。 关于勘误 尽管我花了大量时间和精力去核对文件和语法，但书中难免还会存在一些错误和纰漏，如果大家发现问题，希望可以反馈给我，相关信息可发到我的邮箱。尽管我无法 保证每一

11、个问题都会有正确的答案，但我肯定会努力回答和并且指出一个正确的方向。 如果大家对本书有任何疑问或想进行Linux的技术交流，可以访问我的个人博客，我会在此恭候大家。我的个人博客地址为http:/。另外，我在51CTO和CU社区的用户 名均为“抚琴煮酒”，大家也可以直接通过此用户名在社区内与我进行交流。 余洪春（抚琴煮酒） 第1章 Linux服务器的性能调优 作为一名高级系统架构设计师，每天都要处理系统方面的架构优化设计工作，比如电子商务系统、CDN大型广告平台和DSP电子广告系统运维方案的确定及平台架构的设计等，此外，还会涉及核心业 务的系统优化升级工作。在其中，系统的性能优化是一个非常有意义

12、的工作，也是一个不太容易的工作。性能优化要以系统的稳定性为第一原则，也要本着挖掘系统潜能的宗旨，在两者相互矛盾的时候， 以稳定为主。 1.1 网站架构设计相关 在学习系统优化之前，我们应该了解一下网站架构设计的相关专业知识，这样才能更好地优化系统性能，提升网站的架构设计能力。 1.1.1 评估网站性能涉及的专业名词术语 在开始其他内容之前，我们先学习几个相关的专业名词术语，这样便于后面内容的展开，也便于大家在工作中与其他同事交流。 1.PV（Page View） PV即访问量，中文翻译为页面浏览，代表页面浏览量或点击量，用户每刷新一次就会计算一次。PV的具体度量方法就是从浏览器发出一个对网络服

13、务器的请求（Request），网络服务器接到这个请求 后，会将该请求对应的一个网页（Page）发送给浏览器，从而产生一个PV。只要将请求发送给了浏览器，无论这个页面是否完全打开，下载是否完成，都会被计为1个PV。PV反映的是某网站页面的浏览 数，所以每刷新一次也算一个PV，就是说PV与UV（独立访客）的数量成正比，但PV并不是页面的来访者数量，而是网站被访问的页面数量。 2.UV（Unique Vistor） UV即独立访问，访问网站的一台电脑客户端为一个访客，如果以天为计量单位，程序会统计00：00至24：00这段时间内的电脑客户端，且相同的客户端只被计算一次。独立自然人访问，一个人访问 记

14、为一个UV，通过不同技术方法来记录，实际会有误差。如果企业内部通过NAT技术共享上网，那么出去的公网IP有且只有一个，这个时候在程序里面进行统计，也只能算是一个UV。 3.并发连接数（Concurrent TCP Connections） 当一个网页被浏览，服务器就会和浏览器建立连接，每个连接表示一个并发。如果当前网站页面包含很多图片，图片并不是一个一个显示的，服务器会产生多个连接同时发送文字和图片以提高浏览速 度。也就是说，网页中的图片越多，服务器的并发连接数越多，我们一般以此作为衡量单台Web机器的性能参数。现在Nginx在网站中的应用比例非常大，可以参考Nginx的活动并发连接数。 4.

15、QPS（Query Per Second） QPS即每秒查询率，是衡量一个特定查询服务器在规定时间内所处理流量多少的标准，在因特网上，作为域名系统服务器的机器性能通常用每秒查询率来衡量。对应Fetches/Sec，即每秒的响应请求 数，也是最大吞吐能力。对于系统而言，QPS数值是一个非常重要的参数，它是综合反映系统最大吞吐能力的衡量标准。它反映的不仅是Web层面的性能，还有缓存、数据库等方面的系统综合处理能力。 5.机房的网络质量评估 机房的网络质量可以参考下面3个标准： 1）稳定性。响应延迟，丢包率。测试方法：长时间的ping测试。测试工具有smoke-ping、mtr、ping2。 2）带

16、宽质量。测试TCP的下载速度以及最大TCP的下载速率。测试方法：get/其他下载测试。测试工具有webbench/iperf，也可使用云测试平台。 3）接入位置。接入路由设备离骨干网的位置，接入条数越少越好。测试方法：路由跟踪。测试工具有mtr/tracert等。 参考文档：https:/ 1.1.2 CDN业务的选项 如果自己的业务网站中含有大量的图片和视频类文件，为了加快客户端的访问速度，同时减缓核心机房的服务压力并提升用户体验，建议大家在网站或系统的前端采用CDN缓存加速方案。 CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的Inter

17、net中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可就近取得需要的内 容，提高用户访问网站的响应速度，从而提升用户体验。CDN缓存加速方案一般有几种方式： 租赁CDN：中小型网站直接买服务即可，现在CDN已经进入按需付费的云计算模式，可以准确计算性价比。 自建CDN：这种方案的成本较高，为了保证好的缓存效果，必须在全国机房布点，并且需要自建智能Bind系统。搭建大型网站时推荐采用此方案，一般专业的视频网站或图片网站会考虑采用此方 案。 1.1.3 IDC机房的选择 IDC机房的选择一般也有几种类型： 单电信IDC机房：这种业务模式比较固定，访问量也不是很大，适合新

18、闻类网站或政务类网站。如果网站的PV流量持续增加，建议后期采用租赁CDN的方式解决非电信用户访问网站速度过慢的问 题。 双线IDC机房：因为国内两大网络（电信和网通）之间存在互联互通的问题，所以电信用户访问网通网站或网通用户访问电信网站很慢，也因此产生了双线机房、双线服务器、双线服务器托管和双 线服务器租用服务。双线机房实际是一个有电信、网通、联通等任意两条线路接入的机房。通过双线机房内部路由器的设置以及BGP自动路由的分析，实现电信用户访问电信线路，网通用户访问网通线 路，即实现了电信网通的快速访问。 BGP机房：BGP（边界网关协议）是用来连接Internet的独立系统的路由选择协议。它是

19、Internet工程任务组制定的一个加强、完善、可伸缩的协议。BGP4支持CIDR寻址方案，该方案增加了Internet上 可用IP地址的数量。BGP是为取代最初的外部网关协议EGP设计的，它也被认为是一个路径矢量协议。采用BGP方案实现双线路互联或多线路互联的机房称为BGP机房。对于用户来说，选择BGP机房可以 实现网站在各运营商线路之间互联互通，使得所有互联运营商的用户访问网站都很快，也更加稳定，不用担心全国各地因线路带来访问速度快慢不一的问题，这也是传统双IP双线机房无法相比的优势。在 条件允许的情况下，选择服务器租用和服务器托管时尽量选择BGP机房，可以带给用户最优的访问体验。 现在云

20、计算服务也非常流行，目前首推的就是亚马逊云（AWS）和阿里云这两种云计算平台。 经过对业务需求的深入了解，我们在亚马逊云和阿里云之间选择了亚马逊云。 云计算服务提供的产品能让我们的研发团队专注于产品开发本身，而不是购买硬件、配置和维护硬件等繁杂的工作，还可以减少初始资金投入。我们主要使用亚马逊云的EC2/EBS/S3/Redshift服务产 品，其次，Amazon EC2主机提供了多种适用于不同案例的实例类型以供选择。实例类型由CPU、内存、存储和网络容量形成不同的组合，可让我们灵活地为其选择合适的资源组合。 云计算特别适合在某些日期或某些时段流量会激增的网站，如我们从事的DSP业务的bidd

21、er集群机器，用户会集中在某时段进行竞价，因此在这段时间内使用的instance数量可能是白天的几倍甚至几 十倍。也就是说，这个瞬间可能要开启很多实例处理，且处理完毕后立刻终止（EC2 Instance可以按照运行小时数进行收费）。 像笔者公司的线上系统，经常跑着很多特殊业务的Spot Instance（例如我们自行开发的爬虫系统），以小时计费，完成任务后立即终止Spot Instance，以此达到节约费用的目的。 使用竞标方式获取便宜的Instance，一般在有大量、便宜、短时间使用的需求时使用。 1.2 如何根据服务器应用来选购服务器 无论物理服务器是选用IDC托管还是AWS EC2云主机

22、（以下为了说明简单，统称为服务器），我们都要面临一个问题，那就是如何选择服务器的硬件配置。选购硬件配置时要根据我们的服务器应用需 求而定，因为我们无法通过一台服务器来满足所有的需求，并解决所有的问题。在设计网站的系统架构之前，我们应该从以下方面考虑如何选购服务器： 服务器运行什么应用。 需要支持多少用户访问。 需要多大空间来存储数据。 业务的重要性。 服务器网卡。 安全。 是否安排机架合理化。 服务器的价格是否超出预算。 1.服务器运行什么应用 这是首先需要考虑的问题，通常根据服务器的应用类型（也就是用途）决定服务器的性能、容量和可靠性需求。下面将按照负载均衡、缓存服务器、前端服务器、应用程序

23、服务器、数据服务器和 Hadoop分布式计算的常见基础架构进行讨论。 负载均衡端：除了网卡性能以外，它在其他方面对服务器的要求都比较低。如果选用LVS负载均衡方案，它会直接将所有的连接要求转给后端的Web应用服务器，建议选用万兆网卡；如果选用 HAproxy负载均衡器，由于它的运行机制跟LVS不一样，流量必须双向经过HAproxy机器本身，因此会对CPU的运行能力有所要求，建议选用万兆网卡；如果选用AWS EC2机器，推荐使用m3.xlarge实例类型 （m3类型提供计算、内存和网络资源的平衡，它是很多应用程序的良好选择）。另外，AWS官方也推出了负载均衡服务产品，即Elastic Load

24、Balancing，它具有DNS故障转移和Auto Scalling的功能。 缓存服务器：主要是Varnish和redis，对CPU及其他方面的性能要求一般，但在内存方面的要求较多。笔者曾为了保证预算，在双核（r3.large）机器上运行了4个redis实例，AWS官方也建议将此内存优 化型实例用于高性能数据库、分布式内存缓存、内存中分析、基因组装配和分析，以及SAP、Microsoft SharePoint和其他企业应用程序的较大部署。 应用服务器：因为它承担了计算和功能实现的重任，所以需要为基于Web架构的应用程序服务器（Application Server）选择足够快的服务器，另外，应用

25、程序服务器可能需要用到大量的内存，尤其是 基于Windows基础架构的Ruby、Python、Java服务器，这一类服务器至少需要使用单路至强的配置，我们线上的核心业务机器选用的是AWS c3.xlarge类型。至于可靠性问题，如果你的架构中只有一台应用服 务器，那肯定需要这台服务器足够可靠，此时RAID是绝对不能忽视的选项。但如果有多台应用服务器并设计了负载均衡机制，那么便拥有了冗余功能，那就不必过于担心上述问题了。 c3.xlagre EC2主机属于Compute optimized计算优化型，也就是CPU加强型。这种类型的CPU/内存比例较大，适合计算密集型业务。它包含c1和c3系列，除

26、了较旧的两个c1系列（c1.medium和 c1.xlarge）采用普通磁盘做实例存储以外，其他的（也就是c3系列）都以SSD做实例存储，其中最高档次的c3.8xlarge（32核心108个计算单元）的网络性能明确标注为10Gbps。c3系列被认为是最具性价比的类 型。 特殊应用：除了用于Web架构中的应用程序以外，如果你的服务器还要处理流媒体视频编码、服务器虚拟化、媒体服务器，或者作为游戏服务器（逻辑、地图、聊天等）运行，那同样会对CPU和内 存有一定的要求，至少要考虑四核以上的服务器。 公共服务：这里指的是邮件服务器、文件服务器、DNS服务器、域控服务器等。通常我们会部署两台DNS服务器互

27、相备份，域控主服务器也会拥有一台备份服务器（专用的或非专用的），所以无须 对于可靠性过于苛刻。而邮件服务器至少需要具备足够的硬件可靠性和容量大小，这主要是对邮件数据负责，因为很多用户没有保存和归档邮件数据的习惯，待其重装系统后，就会习惯性地到服务器上重 新下载相应的数据。至于性能问题，应该评估用户数量后再决定。另外，考虑到它的重要性，建议尽量选择稳定的服务器系统，比如Linux或BSD系列。 数据库服务器：数据库对服务器的要求是最高的，也最重要的。一般情况下，无论你使用的是MySQL、SQLServer还是Oralce，它都需要有足够快的CPU、足够大的内存、足够稳定可靠的硬件。因 此，可直接

28、采用Dell PowerEdge R710或HP 580G5，CPU和内存方面也要尽可能最大化，如果预算充分，建议采用固态硬盘做RAID 10，因为数据库服务器对硬盘的I/O要求是最高的。 Hadoop和Spark分布式计算：这里建议选用密集存储实例D2实例，它拥有高频率Intel Xeon E5-2676v3（Haswell）处理器、高达48TB的HDD本地存储、高磁盘吞吐量，并支持Amazon EC2增强 型联网。它适合大规模并行处理数据仓库、MapReduce和Hadoop分布式计算、分布式文件系统、网络文件系统、日志或数据处理等应用。 RabbitMQ集群：Rabbit消息中间件是基于

29、Erlang语言开发的，对内存的要求很高。这里建议选用r3.xlarge，它适合运行高性能数据库、分布式内存缓存、内存中分析、基因组装配与分析、Microsoft SharePoint以及其他企业应用程序。 更多关于AWS EC2实例类型的资料请参考：https:/ 2.服务器需要支持多少用户访问 服务器就是用来给用户提供某种服务的，所以使用这些服务的用户同样是我们需要考虑的因素，可以从下面几个具体的问题进行评估： 有多少注册用户。 正常情况下有多少用户会同时在线访问。 每天同时在线访问的最高峰值大概是多少。 一般在项目实施之前，客户会针对这些问题给出一个大致的结果，但我们要尽量设计得充分具体

30、，同时，还要对未来的用户增长做一个尽可能准确的预测和规划。因为服务器可能需要支持越来越多的 用户，所以在设计网站或系统架构时要让机器能够灵活地进行扩展。 3.需要多大空间来存储数据 这个问题需要从两个方面来考虑，一方面是有哪些类别的数据，包括操作系统本身占用的空间、安装应用程序所需要的空间以及应用程序产生的数据、数据库、日志文件、邮件数据等，如果网站是 Web 2.0的，还需计算每个用户的存储空间；另一方面是从时间轴上来考虑，这些数据每天都在增长，至少要为未来两三年的数据增长做个准确的测算，这需要软件开发人员和业务人员一起来提供足够的 信息。最后，我们将计算出来的结果乘以1.5左右的系数，方便

31、维护的时候做各种数据的备份和文件转移操作。 4.业务有多重要 这需要根据自身的业务领域来考虑，下面举几个简单的例子，帮助大家了解这些服务器对可靠性、数据完整性等方面的要求。 如果你的服务器是用来运行一个W6ordPress博客，那么，一台酷睿服务器，1GB的内存，外加一块160GB的硬盘就足够了（如果是AWS EC2主机，可以考虑t2.micro实例类型）。就算服务器出现了一 点硬件故障，导致几个小时甚至一两天不能提供访问，生活会照常继续。 如果你的服务器是用于测试平台的，那么就不会像生产环境那样对可靠性有极高的要求，你所需要做的可能只是完成例行的数据备份，若服务器宕机，只要能在当天解决完问题

32、就可以了。 如果是一个电子商务公司的服务器，运行着电子商务网站平台，当硬件发生故障而导致宕机时，你需要对以下“危言耸听”的后果做好心理准备：投诉电话被打爆、顾客大量流失、顾客要求退款、 市场推广费用打水漂、员工无事可做、公司运营陷入瘫痪状态、数据丢失。事实上，电子商务网站一般是需要36524小时不间断运行和监控的，且具有专人轮流值守，同时要有足够的备份设备以及每天的 专人检查。 如果是大型广告类或门户类网站，那么建议选择CDN系统。因为它具有提高网站响应速度、负载均衡、有效抵御DDOS攻击等特点，相对而言，每节点都会有大量的冗余。 这里其实只是简单讨论了业务对服务器硬件可靠性的要求。要全面解决

33、这个问题，不能只考虑单个服务器的硬件，还需要结合系统架构的规划设计。 在回答了以上问题后，接下来就可以决定下面这些具体的选项了。 （1）选择什么CPU 回忆一下上面关于“服务器运行什么应用”和“需要支持多少用户访问”两个方面的考虑，这将帮助我们选择合适的CPU。毫无疑问，CPU的主频越高，其性能也就更高，换而言之，两个CPU要比一 个CPU性能更好，至强（Xeon）也肯定比酷睿（Core）性能更强。但究竟怎样的CPU才是合适的呢？下面将为你提供一些常见情况下的建议。 如果业务刚刚起步，预算不是很充足，建议选择一款经典的酷睿服务器，这可以帮你节约大量成本。而且，以后可以根据业务发展的情况，随时升

34、级到更高配置的服务器。 如果需要在一台服务器上同时运行多种应用服务，例如基于LNMP架构的Web网站，那么一个单核至强（例如X3330）或新一代的酷睿I5（双核四线程）将是最佳的选择。虽然从技术的角度来说，这 不是一个好主意，但至少能够帮你节约一大笔成本。 如果服务器要运行MySQL或Oracle数据库，且目前有几百个用户同时在线，未来还会不断增长，那么你至少应该选择安装一个双四核服务器。 如果需要的是Web应用服务器，双四核基本就可以满足我们的要求了。 （2）需要多大的内存 同样，“服务器运行什么应用”和“需要支持多少用户访问”两方面的考虑也将帮助我们选择合适的内存容量。与CPU相比，笔者认

35、为内存（RAM）才是影响性能的最关键因素。因为在相当多正在运 行的服务器中，CPU的利用率一般为10%30%，甚至更低。但我们发现由于内存容量不够导致服务器运行缓慢的案例比比皆是，如果服务器不能分配足够的内存给应用程序，应用程序就需要通过硬盘接 口交换读写数据了，这将导致网站慢得令人无法接受。内存的大小主要取决于服务器的用户数量，当然也和应用软件对内存的最低需求和内存管理机制有关，所以，最好由你的程序员或软件开发商给出最 佳的内存配置建议。下面同样给出了一些常见应用环境下的内存配置建议： 无论是Apache或Nginx服务器，一般情况下Web前端服务器不需要配置特别高的内存，尤其是在集群架构中

36、，4GB的内存就已经足够了。如果用户数量持续增加，我们才会考虑使用8GB或更高的内 存。单Apache Web机器，在配置了16GB内存后，可以抗6000个并发链接数。 对于运行Tomcat、Resin、WebLogic的应用服务器，8GB内存应该是基准配置，更准确的数字需要根据用户数量和技术架构来确定。 数据库服务器的内存由数据库实例的数量、表大小、索引、用户数等决定，一般建议配置16GB以上的内存，笔者公司在许多项目方案中使用了24GB48GB的内存。 诸如Postfix和Exchange这样的邮件服务器对内存的要求并不高，1GB2GB就可以满足了。 还有一些特殊的服务器，需要为之配置尽可

37、能高的内存容量，比如配置有Varnish和Memcached的缓存服务器等。 若是只有一台文件服务器，1GB的内存可能就足够了。 事实上，由于内存技术在不断提高，价格也在不断降低，因此才得以近乎奢侈地讨论4GB、8GB、16GB这些曾经不可想象的内存容量。然而，除了花钱购买内存来满足应用程序的“贪婪”之外，系统 优化和数据库优化仍然是我们需要重视的问题。 （3）需要怎样的硬盘存储系统 硬盘存储系统的选择和配置是整个服务器系统里最复杂的一部分，需要考虑硬盘的数量、容量、接口类型、转速、缓存大小，以及是否需要RAID卡、RAID卡的型号和RAID级别等问题。甚至在一些高 可靠性高性能的应用环境中，

38、还需要考虑使用怎样的外部存储系统（SAN、NAS或DAS）。下面归纳一下服务器的硬盘Raid卡的特点： 如果是用做缓存服务器，比如Varnish或Redis，可以考虑用RAID 0； 如果是跑Nginx+FastCGI或Nginx等应用，可以考虑用RAID 1； 如果是内网开发服务器或存放重要代码的服务器，可以考虑用RAID 5； 如果是跑MySQL或Oracle等数据库应用，可以考虑用固态硬盘做RAID 5或RAID 10。 5.网卡性能方面的考虑 如果你的基础架构是多服务器环境，而且服务器之间有大量的数据交换，那么建议你为每台服务器配置两个或更多的网卡，一个用于对外提供服务，另一个用于内部

39、数据交换。因为现在项目外端都置 于防火墙内，所以很多时候单网卡就足够了。而比如LVS+Keepalived这种只用公网地址的Linux集群架构，对网卡的速率要求很高，建议大家选用万兆网卡。 如果我们采用的是AWS EC2云主机环境，单纯以EC2作为LVS或HAproxy意义不大。如果大家经常使用AWS EC2机器，应该注意到AWS将机器的网卡性能分成三种级别，即Low、Moderate、High， 那么这三个级别是什么情况呢？虽然AWS没有带宽限制，但是由于多虚拟机共享HOST物理机的网络性能和I/O性能，单个虚拟机的网络性能不是特别好度量，不过大概是这样：Low级别的是 20MBps，Mod

40、erate级别的是40MBps，High级别的能达到80MBps100MBps。从上面分析的情况可以得知，单台AWS EC2主机作为网站的负载均衡入口，容易成为网站的瓶颈。这个时候可以考虑使 用AWS提供Elastic Load Balancing的产品，它可以在云中的多个Amazon EC2实例间自动分配应用程序的访问流量，相当于将网站的流量分担到了多台机器上。它可以让我们实现更高水平的应用程序容 错性能，从而无缝提供分配应用程序流量所需的负载均衡容量。 6.服务器安全方面的考虑 由于目前国内的DDoS攻击是比较普遍，建议给每个项目方案和自己的电子商务网站配备硬件防火墙，比如Juniper、

41、Cisco等。当然，这个问题也是网站后期运营维护需要考虑的，这里只是想让大家有 个概念性的认识。此外，建议租赁CDN服务，这样万一不幸遭遇恶意的DDoS流量攻击，CDN能够帮助抵挡部分流量。 7.根据机架数合理安排服务器的数量 这个问题应该在项目实施前就准备好，选择服务器时应该明确服务器规格，即到底是1U、2U、还是4U，到底有多少台服务器和交换机，应该如何安排，毕竟机柜只有42U的容量。在小项目中这个问 题可能无关紧要，但在大型项目的实施过程中，这个问题就很突出了，我们应该根据现有或额定的机架数目确定到底应该选择多少台服务器和交换机。 8.成本考虑：服务器的价格问题 无论是公司采购时，还是在

42、项目实施过程中，这都是重要的问题。笔者的方案经常被退回，理由就是超出预算。尤其在一些小项目，预算更吃紧。之前笔者经常面对的客户需求是为证券类资讯网站设 计方案，只要求网站在周一至周日的早上九点至下午三点期间不出问题即可，并不需要做复杂的负载均衡高可用。所以这时候笔者会做成单Nginx或Haproxy，后面接两台Web应用服务器。可如果是做中 大型电子商务网站，在服务器成本上的控制就尤其重要了。事实上，我们经常出现的问题是，客户给出的成本预算有限，而我们的应用又需要比较多的服务器，这时候，我们不得不设计另外一套最小化成 本预算方案来折中处理。 以上8个方面就是我们在采购服务器时需要注意的因素，在

43、选择服务器的组件时要有所偏重，然后根据系统或网站架构来决定服务器的数量，尽量做到服务器资源利用的最大化。在控制方案成本的同 时，要做到最优的性价比。 1.3 硬件对Linux性能的影响 毋庸置疑，服务器的硬件会对Linux性能产生关键性的影响，其中，如服务器的CPU、内存及硬盘都会影响单机的性能。 1.CPU CPU是操作系统稳定运行的根本，CPU的速度与性能在很大程度上决定了系统整体的性能，因此，CPU数量越多、主频越高，服务器性能也就相对越好。就笔者目前跑的应用来看，确实有因为CPU性 能达不到要求造成业务出现问题的情况。 2.内存 内存的大小也是影响Linux性能的一个重要因素，内存太小

44、，系统进程将被阻塞，应用也将变得缓慢，甚至失去响应；内存太大，导致资源浪费。Linux系统采用了物理内存和虚拟内存两种方式，虚拟 内存虽然可以缓解物理内存的不足，但是占用过多的虚拟内存，应用程序的性能将明显下降，要保证应用程序的高性能运行，物理内存一定要足够大，但是过大的物理内存，会造成内存资源浪费，例如， 在一个32位处理器的Linux操作系统上，超过8GB的物理内存都将被浪费。因此，要使用更大的内存，建议安装64位的操作系统，同时开启Linux的大内存内核支持。由于处理器寻址范围的限制，在32位 Linux操作系统上，应用程序单个进程最大只能使用4GB的内存，这样一来，即使系统有更大的内存

45、，应用程序也无法做到物尽其用，解决的办法就是使用64位处理器，安装64位操作系统。在64位操作系 统下，可以满足所有应用程序对内存的使用需求，几乎没有限制。 3.磁盘I/O性能 磁盘的I/O性能直接影响应用程序的性能，在一个有频繁读写的应用中，如果磁盘I/O性能得不到满足，就会导致应用停滞。好在现今的磁盘都采用了很多方法来提高I/O性能，比如常见的磁盘RAID技 术。 RAID（磁盘阵形）通过将多块独立的磁盘（物理硬盘）按不同方式组合起来形成一个磁盘组（逻辑硬盘），从而提供比单个硬盘更高的I/O性能和数据冗余。通过RAID技术组成的磁盘组就相当于一个 大硬盘，用户可以对它进行分区格式化、建立文

46、件系统等操作，跟单个物理硬盘一模一样，唯一不同的是RAID磁盘组的I/O性能比单个硬盘要高很多，同时在数据的安全性方面也有很大提升。 根据磁盘组合方式的不同，RAID可以分为RAID 0、RAID 1、RAID 2、RAID 3、RAID 4、RAID 5、RAID 6、RAID 7、RAID 0+1、RAID 10等级别，常用的RAID级别有RAID 0、RAID 1、RAID 5、 RAID 10，这里进行简单介绍。 RAID 0：通过把多块硬盘粘合成一个容量更大的硬盘组，提高了磁盘的性能和吞吐量。这种方式成本低，要求至少两个磁盘，但是没有容错和数据修复功能，因而只能用在对数据安全性要求不

47、高的 环境中。 RAID 1：也就是磁盘镜像，通过把一个磁盘的数据镜像到另一个磁盘上，最大限度地保证磁盘数据的可靠性和可修复性，具有很高的数据冗余能力，但磁盘利用率只有50%，因而成本最高，多用在 保存重要数据的场合。 RAID 5：采用了磁盘分段加奇偶校验技术，从而提高了系统可靠性，RAID5读出效率很高，写入效率一般，至少需要3块盘。允许一块磁盘故障，而不影响数据的可用性。 RAID 10：把RAID 1和RAID 0技术结合起来就成了RAID 10，至少需要4个硬盘。此种方式的数据除分布在多个盘上外，每个盘都有其镜像盘，提供全冗余能力，同时允许一个磁盘故障，而不影响数 据可用性，并具有快

48、速读/写能力。 通过了解各个RAID级别的性能，可以根据应用的不同特性，选择适合自身的RAID级别，从而保证应用程序在磁盘方面达到最优性能。另外，固态硬盘（SSD）的磁盘IO性能比SAS磁盘优异很多，可以 考虑用SSD磁盘要代替普通的SAS磁盘。 4.网络宽带 Linux系统下的各种应用一般都是基于网络的，因此网络带宽也是影响性能的一个重要因素，低速、不稳定的网络将导致网络应用程序的访问阻塞，而稳定、高速的网络带宽可以保证应用程序在网络上 畅通无阻地运行。幸运的是，现在的网络一般都是千兆带宽或光纤网络，带宽问题对应用程序性能造成的影响也在逐步降低。 1.4 CentOS 6.8 x86_64最

49、小化安装后的优化 购买服务器以后要做的第一件事就是安装操作系统，这里推荐CentOS 6.8 x86_64，安装系统时要选择最小化安装（不需要图形），大家在用服务器时记得一个原则，系统安装的应用程序包越少，服 务器越稳定。至于服务器单机性能调优，应本着稳定安全的原则，尽量不要改动系统原有的配置（CentOS系统自身的文件和内存机制就很优秀），以下配置优化部分也适合Amazon Linux系统，大家可以 对比参考。 1.4.1 系统的基础优化 建议对CentOS 6.8系统做如下的基础优化，比如更新yum源提升速度，关闭不必要开启的服务等。 1.更新yum官方源 CentOS 6.8系统自带的更新源速度较慢，想必各位都有所感受。为了让CentOS 6.8系统使用速度更快的yum更新源，运维人员都会选择更换源，笔者一般会选择网易的更新源，详细步骤如下所示。 1）下载repo文件，命令如下所示： wget http:/mirrors