【现货速发】可伸缩架构

译者序
互联网从一穷二白发展到今天，“可伸缩性”“水平伸缩”这些以前只有大型互联网公司才面临的技术挑战，现在几乎是任何一家互联网公司都需要想办法去解决的难题。在我看来，写好一段代码不难，写好一个单机软件也不难，但是写好一个伸缩性良好的大规模分布式系统却很难。这其中难的地方首先在于思想观念的转变。程序员一开始接触
到的就是确定的概念和世界，当程序逻辑一定时，什么样的输入就应该有什么样的输出。
但是在面对大规模系统时，我们首先要承认的是不确定性，即有很多我们想不到、料不到的事情会发生，一个边角的小错误都可能导致整个系统全面“雪崩”。因此，我们不能再把系统当作一个稳定的、确定的程序看待，而需要在设计时充分考虑到那些可能不确定的情况。其次，就是要改变管理整个系统的有效手段。随着系统规模的不断增长，之前的人工操作方式已经明显无法跟上机器的增长速度，规模增长所带来的可靠性、可用性问题时刻都在挑战着整个团队的极限。因此，如何有效地评估、预测、管理、监控一个大规模的系统，这件事本身已经变成一个复杂的系统性工程，需要有效的方法论、原则、工具以及实践经验的相应支撑。
当一个系统的规模开始扩张时，可用性往往是系统首先要面临的问题。在激增的流量面前，每一次系统处理缓慢、崩溃都会给公司的业务带来损失，因此理解什么是高可用性对系统保障来说至关重要。为了维持或提高系统的可用性，我们需要一套标准和手段来测量系统的可用性，从而在时间发现系统可用性是否发生了变化，并制定相应的解决方案。
随着系统规模不断扩大，各种不确定的因素会被放大，这些不确定性会给系统带来更多的不确定性。在构建大规模可伸缩系统的时候，需要先梳理清楚系统中存在哪些不确定性，把它们定义成风险因素并建立相应的风险模型，定期回顾并确保更新风险因素。在这之后，我们要针对每个风险因素制定相应的应对方案和措施，并持续对风险管理计划、缓和计划和容灾计划进行测试和评估，这样才能避免在风险发生时手忙脚乱。
当系统规模发展到一定程度时，系统本身的架构瓶颈就会突显出来，之前的单体系统已经难以再开发和维护。这时候，不管从技术角度出发，还是从团队人员角度出发，服务化都是一个必然的趋势。我们需要将原有的系统功能和逻辑，拆分成多个独立的服务来进行管理。但是，随着服务越来越多，如何管理各个服务、服务间如何通信，以及团队如何划分都是新的问题。随着业界在这方面的经验越来越多，经过 Netflix、Amazon 等公司的实践和推广，微服务的概念出现，完善的解决方案和工具也开始出现。
在解决这些问题之后，我们会发现，系统规模再继续发展就会遇到 IDC 的限制，单个数据中心甚至没有空间来存放服务器，也支持不了所需的网络带宽。幸运的是，云计算和服务的出现为我们创造了无限的可能。我们无须再考虑硬件和场地的问题，无须再处理烦琐的运维事项，可以按照使用量来付费，甚至很多服务也无须自己搭建，可以直接使用云服务厂商提供的各种高性能、高可用服务。云计算给我们带来的是一种颠覆性的变化，不仅影响到我们的开发、运维、技术栈，更深远地影响到我们对技术和架构的思考方式，进而为创造更多商业价值提供可能。
本书作者 Lee Atchison 是 New Relic 的首席云架构师和布道师，负责领导公司基础设施产品的搭建，并且帮助公司设计了一个稳定的、基于服务的系统架构。他曾在 Amazon担任了 7 年高级技术经理，深刻了解如何设计基于云的、可伸缩的系统，也主导创建了AWS Elastic Beanstalk 等产品。在本书中，Lee 根据自身多年的经验，为我们分享了在大规模可伸缩系统的设计和实现中应该注意的几个方面，这其中的方法和技巧都是经过时间考验的无价经验。相信各位读者看完此书后，不会再惧怕那些未知的困难，能够在保持系统规模增长的同时，保证系统的高可用性和可伸缩性。
愿以后的每个系统都是高可用、可伸缩的系统。

序
第 2 版序言
本书是一本内容全面的技术图书，面向那些已经认识到，所有公司都已经从简单地称自己为“数字型企业”，转变为如果不真的这么做就会面临破产的企业管理人员。银行、保险和其他曾经拥有巨大“护城河”的行业，正在被一些新贵企业所冲击。这些企业能够提供令人惊叹的用户体验，是因为它们的运营方式真的像一家数字型企业一样，而不仅仅是纸上谈兵。
本书对于那些希望在实践中拥有一个高可靠性的可操作路线图、实现现代化运维理念（例如，DevOps、网站可靠性工程等），以及想应用技术概念和服务（例如，微服务、云计算、边缘计算）的主管、经理和架构师们来说，是一本全面指南。
我很高兴能够在 New Relic 公司与 Lee 共事，New Relic 是一家能够让企业在全球范围内监控它们数字业务的公司。在 New Relic 的时候，Lee 周游了世界，帮助许多公司实现了数字化转型，加速了创新的实现，并且交付了百分之百可用的服务。
在许多 30 分钟的会议上，我一次又一次地看到 Lee 推动了许多公司的转型。请各位尽情享受这本书！它将对你的公司和职业生涯产生深远的影响！
——Ken Gavranovic，New Relic 的 EVP 兼 GM，Interland 公司（现在是 web.com）的 CEO 兼创始人

第 1 版序言
我们生活在一个有趣的时代，可以称它为软件的“寒武纪大爆炸”时代。在这个过程中，构建新系统的成本呈数量级下降，同时系统之间的关联程度呈同等数量级增长。借助于Amazon 的 AWS、微软的 Azure 和 Google 的 GCP 等资源，我们可以将系统在物理上扩展到一个几年前还只能想象的规模。
这些资源及其似乎无限的能力，正在以各种前所未见的方式，将新的思想、产品和市场极其快速地传播出去。但是，只有当我们构建的系统可以保持扩展的同时，所有这些探索才能成为可能。与以前相比，虽然构建小型系统变得容易很多，但是构建一个可以快速、可靠扩展的系统，并不像增加更多的硬件和存储空间那么容易，实践证明，这要难得多。
每个软件系统都会经历一个可预见的生命周期，从一个人能够完全理解的、小型的、设计精妙的解决方案，迅速增长为一个积累了大量技术债务的庞大系统，随后又逐渐分裂成由一些不完善的服务随机组成的组合，并终演化成在广度（更多用户）和深度（更多功能）方面均可稳定伸缩的、设计良好的分布式系统。对于这样的系统来说，我们很容易从外部了解要做哪些事情（让它变得更加可靠！），但又很难了解它的内部细节。幸运的是，本书是一本关于这方面不可或缺的指南，从可用性到服务层，从比赛日到风险模型，Lee 一步步介绍了影响大规模系统的各个关键因素和实践方式。
Lee 加入我们的时候，是 New Relic 次从仅拥有一个产品正在向多个产品转型的时期，当时我们正沉浸在用户极速增长和公司成功的喜悦中。Lee 的到来，为我们带来了他在 Amazon 的丰富经验，不管是零售业务还是 AWS 业务都曾经历过巨大的增长。Lee曾是这些团队的领头人，曾经积极参与过与可伸缩性有关的所有事情，也遇到过很多失败。对我们来说，幸运的是，他已经经历过这些挫折与困苦，其中的教训可以让我们避免再犯同样的错误。
在 Lee 加入 New Relic 之前，多年以来，我们一直处于系统服务不可用的尴尬处境。我们原有的庞大系统也逐渐无法支持业务的发展，不管是可用性、可靠性还是性能都不是很好。但是，通过充分运用 Lee 在本书中所写的各项技巧，我们逐渐克服了这些困难，并构建了如今稳定可靠的企业级服务。其中我们使用的一个工具，建立了可用性工程的四个级别 ：青铜、白银、黄金和白金。要达到青铜级，团队必须拥有风险模型以及预定义的 SLA 标准。要达到白银级，团队必须能够监控风险模型中标识出来的问题，并使用比赛日的方式来解决。黄金级意味着风险已经被缓解。白金级如同 CMM 5 级一样，不仅系统可以自愈，而且我们关注于持续性的改进。我们首先集中精力对级的服务进行改进，然后上升到第二级的服务，逐步推进，终使得所有团队都至少达到白银级，并且大多数团队通过了黄金级，甚至有几个团队达到了白金级。
后来我加入了 InVision App 这个更年轻的公司。我又一次经历了从早期成功转向高速增长的过程，一直推荐大家去使用 Lee 之前带给我的技术和工具。在这个新系统、新产品、新公司的爆炸年代，我强烈建议大家跟我做一样的事：向 Lee 学习如何构建可伸缩的系统。
— Bjorn Freeman-Benson 博士

前言
本书是一本关于现代化软件架构的书。书中介绍了如何构建和更新你的关键应用程序，来满足日益苛刻的数字化客户的需求。书中还介绍了如何实现高可用性，如何使用现代的开发和运维技术来架构应用程序，如何组织开发团队帮助应用程序和业务获得成功，如何将系统扩展到规模，以及如何利用云计算的可用资源来迎接上述挑战。
设计可伸缩架构的整个过程，远不只是知道如何处理大流量。
本书的读者对象
本书的目标读者包括构建和管理大规模应用程序和系统的软件工程师、架构师、技术经理及总监。如果你管理着软件开发人员、系统可靠性工程师、DevOps 工程师，或者经营着一个拥有大规模应用程序和系统的机构，本书中所提供的建议和指导都能够帮助你，让你的系统运行得更加平稳和可靠。
如果你的应用程序已经从很小的规模变得很大（并且正在经历着增长所带来的各种问题），那么你可能正在为系统的低可靠性和低可用性烦恼。如果你正在头疼如何管理技术债务以及相关的系统故障，本书恰好提供了这些方面的指导，能够帮助你通过降低技术债务，让应用程序更轻松地扩展到更大规模。
编写本书的原因
在 Amazon 零售和 AWS 业务团队从事了 7 年的构建高可伸缩应用程序的工作之后，我加入了 New Relic 这个正在迅速成长的公司。当时，New Relic 已经感受到了因为缺少管理高可伸缩应用程序的系统、流程所带来的痛苦，但是尚未完整形成能够扩大其应用程序规模的流程和规范。
在 New Relic，我目睹了一个公司在规模扩张过程中所经历的痛苦与挣扎，同时也意识到，还有很多其他公司每天都在经历着同样的痛苦。
现在我在世界各地旅行，与许多客户和像你一样的人谈论云计算、可伸缩性、可用性，以及如何构建现代化应用程序的关键过程。我会举办一些演讲、小组讨论、课程以及研讨会。我会与工程部门的领导和管理人员进行面对面的交流，帮助他们实现目标，并从他们身上学习什么是可行的，什么是不可行的。我会撰写一些文章，接受一些采访，并参加一些播客节目。
编写本书的初衷，是帮助那些正在面对其应用程序高速增长的人们，使其了解到一些有用的流程和实践，避免他们掉入规模扩张过程的各种陷阱之中。
无论你的应用程序每年增长十倍还是百分之十，也无论增长的是用户数量、交易数量、数据存储量还是代码复杂性，本书都可以在构建和维护应用程序方面提供帮助，以帮助你在保持高可用性的前提下实现增长。
如今我们所说的规模
随着应用程序的增长，它们开始变得非常复杂，并且要处理非常巨大的流量。
复杂性的增加意味着脆弱性也在增加。更多的流量意味着管理流量的机制要更加新颖和复杂。
应用程序开发人员很少从一开始构建的就是一个可伸缩的应用程序。我们经常认为自己已经实现了可伸缩性，并且相信已经能够让应用程序扩展到我们可以想象的别。
但是更常见的情况是，我们在逻辑上和应用程序中发现了许多错误。这些错误只有在我们开始面临扩展的问题时才会出现，从而使得应用程序更加难以扩展到可支持更大的流量和更大的数据集。
这就导致了更高的复杂性和更强的脆弱性。
终，这种规模 - 脆弱性 - 规模 - 复杂性的循环会成为应用程序的死亡螺旋，因为它会遇到断电、宕机和其他各种服务质量和可用性的问题。
但是这些其实都是你的问题，你的客户并不关心这些问题。他们只是想用你的应用程序来完成他们所期望的工作。如果你的应用程序持续宕机、运行缓慢或者不稳定，客户就会放弃你，转而寻找能够处理他们业务的竞争对手。
如何能提高应用程序的可伸缩性，即使是才开始意识到这些因为规模增长导致的限制也能提高呢？显然，我们在应用程序的生命周期中越早考虑可伸缩性，扩展就越容易。但是，我们不希望过度地设计应用程序来获得超出需要的可伸缩性。在生命周期中的任何时刻，你都可以使用各种技术来提高应用程序的可伸缩性。
但是在考虑如何使用扩展应用程序的技术之前，必须先确定什么是应用程序的可用性。
在迈出这一步之前，没有什么比这更重要了。如果你现在不考虑这一点，那么随着应用程序的不断扩展，迟早你会搞不清楚它的工作方式，并且开始出现随机的、意想不到的问题。这些问题会导致宕机和数据丢失，并将极大地影响你构建和改进应用程序的能力。
此外，随着流量和数据的增加，这些问题只会变得更加糟糕。在做任何其他事情之前，请你先梳理清楚系统的可用性和风险管理。
第 2 版中的新内容
虽然这本书中讨论的许多概念大多与时间无关，但是许多（例如，无服务器计算）技术必须保持与时俱进，以便能够反映过去四年的行业变化。
另外，在过去的几年里，我一直在世界各地讨论这些话题。从与客户和其他专家的各种交流中，我学到了很多东西，并且会将我学到的很多东西融入这个版本。
本书还对如何使用云计算服务进行了大量的更新。
后，我重写了第 1 版中的大量内容，对章节进行了重新组织，使得读者更容易获取相关信息。
使用云计算服务
基于云计算的服务正在以极高的速度增长和占领市场。软件即服务（SaaS）正在成为应用程序开发的规范，这主要缘于对这些基于云计算的服务需求。SaaS 应用程序由于其多租户的特点，尤其关注可伸缩性的问题。
随着世界的变化，我们越来越关注 SaaS 服务、基于云计算的服务和海量数据应用程序，可伸缩性变得越来越重要。
对于我们的云应用程序的规模和复杂性，似乎还没有看到增长结束的迹象。
如今管理可伸缩性的的技术，在未来都将只是基本的功能，而将来的可伸缩性问题的解决方案会让今天的解决方案看起来过于简单和初级。我们的行业将需要越来越复杂的系统和架构来处理未来要面对的规模。
自然地，随着时间的推移，这本书中的一些资料会逐渐过时。我的目的是提供尽可能多的内容，让它们能够经得起时间的考验。
服务和微服务
对于服务和微服务这两个术语的使用，业界存在很多争议。我个人不喜欢“微服务”这个术语，因为它意味着服务的特定规模，这未必是一个健康的假设。许多服务都是小型的，有些确实是“微型的”，但也有许多服务是大得多的。大小是否合适是取决于上下文环境的，并且受到许多条件和标准的影响 注 1 ，在我看来，术语“微服务”的使用会影响这种讨论。然而，我也意识到，“微服务”这个术语在业界非常流行。
还有一些人将“服务”这个术语定义为 SOA 的一部分，并进一步将这些术语与十多年前流行的某种架构联系起来。我认为这些比较是不准确和令人困惑的。
我个人倾向使用“服务”这个术语，但我知道很多人更愿意使用“微服务”这个术语。因此，在与其他公司讨论时，这两个术语我都会使用，具体选择哪个取决于上下文环境。在我看来，这两个术语的意思完全相同。
不过，“服务”这个词还有一个值得讨论的用法，例如，当我们指称某个外部服务的时候，比如“Amazon 提供了 Amazon S3 服务”，“服务”这个词的用法看起来是截然不同的，似乎在采用这个词的另一种用法，但实际上两者是一回事。“服务”是一个软件模块，它提供了特定的功能和支持该功能的数据。无论服务由你的开发人员编写还是由 Amazon的工程师编写，是无关紧要的。然而，我确实意识到，有时区分这两种类型的“服务”是很重要的。
这就是我在书中使用这些术语的方式。根据上下文环境，这两个术语可以互换使用。在这本书中，你一定会看到我对“服务”这个词的偏爱。你应该假设这两个术语的意思是完全相同的。当我指称另一家公司提供的特定类型的服务，比如某个云服务时，也会这样表示。因此，在本书中你将会看到“AWS 服务”“云服务”“SaaS 服务”等术语。
现代化的数字客户体验
在现代数字世界中，软件应用程序已经成为我们的品牌和公司的标志。客户与我们互动是通过我们的软件来实现的。我们的应用程序不仅仅是客户体验的一部分，在许多情况下，它们就是整个客户体验。软件对我们的成功来说至关重要，现代化的客户希望我们的应用程序也要现代化，他们如何看待我们的品牌和公司，在很大程度上取决于他们如何看待我们的软件。
一个不够现代化的应用程序
考虑一下这个例子 ：在我儿子的智能手机上有一个应用程序，我的儿子必须使用这个程序来获得一些医疗福利。它是一个政府提供的应用程序，由美国政府开发和负责运行。
这个应用程序不是一直都能工作。当你在一天中某个“不合适”的时间启动应用程序时，你将收到一条错误消息。错误消息的意思是 ：“该应用程序仅在东部时间星期一到星期五的上午 9 点到下午 5 点之间可以使用。”
没错，实际情况就是这样。这就是我儿子智能手机上的一个移动软件应用程序，除了在东海岸的营业时间之内，软件是被禁止使用的。
你的企业可以使用这样的应用程序吗？它在使用时也有这样的限制吗？商业化的企业如果像这样对客户设定限制，还能够继续经营下去吗？
不，我敢打赌，没有一个商业化的企业能够以这种方式生存并且对待它的客户。我们必须为客户提供令人难忘的用户体验。应用程序必须在客户希望使用它们的任何时候都能工作，必须是 100% 的时间里都可以工作，一天 24 小时，一周 7 天。如果不是这样，我们就会让客户感到失望，失望的客户就会离开。
本书导读
管理可伸缩性并不只是管理流量，还包括管理风险和可用性。通常来说，所有这些都是描述相同问题的不同方式，并且它们息息相关。因此，为了能够合理地讨论可伸缩性问题，我们还必须考虑到可用性、风险管理、团队及组织流程，以及像微服务和云计算这样的现代架构模型。
因此，本书被组织成 5 个主要部分，每个部分都代表了面向可伸缩架构的主要原则。让我们分别来看一下。
原则 1.　可用性 ：维护现代化应用程序的可用性
现代化软件必须保持高可用性。客户不会容忍服务中断。如果你的应用程序在客户需要时不能工作，那么他们将不会成为你的长期客户。
第Ⅰ部分讨论了应用程序可用性对客户的重要性，以及它如何受到应用程序伸缩的影响。
理解、测量和提高可用性是这些章节的重点。
这部分的章节包括 ：
第 1 章，理解、测量和提高可用性
第 2 章，两次失误的高度 — 预留从错误中恢复的空间
原则 2.　现代化应用程序架构 ：使用服务
现代化的软件需要使用现代化的应用程序架构。现代化的应用程序架构要求远离单体应用程序，而采用基于服务的架构。
无论是从伸缩流量的角度，还是从伸缩组织处理应用程序能力的角度来看，单体应用程序都很难进行伸缩。单体程度越大，更改应用程序的速度就越慢，能够处理和有效管理它的人员就越少，流量变化和流量增长对可用性产生负面影响的可能性就越大。
面向服务的架构通过在流量伸缩方面提供更大的灵活性来解决这些问题。此外，它们还提供了一个可伸缩的框架，允许大型开发团队能够处理应用程序，使得应用程序本身可以变得更大、更复杂。
第Ⅱ部分的章节包括 ：
第 3 章，使用服务
第 4 章，服务和数据
第 5 章，处理服务故障
原则 3.　组织 ：为现代化应用程序建立可伸缩性的组织
除非你的开发团队使用现代化的过程管理手段，否则你无法构建现代化的软件。这包括服务所有权责任和开发流程。
应用程序如何伸缩并不重要，但如果你的开发团队的组织架构不支持可伸缩性，或者你的组织没有正确的文化来驱动更高的可用性和更大的可伸缩性，那么你就无法伸缩你的应用程序。
组织好你的团队，使其可以更好地支持你的可伸缩性需求，这会创造出一种文化，从而支持应用程序的可伸缩需求。
第Ⅲ部分的章节包括 ：
第 6 章，服务所有权 — STOSA
第 7 章，服务分级
第 8 章，服务等级协议
原则 4.　风险 ：现代化应用程序的风险管理
你不能消除一个系统中的所有风险，这是不可能的。所有复杂的系统都有其固有存在的风险。我们必须学会如何管理风险，并将风险作为评估技术债务和对应用程序改进做出决策的一个工具。
理解风险、测量风险和根据测量的风险结果来确定行为的优先级，是构建一个具有高伸缩性、高可用性的应用程序的重要工具。
第Ⅳ部分包括 ：
第 9 章，如何在设计可伸缩架构时使用风险管理
第 10 章，比赛日
第 11 章，构建低风险系统
原则 5.　云计算 ：利用云计算
现代化应用程序中的高可用性要求能够灵活伸缩。我们再也负担不起为了满足应用程序的峰值需求，而采购过剩的基础设施。我们必须根据当前的需要，按需动态地分配和消费基础设施资源。
动态的基础设施，以及能够支持和优化动态基础设施的应用程序，是构建高伸缩性、高可用性的应用程序的一个关键架构组件。
动态的基础设施是公有云的基础优势。利用好公有云对于保证应用程序的高可用性至关重要。
第Ⅴ部分的章节包括 ：
第 12 章，使用云计算来设计可伸缩架构
第 13 章，云计算改变的 5 个行业趋势
第 14 章，SaaS 和租赁类型
第 15 章，在 AWS 云上分发你的应用程序
第 16 章，托管的基础设施
第 17 章，云资源分配
第 18 章，无服务器计算和函数即服务
第 19 章，边缘计算
第 20 章，地理位置对云计算的影响
这些是构建满足客户现代化需求的应用程序的 5 个关键原则。这些原则构成了设计可伸缩架构的基础。

本书是一本关于现代化软件架构的书。书中介绍了如何构建和更新你的关键应用程序来满足日益苛刻的数字化客户的需求。书中还介绍了如何实现高可用性，如何使用现代化的开发和运维技术来架构应用程序，如何组织开发团队帮助应用程序和业务获得成功，如何将系统扩展到*规模，以及如何利用云计算的可用资源来迎接上述挑战。本书的目标读者包括构建和管理大规模应用程序和系统的软件工程师、架构师、技术经理及