我们如何在AWS上构建一个完全区域性的云架构

至少对我来说，在云上构建经常给我带来意想不到的快乐。想到我可以从沙发上部署巴林或日本的服务器，我还是会感到兴奋的

在Apptrail，我们完全在云上运行，特别是AWS，其中一个主要原因是在新的地理区域推出服务是多么容易。我们将服务部署到独立的云区域，并为客户提供区域性的终端（例如：events.us-west-2.apptrail.com ）。

以下是我们在AWS上构建完全区域性服务的一些心得体会。

什么是云区域？

云提供商对他们的云有一个区域的概念。这些是孤立的地理区域，他们的物理基础设施被托管在那里，他们在那里提供云服务。例如，在写这篇文章时，AWS提供26个不同的云区域。建立在云上的软件应用程序可以利用云区域，在他们的应用程序中也建立一个区域的概念，以改善他们的服务。

区域性架构

要了解区域性，最好是了解蜂窝式架构。细胞（或基于细胞）架构是一种将系统分离成孤立的细胞的方式，以减少出错的爆炸半径。这个想法是，一个故障不应该跨越单元，所以细胞化是创建这些独立分区的一种方式。选择一个单元的实际方法可以是任何东西，从基于ID的随机到像地理区域的逻辑。你也可以有嵌套的单元来进一步隔离（例如，美国西部地区的大批量客户可以是一个特定的单元）。例如，AWS可用性区域也是次区域单元。总而言之，细胞化是设计可用系统的一种非常强大的方式，你可以在这里了解更多。

为什么存在区域

那么，区域只是基于地理区域的单元。区域有几个目的。从可用性和可靠性的角度来看，区域是云的可靠性战略的中心。在蜂窝式架构中，区域作为第一和最主要的单元。它们确保有一个与其他资源隔离的逻辑遏制。这有助于防止大范围的停电。

区域确实是指实际的地理区域，所以这也是它们存在的一个重要部分。这样做的一个好处是延时。为客户提供一种方法，以确保他们的工作负载运行在一个特定的区域，有助于他们在靠近客户的地方运行工作负载。

另一个重要的用例是合规性和数据主权。许多国家正在通过立法，要求用户数据和其他敏感数据必须实际存储在其管辖的地点。云区域是确保遵守这些法规的一种方式。

多区域架构

由于云供应商做了艰苦的工作，确保他们的所有服务在孤立的地区可用，客户得到的一个好处是能够运行多地区工作负载。多区域架构是一种在多可用区之外获得另一层可靠性的方式。例如，你可以使用Route 53在多个区域内运行负载平衡服务，以实现基于延迟的路由和基于健康检查的故障转移。人们还可以使用区域来保存和备份数据，例如使用Amazon S3。在AWS，区域范围内的故障是相当罕见的，所以积极的多区域服务可能是矫枉过正的（因为它也可能有缺点，如跨区域数据传输），但每个人都有他们的可用性要求，多区域架构是一个强大的工具，可以利用它来提高可用性。

区域化架构

区域化架构是指区域性是服务界面的一部分。例如，在区域性架构中，人们有专门的区域性终端，客户为每个支持的区域使用这些终端。区域化架构中的每个区域服务都应该独立于在其他区域运行的其他实例。

举个例子，比如我们有一个图像处理API。我们的客户使用这个API来上传、处理和检索视频。为了使这个API区域化，我们可以将API部署到多个区域，并提供region1.videoapi.example.com 和region2.videoapi.example.com 等端点供客户使用。

多区域和区域化架构之间的区别

区域（左）和多区域架构之间的比较

多区域和区域化架构的关键区别在于，在区域化架构中，区域是服务合同的一部分，而在多区域架构中，它只是实现的一部分。在多区域架构中，区域被用作单元，以增加可用性或作为故障转移。并不保证特定客户的请求会在特定区域内运行。相反，客户甚至不需要知道区域相对于服务的概念。然而，在区域架构中，区域是公共API的一部分，客户选择或被告知他们所关联的区域。

为区域化架构选择区域

构建区域化架构时，需要挑选一个要支持的地理区域列表和分配它们的方法。你很可能部署在云上，所以一个简单的决定是选择你的区域来对应云区域。例如，这就是我们在Apptrail所做的。人们可以重新命名它们，或者只是使用相同的名字，这就是我们在Apptrail自己所做的。

然而，一对一的映射是没有必要的。你也可以想出与多个云区域对应的区域。例如，一个区域的结构可以是这样的。

区域	AWS区域(s)
我们	美东-1, 美西-2, 美东-2
eu	欧盟-西部-1，欧盟-西部-2
日本	东北亚-1，东北亚-2
中	AP-South-1, AP-South-2

使用多区域单元的区域化方案

这样的方案给人一些好处，每个应用区域由多个云区域组成，可以提高可用性。

有兴趣为你的SaaS客户提供世界级的审计日志吗？ ApptrailApptrail是一个全面管理的审计跟踪服务。了解更多或开始。

何时使用区域架构

大多数服务可能不需要完全区域化。与多区域性不同的是，多区域性完全是一个技术工程的决定，而选择将你的公共API或服务区域化则更像是一个产品的决定。一般来说，它应该为你的客户提供一些需求或目的。我们观察常见的用例。

数据驻留要求

你的服务的区域化是一种允许你的客户确保他们的数据在一个特定的地区被存储和处理的方式。这通常是由于监管的原因而要求的。

延迟

对于其他应用，最大限度地减少客户延迟是非常重要的。将请求保留在离客户最近的区域是实现这一目标的一种方式。然而，由于将请求保持在区域内本身并不是一个严格的要求，完全的区域化在这里可能是也可能不是正确的方法，因为基于延迟的单一终端路由也可能满足要求。在这里，客户所期望的体验是需要考虑的（例如，你希望你的客户不得不考虑区域问题吗？）

选择要区域化的组件

当评估一个区域架构时，一个自然的问题是哪些组件要区域化。具体来说，哪些服务要有一个公开的区域接口。这里有几个考虑因素，而答案又回到了为什么要使用区域性架构的问题上。我们使用的一个有用的启发式方法是控制平面和数据平面之间的一个。一般来说，控制平面服务不应该是区域性的，但数据平面服务可以是区域性的。为了理解这个原因，我们可以考虑一下我们在控制平面上做的常见动作：例如，计费、用户管理或其他全局配置。这些通常有单一区域的依赖性，而且相对不频繁。对我们来说，让这些动作被区域化既不重要也不可取。另一方面，我们处理和存储重要数据的数据平面进程是区域化的。

请注意，虽然这是一个我们自己认为有用的一般准则，但它决不是规定性的。在很多情况下，我们可以将控制平面也区域化。一般来说，区域化的原因应该是这个决定的核心。人们应该考虑区域化服务将如何帮助或阻止他们实现这一目标。

我们如何部署到许多地区

基础设施和部署自动化是在不同地区部署许多服务时能够保持一致性、可靠性和可理解性的关键。值得庆幸的是，基础设施即代码的解决方案，特别是AWS CDK，让这一切变得更加容易。

使用波浪的分阶段部署

在Apptrail部署软件时，我们使用一个波浪的概念。回到蜂窝式结构，一个波段基本上是一组单元，可以同时部署到。例如，目前，我们的波段是。

浪潮	Apptrail区域
浪潮1	ap-south-1
第2波	eu-west-1
第3波	美国西部-2，美国东部-1

我们目前在Apptrail的浪潮

一次部署到一个波段，确保错误的变化不会导致全球中断。结合烘烤时间（在各波之间增加等待时间以监测退化）和自动回滚，波浪可以帮助确保你不会出现灾难性的故障。我们发现它们对暂存我们的变化非常有用。你可以在这里了解更多关于波浪的信息。

基础设施即代码 -CDK

在部署到许多地区时，完全自动化你的基础设施是必不可少的，因为每次部署到一个新的地区时，都是在复制整个应用程序和服务。我们使用AWS CDK来帮助我们做到这一点。CDK是CloudFormation的一个封装器，让你把基础设施写成真正的代码（例如，我们使用Typescript）。它使建立可重复使用的抽象（称为构造）像编写类或函数一样简单（在这里了解更多信息，我们认为这是AWS提供的最酷的东西之一！）。

CDK还提供了有用的高级抽象，所以你不必重新发明车轮。

将我们的一个区域服务部署到我们的一个浪潮中的管道

例如，我们使用CDK Pipelines来部署我们在Apptrail的所有基础设施。在CDK Pipelines中，原生支持阶段和波段，所以你可以轻松地部署蜂窝应用程序。在Apptrail，我们已经开发了一个标准的Pipeline结构，设置了我们的标准波，使创建符合Apptrail区域和波的区域化服务变得非常简单。

围绕区域架构的其他考虑

以下是我们在AWS上构建区域性应用的一些其他经验。

每个区域使用独立的AWS账户

这是一般的AWS最佳实践，但加强了对部署在区域内的服务的每个实例的思考，因为它具有明确划分的爆炸辐射。

管理成本

区域化本质上会带来一些额外的成本。然而，当一个应用程序被正确架构时，区域化带来的额外成本应该主要是每个区域的固定成本，这在规模上通常可以忽略不计。区域化服务一般不应该有过度的跨区域数据传输（数据库和其他全球数据往往是例外，但这应该是低成本的）。

全球数据

在评估区域化或多区域架构时，一个常见的考虑是如何处理全球数据。这里没有一个答案。牢记我们先前关于选择区域化组件以及数据平面和控制平面的讨论，我们有几种方法可以处理这个问题。例如，我们可以将全局数据保存在一个控制平面区域，而我们的区域化数据平面服务可以依赖于这个控制平面。这就是我们在Apptrail使用的方法。然而，这可能是也可能是不能接受的。如果延迟是区域化的主要动机，那么这就不太理想了。有几种方法可以处理这个问题，包括DynamoDB全局表和数据库复制，这超出了本文的范围（更多信息见此视频）。另一方面，如果区域化的主要原因是数据驻留，而我们的控制平面只存储不敏感的配置，那么这是一个更合适的方法。

总结

随着部署到云端越来越容易，以及对数据主权的关注度越来越高，区域性架构也变得越来越普遍。这让你了解了我们如何在AWS上轻松维护我们在Apptrail的区域服务。你的下一个项目可能不需要区域化，但我希望这对你有帮助，有参考价值。