作者：侯杰
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
混沌工程：Netflix系统稳定性之道试读：
内容简介
在一个由很多微服务组成的分布式系统中，我们永远难以全面掌握发生什么事件会导致系统局部不可用，甚至全面崩溃。但我们却可以尽可能地在这些不可用的情况发生之前找出系统中的脆弱点。本书介绍了Netflix的工程师团队是如何根据多年实践经验主动发现系统中脆弱点的一整套方法。这套方法现在已经逐渐演变成计算机科学的一门新兴学科，即“混沌工程”。通过一系列可控的实验和执行实验的原则，混沌工程将揭示出分布式系统中随时发生的各类事件是如何逐步导致系统整体不可用的。
本书既适合研发、测试人员用来了解如何构建健壮的系统，也适合软件架构师用来了解设计创建高可用微服务体系的前沿方法，同时更适合在大型互联网或技术组织中专门负责系统稳定性的工程团队阅读。
©2017 by Casey Rosenthal,Lorin Hochstein, Aaron Blohowiak, Nora Jones, Ali Basiri,Simplified Chinese Edition, jointly published by O’Reilly Media, Inc. and Publishing House of Electronics Industry, 2019. Authorized translation of the English edition, 2017 O’Reilly Media, Inc., the owner of all rights to publish and sell the same.
All rights reserved including the rights of reproduction in whole or in part in any form.
本书简体中文版专有出版权由O’Reilly Media, Inc. 授予电子工业出版社。未经许可，不得以任何方式复制或抄袭本书的任何部分。专有出版权受法律保护。
版权贸易合同登记号 图字：01-2019-4197
图书在版编目（CIP）数据
混沌工程：Netflix系统稳定性之道 /（美）凯西·罗森塔尔（Casey Rosenthal）等著；侯杰译. —北京：电子工业出版社，2019.8
书名原文：Chaos Engineering
ISBN 978-7-121-36351-1
Ⅰ.①混… Ⅱ.①凯… ②侯… Ⅲ.①分布式计算机系统－系统工程 Ⅳ.①TP338.8
中国版本图书馆CIP数据核字（2019）第071011号
责任编辑：刘恩惠
印 刷：
装 订：
出版发行：电子工业出版社
北京市海淀区万寿路173信箱 邮编100036
开 本：787×1092 1/32 印张：3.75 字数：72千字
版 次：2019年8月第1版
印 次：2019年8月第1次印刷
定 价：45.00元
凡所购买电子工业出版社图书有缺损问题，请向购买书店调换。若书店售缺，请与本社发行部联系，联系及邮购电话：（010）88254888，88258888。
质量投诉请发邮件至zlts@phei.com.cn，盗版侵权举报请发邮件至dbqq@phei.com.cn。
本书咨询联系方式：010-51260888-819，faq@phei.com.cn。
O’Reilly Media, Inc.介绍
O’Reilly Media通过图书、杂志、在线服务、调查研究和会议等方式传播创新知识。自1978年开始，O’Reilly一直都是前沿发展的见证者和推动者。超级极客们正在开创着未来，而我们关注真正重要的技术趋势——通过放大那些“细微的信号”来刺激社会对新科技的应用。作为技术社区中活跃的参与者，O’Reilly的发展充满了对创新的倡导、创造和发扬光大。
O’Reilly为软件开发人员带来革命性的“动物书”；创建第一个商业网站（GNN）；组织了影响深远的开放源码峰会，以至于开源软件运动以此命名；创立了Make杂志，从而成为DIY革命的主要先锋；公司一如既往地通过多种形式缔结信息与人的纽带。O’Reilly的会议和峰会集聚了众多超级极客和高瞻远瞩的商业领袖，共同描绘出开创新产业的革命性思想。作为技术人士获取信息的选择，O’Reilly现在还将先锋专家的知识传递给普通的计算机用户。无论是通过书籍出版、在线服务或者面授课程，每一项O’Reilly的产品都反映了公司不可动摇的理念——信息是激发创新的力量。业界评论“O’Reilly Radar博客有口皆碑。”
——Wired“O’Reilly凭借一系列（真希望当初我也想到了）非凡想法建立了数百万美元的业务。”
——Business 2.0“O’Reilly Conference是聚集关键思想领袖的绝对典范。”
——CRN“一本O’Reilly的书就代表一个有用、有前途、需要学习的主题。”
——Irish Times“Tim是位特立独行的商人，他不光放眼于最长远、最广阔的视野并且切实地按照Yogi Berra的建议去做了：‘如果你在路上遇到岔路口，走小路（岔路）。’回顾过去，Tim似乎每一次都选择了小路，而且有几次都是一闪即逝的机会，尽管大路也不错。”
——Linux Journal序
要设计良好的系统需要考虑很多因素，比如可靠性、安全性、可扩展性、可定制化、可伸缩性、可维护性、用户体验等。为了更高效地支撑业务发展，越来越多的企业选择基于云服务或云原生理念来构建平台。采用新思路和新技术必然会带来系统架构和组织结构的变革，引入风险因素。如何通过实验证明生产环境下的分布式系统在面对失控条件的时候依然具备较强的“可观测性”和故障恢复能力呢？这就是混沌工程要解决的问题。
为了提升研发效率、支撑未来业务发展，2008年淘宝完成了服务化拆分和改造。伴随着应用数量的激增，多起因为不合理依赖导致的可用性故障发生了。作为保障高可用的技术团队，2011年我们开始尝试使用故障注入的方法来验证和治理系统的依赖问题，并在故障模拟实现、自动化验证、环境隔离、流量制造等方面进行了多次方案升级，沉淀了一套自动化的依赖治理方案。2016年，为了更真实地验证系统的容错设计和组织响应问题的能力，我们开始尝试在生产环境中进行故障场景演练。通过几年的发展，线上故障演练已经覆盖了大部分核心业务，提前发现了很多系统、工具、流程方面的问题。
也许很多人听说过Netflix的Chaos Monkey，但是大多数人对于混沌工程的概念还是比较模糊的。随着2017年本书的英文版面世，这种状况得到了改观。书中凝聚了第一批混沌工程师的智慧和经验，从建立稳定状态的假设、用多样的现实世界事件做验证、在生产环境中进行实验、自动化实验以持续运行、最小化爆炸半径五个角度对混沌工程进行抽象和概括，详细地阐述了混沌工程的演进和实践原则。书中的每条原则都既传递了一种思想，也代表着一套工具产品的设计思路。结合阿里巴巴在依赖治理、故障演练方面的实践积累，更能体会到每条原则的精妙。
近两年，混沌工程发展得很快，2017年被收录到ThoughtWorks的技术雷达中，2018年成为CNCF（Cloud Native Computing Foundation）的一个技术领域，越来越多的企业开始计划引入混沌工程。作为混沌工程的早期实践者和推动者，有三点经验与大家分享：
第一，引入混沌工程，需要建立进行面向失败设计（可以使系统暴露出已有问题的设计）和拥抱失败的技术文化。
在思想上要认识到混沌工程的核心是通过引入一些风险变量去暴露已有问题，而不是创造问题。在恰当的时间和可控的爆炸半径下进行实验，有助于问题的发现和处理，降低潜在故障带来的影响。
传统的基础设施对稳定性和健壮性有非常高的要求，虽然降低变更频率可以减少故障，但这不是解决问题的根本方法。随着各项服务被迁移到云上，基础设施的管理被转移给云厂商负责，上层业务更需要做好面向失败设计才可以应对可能存在的极端情况。
第二，实施混沌工程，需要定义一个清晰可衡量的目标。
混沌工程的业务价值并不适合用过程指标（比如模拟了多少种实验场景、发起多少次实验等）来衡量，需要配合其他稳定性手段一起来衡量。比如，前期可以选择对历史故障进行复现，确保故障改进的有效性；中期可以选择监控发现率，验证故障发现能力和监控的完备程度；随着实施混沌工程的经验越来越丰富，后期可以考虑引入一些复杂的MTTR（Mean Time To Restoration）度量指标，比如故障的“发现-定位-恢复”时长这种综合性指标。
第三，推广混沌工程，要在控制风险的前提下不断提升效率。
越贴近生产环境的实验，结果越真实，同时风险也越大。大家可以先从一些简单的场景开始尝试，逐渐增加对系统和组织的信心。实验准备比实验执行更重要，混沌工程不是故障注入测试，要明确定义系统稳定状态和终止条件。
混沌工程是一种实践思想，本身不绑定任何技术或工具。不过在进行规模化推广和实施时，从真实性、开发成本、运维效率的角度考虑，还是建议复用一些成熟的开源组件或商业工具。
减少问题的最好方法就是让问题经常性地发生，通过不断重复失败过程并找出解决方案，来持续提升系统的容错能力和弹性。混沌工程作为一门新兴学科，还处于一个定义和被定义的过程。如果你对混沌工程感兴趣，愿意去了解和实践混沌工程，非常推荐你从阅读本书开始行动。周洋（花名：中亭）阿里巴巴高可用架构团队高级技术专家开源项目ChaosBlade发起人2019.4
译者序
软件服务于人类的历史，历经了从单机软件在本地运行，到复杂系统通过网络提供服务的发展历程。软件的功能和质量每向前发展一步，都伴随着更多新的组成部分的加入。为了更好地服务于更多用户，进行规模更大、更复杂的运算，软件系统的能力需要不断进化升级，小型软件开始一步一步演化发展为大型分布式复杂系统。在软件系统变强的同时，越来越多的组成部分被加入系统，复杂性也在随之逐步增加。
每个软件从业者从写下第一行代码开始，就一刻不停地在和软件中的错误做斗争。开发和维护（修复缺陷、确保资源充足等保障软件运行的活动）是一对伴随软件运行而产生的双生子。热爱从零到一开发软件是开发者的天性，看着自己编写的软件完美运行，为其他人提供服务，一直是驱动开发者前进的动力。为了更快更好地开发软件，我们不断改进开发方法和软件架构，但是开发者在使用新的方法和更复杂的架构时，往往会低估潜在的风险。
近年来，随着系统架构逐渐向微服务架构演化，开发效率以及系统扩展性大幅提高。但同时，系统的复杂性也随之逐渐增长到了一个拐点，传统的测试方法已经不能全面理解和覆盖系统所有可能的行为，测试的有效性被大打折扣。我们通过各种测试、SRE、DevOps、金丝雀发布、蓝绿部署、预案、故障演练等方法，希望能够防患于未然。但服务规模不断增长，服务之间的依赖性所带来的不确定性也呈指数级增长。在这样的服务调用网中，任何一环出现的正常或异常的变化，都有可能对其他服务造成类似蝴蝶效应一般的影响。
软件系统自身复杂度的激增、开发者在引入复杂性的同时对风险的低估和忽视，是系统可用性面临的两大挑战。
为了应对这两大挑战，Netflix选择了一条不同寻常的路。从混乱猴子开始，Netflix为应对不确定性的领域带来了一种全新的思维方式——主动出击。这种主动出击的思维方式衍生出的一套实践方法，被称为混沌工程（Chaos Engineering），它旨在从根本上改变开发者应对软件缺陷和故障的思维方式。在此之前，我们期望通过一系列的测试验证手段，尽最大的可能确保在线上运行的系统没有缺陷和故障。而混沌工程的理念认为这既不现实，也不符合系统自然发展的规律。混沌工程提倡我们首先要正面接受系统一定会存在缺陷，并且一定会时不时地发生故障的事实；然后，要求我们通过一系列实验找出可能发生问题的风险点，进而在不断加固系统的同时，促使开发者在开发软件时必须选择将防御性内建在系统中。
混沌工程的理论，建构于塔勒布在《反脆弱》一书中所阐述的思想之上，即系统如何在不确定性中获益。在接受“系统越复杂，越脆弱”的事实之后，让系统在每一次失败中获益，然后不断进化，这是混沌工程的核心思想。在实践中，混沌工程提倡用一系列实验来真实地验证系统在各类故障场景下的表现，通过频繁地进行大量实验，既使得系统本身的反脆弱性持续增强，也让开发者对系统越来越有信心。这个信心同时也是系统高速迭代，占尽市场先机的一个前提因素。
各个行业都涌现出了很多基于混沌工程应对上述两大挑战的实践案例。译者所从事的汽车金融行业是一个长链条，重流程，涉及获客、风控、审批、资金流转、贷后管理等多个环节的复杂业务体系。任何差错都有可能造成故障及问题数据的蔓延，轻则导致各种程度的业务不可用，重则可能会造成重大资损（资产损失）。传统的各类方法已经无法保障这样一个大规模系统的可用性和正确性，因此我们在2018年下半年开始采用混沌工程的思想，实践了若干方法，目前看来已经初见一些成效。在混沌工程原则的指导下，我们为实施线上实验开发了实验组的控制功能，从而可以将线上实验的影响控制在最小的范围，即最小化爆炸半径。这为我们在线上放心进行实验提供了基础保障。举一个线上实验的例子：我们通过切断对第三方存储服务的依赖，验证了备用存储服务是否能够无缝接管。第一次执行实验的时候，我们发现虽然在移动端上传的图片可以成功存储在备用存储空间里，但是在业务链条的末端有个别读取服务却没有能够正确地从备用存储空间中获取到该图片。实验只影响了一小部分流量，快速修复后，实验可以进一步在满流量的情况下运行。接下来，通过每天自动运行这样的实验，我们可以确保任何后续对系统的变更都不会引入新的系统行为盲点。因为我们会每天自动运行大量实验，开发者不得不在编码时思考“我的代码如何在这些混沌实验场景下存活下来”，并逐步提高质量，形成正向循环。
混沌工程目前还是一个新兴的学科，它为软件工程行业带来了全新的思维方式。相信越来越多的实践和工具，会一步步释放这个学科的能量，吸引更多的实践者。团队或组织可以在任何时间点引入混沌工程的理念，这是一门实践性的学科，所以现在就和我们一起，开启你的混沌之旅吧！
译者介绍
侯杰，美利金融集团技术副总裁，TGO鲲鹏会会员，毕业于南京大学；曾就职于IBM中国、IBM澳大利亚和iClick（爱点击）；在多个行业的大型组织机构中负责过研发和管理工作，拥有十多年大规模分布式信息系统的设计、研发和实施经验。
技术审校者
周洋，花名中亭，阿里巴巴高可用架构团队高级技术专家，混沌工程布道师，开源项目ChaosBlade发起人。具有多年高可用保障、产品研发和系统架构经验，曾担任2015年双11稳定性负责人。目前负责高可用技术云化输出，并担任应用高可用服务（AHAS）及集团突袭演练负责人。第一部分 混沌工程介绍混沌工程是一门新兴的技术学科，它的初衷是通过实验性的方法，让人们建立复杂分布式系统能够在生产中抵御突发事件能力的信心。——Principles of Chaos Engineering
只要你有过在生产环境中实际运行一个分布式系统的经历，你就应该清楚，各种不可预期的突发事件是一定会发生的。分布式系统天生包含大量的交互、依赖点，可能出错的地方数不胜数。硬盘故障，网络不通，流量激增压垮某些组件……我们可以不停地列举下去。这都是每天要面临的常事，任何一次处理不好就有可能导致业务停滞、性能低下，或者其他各种无法预料的异常行为。
在一个复杂的分布式系统中，我们单靠人力并不能够完全阻止这些故障的发生，而应该致力于在这些异常行为被触发之前，尽可能多地识别出会导致这些异常的、在系统中脆弱的、易出故障的环节。当我们识别出这些风险时，就可以有针对性地对系统进行加固、防范，从而避免故障发生时所带来的严重后果。我们能够在不断打造更具弹[1]性系统的同时，建立对运行高可用分布式系统的信心。
混沌工程正是这样一套通过在系统基础设施上进行实验，主动找出系统中的脆弱环节的方法学。这种通过实验验证的方法显然可以为我们打造更具弹性的系统，同时让我们更透彻地掌握系统运行时的各种行为规律。[2]
混沌工程的应用可以简单到在STG环境的某个实例上运行kill [3]-9来模拟一个服务节点的突然宕机，也可以复杂到在线上（生产环境中）挑选一小部分（但足够有代表性的）流量，基于这部分流量按照一定的规则或频率自动运行一系列实验。混沌工程在Netflix的发展历程2008年Netflix开始将服务从数据中心迁移到云上，之后就开始尝试在生产环境中开展一些系统弹性的测试。过了一段时间，这个实践过程才被称为混沌工程。最早被大家熟知的是“混乱猴子”（Chaos Monkey），因为其在生产环境中随机关闭服务节点而“恶名远扬”。进化成为“混乱金刚”（Chaos Kong）之后，这些之前获得的小规模益处被扩大到非常大。规模的扩大得益于一个叫作“故障注入测试”（Fault Injection Test，FIT）的工具。我们随后确立了混沌工程的若干原则，用于将这个实践进行规范并学科化，同时推出了混沌工程自动化平台，使得我们能够在微服务体系架构上7×24小时不间断地自动运行混沌工程实验。在开发这些工具和进行实践的过程中，我们逐渐意识到，混沌工程并非是简单地制造服务中断等故障。当然，尝试破坏系统和服务很简单，但并不是全都可以有建设性地、高效地帮我们发现问题。混沌工程存在的意义在于，能让复杂系统中根深蒂固的混乱和不稳定性浮出水面，让我们可以更全面地理解这些系统中的固有现象，从而有根据地在分布式系统中实现更好的工程设计，来不断提高系统弹性。
本书介绍混沌工程的主要概念，以及如何在组织中实践这些概念和经验。也许我们开发的相关工具只适用于Netflix自身的业务和系统环境，但我们相信工具背后的原则可以被更广泛地应用于其他领域。[1]译者注：系统应对故障、从故障中恢复的能力。[2]译者注：STG环境是系统发布流程中的多个环境之一。完整的部署环境一般包括开发环境、测试环境、STG模拟或登台环境（Staging Environment）及生产环境。STG环境一般被认为是最接近生产环境的部署环境，通常STG环境可能会使用一些生产环境的服务或数据库。[3]译者注：kill -9是一个Linux命令，kill命令用来终止一个进程，加上-9参数表示强制终止进程。第1章 为什么需要混沌工程
混沌工程是一种通过实验探究的方式来让我们理解系统行为的方法。就像科学家通过实验来研究物理和社会现象一样，混沌工程通过实验来了解特定的系统。
如何使用混沌工程提高系统弹性呢？混沌工程通过设计和执行一系列实验，帮助我们发现系统中潜在的、可以导致灾难的或让我们的用户受损的脆弱环节，推动我们主动解决这些环节存在的问题。和现在各大公司主流的被动式故障响应流程相比，混沌工程向前迈进了一大步。混沌工程和测试的区别
混沌工程、故障注入和故障测试在侧重点和工具集的使用上有一些重叠。举个例子，Netflix的很多混沌工程实验的研究对象都是基于故障注入来引入的。混沌工程和其他测试方法的主要区别在于，混沌工程是发现新信息的实践过程，而故障注入则是基于一个特定的条件、[1]变量的验证方法。
例如，当你希望探究复杂系统会如何应对异常时，会对系统中的服务注入通信故障，如超时、错误等，这是一个典型的故障注入场景。但有时我们希望探究更多其他非故障类的场景，如流量激增、资源竞争条件、拜占庭故障（例如性能差或有异常的节点发出错误的响应、异常的行为、对调用者随机返回不同的响应等）、非计划中的或消息内容非正常组合的处理等。如果一个面向公众用户的网站突然出现流量激增的情况，从而产生了更多的收入，那么我们很难将这种情况称为故障，但我们仍然需要探究清楚系统在这种情况下会如何变现。和故障注入类似，故障测试是通过对预先设想到的可以破坏系统的点进行测试，但是并不能去探究上述这类更广阔领域里的、不可预知的、但很可能发生的事情。
我们可以描述一下测试和实验最重要的区别。在测试中，我们要进行断言：给定一个特定的条件，系统会输出一个特定的结果。一般来说，测试只会产生二元的结果，即验证一个结果是真还是假，从而判定测试是否通过。严格意义上来说，这个实践过程并不能让我们发掘出系统未知的或尚不明确的认知，它仅仅是对已知的系统属性可能的取值进行测验。而实验可以产生新的认知，而且通常还能开辟出一个更广袤的对复杂系统的认知空间。整本书都在探讨这个主题——混沌工程是一种帮助我们获得更多的关于系统的新认知的实验方法。它和已有的功能测试、集成测试等测试已知属性的方法有本质上的区别。
一些混沌工程实验的输入样例：
·模拟整个云服务区域或整个数据中心的故障。[2]
·跨多实例删除部分Kafka主题（Topic）来重现生产环境中发生过的问题。
·挑选一个时间段，针对一部分流量，对其涉及的服务之间的调用注入一些特定的延时。
·方法级别的混乱（运行时注入）：让方法随机抛出各种异常。
·代码插入：在目标程序中插入一些指令，使得故障注入在这[3]些指令之前先运行。[4]
·强迫系统节点间的时间彼此不同步。
·在驱动程序中执行模拟I/O错误的程序。
·让一个Elasticsearch集群的CPU超负荷。
混沌工程实验的可能性是无限的，根据不同的分布式系统架构和不同的核心业务价值，实验可以千变万化。混沌工程绝不是Netflix的专属
我们在和其他公司或组织的专业人士讨论混沌工程时，经常收到的一个反馈是：“哇哦，听起来非常有意思，但是我们的系统功能和业务与Netflix完全不同，所以这东西应该不适合我们吧。”
虽然我们提供的特定的案例都来自于我们在Netflix的经验，但是书中所描述的基本原则并不针对任何特定的组织，所介绍的实验设计指南也没有基于任何特定的架构或者工具集。在第9章里，我们会讨论混沌工程的成熟度模型，读者可以采用这个模型，评估自己将要或者已经开始实施的混沌工程实践的初衷是否合理、切入点是否正确，以及下一步应该朝哪个方向继续开展实践。
最近的一次混沌工程社区日聚集了来自不同组织的混沌工程实践者，参会者来自Google、Amazon、Microsoft、Dropbox、Yahoo!、Uber、cars.com、Gremlin Inc.、加州大学圣克鲁兹分校、SendGrid、北卡罗来纳州立大学、Sendence、VISA、New Relic、Jet.com、Pivotal、ScyllaDb、GitHub、DevJam、HERE、Cake Solutions、Sandia National Labs、Cognitect、Thoughtworks和O’Reilly出版社。在本书中，你会找到来自各行各业（金融、电子商务、航空航天等）的关于混沌工程实践的案例和工具。
混沌工程也同样适用于传统行业，如大型金融机构、制造业和医疗机构。对于金融交易所依赖的复杂系统，有大型银行正在使用混沌[5]工程来验证其交易系统是否有足够的冗余。对于生死攸关的医疗系统，在美国，混沌工程在许多方面被当作模型应用在了临床试验系统中，从而形成了美国医疗验证的黄金标准。横跨金融、医疗、保险、火箭制造、农业机械、工具制造领域，无论是数字巨头企业还是创业公司，混沌工程作为一门复杂系统改进学科，正在寻找它在各行各业中的立足点。飞机启动失败？在伊利诺伊大学香槟分校，Naira Hovakimyan和她的研究团队把混沌工程[6]用在了喷气式战斗机上。团队由两名B-52飞行员、一名F-16飞行员、两名飞行测试工程师和两名安全飞行员组成。在试飞过程中，飞机被注入了几种不同的故障配置。这些配置甚至包括飞机重心的突然变化和空气动力学参数的变化！能否在故障发生时重新构建机体爬升动力学参数以及其他会导致故障的配置对于团队来说是极大的挑战。在制定并亲身实践了一系列故障情景之后，团队最终能够自信地认定该系统对于低空飞行是安全的。实施混沌工程的前提条件
在判断你的团队是否已经准备好实施混沌工程之前，你需要回答这样一个问题：你的系统是否已经具备一定的弹性来应对真实环境中的一些异常事件，像某个服务异常、网络闪断或瞬间延迟提高这样的事件。
如果你的答案是明确的“No”，那么在实施本书中讨论的各项原则之前，你需要先做一些准备工作。混沌工程非常适合用于暴露生产系统中未知的脆弱环节，但如果你很确定一个混沌工程实验会导致系统出现严重的故障，那么进行这样的实验是没有任何意义的。你需要先解决这个问题，然后再回到混沌工程，在进行混沌工程实验之后，你要么能继续发现更多未知的脆弱点，要么能对系统真实的弹性水平更有信心。
实施混沌工程的另一个前提条件是配套监控系统，你需要用它来判断系统当前的各项状态。如果无法对系统行为进行观察，你就无法从实验中得出有效的结论。由于每个系统都是独一无二的，因此当混沌工程暴露出系统脆弱环节时，如何更好地进行根源分析，我们留给读者作为练习。混乱猴子（Chaos Monkey）2010年年底，Netflix向全世界推出了“混乱猴子”。这家流媒体服务提供商在几年前就开始陆续将服务迁移到了云上。之前数据中心中的垂直扩展导致了很多单点故障，其中一些故障甚至导致了当时的DVD业务大规模中断。云服务不光带来了水平扩展的机会，同时把无差别的重度基础设施运维工作转移给了可靠的第三方。数据中心本来就会时不时地发生一些小故障，然而在云服务的水平扩展架构中，提供同一个服务的节点数大幅增加，发生这类故障的概率也大幅增加。在数以千计的服务节点里，几乎可以确定的是，时不时地就会有节点出现异常或者掉线。需要有一种全新的方法，既可以保留水平扩展带来的好处，同时又有足够的弹性来应对节点时不时发生的故障。在Netflix，并没有制度要求工程师一定要按照某种规定来构建所有东西。相反的是，高效的领导者会在工程师之间建立一种强有力的一致规约或原则，让工程师在自己的领域里找到解决问题的最好办法。在这个节点时不时就会发生故障的案例里，我们要建立的强有力的规约和原则就是，我们开发的服务要具备在单一节点突然掉线的情况下还能持续提供端到端服务的能力。在业务正常进行期间，混乱猴子会伪随机地关闭生产环境中正在运行的节点，而且关闭的频率比正常节点发生故障的频率还要高很多。通过高频率地触发这些不常见且潜在的灾难性事件，我们使工程师有了强大的动力在开发服务时必须考虑到如何轻松应对这类事件。工程师必须尽可能早地频繁处理这类故障。除此以外，自动化、冗余、回滚策略，以及其他弹性设计的最佳实践，都使工程师在这些故障发生时能很快让自己的服务恢复正常。经过几年的发展，混乱猴子逐渐变得更加强大，现在它可以指定终止一组节点，并且通过与Spinnaker（我们的持续发布平台）集成来自动进行线上实验。但从根本上来说，它提供的还是与2010年以来一样的功能。混乱猴子最大的成就在于使工程师之间形成了构建具备足够弹性的服务的规约和原则。现在，它已经是Netflix工程师文化中不可或缺的一部分了。在过去五年左右的时间里，只有一次节点掉线影响了我们的服务。当时正是混乱猴子终止了一个由于部署失误而没有冗余的服务节点造成了问题。幸运的是，这个故障发生在白天工作时间，而且是在刚刚部署了这个服务不久后，所以对用户造成的影响非常小。可想而知，如果这个服务一直在线上运行了几个月，而在某个周末的晚上，当负责该服务的工程师没有值班（on-call）的时候，混乱猴子终止了它的节点，那将会造成多大的灾难。混乱猴子的美妙之处就在于此，它能尽可能地将服务节点失效带来的痛苦提前，同时让所有工程师在构建一个具有足够弹性应对失败的系统上，达成一个一致的目标。[1]译者注：混沌工程和故障注入本质上是思维方式上的不同。故障注入首先要知道会发生什么故障，然后一个一个地注入，然而在复杂分布式系统中，想要穷举所有可能的故障，本身就是奢望。混沌工程的思维方式是主动去找故障，是探索性的，你不知道摘掉一个节点、关掉一个服务会发生什么故障，虽然按计划做好了降级预案，但是关闭节点时却引发了上游服务异常，进而引发雪崩，这不是靠故障注入或预先计划能发现的。[2]译者注：Kafka主题（Topic）是Kafka对消息的归类方式，相当于传统消息中间件的队列（Queue）。[3]译者注：插入的指令可以干扰程序执行，使得执行程序后提前返回不同的结果或者抛出异常等。[4]译者注：很多程序的执行或者逻辑会依赖系统时间，比如定时任务，程序获取系统时间后根据时间执行一些逻辑，如果分布式系统各节点的时间不一致，就有可能引发不同节点的逻辑不一致。[5]译者注：系统需要足够的冗余来应对峰值及突发状况。[6]Julia Cation.Flight control breakthrough could lead to safer air travel. Engineering at Illinois,2015.第2章 管理复杂性
复杂性对工程师来说既是挑战也是机遇。你需要一支技术纯熟同时有足够应变能力的团队，来成功管理和运行一个包含许多组件和交互的分布式系统。在这样的复杂系统中充满了创新和优化的机会。
软件工程师通常会对这三个方面进行优化：性能、可用性、容错能力。性能
这里的性能特指使延迟或资源成本最小化。可用性
可用性，即系统正常响应和避免宕机的能力。容错能力
容错能力是指系统从非正常状态中恢复的能力。
通常，一个有经验的团队会同时针对这三个方面进行优化。
在Netflix，工程师们还会考虑第四个方面：新功能开发的速度
新功能开发的速度指工程师可以把新功能、创新功能提供给用户的速度。
Netflix在软件工程的决策过程中，非常明确地鼓励端到端的功能开发速度，而不仅仅是快速部署本地功能。在以上四者中找到平衡的过程，可以为架构选型提供必要的信息。
在充分考虑了这些方面之后，Netflix选择采用微服务架构。但我们要记住康威定律：任何组织所做的系统设计（广义的系统）的结构，将不可避免地复制这个组织信息沟通的组织结构。——Melvin Conway，1967
在微服务架构中，各团队彼此独立地开发和运营他们的服务。这就允许每个团队可以自行决定何时将代码布置到生产环境中。这个架构策略以沟通协调为代价来提高新功能的开发速度。将一个工程组织视为许多个这样的小型团队通常更直观。我们希望这些小团队的特点是松散耦合（即没有太多的组织架构限制，而是强调小团队之间的协作）和高度协调（即每个人都能看得更全面，从而明确他们的工作是如何有助于和其他团队一起实现更大的目标的）的。小团队之间的有效沟通是成功实施微服务架构的关键。混沌工程通过适时地验证系统弹性，来支持快速的功能开发、实验，以及增强团队对系统的信心。[1]理解复杂系统
想象一个向消费者提供产品信息的分布式系统，其微服务架构如图2-1所示。
试读结束[说明：试读内容隐藏了图片]