随着互联网的发展越来越成熟,流量和数据量飞速增长,许多公司的关键应用程序都面临着伸缩性的问题,系统变得越来越复杂和脆弱,从而导致风险上升、可用性降低。本
书是一本实践指南,让IT、DevOps和系统稳定性管理员能够了解到,如何避免应用程序在发展过程中变得缓慢、数据不一致或者彻底不可用等问题。规模增长并不只意味着处理更多的用户,还包括管理更多的风险和保证系统的可用性。作者Lee Atchison 在可用性、风险管理、服务和微服务、扩展应用程序和云服务方面提出了一些技巧,使得我们在构建各类应用程序时,既能够保证产品的质量,又能够处理海量的流量、数据以及需求。
如果你管理着软件开发人员、系统可靠性工程师、DevOps工程师,或者你经营着一个拥有大规模应用程序和系统的机构,本书中所提供的建议和指导都能够帮助你,让你的
系统运行得更加平稳和可靠。
流量|数据|复杂度一路攀升 超大规模迫在眉睫 你亟需一套成熟方法和技巧→它来了!
序
我们生活在一个有趣的时代,可以称它是一个软件的寒武纪大爆炸。在这个过程中,构建新系统的成本呈数量级式下降,同时系统之间的关联程度也呈同等数量级的增长。借助于 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博士, InVision App首席技术官
前言
当应用程序开始增长时,通常会出现两件事情:它们明显变得更加复杂(也更加脆弱),并且需要处理显著增加的流量(需要更先进、更复杂的管理机制)。这会让应用程序逐渐陷入一个死亡漩涡,用户会不断经历着限流、宕机以及其他服务质量和可用性方面的问题。
但是你的用户不会关心这些。他们只希望使用应用来做他们希望做的事情。如果你的应用程序宕机、响应缓慢或者信息不一致,用户会马上抛弃你,转而投靠能够帮助他们处理生意的竞争对手。
本书可教会你一些如何构建并管理大规模应用程序的基本技巧,帮助你避免陷入如上所述的死亡漩涡。一旦你掌握了这些技巧,你的系统就能够可靠处理海量的流量,从容面对流量中大量的不确定性,同时不会对用户期望造成任何影响。
本书的读者对象
本书的目标读者包括构建和管理大规模应用程序和系统的软件工程师、架构师、技术经理以及总监。如果你管理着软件开发人员、系统可靠性工程师、 DevOps工程师,或者你经营着一个拥有大规模应用程序和系统的机构,本书中所提供的建议和指导都能够帮助你,让你的系统运行得更加平稳和可靠。
如果你的应用程序已经从很小的规模变得很大(并且正在经历着增长所带来的各种问题),你可能正在为系统的低可靠性和低可用性烦恼。如果你正在头疼如何管理技术债务以及相关的系统故障,本书恰好提供了这些方面的指导,能够帮助你通过降低技术债务,让应用程序更轻松地扩展到更大规模。
编写本书的原因
在 Amazon零售和 AWS业务多年从事构建高可伸缩应用程序之后,我加入了 New Relic这个正在迅速成长的公司。当时, New Relic已经感受到了因为缺少管理高可伸缩应用程序的系统、流程所带来的痛苦,但是尚未完整形成能够扩大其应用程序规模的流程和规范。
在 New Relic,我亲眼目睹了一个公司在扩张规模过程中所经历的痛苦与挣扎,同时也意识到,还有很多其他公司每天都在经历着这些痛苦。
编写本书的初衷,是为了帮助那些正在面对其应用程序高速增长的人们,使其了解到一些有用的流程和最佳实践,避免他们再掉入规模扩张过程的各种陷阱之中。
无论你的应用程序每年增长十倍还是百分之十,也无论增长的是用户数量、交易数量、数据存储量还是代码复杂性,本书都可以在构建和维护应用程序方面为你提供帮助,让它们在保持高可用性的前提下实现增长。
现在我们所说的规模
基于云的服务正在以极快的速度增长和扩张。这主要归功于对云服务的大量需求,“软件即服务(SaaS)”逐渐成为应用程序开发的标准。由于 SaaS应用程序天生多租户的特点,它们对于规模上的问题尤其敏感。
随着世界的改变,以及我们对 SaaS服务、云服务、海量应用程序越来越多的关注,规模性问题也变得越来越重要。似乎我们看不到,云应用程序在体积和复杂性方面会出现增长到头的情况。
关键的机制在于,我们当前用来管理大规模系统的前沿科技,很可能会成为明天的基础工具,而明天我们可能遇到的规模问题,也会让当前的解决方案相形见绌。我们需要越来越复杂的系统和架构,来处理将来可能无限增长的规模。
本书的目的,就是为了提供可以禁得起时间考验的知识。
本书导读
管理规模并不只是管理流量,还包括管理风险和可用性。通常来说,所有这些东西都是描述相同问题的不同方式,并且它们息息相关。因此,为了能够合理地讨论规模问题,我们还必须考虑到可用性、风险管理以及像微服务和云服务这样的现代架构模型。因此,本书按照如下章节来划分内容。
第Ⅰ部分:可用性
当某个应用程序开始扩张规模时,可用性和可用性管理通常是最先受到影响的部分。
第 1章,什么是可用性为了更好地让读者理解,我们会讲解一下高可用性的意义,以及它与可靠性之间的区别。
第 2章,提高应用程序可用性的五个要点
在本章中,我针对如何提高应用程序的可用性提出了五个核心方向。
第 3章,测量可用性
本章会介绍一种测量可用性的标准算法,并进一步讲解高可用性的作用和价值。
第 4章,提高下降的可用性如果你的应用程序正遇到可用性的问题(或者你想知道这是否正在发生),我们提供了一些管理手段,来帮助你提高应用程序的可用性。
第Ⅱ部分:风险管理
理解系统中的风险,对于提高应用程序的可用性,以及它后续向更大规模发展的能力是至关重要的。
第 5章,什么是风险管理
本章会通过介绍风险管理的基本知识,引出如何管理高可伸缩应用程序的话题。
第 6章,可能性与严重性本章会讨论风险发生时的严重性与可能性之间的区别。它们都非常重要,但是方式不同。
第 7章,风险模型
在本章中,我会以一个精心设计的系统为例,来帮助你理解和管理系统中的风险。
第 8章,风险缓和
本章会讨论如何处理系统中已知的风险,并减少它们对应用程序的影响。
第 9章,比赛日本章会介绍如何对风险管理计划、风险缓和计划以及容灾计划进行持续的测试和评估。本章回顾了在生产环境实现比赛日所需的技术,以及它所带来的好处。
第 10章,构建低风险系统
在本章中,我会给出如何降低应用程序中的风险,以及如何构建低风险系统的建议。
第Ⅲ部分:服务和微服务
服务和微服务都是一种架构方案,用于构建需要更大规模运行的、更加大型且复杂的应用程序。
第 11章,为什么使用服务
本章会介绍为什么服务对于构建高度可扩展的应用程序如此重要。
第 12章,使用微服务
在本章中,我会介绍如何创建基于微服务的架构,主要关注于如何对服务大小进行合理分割,确定服务的边界,以便提高可扩展性和可用性。
第 13章,处理服务故障
在本部分的最后一章中,我们会来讨论如何构建能够处理故障的服务。
第Ⅳ部分:如何让应用程序具有伸缩性
“伸缩”其实不仅仅与流量有关,它关系你的组织,以及你的组织如何来响应更大的应用程序需求。
第 14章,两次失误的高度
本章会介绍如何在出现故障的情况下,依然能够通过伸缩系统来保持高可用性。
第 15章,服务所有权
本章会讲解,关注服务的所有权,能如何帮助你扩展组织和应用程序。
第 16章,服务分级
本章会介绍如何区分各个服务的关键程度,从而帮助管理对服务的期望。
第 17章,使用服务分级
当制订服务分级制度之后,我们会介绍如何通过它来管理服务故障的影响、响应性需求以及期望管理。
第 18章,服务等级协议
在本章中,我们会讨论如何使用 SLA来管理服务所有者之间的相互依赖。
第 19章,持续改进
本章会就如何改进应用程序整体的可扩展性,提供相应的技术和指导。
第Ⅴ部分:云服务
对于构建和管理需要极强可伸缩能力的大型、关键性系统来说,基于云的服务正在变得日益重要。
第 20章,变化和云服务本章介绍了云服务对构建高度可伸缩的 Web应用程序所带来的改变。
第 21章,云上的分布
本章概述了如何有效使用地域和可用区来提高可用性和可伸缩性。
第 22章,托管的基础设施本章会介绍如何使用托管服务(例如 RDS、SQS、SNS和 SES)来伸缩应用程序,同时降低管理方面的工作。
第 23章,云资源分配
本章中我们会讨论如何分配云资源,以及不同分配技术对应用程序可伸缩性的影响。
第 24章,可伸缩的计算选项本章会介绍一些高度可伸缩的编程模型,例如 AWS Lambda。你可以通过这些技术来提高可伸缩性、可用性以及应用程序的可管理性。
第 25章,AWS Lambda本部分的最后一章会更加深入地介绍 AWS Lambda技术,它可以为简单的计算型需求提供高度的可伸缩性。
第Ⅵ部分:总结
第 26章,融会贯通
本章会将之前每个部分的核心要点汇总成一个简短的总结,帮助你来回忆每章的内容。
在线资源
本书的网站(http://www.architectingforscale.com/)提供了一些额外的信息,包括补充材料的链接地址。你可以在这个网站上找到更多关于我的信息,也可以关注我的博客。
本书使用的约定
本书使用以下一些排版约定:
斜体(Italic)
表示新的名词、URL、电子邮件地址、文件名以及文件扩展名。
等宽字体(Constant width)用于程序清单,以及段落中对变量、函数名、数据库、数据类型、环境变量、语句和关键字等程序元素的引用。
等宽加粗字体(Constant width bold)
用于显示命令或者其他需要由用户输入的文字。
等宽斜体字体(Constant width italic)
用于显示需要由用户提供的值或者由上下文决定的值所替换的文本。
该图标表示一个提示或者建议。
该图标表示一个一般说明。
该图标表示一个提醒或者警告。
Safari Books Online
前言 | xxiii
致谢
虽然我无法一一列举出所有为本书出版做出贡献的人,但是我还是想特别感谢以下帮助过我的人。
. Bjorn Freeman-Benson,在开始编写本书时,他给了我很多支持,并且提供了加入 New Relic的工作机会,让我能够去思考如何编写本书。
. Kevin McGuire,我们既是朋友也是知己。我们从 New Relic开始就在一起工作,他的远见和想象力为我的职业生涯指明了方向,并一直指导我到今天。
. Natasha Litt,她是我的好朋友,同时也给了我很多鼓励和支持。
. Jade Rubick,他始终保持着一贯的笑容和积极的态度,为我提供了很好的建议和指导。有幸与你为友。
. Jim Gochee,是他向我介绍了 New Relic这个产品,最终也成为我的工作。
. Lew Cirne,是他的远见带给了我们 New Relic,也带给了我一份工作和一个家庭。每次在跟 Lew进行一对一的谈话后,我都会被他的幽默和热情所感染和打动。怪不得 New Relic会如此成功。
. Abner Germanow、Jay Fry、Bharath Gowda和 Robson Grieve,他们为我争取到了在 New Relic工作的机会。谁说我就一定不能胜任这个职位呢?相反,我做得还非常好。这是目前为止我感到最开心、最有收获,以及对我个人来说最充实的一份工作。
. Mikey Butler、Nic Benders、Matthew Flaming,以及其他 New Relic的技术主管,感谢他们多年以来的支持。
. Kurt Kufeld,他曾是我的导师,感谢他帮助我融入 Amazon怪异、混乱的工作环境,让我不断接受挑战,拼尽每一分努力,并最终获得了巨大的成功。
. Greg Hart、Scott Green、Patrick Franklin、Suresh Kumar、Colin Bodell和 Andy Jassy,他们给了我在 Amazon和 AWS工作的机会,之前从未想过。
. Brian Anderson,我的编辑,他给了我编写本书的机会,并且在写书的每个阶段都在帮助我。
我想要特别感谢 Abner Germanow和 Bjorn Freeman-Benson,是他们让我有机会能够编写本书,没有他们,也不可能有本书的存在。出于这个原因,我会永远感谢他们。
感谢我的家庭,尤其是我的妻子 Beth,她永远是指引我生活方向的灯塔。与她在一起,我的生活变得越来越光明,我前进的道路也越来越清晰。
对于所有帮助过我的人们,以及所有我没有提到的人们,我衷心地感谢你们。
最后,我还必须介绍一下那些毛茸茸的小家伙们: Izzy,爱打鼾的西班牙猎犬; Abby,快乐的柯基犬;以及 Budha,一只好动的小猫咪,它给我带来的可不仅仅是本书中的错别字而已。