云架构设计原则

译者序

AWS用户广泛，产品线复杂，AWS发布的白皮书《Architecting for the Cloud-AWS Best Practices》介绍了常见场景下云架构的最佳实践，不仅对于使用AWS的用户，对于广大使用云的用户都有参考意义，新钛云服工程师特意翻译了本白皮书，供广大使用云的用户参考。

请点击输入图片描述

1. 摘要

本白皮书适用于在Amazon Web Services（AWS）上的构建解决方案的架构师和开发人员。本白皮书提供有关技术设计模型的架构指导和建议，以及如何应用于云计算环境中。本白皮书提供了在AWS上设计解决方案时的关键概念和差异。本白皮书还讨论了如何利用特定于云计算动态特性的属性，如弹性和基础设施自动化。这些模型可以为对选择、操作状态和实现状态进行更详细的审查提供上下文，就像《AWS Well-Architected Framework》中详细描述的那样.

2. 介绍

将应用程序迁移到AWS，即使没有重大更改（称为直接迁移的方法），也可为组织提供安全且经济高效的基础架构优势。但是，为了充分利用云计算可能带来的弹性和灵活性，工程师必须改进其架构以利用AWS功能。

对于新应用程序，基于云的IT体系架构模型可以帮助提高效率和可伸缩性。这些新架构可以支撑从互联网规模数据的实时分析到具有数千个连接的物联网（IoT），或移动设备的不可预测流量的应用程序的任何内容。

无论是重新架构在本地环境中运行的当前应用程序以在AWS上运行，还是设计云原生应用程序，你都必须考虑传统环境与云计算环境之间的差异。这包括体系架构选择，可伸缩性，资源类型，自动化以及灵活的组件，服务和数据库。如果你不熟悉AWS，我们建议你查看“ About AWS”页面上的信息，以便基本了解AWS服务。

3. 传统环境和云计算环境之间的差异

云计算在许多方面不同于传统的本地环境，包括灵活，全局和可扩展的容量，托管服务，内置安全性，成本优化选项以及各种操作模型。

3.1 IT资产作为可配置资源

在传统计算环境中，可以基于理论最大峰值的估计来提供容量。这可能导致阶段性昂贵的资源闲置或容量不足。借助云计算，可以根据需要访问尽可能多的容量，并动态扩展以满足实际需求，同时只需为使用的资源付费。

在AWS上，可以在几秒钟内实例化服务器，数据库，存储和更高级别的应用程序组件。可以将这些视为临时资源，而不受固定和有限IT基础架构的不灵活性和限制。这会重置处理变更管理，测试，可靠性和容量规划的方式。这种方法的改变通过引入流程中快速失败和快速迭代的能力来鼓励体验。

3.2 全球，可用和可扩展的容量

使用AWS的全局基础架构，可以将应用程序部署到最符合你要求的AWS可用区域（例如，与最终用户的接近程度，合规性，数据驻留限制和成本）。对于全局应用程序，可以使用Amazon CloudFront内容交付网络（CDN）在全球范围内减少到终端用户的延时。这也使得跨多个数据中心操作生产应用程序和数据库变得更加容易，从而实现高可用性和容错性。AWS的全球基础架构以及根据需要配置容量的能力，使你可以根据对应用程序的需求和服务范围的扩展，来对你的基础架构进行不同的思考。

3.3 更高级的托管服务

除了Amazon Elastic Compute Cloud（Amazon EC2）的计算资源外，还可以访问各种存储，数据库，分析，应用程序和部署服务。由于这些服务可立即供开发人员使用，因此可减少对内部专业技能的依赖，并使组织能够更快地交付新解决方案。管理的AWS服务可以降低运营复杂性和成本。它们还具有可扩展性和高可用性，因此可以降低实施风险。

3.4 内置安全性

在传统IT环境中，基础架构安全审核可以是定期和手动过程。相比之下，AWS Cloud提供的治理功能可以持续监控IT资源的配置更改。AWS的安全性是最高优先级，这意味着可以从为满足大多数安全敏感组织的要求而构建的数据中心和网络体系结构中受益。

由于AWS资源可使用工具和API进行编程，因此可以将安全策略正式化并嵌入基础架构设计中。由于能够启动临时环境，安全测试现在可以成为持续交付流水线的一部分。最后，可以利用各种云原生的AWS安全和加密功能，这些功能可以帮助你实现更高级别的数据保护和合规性。

3.5 成本架构

内部部署解决方案的传统成本管理通常不与提供服务紧密耦合。在配置云计算环境时，优化成本是架构师的基本设计租户。选择解决方案时，不仅应关注功能架构和功能集，还应关注所选解决方案的成本配置文件。

AWS提供细粒度计费，使你能够跟踪与解决方案的所有方面相关的成本。有一系列服务可帮助你管理预算，提醒你产生的费用，并帮助你优化资源使用和成本。

3.6 AWS上的运维

在AWS上运行服务时，有几种常见的运维模型：

• 迁移的应用程序，维护现有的传统操作模型，利用通过API管理基础架构作为代码的能力，从而实现可靠且可重复的构建过程，从而提高可靠性。
• 重构的解决方案利用更高级别的操作流程自动化作为支持服务，例如， AWS Auto Scaling和自我修复架构。
• 针对云运营重新构建和设计的解决方案通常通过DevOps流程实现全面自动化，以实现交付管道和管理。

支持这些转变不仅会改变所使用的技术，还会改变开发和运维团队管理方式的文化变化。

AWS提供工具，流程和最佳实践，以支持运维实践的转变，从而最大限度地利用云计算带来的收益。

4. 设计原则

AWS 包含许多可应用于各种用例的设计模式和体系结构选项。AWS的一些关键设计原则包括可扩展性，可支配资源，自动化，用松耦合管理服务，以及灵活的数据存储选项。

4.1 可扩展性

预计随着时间的推移而增长的系统需要建立在可扩展的架构之上。这样的体系架构可以支持用户，流量或数据大小的增长，而不会降低性能。应该以线性方式按比例提供资源，添加额外资源至少导致成比例增加提供额外负载的能力。增长应引入规模经济，成本应遵循从该系统产生商业价值的相同维度。虽然云计算提供几乎无限的按需容量，但你的设计需要能够无缝地利用这些资源。

通常有两种扩展IT架构的方法：纵向扩展和横向扩展。

4.1.1 纵向扩展

纵向扩展通过增加单个资源的规模来实现，例如升级具有更大硬盘驱动器或更快CPU的服务器。使用Amazon EC2，你可以停止实例并将其调整为具有更多RAM，CPU，I/O或网络功能的实例类型。这种缩放方式最终将达到极限，并且它并不总是具有成本效益或高度可用的方法。但是，它很容易实现，并且对于许多用例来说已经足够了，特别是在短期内。

4.1.2 横向扩展

通过增加资源数量来横向扩展，例如向存储阵列添加更多硬盘驱动器，或添加更多服务器以支持应用程序。这是构建利用云弹性的互联网规模应用程序的好方法。并非所有体系结构都旨在将其工作负载分配给多个资源，因此让我们检视一些可能的情况。

1) 无状态应用

当用户或服务与应用程序交互时，通常会执行一系列形成会话的交互。会话是用户在使用应用程序时在请求之间保持不变的唯一数据。无状态应用程序是不需要先前交互知识，且不存储会话信息的应用程序。例如，给定相同输入，向任何最终用户提供相同响应的应用程序是无状态应用程序。无状态应用程序可以横向扩展，因为任何可用的计算资源（例如EC2实例和AWS Lambda函数）都可以为任何请求提供服务。如果没有存储会话数据，可以根据需要添加更多计算资源。当不再需要该容量时，可以在运行任务耗尽后安全地终止这些单独的资源。这些资源不需要知道同伴的存在，所需要的只是将工作负载分配给它们的方法。

2) 将负载分配给多个节点

要将工作负载分配到环境中的多个节点，可以选择推模型或拉模型。

使用推模型，可以使用Elastic Load Balancing（ELB）来分配工作负载。ELB跨多个EC2实例路由传入的应用程序请求。在路由流量时，网络负载均衡器在开放系统互连（OSI）模型的第4层运行，以处理每秒数百万个请求。通过采用基于容器的服务，还可以使用应用程序负载均衡器。应用程序负载均衡器提供OSI模型的第7层，并支持基于应用程序流量的基于内容的请求路由。或者，可以使用Amazon Route 53实施DNS轮询。在这种情况下，DNS响应以循环方式从有效主机列表中返回IP地址。虽然易于实施，但这种方法并不总能很好地适应云计算的弹性。这是因为即使你可以为DNS记录设置低生存时间（TTL）值，缓存DNS解析器也不在Amazon Route 53的控制范围内，并且可能并不总是遵循你的设置。

可以为异步，事件驱动的工作负载实现拉模型，而不是负载平衡解决方案。在拉模型中，需要执行的任务或需要处理的数据可以使用Amazon Simple Queue Service（Amazon SQS）作为消息存储在队列中，也可以作为流数据解决方案存储

比如亚马逊Kinesis，多个计算资源可以提取和使用这些消息，以分布式方式处理它们。

3) 无状态组件

实际上，大多数应用程序都维护某种状态信息。例如，Web应用程序需要跟踪用户是否已登录，以便可以基于先前的操作呈现个性化内容。自动化的多步骤过程还需要跟踪先前的活动，以确定其下一步应该是什么。仍然可以通过不在本地文件系统中存储需要多于一个请求的任何内容，来使这些体系结构的一部分无状态。

例如，Web应用程序可以使用HTTP cookie在Web客户端缓存中存储会话信息（如购物车项目）。浏览器在每个后续请求时将该信息传递回服务器，以便应用程序不需要存储它。但是，这种方法有两个缺点。首先，HTTP cookie的内容可能会在客户端被篡改，因此你应始终将其视为必须经过验证的不可信数据。其次，HTTP cookie随每个请求一起传输，这意味着你应该将其大小保持在最小，以避免不必要的延迟。

考虑仅在HTTP cookie中存储唯一的会话标识符，并在服务器端存储更详细的用户会话信息。大多数编程平台都提供以这种方式工作的本机会话管理机制。但是，默认情况下，用户会话信息通常存储在本地文件系统中，从而形成有状态架构。此问题的常见解决方案是将此信息存储在数据库中。Amazon DynamoDB是一个很好的选择，因为它具有可扩展性，高可用性和耐用性特征。对于许多平台，有一些开源替代库，允许你在Amazon DynamoDB中存储本机会话。

其他方案需要存储较大的文件（例如用户上载和批处理的中间结果）。通过将这些文件放在共享存储层（如Amazon Simple Storage Service，Amazon S3；或Amazon Elastic File System，Amazon EFS））中，可以避免引入有状态组件。

最后，复杂的多步骤工作流是另一个必须跟踪每个执行的当前状态的示例。可以使用AWS步骤功能集中存储执行历史记录，并使这些工作负载无状态。

4) 有状态组件

不可避免地，你的架构层将不会变成无状态组件。根据定义，数据库是有状态的。有关更多信息，请参阅后面的“数据库章节"。此外，许多遗留应用程序设计为依靠本地计算资源在单个服务器上运行。其它用例包括可能需要客户端设备长时间保持与特定服务器的连接。例如，实时多人游戏必须以非常低的延迟为多个玩家提供一致的游戏世界视图。在非分布式实现中实现这一点要简单得多，其中参与者连接到同一服务器。

仍然可以通过将负载分配到具有会话亲缘关系的多个节点来水平扩展这些组件。在此模型中，将会话的所有事务绑定到特定的计算资源。但是，这个模型确实有一些局限性。现有会话不会直接受益于新启动的计算节点的引入。更重要的是，无法保证会话亲和力。例如，当节点终止或变得不可用时，绑定到该节点的用户将断开连接并遇到特定于会话的数据丢失，这些数据不会存储在共享资源，如Amazon S3，Amazon EFS或a数据库。

5) 实现会话亲和性

对于HTTP和HTTPS流量，你可以使用应用程序负载均衡器的粘性会话功能，将用户的会话绑定到特定实例。使用此功能，应用程序负载均衡器将尝试在该持续时间内为该用户使用相同的服务器会议。另一个选项，如果你控制在客户端上运行的代码，是使用客户端负载平衡。这会增加额外的复杂性，但在负载均衡器不符合你的要求的情况下非常有用。例如，你可能正在使用ELB不支持的协议，或者你可能需要完全控制如何将用户分配给服务器（例如，在游戏场景中