前言

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

设计可伸缩架构的整个过程，远不只是知道如何处理大流量。

本书的读者对象

本书的目标读者包括构建和管理大规模应用程序和系统的软件工程师、架构师、技术经理及总监。如果你管理着软件开发人员、系统可靠性工程师、DevOps工程师，或者经营着一个拥有大规模应用程序和系统的机构，本书中所提供的建议和指导都能够帮助你，让你的系统运行得更加平稳和可靠。

如果你的应用程序已经从很小的规模变得很大（并且正在经历着增长所带来的各种问题），那么你可能正在为系统的低可靠性和低可用性烦恼。如果你正在头疼如何管理技术债务及相关的系统故障，本书恰好提供了这些方面的指导，能够帮助你通过降低技术债务，让应用程序更轻松地扩展到更大规模。

编写本书的原因

在Amazon零售和AWS业务团队从事了7年构建高可伸缩应用程序的工作之后，我加入了New Relic这个正在迅速成长的公司。当时，New Relic已经感受到了因为缺少管理高可伸缩应用程序的系统、流程所带来的痛苦，但是尚未完整形成能够扩大其应用程序规模的流程和规范。

在New Relic，我目睹了一个公司在规模扩张过程中所经历的痛苦与挣扎，同时也意识到，还有很多其他公司每天都在经历着同样的痛苦。

现在，我在世界各地旅行，与许多客户和像你一样的人谈论云计算、可伸缩性、可用性，以及如何构建现代化应用程序的关键过程。我会举办一些演讲、小组讨论、课程及研讨会。我会与工程部门的领导和管理人员进行面对面的交流，帮助他们实现目标，并从他们身上学习什么是可行的，什么是不可行的。我会撰写一些文章，接受一些采访，并参加一些播客节目。

编写本书的初衷，是帮助那些正在面对其应用程序高速增长的人们，使其了解到一些有用的流程和最佳实践，避免他们掉入规模扩张过程的各种陷阱之中。

无论你的应用程序每年增长十倍还是百分之十，也无论增长的是用户数量、交易数量、数据存储量还是代码复杂性，本书都可以在构建和维护应用程序方面提供帮助，以帮助你在保持高可用性的前提下实现增长。

如今我们所说的规模

随着应用程序的增长，它们开始变得非常复杂，并且要处理非常巨大的流量。

复杂性的增加意味着脆弱性也在增加。更多的流量意味着管理流量的机制要更加新颖和复杂。

应用程序开发人员很少从一开始构建的就是一个可伸缩的应用程序。我们经常认为自己已经实现了可伸缩性，并且相信已经能够让应用程序扩展到我们可以想象的最高级别。但是更常见的情况是，我们在逻辑上和应用程序中发现了许多错误。这些错误只有在我们开始面临扩展的问题时才会出现，从而使得应用程序更加难以扩展到可支持更大的流量和更大的数据集。

这就导致了更高的复杂性和更强的脆弱性。

最终，这种规模-脆弱性-规模-复杂性的循环会成为应用程序的死亡螺旋，因为它会遇到断电、宕机和其他各种服务质量及可用性的问题。

但是这些其实都是你的问题，你的客户并不关心这些问题。他们只是想用你的应用程序来完成他们所期望的工作。如果你的应用程序持续宕机、运行缓慢或者不稳定，客户就会放弃你，转而寻找能够处理他们业务的竞争对手。

如何能提高应用程序的可伸缩性，即使是才开始意识到这些因为规模增长导致的限制？显然，我们在应用程序的生命周期中越早考虑可伸缩性，扩展就越容易。但是，我们不希望过度地设计应用程序来获得超出需要的可伸缩性。在生命周期中的任何时刻，你都可以使用各种技术来提高应用程序的可伸缩性。

但是在考虑如何使用扩展应用程序的技术之前，必须先确定什么是应用程序的可用性。在迈出这一步之前，没有什么比这更重要了。如果你现在不考虑这一点，那么随着应用程序的不断扩展，迟早你会搞不清楚它的工作方式，并且开始出现随机的、意想不到的问题。这些问题会导致宕机和数据丢失，并将极大地影响你构建和改进应用程序的能力。此外，随着流量和数据的增加，这些问题只会变得更加糟糕。在做任何其他事情之前，请你先梳理清楚系统的可用性和风险管理。

第2版中的新内容

虽然这本书中讨论的许多概念大多与时间无关，但是许多（例如，无服务器计算）技术必须保持与时俱进，以便能够反映过去四年的行业变化。

另外，在过去的几年里，我一直在世界各地讨论这些话题。从与客户和其他专家的各种交流中，我学到了很多知识，会将学到的这些知识融入这个版本。

本书还对如何使用云计算服务进行了大量的更新。

最后，我重写了第1版中的大量内容，对章节进行了重新组织，使得读者更容易获取相关信息。

使用云计算服务

基于云计算的服务正在以极高的速度增长和占领市场。软件即服务（SaaS）正在成为应用程序开发的规范，这主要缘于对这些基于云计算的服务需求。SaaS应用程序由于其多租户的特点，尤其关注可伸缩性的问题。

随着世界的变化，我们越来越关注SaaS服务、基于云计算的服务和海量数据应用程序，可伸缩性变得越来越重要。

对于我们的云应用程序的规模和复杂性，似乎还没有看到增长结束的迹象。

如今管理可伸缩性的最先进的技术，在未来都将只是基本的功能，而将来的可伸缩性问题的解决方案会让今天的解决方案看起来过于简单和初级。我们的行业将需要越来越复杂的系统和架构来处理未来要面对的规模。

自然地，随着时间的推移，这本书中的一些资料会逐渐过时。我的目的是提供尽可能多的内容，让它们能够经得起时间的考验。

服务和微服务

对于服务和微服务这两个术语的使用，业界存在很多争议。我个人不喜欢“微服务”这个术语，因为它意味着服务的特定规模，这未必是一个健康的假设。许多服务都是小型的，有些确实是“微型的”，但也有许多服务是很大的。大小是否合适是取决于上下文环境的，并且受到许多条件和标准的影响[1]。在我看来，术语“微服务”的使用会影响这种讨论。然而，我也意识到，“微服务”这个术语在业界非常流行。

还有一些人将“服务”这个术语定义为SOA的一部分，并进一步将这些术语与十多年前流行的某种架构联系起来。我认为这些比较是不准确和令人困惑的。

我个人倾向使用“服务”这个术语，但我知道很多人更愿意使用“微服务”这个术语。因此，在与其他公司讨论时，这两个术语我都会使用，具体选择哪个取决于上下文环境。在我看来，这两个术语的意思完全相同。

不过，“服务”这个词还有一个值得讨论的用法。例如，当我们指称某个外部服务的时候，比如“Amazon提供了Amazon S3服务”，“服务”这个词的用法看起来是截然不同的，似乎在采用这个词的另一种用法，但实际上两者是一回事。“服务”是一个软件模块，它提供了特定的功能和支持该功能的数据。无论服务由你的开发人员编写还是由Amazon的工程师编写，都是无关紧要的。然而，我确实意识到，有时区分这两种类型的“服务”是很重要的。

这就是我在书中使用这些术语的方式。根据上下文环境，这两个术语可以互换使用。在这本书中，你一定会看到我对“服务”这个词的偏爱。你应该假设这两个术语的意思是完全相同的。当我指称另一家公司提供的特定类型的服务，比如某个云服务时，也会这样表示。因此，在本书中你将会看到“AWS服务”“云服务”“SaaS服务”等术语。

现代化的数字客户体验

在现代数字世界中，软件应用程序已经成为我们的品牌和公司的标志。客户与我们互动是通过我们的软件来实现的。我们的应用程序不仅仅是客户体验的一部分，在许多情况下，它们就是整个客户体验。软件对我们的成功来说至关重要，现代化的客户希望我们的应用程序也要现代化，他们如何看待我们的品牌和公司，在很大程度上取决于他们如何看待我们的软件。

你的企业可以使用这样的应用程序吗？它在使用时也有这样的限制吗？商业化的企业如果像这样对客户设定限制，还能够继续经营下去吗？

不，我敢打赌，没有一个商业化的企业能够以这种方式生存并且对待它的客户。我们必须为客户提供令人难忘的用户体验。应用程序必须在客户希望使用它们的任何时候都能工作，必须在所有的时间里都可以工作，一天24小时，一周7天。如果不是这样，我们就会让客户感到失望，失望的客户就会离开。

本书导读

管理可伸缩性并不只是管理流量，还包括管理风险和可用性。通常来说，所有这些都是描述相同问题的不同方式，并且它们息息相关。因此，为了能够合理地讨论可伸缩性问题，我们还必须考虑到可用性、风险管理、团队及组织流程，以及像微服务和云计算这样的现代架构模型。

因此，本书被组织成5个主要部分，每个部分都代表了面向可伸缩架构的主要原则。让我们分别来看一下。

原则1. 可用性：维护现代化应用程序的可用性

现代化软件必须保持高可用性。客户不会容忍服务中断。如果你的应用程序在客户需要时不能工作，那么他们将不会成为你的长期客户。

第Ⅰ部分讨论了应用程序可用性对客户的重要性，以及它如何受到应用程序伸缩的影响。理解、测量和提高可用性是这部分的重点。

第I部分的章节包括：

• 第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个关键原则。这些原则构成了设计可伸缩架构的基础。

在线资源

本书的网站（网址参见链接1）[2]上提供了一些额外的信息，包括补充材料的链接地址。你可以在我的网站（网址参见链接2）上找到更多关于我的信息，也可以关注我的博客（网址参见链接3）。

本书使用的约定

本书使用以下一些排版约定：

该图标表示提示或者建议。

该图标表示提示或者建议。

该图标表示一般说明。

O'Reilly在线学习（O'Reilly Online Learning）

40多年来，O'Reilly Media为许多企业提供技术咨询、商业培训、知识和洞察力，帮助企业获得成功。

我们独特的专家和创新者网络会通过书籍、文章、会议和在线学习平台分享他们的知识和专长。O'Reilly的在线学习平台可以让你按需访问在线培训课程、深度学习路径、交互式编程环境，以及来自O'Reilly和200多个其他出版商的大量文章和视频。更多信息，请访问O'Reilly公司的网站。

如何联系我们

请将对本书的评价和存在的问题通过如下地址告知出版社。

美国：

O'Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

中国：

北京市西城区西直门南大街2号成铭大厦C座807室（100035）

奥莱利技术咨询（北京）有限公司

O'Reilly的每一本书都有专属网站，你可以在那里找到本书的相关信息，包括勘误列表、示例代码以及其他信息。本书的网站地址是：

https://oreil.ly/architecting-for-scale-2e

对于本书的评论和技术性的问题，请发送电子邮件到：

bookquestions@oreilly.com

关于我们的书籍、课程、会议和新闻的更多信息，请参阅网站http://www.oreilly.com。

在Facebook上找到我们：http://facebook.com/oreilly

在Twitter上关注我们：http://twitter.com/oreillymedia

在YouTube上观看我们：http://www.youtube.com/oreillymedia

致谢

虽然我无法一一列举出所有为本书出版做出贡献的人，但我还是想特别感谢以下帮助过我的人。

• Ken Gavranovic，“朋友”这个词已经不足以来形容我俩的关系。永远相信猴子的力量。

• Bjorn Freeman-Benson，在开始编写本书时，你就给了我很多支持，并且提供了加入New Relic的工作机会，让我能够去思考如何编写本书。我很高兴我们的友谊能够在一起共事之后持续至今。

• Kevin McGuire，我们既是朋友也是知己。我们从在New Relic开始就在一起工作，你的远见和想象力为我的职业生涯指明了焦点和方向，而我直到今天也从未偏离。

• Abner Germanow、Darren Cunningham、Jay Fry、Bharath Gowda和Robson Grieve，你们为我争取到了在New Relic工作的机会。与你们在一起的这段日子，是我感到最开心、最有收获，以及对我个人来说最充实的时光。我非常怀念那些时光。尤其是Abner，如果没有你，我就不会有今天的事业。你引导我进入这个新的角色，并帮助我从一个工程师和架构师成长为一个战略家、专家和思想领袖。谢谢你相信我，并在这条路上指导我。

• Jim Gochee，是你向我介绍了New Relic这个产品，最终它也成就了我的工作。

• Lew Cirne，是你的远见带给了我们New Relic，也带给了我一份工作和一个家庭。每次跟你进行一对一的谈话后，我都会被你的幽默和热情所感染和打动。怪不得New Relic会如此成功。

• Kevin Downs，我的朋友和云计算伙伴。替我向老鼠问好。顺便说一下，容器才是王道。

• Brandon Sangiovanni，我的朋友。从美国职棒大联盟到漫威和米奇，你已经搞定了我在这本书中讨论的许多挑战，而你仍然毫发未损、笑对人生！感谢你的支持、你的知识，以及最重要的，你的友谊。

• Abbas Haider Ali，我非常敬重你。我们都扮演着行业思想领袖的角色，有一个可以交流想法和提出建议的人简直太好了。你对这本书早期草稿的建议使它变得更好。谢谢你！

• Kurt Kufeld，你曾是我的导师，帮助我适应了这个古怪、混乱、漫长、乏味，以及最终让我收获颇丰的世界，它叫Amazon。

• Greg Hart、Scott Green、Patrick Franklin、Suresh Kumar、Colin Bodell和Andy Jassy，你们给了我之前从未想过的在Amazon和AWS工作的机会。

• Brian Anderson，我的编辑，以及现在O'Reilly的编辑Kathleen Carr，是你们让本书和O'Reilly的很多项目得以进行。Brian负责出版了本书的第1版。而Kathleen鼓励我在第2版中增加了更多内容，还包括相关的课程、培训和知识讲座。

O'Reilly的Amelia Blevins，你对本书的版式、布局和内容提出了实质性的编辑建议。这些建议对本书的质量和可读性产生了巨大的提升。

向所有在读完第1版后联系我的人致敬，你们给了我赞扬、鼓励和建议，感谢你们的帮助，是你们帮助我保持写作的动力，并给了我关于改进第2版的想法。

感谢我的家人，尤其是我的妻子Beth，你永远是指引我生活方向的灯塔。与你在一起，我的生活变得越来越光明，我前进的道路也越来越清晰。

所有帮助过我的人，以及所有我没有提到的人，我也衷心地感谢你们。

最后，我还必须介绍一下那些毛茸茸的小家伙：Issie，爱打鼾的西班牙猎犬；Abbey，快乐的柯基犬；以及Budha，一只好动的小猫咪，它们给我带来的可不仅仅是本书中的错别字。

读者服务

微信扫码回复：39343

• 获取博文视点学院20元付费内容抵扣券

• 获取本书参考资料中的配套链接

• 获取更多技术专家分享的视频与学习资源

• 加入读者交流群，与更多读者互动

[1] 我在第3章的“深入了解服务”一节中更详细地讨论了如何看待服务的大小。

[2] 请访问http://www.broadview.com.cn/39343下载本书提供的附加参考资料。正文中提及参见“链接1”“链接2”等时，可在下载的“参考资料.pdf”文件中查询。