《云系统管理：大规模分布式系统设计与运营.html.pdf》由会员分享，可在线阅读，更多相关《云系统管理：大规模分布式系统设计与运营.html.pdf（315页珍藏版）》请在三一文库上搜索。
1、译者序 我们这一代人是幸运的，因为我们生在变革的年代，亲眼见证了蒸汽机发明以来最重要的技术成就计算机和互联网的 兴起。 在我们儿时，连机械化都是一种梦想，仅仅在十年之前，还无法想象一部手机就可以拥有过去大型计算机的能力，过去只有 在科幻小说中才能看到的情景，而今已经十分普遍。世界仿佛变得很小，一切都在我们的指尖之下，这就是科技的力量。 科技的发展帮助人类不断创造出更高质量、更低价格的产品，而产品之后的设计思想更为重要。我们今天拥有似乎无穷无尽 的网络资源和计算能力，不仅是因为硬件技术的发展，更为关键的是分布式计算的出现，它将非关即开的数字化设备模型化为传 统上的“模拟”系统，增进了系统的伸缩性
2、和可靠性。借助这一关键的思路，我们才有了今天724运行的各种线上系统，以及 引人遐想的“云计算”。 本书是几位供职于全球最大规模技术公司的专家的力作，全方位地介绍了大规模分布式系统的设计和运营，内容十分充实， 不仅介绍了有关分布式系统架构、应用和设计原则的理论知识，更有Google、Facebook等公司的成功案例分析，在附录中还 介绍了分布式系统的由来以及成熟度模型、设计文档等模板。尽管本书的主题是运营，但是其中系统阐述了运营与开发的关系， 包括DevOps等全栈融合思想，对于这种环境下的开发人员也极有教益。细细阅读，不仅能够了解许多分布式计算的关键概念和 思想，还可以深深体会技术的发展过程
3、，以及大规模网站运营中的经验和教训。在艰苦的翻译期间，我们的思想也受到了很大的 冲击，感受到技术发展对运营思想甚至整个企业经营思想的影响。掩卷之时也有一份担心，我们是否已经捕捉到原书的精髓，并 将其准确传达给读者？ 本书的翻译工作主要由姚军和陈志勇完成，徐锋、刘建林、吴兰陟、宁懿、姚红斌、白龙、陈美娜、谢志雄、方翊、陈霞、 林耀成、管军凯、吴玥、余骆、耿飞等人也为翻译工作做出了贡献。 译者 2016年3月 前言 下面的表述是否真实？ 1）最为可靠的系统是使用廉价、不可靠的组件构建的。 2）Google为数十亿用户服务所用的技术遵循的模式，与你处理数千名用户的系统所遵循的模式相同。 3）某种过程
4、的风险越大，你越应该尝试。 4）某些最重要的软件功能是用户从未发现的。 5）你应该随意选择一些机器，并关闭其电源。 6）Facebook在接下来六个月中所要发布的代码，其功能可能已经在你的浏览器中出现了。 7）每天多次更新软件所需要的人工很少。 8）随时待命并不一定是一种紧张、痛苦的体验。 9）你不应该监控机器是否启动。 10）运营和管理可以通过试验和证明的科学原理进行。 11）Google已经对僵尸攻击时的对策进行了演练。 这些表述都是真实的，当你读完本书，就会知道原因。 本书讲述的是大规模云服务（数百万甚至数十亿用户使用的基于互联网的服务）的构建和运行。每天，都有越来越多的企业 采用这些技
5、术，因此，本书是为所有人写的。 本书的目标读者是系统管理员和他们的经理。你无需计算机科学的背景，但是你应该有Unix/Linux系统管理、联网的经 验，以及操作系统的概念。 我们重点关注构建和运营组成“云”的服务，而不是指导云服务的使用。 云服务必须是可用的、快速的和安全的。考虑到云的规模，这将是独特而杰出的工程成就。因此，云规模服务设计不同于典 型的企业服务。可用性很重要，因为互联网是724开放的，用户处于各个时区。快速的重要性在于用户会因为慢速的服务而感 到沮丧，所以缓慢的服务会被更快的竞争者所取代。安全的重要性则在于，作为他人数据的托管者，我们义不容辞（而且负有法 律责任）地要保护人们的
6、数据。 这些要求是互相交织的。如果网站不安全，当然也就不可能可靠。如果网站速度不快，可用性也就不足。如果网站下线，当 然就不可能快速。 最明显的云规模服务是网站。但是，还有一个巨大的无形互联网访问服务生态系统，这些服务不是通过浏览器访问的。例 如，智能手机应用通过API调用访问云服务。 在本书余下的部分中，我们倾向于使用“分布式计算”而非“云计算”。云计算是一个营销用语，对不同的人有不同的含 义。分布式计算描述了使用许多机器（而非单一机器）提供应用程序和服务的一种架构。 本书介绍的是不受时间影响的基本原理及方法。因此，我们不推荐使用特定的产品或者技术。我们可以提供前5种最流行的 Web服务器、
7、NoSQL数据库或者持续构建系统的对比，但是如果这么做，本书就会在出版的那一刻过时。相反，我们讨论的是 选择这些系统时应该注意的特质，提供一种工作模式。这种方法的意图是帮助你在技术不断变化的漫长职业生涯中始终做好准 备。当然，我们将用具体的技术和产品说明我们的观点，但是不代表我们支持这些产品和服务。 本书有时看似理想化，这是故意为之。我们想为读者提供事物将会如何发展、该坚持什么原则的愿景，目的是更上一层楼。 关于本书 本书分为两个部分设计和运营。 第一部分捕捉我们在大规模、复杂、基于云的分布式计算系统设计上的想法。在引言之后，我们从下向上逐层介绍设计的每 个要素。我们从系统管理员（而非计算机科
8、学家）的角度介绍分布式系统，要运营一个系统就必须理解其内部原理。 第二部分描述如何运营这些系统。前面几章介绍最基本的问题。后面几章深入更为复杂的技术活动，然后是概要规划和将以 上要素组合起来的战略。 最后是附加材料，包括运营团队的评估系统、被歪曲的分布式计算历史、正文中提及的表单模板、建议阅读的材料以及其他 参考材料。 我们满怀兴奋之情介绍本系列书籍中的一个新特征：运营评估系统。这个系统由一系列评估活动组成，你可以用它们评估自 己的运营，找出需要改进的领域。评估问题和“搜索”建议可以在附录A中找到。第20章是该系统的说明。 致谢 没有我们所在社区及来自全球的帮助及反馈，本书就不可能出版。Dev
9、Ops社区慷慨地提供了帮助。 首先，我们要感谢我们爱人和家人：Christine Polk、Mike Chalup、Eliot和Joanna Lear。他们的爱和耐心成就了一切。 之所以我们能够看得更远，那是因为我们站在巨人的肩上。某些章节在很大程度上得到了下列人士的支持和建议：John Looney和Cian Synnott（第1章）；Marty Abbott和Michael Fisher（第5章）；Damon Edwards、Alex Honor和Jez Humble（第9章和第10章）；John Allspaw（第12章）；Brent Chapman（第15章）；Caskey Dicks
10、on和Theo Schlossnagle（第16章和17章）；Arun Kejariwal和Bruce Yan（第18章）；Benjamin Treynor Sloss（第19章）；Geoff Halprin（第20章和附录A）。 感谢Gene Kim“有策略”的启发和鼓励。有几十位人士帮助过我们有些人提供奇闻轶事，有些人审核某些部分或者整 本书。感谢他们所有人的公平方式是按照字母顺序排列，并预先向我们遗漏的所有人道歉：Thomas Baden、George Beech、 Raymond Blum、Kyle Brandt、Mark Burgess、Nick Craver、Geoff Dalga
11、s、Robert P.J.Day、Patrick Debois、Bill Duane、Paul Evans、David Fullerton、Tom Geller、Peter Grace、Elizabeth Hamon Reid、Jim Hickstein、Zachary Hueras、Matt Jones、Jennifer Joy、Jimmy Kaplowitz、Daniel V.Klein、Steven Levine、Cory Lueninghoener、Shane Madden、Jim Maurer、Stephen McHenry、Dinah McNutt、Scott Hazen Muel
12、ler、Steve Murawski、Mohit Muthanna、Lenny Rachitsky、Amy Rich、Adele Shakal、Bart Silverstrim、Josh Simon、Joel Spolsky、Desiree Sylvester、Win Treese、Todd Underwood、Nicole Forsgren Velasquez和Dave Zwieback。 最后（但并非不重要），感谢Addison-Wesley的所有人，特别要感谢Debra Williams Cauley将我们引见给Addison- Wesley，并在整个过程中为我们掌舵；感谢Michael
13、 Thurston对本书初稿的编辑和改进，使之更加完美；感谢Kim Boedigheimer的协调工作以及在我们惊慌的时候帮助我们保持镇静；感谢我们的LaTeX奇才Lori Hughes；感谢产品经理Julie Nahil；感谢文字编辑Jill Hobbs；还要感谢John Fuller和Mark Taub忍受我们的特殊要求！ 第一部分 设计：构建系统 第1章 分布式世界中的设计 概述分布式系统的设计。 第2章 为运营而设计 为了实现平稳运营而应该具备的软件功能。 第3章 选择服务平台 物理机和虚拟机，私有云和公共云。 第4章 应用程序架构 创建Web和其他应用程序的基本组件。 第5章 伸缩性
14、设计模式 扩增服务所用的基本组件。 第6章 弹性设计模式 创建可幸免于故障的系统的基本组件。 第二部分 运营：运行系统 第7章 分布式世界中的运营 分布式系统运行方式概述。 第8章 DevOps文化 DevOps文化、历史和实践简介。 第9章 服务交付：构建阶段 如何构建服务和准备投产。 第10章 服务交付：部署阶段 服务如何测试、批准和投产。 第11章 升级运行中的服务 如何在不停机的情况下升级服务。 第12章 自动化 创建工具和自动化运营工作。 第13章 设计文档 书面交流设计和意图。 第14章 随时待命 处理异常情况。 第15章 灾难准备 通过规划和实践强化系统。 第16章 监控基础知识
15、 监控术语和策略。 第17章 监控架构与实践 监控组件和方法。 第18章 容量规划 在需要之前规划并提供附加资源。 第19章 建立KPI 通过计量和反思科学地推动行为。 第20章 卓越运营 持续改善的战略。 第三部分 附录 附录A 评估 附录B 分布式计算和云的起源及未来 附录C 伸缩性术语和概念 附录D 模板和示例 附录E 推荐读物 后记 最后的一些想法。 参考文献 作者简介 托马斯A.利蒙切利（Thomas A.Limoncelli）是具有国际声誉的作家、演说家和系统管理专家。在Google NYC的7年中， 他曾经担任Blog Search（博客搜索）、Ganeti和各种内部企业IT服务
16、项目的SRE。他现在于Stack Exchange公司任SRE，该公 司主办ServerF和Stack-O网站。Thomas的第一份有报酬的系统管理工作是1987年在德鲁大学学习时获 得的，此后在小型和大型公司中任职，包括AT&T/Lucent贝尔实验室等。他的著名作品包括Time Management for System Administrators（OReilly）和The Practice of System and Network Administration，Second Edition（Addison- Wesley）。他的爱好包括草根行动，为此进行的工作在州乃至国家的层面上得到
17、公认。Thomas目前住在新泽西州。 斯特拉塔R.查卢普（Strata R.Chalup）已经领导和管理复杂IT项目多年，所担任的职务包括项目经理和运营主管。Strata曾 经撰写过管理方面的多篇论文，并且与许多团队合作，在各种志愿组织（包括BayLISA和SAGE）应用其管理技能。她于1983年 在波士顿的MIT开始管理VAX Ultrix和Unisys UNIX，在硅谷度过了.com年代，为iPlanet和Palm等客户构建互联网服务。2007 年，她与Tom和Christina一起编写了The Practice of System and Network Administration，S
18、econd Edition。Strata的 爱好包括学习新技术（如Arduino和各种2D CAD/CAM设备）和园艺。她住在加州的圣克拉拉县。 克里斯蒂娜J.霍根（Christina J.Hogan）在系统管理和网络工程上有20年的经验，足迹遍及美国硅谷、意大利和瑞士。她 在小型创业公司、中等规模技术公司和大型跨国公司获得了经验，多年担任安全顾问，客户包括eBay、Silicon Graphics和 SystemExperts。2005年，她和Tom因为合著的The Practice of System and Network Administration一书而分享了 SAGE杰出成就奖。她
19、拥有数学学士学位、计算机科学硕士学位、航空工程博士学位和法学文凭。她还曾在某F1车队担任空气动 力学家6年之久，并代表爱尔兰参加1988年国际象棋奥林匹克竞赛，现居瑞士。 引言 本书的目标是帮助你构建和运行最佳的云规模服务。什么是我们希望创建的理想环境？ 商业目标 简单地说，理想环境的最终结果是满足商业目标。这听起来有些乏味，但是实际上在全公司注目的焦点上切入，共同实现同 一个目标，是十分激动人心的。为此，我们必须理解商业目标，并且由此倒推出应该构建的系统。 满足商业目标意味着了解这些目标、制定计划实现它们并且消除沿途的障碍。定义良好的商业目标是可计量的，这些计量指 标可以自动化收集。自动化生
20、成的仪表盘使每个人了解进展，这种透明度能够增强信任。 下面是商业目标的一些例子： 通过网站销售我们的产品。 在99.99%的时间内提供服务。 每个月处理x百万笔订单，每月增长10%。 每周两次推出新功能。 在24小时内修复重大缺陷。 在我们的理想环境中，业务和技术团队以可预测和可靠的方式满足他们的目标和项目目标。因此，两类团队都信任其他团队 能够满足未来的目标。结果是，团队可以更好地制定计划。他们可以制定更为积极的计划，因为确信外部依赖不会失效。在这种 情况下，计划可以更加积极，这种方法会形成向上的螺旋，加速整个公司的进展，惠及每个人。 理想系统架构 理想的服务是在稳定的架构上构建的，它能够满
21、足当前的服务需求，并且在系统变得较为流行、接收更多流量时提供明显的 成长路径。这种系统对故障具备弹性，架构不会对故障感到意外，将其作为异常情况对待，而是接受硬件和软件故障作为信息技 术（IT）物性的一部分。结果是，这种架构包含应对故障的冗余和弹性特征，组件失效时系统仍可存活。 组成服务的每个子系统本身也是服务。所有子系统都可以通过应用程序编程接口（API）编程，因此，整个系统是互联子服 务的生态系统，这称作面向服务架构（SOA）。因为这些系统都使用相同的底层协议通信，具有管理上的一致性。每个子服务 相互松散耦合，因此这些服务可以独立伸缩、升级或者替换。 基础设施的几何结构采用电子方式描述，这种
22、电子描述由IT自动化系统阅读，然后在没有人为干预的情况下构建生产环境。 基于这种自动化，整个基础设施可以在其他地方重建，软件工程师利用自动化建立环境的微版本，供个人使用。质量和测试工程 师利用自动化创建用于系统测试的环境。 无论我们是使用物理机器还是虚拟机器，也不管是使用我们运行的还是由云提供商托管的数据中心，都能实现这种“基础架 构即代码”。对于虚拟机，显然有API可以用于准备新机器。但是，即使使用物理机器，从裸机到工作系统的整个流程也可以自 动化。在我们的理想世界中，自动化使组合物理和虚拟机器创建环境成为可能。开发人员可以从虚拟机构建环境，生产环境可能 包含物理和虚拟机的组合。额外容量的临
23、时和意外需求可能需要在一段时期内将生产环境扩展到一个或者多个云提供商。 理想的发行过程 理想的环境具备从代码开发到运营的平稳流程。传统上（不是在我们的理想环境中）顺序是这样的： 1）开发者在存储库中登记代码。 2）测试工程师将代码投入一系列测试。 3）如果所有测试通过，发行工程师将构建一个用于部署软件的“包”。大部分文件来自于源代码库，但是有些文件可能必 须来自其他来源，如图形部门或者文档编写者。 4）创建一个测试环境；如果没有采用“基础架构即代码”模式，这可能需要花费数周。 5）软件包被部署到测试环境中。 6）测试工程师进一步执行测试，重点是子系统之间的交互。 7）如果所有测试成功，则将代码
24、投入生产环境。 8）系统管理员升级系统同时寻找缺陷。 9）如果有缺陷，则将软件回滚。 人工进行上述步骤会招致许多风险，这是因为事先得具备合适的人员、上述步骤每次都以相同的方式完成、没有人会犯错误 且所有任务都会及时完成等假设。 错误、程序缺陷和偏差当然会发生因此缺陷会被传递到下一个阶段。发现错误时，工作流倒转，负责前一阶段的团队 成员被告知需要修复他们的问题。这意味着工作无法取得进展、损失了时间。 对某种高风险过程的典型反应是尽可能少做。因此就产生了尽可能少发行的念头，结果是“重大发行版本”每年只投放一两 次。 但是，将许多更改一次性批量进行，实际上造成了更大的风险。如何确保同时发布的几千项更
25、改在第一次尝试中全部取得成 功？我们做不到。因此，我们变得更加不情愿和恐惧变化。很快，变化几乎不可能发生，创新的脚步也停止下来。 在我们的理想环境中不是这样的。 在理想环境中，我们找到自动化的方法，消除软件构件、测试、发行和部署过程中的所有人工步骤。自动化精确、一致地执 行测试，避免缺陷传递到下一步骤。结果是，流程只有一个方向：向前。 我们的理想环境并不创建“重大发行版本”，而是创建“微发行版本”。通过进行多次部署，每次进行少量小规模更改，降 低了风险。实际上，我们每天可以进行100次部署。 1）当开发者登记代码时，有一个系统检测到这一事实，触发一系列自动化测试，这些测试验证代码的功能。 2）
26、如果这些测试通过，则开始构建软件包的过程，并且以完全自动化的方式运行。 3）新软件包的成功创建触发测试环境的创建。构建测试环境过去需要漫长的一周来连接电缆和安装机器，但是利用“基础 设施即代码”模式，整个环境可以在没有人工干预的情况下快速创建。 4）测试环境完成时，运行一系列自动化测试。 5）成功完成之后，新软件包投入生产环境试运行。试运行也是自动化的，但是有序且审慎。 6）某些系统首先升级并监视其故障。由于测试环境构建时使用与生产环境一样的自动化手段，两者之间的差别应该非常 小。 7）如果没有发现故障，新的软件包向越来越多的系统铺开，直到整个生产环境都被升级。 在我们的理想环境中，所有问题都
27、在投产之前捕捉到。也就是说，试运行并不是测试的一种形式，在此期间发生的故障基本 上都被排除。但是，如果确实发生故障，应该将其视为严重的问题，有理由停止新发行版本投产，直到根源分析完成。增加测试 以检测和预防未来发生同一故障，从而使系统随着时间推移变得更加坚固。 因为采用上述的自动化手段，发行工程、质量保证及部署的传统任务实际上不同于传统公司。许多个小时的人工被节约下 来，为改善打包系统、改善软件质量和调整部署过程留出了更多时间。换言之，人们将更多的时间花在已完成工作的改进上，而 不是工作本身。 对第三方软件也采用类似的过程。并不是所有系统都是自产或者提供源代码的。部署第三方服务和产品遵循类似的
28、发行、测 试、部署模式。但是，因为这些产品和服务是在外部开发的，它们需要的过程略有不同。发行新版本的频率可能较低，我们对每 个新发行版本的控制也较弱。这些组件需要的测试通常与功能、兼容性和集成有关。 理想的运营 一旦代码投产，运营目标就成为优先考虑的因素。软件被“仪表化”以便进行监控，收集处理来自外部用户和内部API事务 所花费的时间的相关数据，还要监控内存使用率等指标。收集这些指标以便根据数据做出运营决策，而非依靠猜测、运气或者希 望。这些数据需要存储许多年，以便用于预测未来的容量需求。 使用计量可以在内部问题还比较小、远不会造成用户可见中断的时候发现它们，我们可以在问题爆发之前修复。真正的
29、停机 事故很少见，在出现时进行深入的调查。当发现问题时，有某种过程确保它们的识别、处理和快速解决。 自动化系统检测问题并警告所有值班人员。我们采用轮流值班制度，使每个班次接收的警报次数可控。在任何时候都有一位 主要值班人员，他最先接收到警报，如果这个人没有及时响应，则向第二个人发出警报。值班安排提前准备充分，以便人员计划 假期、娱乐活动和个人时间。 对于如何处理各种可能产生的警报都有“剧本”。各种警报都有文档，从技术上描述出现的错误、对业务的影响和修复问题 的方法。这些“剧本”持续改进，任何值班人员都使用“剧本”修复问题，如果证明“剧本”不充足，将有精心定义的升级路 径，通常导向相关子系统的值
30、班人员。开发人员也是值班轮次的参与者，这样，他们就能够了解所构建系统在运营上的“痛 点”。 所有故障都有相应的对策，这些对策或人工激活，或自动激活。频繁激活的对策始终是自动化的。我们的监控系统检测过度 使用，因为这代表着较大的问题。监控系统收集工程师使用的内部指标数据，减少故障率、改进对策。 对策激活的次数越少，我们就越不确信它在下一次需要的时候是否有效。因此，不经常激活的对策必须通过有意造成故障而 定期、自动演练。正如我们要求学生进行消防演习，使每个人知道在紧急情况下怎么做一样，对于运营实践也要进行演练。这 样，我们的团队在实施对策时就变得很有经验，并对工作表现出自信。如果数据库故障切换过程
31、因为意外的依赖性而失效，最好 在周一上午十点的实操演习中研究，而不是在周日凌晨4点的停机事故中研究。 我们通过反复演练来减少风险，而不是回避问题。通过重复改善某些环节的技术术语是“实践”。我们坚信，实践造就完 美。 我们的理想环境是可以自动伸缩的。需要更多容量时，附加的容量来自于内部或者外部云提供者。当重新架构的解决方案比 简单地分配更多RAM、磁盘或者CPU更好时，我们的仪表盘将会指明。 系统的收缩也是自动化的。当系统过载或者降级时，我们不再用“503Service Unavailable”错误拒绝用户，相反，系 统会自动切换到使用更少资源的算法。带宽完全被占用了？启动低带宽版本的服务，显示
32、较少图形或者简化的用户界面。数据库 损坏了？只读版本的服务能够满足大部分用户的要求。 服务的每个功能都可以单独启用或者禁用。如果某个功能造成负面的结果，如安全漏洞或者意外地劣化性能，可以禁用它而 无须部署不同的软件发行版本。 当某项功能修订时，新代码不会淘汰旧功能。可以禁用新行为，展示旧行为。这在新用户界面投入试运行时特别有用。如果 某个发行版本既能生成旧的用户界面，又能生成新的界面，这样每个用户都可以单独禁用某个界面。这使我们可以从“早期访 问”用户那里得到反馈，在正式发行日，成功地为越来越大的用户群体启用新功能。如果发现性能问题，该功能很容易恢复或者 完全关闭。 在理想的环境中有卓越运营保
33、健法。就像刷牙一样，我们定期进行保持运营健康的活动。我们为如何处理每个对策、过程和 警报维护清晰的最新文档。对过于频繁出现的警报进行微调而不忽略。将未解决缺陷的数量保持在最低限度。停机事故之后会发 布事后剖析报告，提出未来系统改进的建议。任何“快速修复”之后都进行根源分析并实施长期修复。 最重要的是，开发人员和运营人员不将自己视为两个不同的团队。他们只是更大团队中的不同专业。有些人写的代码比其他 人多；有些人负责的运营项目比其他人多。所有人的共同责任是保持高的正常运行时间。为此，所有成员轮流值班（接听电话和 传呼）。开发人员在感受到运营的痛苦时，也会激发其改善影响运营的代码的积极性。如果运营人
34、员想要有建设性地与开发人员 协作，就必须理解开发过程。 现在，你已经知道了我们对理想环境的愿景，本书剩下的部分将解释创建和运营这种环境的方法。 第一部分 设计：构建系统 第1章 分布式世界中的设计 第2章 为运营而设计 第3章 选择服务平台 第4章 应用程序架构 第5章 伸缩性设计模式 第6章 弹性设计模式 第1章 分布式世界中的设计 构造软件设置有两种方法：一种是使其简单化，明显没有任何缺陷；另一种则是使其复杂化，没有明显的缺陷。 C.A.R.Hoare 1980年ACM图灵奖获奖演讲 Google搜索是如何工作的？Facebook动态时报（Timeline）是如何不断更新的？Amazon是
35、如何扫描不断增长的商品目 录，告诉你购买这个商品的人还买了袜子的？ 这是魔术吗？不，这就是分布式计算。 本章概述设计使用分布式计算技术的服务所需涉及的环节。这些技术是所有大型网站实现其规模、伸缩性、速度和可靠性时 使用的。 分布式计算是构建大型系统，将工作分配到许多台机器的艺术。相比之下，传统计算系统中由单台计算机运行提供服务的软 件，而客户端/服务器计算则由许多台机器远程访问一个集中化服务。在分布式计算中，通常有成百上千台机器一起工作，提供 大规模服务。 分布式计算在许多方面不同于传统计算。大部分不同之处是缘于系统本身的规模。分布计算可能涉及数百甚至数千台计算 机，为几百万用户提供服务，处理
36、数十亿（有时甚至达到数千亿）次查询。 必知术语 服务器：提供功能或者应用程序接口（API）的软件（不是一个硬件设备）。 服务：由许多服务器组成的用户可见系统或者产品。 机器：虚拟或者物理机器。 QPS：每秒查询次数。通常是每秒接收的点击数量或者API调用次数。 流量：查询、API调用或者其他发送给服务器的请求的统称。 高性能（Performant）：系统的性能符合（达到或者超过）设计要求。这个新词是“性能”（Performance）和“符 合”（Conformant）组合而成的。 应用编程接口（API）：管理服务器与其他机器通信方式的协议。 速度很重要。对于一个服务来说，快速、反应灵敏是竞争优
37、势。如果不能在200ms以内响应，用户会认为网站迟钝。网络 延时占据了这段时间的大部分，留给服务构建网页的时间很少。 在分布式系统中，故障是很正常的。硬件故障很少见，但是由于有数千台机器，故障就变得常见了。因此，必须假定故障的 存在，设计变通方法和预测故障的软件。故障是预期的一部分。 由于分布式系统的规模很大，运营必须实现自动化。人工完成涉及数百或者数千台机器的任务是不可思议的。自动化对于软 件的准备和部署、日常运营和故障处理都至关重要。 1.1 大规模的可见性 为了管理大型分布式系统，必须拥有系统的可见性。检查内部状态的能力称作内省（Introspection）是运营、调 试、调整和维修大型
38、系统所必需的。 在传统系统中，可以想象由一位对系统有足够认识的工程师密切注视关键组件或者根据经验“就能知道”哪里出了问题。在 大型系统中，这种水平的可见性必须通过设计提取信息并使其可见的系统主动地创建。没有任何个人或者团队能够人工监控所有 部件。 因此，分布式系统的组件必须能够产生足以描述系统中所发生情况的丰富日志。然后，这些日志汇集到一个中心位置，供收 集、存储和分析。系统可能记录很高级别的日志，如在用户每次购物、Web查询或者API调用时记录。也可能记录低级别信息， 如重要代码中每次函数调用的参数。 系统应该输出指标，它们应该统计感兴趣的事件，如特定API被调用多少次，并且提供计数器的访问
39、手段。 在许多情况下，可以使用特殊URL查看这些内部状态。例如，Apache HTTP Web服务器有一个“服务器状态”（Server- status）页面（http:/ 此外，分布式系统的组件往往评价自身健康状况并使这些信息可见。例如，某个组件可能有一个URL，可以输出系统是否已 为接收新请求做好了准备（OK）。在接收输出不是字节“O”和后续的字节“K”（包括完全没有响应）时，说明系统不打算接 收新请求。负载平衡器使用这一信息确定服务器是否健康，是否准备接收流量。当服务器正在启动和仍在初始化、正在关闭且不 再接收新请求但正在处理已提交请求时，会发送负面的响应。 1.2 简单的重要性 设计在能
40、够满足服务需求的同时尽可能保持简单是很重要的。随着时间的推移，系统成长且变得更加复杂。从已经很复杂的 系统入手，意味着一开始就处于不利地位。 出色的运营工作需要人们掌握系统的心智模型。在工作时，我们设想系统的运行模式，并使用这个心智模型跟踪系统的工作 方式，在系统不正常时进行调试。系统越复杂，掌握精确的心智模型就越困难。过度复杂的系统会造成这样一种情况：任何人在 任何时候都无法完全理解系统。 在The Elements of Programming Style中，Kernighan和Plauger（1978）写道： 调试的难度两倍于代码的编写。因此，如果你尽可能巧妙地编写代码，那么调试代码也就
41、不需要那么多的技巧。 对于分布式系统也是如此，为简化设计所花费的每一分钟，在运营的时候会一再得到回报。 1.3 构成 分布式系统由许多较小的系统组成。在本节中，我们详细研究3种基本构成模式： 具有多个后端副本的负载平衡器。 具有多个后端的服务器。 服务器树。 1.3.1 具有多个后端副本的负载平衡器 第一种构成模式是具有多个后端副本的负载平衡器。如图1.1所示，请求发送给负载平衡服务器。对于每个请求，服务器选 择一个后端（Backend）并将请求转发给它。响应返回给负载平衡服务器，由此转发给原始请求者。 图1.1 具有许多副本的负载平衡器 后端被称为副本（Replica）是因为它们互为对方的复
42、制品。请求发给任何一个副本都应该产生相同的响应。 负载平衡器必须始终知道哪些后端存活、正做好准备接收请求。负载平衡器向后端每秒发送数十次健康检查（health check）查询，如果健康检查失败，则停止向该后端发送请求。健康检查是简单的查询，应该快速执行并返回系统是否应该接收 流量的结果。 选择向哪个后端发送请求可能很简单，也可能很复杂。简单的方法通常以循环方式交替使用后端这种方法被称为循环 法（Round-robin）。但是，有些后端可能比其他后端更强大，因此在使用比例循环方案时更常被选择。更复杂的解决方案包 括最小负载（least loaded）方案。在这种方法中，负载平衡器跟踪每个后端的
43、负载，始终选择负载最小的后端。 选择最小负载的后端似乎很合理，但是简单地实施可能成为一场灾难。后端可能在真正过载很久之后才显示负载的信号。这 个问题的发生是因为难以准确地计量系统的负载，如果负载以最近与该服务器建立连接的数量计量，这一定义就忽视了有些连接 持续很长时间，而其他连接可能很快断开这一事实。如果计量基于CPU利用率，那么又忽视了输入/输出（I/O）过载。经常使 用的计量是最后5分钟的平均负载。这种计量有一个问题：作为平均值，它们反映的是过去而非现在。因此，负载的急剧和突然 增加在一段时间内不会反映到平均值上。 想象一个具有10个后端的负载平衡器，每个运行于80%的负载。此时加入一个新
44、后端，因为它是新加入的，所以没有任何 负载，从而成为最小负载后端。简单最小负载算法将把所有流量发送到这个新后端；其他10个后端没有接收任何流量。很快， 这个新后端就会陷入“泥沼”。没有一个后端能够处理之前由10个后端处理的流量，使用最近平均值意味着旧的后端将在几分 钟内发出高负载的虚假报告，而新的后端仍然虚假地报告低负载。 使用这种方案，负载平衡器在一段时间内将会认为新机器的负载低于其他的所有机器。在这种情况下，新机器可能过载以致 崩溃并重启，或者被试图纠正这一状态的系统管理员重启。当它重新投入服务时，又将重复上述循环。 这种情形使循环方法看上去很不错。稍复杂一些的最小负载方案采用某种控制，永
45、远不会连续向同一机器发送超过某一数量 的请求。这称作慢启动（slow start）算法。 简单最小负载算法引发的麻烦 如果不使用慢启动，负载平衡器会造成许多问题。一个著名的例子发生在2001年9月11日恐怖袭击当天的CNN.com网站。许 多民众试图访问CNN.com导致后端超载，其中一个后端崩溃，在恢复之后因为简单最小负载算法将所有流量发送给它而再度崩 溃。在它停机之后，其他后端也超载并崩溃。所有后端逐一超载、崩溃，然后接收所有流量而再次崩溃。 结果是，当系统管理员赶来了解情况时，该服务实际上已经无法使用。在他们进行防御时Web还是新生事物，没有人有处理 类似9月11日遇到的突发高流量的经验
46、。 CNN采用的解决方案是停止所有后端并同时启动它们，使它们全部显示零负载、接收相同的流量。 CNN团队后来发现，几天以前，他们的负载平衡器收到了一个软件升级，但是尚未安装，这个升级中加入了慢启动机制。 1.3.2 具有多个后端的服务器 第二种构成模式是具有多个后端的服务器。服务器接收请求，向许多后端服务器发送查询，合并所有应答组成最后的响应。 这种方法通常用在原始查询很容易分解为一些独立查询，并且这些查询可以组合形成最终应答的情况。 图1.2a展示了简单的搜索引擎如何在多个后端的帮助下处理查询。前端接收请求，并将请求转发给许多后端服务器。拼写检 查器发出应答信息，使搜索引擎能够建议替代的拼写
47、。Web和图像搜索后端以与查询相关的网站和图像列表作为应答。广告服 务器以与查询相关的广告应答。接收到应答之后，前端使用这些信息构造组成用户搜索结果页面的HTML，然后作为应答发送。 图1.2b展示了具有复制、负载平衡和后端的同一架构，使用相同原则，但是系统可以更好地伸缩并在故障时存活。 图1.2 这个服务由一个服务器和许多后端组成 这种构成有许多优势。后端并行完成自己的工作。不必等待一个后端处理结束，就可以开始处理下一个应答。系统的耦合很 松散，一个后端失效时，页面仍然可以通过填入默认信息或者将该区域留空来构造。 这种模式还能够进行某种相对复杂的延迟管理。假定这个系统预期在200ms或者更短
48、的时间内返回结果。如果一个后端因 为某种原因而处理缓慢，前端不用等待它。如果它花费10ms就可以构成并发送结果HTML，在190ms时，前端可以放弃缓慢的 后端，用所具有的信息生成页面。这种管理延迟时间预算的能力非常强大，例如，如果广告系统缓慢，搜索结果可以不显示任何 广告。 更清楚一点说，“前端”和“后端”这两个术语是视角的问题。前端向后端发送请求，后端以某种结果应答。服务器既可能 是前端也可能是后端。在前一个例子中，服务器对Web浏览器来说是后端，对拼写检查服务器来说是前端。 这一模式有许多变种。每个后端可以复制，以增加容量或者弹性。缓存也可以在多个级别上完成。 扇出（fan out）这一
49、术语指的是一个查询造成许多新查询，每个查询对应一个后端的事实。查询“扇出”到单独的后端， 而应答按照设置“扇入”到前端，组合为最终结果。 任何扇入的情况都有拥塞的危险。小的查询往往可能造成大的响应，因此扇出时使用的少量带宽往往不足以承受扇入。这可 能造成网络连接拥塞和服务器过载。如果查询和响应是一致的，或者偶然有大规模响应，那么很容易设计具有合适网络数量和服 务器容量的系统。困难的是当出现突然、不可预测的大规模应答爆发的时候，有些网络设备专门设计为在突发流量时动态供给更 多缓冲区空间，以处理这种状况。 同样，后端也可以限制自身的速率，避免一开始就造成上述情况。最后，前端可以通知后端减速，控制发出的新查询数，或 者实施紧急措施更好地处理洪泛，管理自身的拥塞。最后一种选项在第5章中讨论。 1.3.3 服务器树 另一种基本构成模式是服务器树（Server Tree），正如图1.3所示，在这种方案中，许多服务器相互协作，其中之一作为树 根，下方是父服务器，树的底部是叶子服务器（在计算机科学中，树是上下颠倒的）。这种模式一般用于访问大的数据集（语料 库）。语料库很大，任何机器都无法容纳，因此每个叶子服务器存储整个