当区域性故障来临,您的系统还能幸免于难吗?

韧性是所有工程师都喜欢时不时提及的“热词”之一。但我们真的知道 "韧性 "代表着什么吗？我们知道如何 "实现韧性 "吗？

通常，当我们的系统能够适应和克服某些事件时，它们就具有韧性。

当然，韧性不是绝对的。我们的系统部署模式繁杂，其高度依赖于运行应用的基础设施。新的部署模式，如Kubernetes，已经证明它们比基于虚拟机的部署在稳定性上有明显的改善。采用某些云提供商的技术是一个更优的选择，因为这可让我们拥有几乎无限的计算能力。

但是，我们如何才能提高系统的韧性呢？Netflix给出了明确的答案。

仅仅设计一个容错架构是不够的。我们必须不断地测试系统在这些“百年不遇”的故障中实际生存的能力。

- Netflix Simian Army

混沌工程可以拯救您! 韧性是那些只有在出现问题时才会确认的特性之一。所以，提高系统韧性的最好的方法就是拥抱混沌，迫使“某件事”出错。“某件事”是指什么事情？任何可能发生的事情!

混沌变量反映现实世界的事件。根据潜在影响或预估频率对事件进行优先级排序。考虑对应硬件故障（如服务器宕机）、软件故障（如异常响应）和非故障事件（如流量激增或弹性伸缩事件）。任何能够破坏稳态的事件都是混沌实验中的潜在变量。

- 混沌工程指导思想

了解这些后，我们可以开始考虑这些事件。最坏的情况是什么？好吧，互联网中断。但这是您几乎无能为力的事情。下一个呢？数据中心故障。这似乎更加有趣，我们可以开始考虑冗余、多活和一些更流行的词汇。如前所述，云提供商在这个意义上是一个更优的选择。所以，假设在AWS上运行我们的工作负载。

在AWS中，您可以将您的服务部署在几个区域，也就是AWS数据中心的地理分组。每个区域至少由2-3个可用区数据中心组成（免责声明：一个可用区可能由多个数据中心组成，但在本文章中，我们假设一个可用区对应一个数据中心）。最佳实践决定了您应该在多个可用区上部署服务，但是如果整个区域崩溃了会怎样？这是个现实中存在的场景吗？

存在，但罕见。2020年11月，AWS弗吉尼亚北部区域发生故障，影响了多项服务。2015年9月，与DynamoDB有关的另一个问题导致区域性中断。所以，这类事件不太可能发生，但肯定能发生。在接下来的内容中，我们将分析一个用例，以及我们如何设计一个系统，使区域中断不会导致业务收入损失。

需求说明

为了简单起见，我们将建立一个短域名应用程序。它应该提供两个功能。

•给予一个长的URL，它应该生成一个短的URL。•给定一个缩短的URL，它应该重定向到长的URL。

举例来说：

•一个用户想缩短URL https://some-domain.com/some-path/another-path?queryParam1=demo&queryParam2=demo。生成的URL是https://my-shortener-service.com/demo•用户通过浏览器访问https://my-shortener-service.com/demo。该服务返回一个重定向到https://some-domain.com/some-path/another-path?queryParam1=demo&queryParam2=demo。

目标是，AWS区域性中断对用户造成的影响最小。

架构设计

让我们开始设计系统吧! 我们将采用标准的技术栈。

系统架构版本1

这是一个很简单的架构。通过Amazon Route 53，我们将为用户提供一个域名，让他们使用我们的服务。如果您像我们一样，有一个出色的平台团队提供一个共享的Kubernetes集群，那么，您会在您的命名空间中部署服务。我们可以选择基于Java的后端或其他技术。对于数据库，我们将依靠常规的MySQL数据库。随着我们对AWS的频繁使用，我们将建立一个Aurora MySQL集群。这些都在AWS eu-west-1（爱尔兰）区域运行。

爽！我们的服务已经启动和运行。我们完成了这个项目。但是......真的完成了吗？

架构优化

毫无疑问，我们的系统是可以正常工作的。但，让我们检查一些可改进的点。

•我们需要一个独占的MySQL来运行我们的服务吗？这似乎有点太重了…•我们需要一个24小时不间断运行的应用载体吗？在晚上它可能是空闲的，这似乎是一种资源的浪费…•SpringBoot是一个相当标准的堆栈，但它的内存和CPU要求有点高。我们能不能做点什么来改善它？•这种架构能在区域性中断中幸免于难吗？

第一点是很容易解决的。我们的场景对于基于键值的数据库来说是完美的适配的，所以数据库可以进行优化!

系统架构版本2

亚马逊 DynamoDB 是一个完全托管的、键值、文档型数据库。它能完美地支持我们的场景，并具有一个特殊的功能，我们将基于它来实现最终的韧性架构。此外，我们可以使用它的Serverless功能来确保我们按实际使用付费! 但是，我们还是要为Kubernetes资源付费。好了，我们在数据库层引入了Serverless技术，那么让我们在应用层也这样做吧!

系统架构版本3

AWS Lambda是AWS的Serverless服务。它允许按需运行我们的功能。我们可以将它们与Amazon API Gateway集成，这样我们就可以为用户暴露一个REST接口。这两种服务都是以请求次数与执行时间的模式来计费的，所以可以节省成本! 此外，能够在不同的Lambda中分离不同的接入点，使我们能够以框架透明的方式用不同的语言进行编码。虽然您可以维护Spring annotations，但我强烈建议您不要这么做。Serverless世界的规则与微服务世界的规则有些不同。

我们的架构已经改进了不少。但还是有可改进的地方。使用Serverless技术是一种改进。但真的需要Lambda函数吗？如果能够去除它们，就可以减少响应时间（以及费用！）。幸运的是，Amazon API Gateway可以与其它AWS服务集成。它还提供输入验证功能，因此我们拥有所需的一切。

系统架构版本4

最后，我们拥有超级精简的架构，满足了我们的需求。

通过复制实现韧性

我们的新架构再简洁不过了。采用细胞架构，细胞将由API Gateway和DynamoDB表组成。

一个细胞是一些组件的集合，从设计、实现到部署都是分组的。每个细胞是独立可部署的，可管理的，可观测的。

- 基于细胞的架构

每个细胞都能够自行提供所需的功能。另外，通过使用DynamoDB全局表，我们可以确保数据在最多五个副本之间以小于一秒的延迟进行同步，同时提供多活的配置。因此，我们可以像使用主数据库一样使用任何区域的表，所有的变化都会传播到其他区域。现在我们已经拥有了设置全局韧性所需的一切!

系统架构版本5

复制是一个韧性系统的核心。要注意的是，在任何一个时间点，一个区域可能会故障，所以我们需要至少两个可用的区域。由于我们的场景非常简单，我们可以根据用户的位置来划分用户，这样他们就会使用离他们更近的细胞（基于延迟的路由）。我们的定期健康检查将确保所有细胞在任何时间点都是活着的，如果其中一个细胞死亡，它将被丢弃，所有的流量将被发送到活着的那个细胞。

验证假设

理论上，我们有一个能够抵御区域性故障的系统。我说 "理论上"，是因为除非我能证明这一点，否则就不是。我们不应该声称在生产中拥有一个有韧性的系统，除非我们真的确认它是。不要忘记，韧性不是非黑即白的，有很多问题需要回答。它真的有效吗？故障转移到其他区域需要多长时间？一个细胞是否能够承担两个细胞的所有负载？有自愈流程吗？

没有数据，你就是另一个有意见的人

- 爱德华兹·戴明(W. Edwards Deming)

没有数据，你就是另一个有意见的人。而我是你的老板。所以我的意见比你的更有效

- 我合作过的老板

一切都是为了数据。数据是客观的，是不能争辩的。数据提供有意义的信息，应该推动决策。我们需要数据。因此，让我们开始进行验证。

•该系统是否真的能抵御区域性故障？•系统故障切换需要多长时间？

这两个问题将给我们一些提示，以确定区域性故障的爆炸半径。为了回答这两个问题，我们将模拟爱尔兰区域的流量，然后将其关闭。最简单的方法是直接删除API Gateway。这将向我们展示在故障转移发生时，我们的欧洲用户将遭受多长时间的服务中断。之后，我们将在爱尔兰重新部署一切，看看对我们用户的影响。请记住，我们有两个细胞在运行：一个在爱尔兰，另一个在俄勒冈。以下负载是从位于西班牙的本地笔记本电脑上发出的。

验证假设

我们来分析一下发生了什么。

•起初，我们的API运行良好 ，有230毫秒的延迟，对于西班牙和爱尔兰的连接来说还不错。没有用户收到任何错误响应•删除API Gateway。用户在 00:01:10 开始收到错误响应•Route 53的健康检查检测到爱尔兰细胞已死。它将其从可用细胞列表中删除，并在00:01:30将所有流量重定向至俄勒冈。•流量现在是从西班牙到俄勒冈。这解释了为什么响应时间增加到820毫秒，错误响应下降。•重新部署爱尔兰的细胞。Route 53检测到它是一个有效的细胞，并将其列入可用细胞列表中。•流量又恢复从西班牙到爱尔兰。延迟恢复到平时的220毫秒

有了这些信息，我们可以确认。是的，我们的系统对区域性中断是有韧性的。如果发生一次区域性故障，离该地区较近的用户将在约20秒的时间内发生服务中断。当然，我们可以完善我们的解决方案，以进一步减少这个数据。而且通过在全球范围内拥有更多的细胞，延迟会降低。

结束语

韧性不是我们在开发结束后就能简单解决的。在设计架构的时候应该考虑到这个概念，因为不这样做可能会招致我们的应用重写几次。迭代您的架构设计，并不断改进，直到大部分问题有答案。

推荐阅读

•Netflix Simian Army^[1]•混沌工程指导思想^[2]•基于细胞的架构^[3]•弗吉尼亚北部区域（US-EAST-1）的Amazon Kinesis事件摘要^[4]•US-EAST区域的Amazon DynamoDB服务中断及其相关影响摘要^[5]

---

引用链接

[1] Netflix Simian Army: https://netflixtechblog.com/the-netflix-simian-army-16e57fbab116
[2] 混沌工程指导思想: https://principlesofchaos.org/
[3] 基于细胞的架构: https://github.com/wso2/reference-architecture/blob/master/reference-architecture-cell-based.md
[4] 弗吉尼亚北部区域（US-EAST-1）的Amazon Kinesis事件摘要: https://aws.amazon.com/message/11201/
[5] US-EAST区域的Amazon DynamoDB服务中断及其相关影响摘要: https://aws.amazon.com/message/5467D2/