译者序

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不支持的协议，或者你可能需要完全控制如何将用户分配给服务器（例如，在游戏场景中，可能需要确保游戏参与者匹配并连接到相同的服务器）。在此模型中，客户端需要一种方法来发现有效的服务器端点以直接连接。可以使用DNS，或者你可以构建一个简单的发现API，以便将该信息提供给客户端上运行的软件。在没有负载均衡器的情况下，还需要在客户端实现健康检查机制。应该设计客户端逻辑，以便在检测到服务器不可用时，设备重新连接到另一台服务器，而对应用程序几乎没有中断。

6) 分布式处理

涉及处理大量数据的用例，无法及时处理单个计算资源的任何事物，需要采用分布式处理方法。通过将任务及其数据划分为许多小的工作片段，可以跨一组计算资源并行执行它们。

7）实施分布式处理

通过使用AWS Batch，AWS Glue和Apache Hadoop等分布式数据处理引擎，可以水平扩展脱机批处理作业。在AWS上，可以使用Amazon EMR在一组EC2实例之上运行Hadoop工作负载，而无需运维复杂性。对于流数据的实时处理，Amazon Kinesis将数据分成多个分片，然后由多个Amazon EC2或AWS Lambda资源使用，以实现可扩展性。

有关这些类型工作负载的更多信息，请参阅《Big Data Analytics Options on AWS 》和《Core Tenets of IoT》白皮书。

4.2 一次性资源而不是固有服务器

在传统的基础架构环境中，由于引入新硬件的前期成本和前置时间，必须使用固定资源。这推动了诸如手动登录服务器以配置软件或修复问题，硬编码IP地址以及按顺序运行测试或处理作业等实践。

在为AWS设计时，可以利用云计算的动态配置特性。可以将服务器和其他组件视为临时资源。可以根据需要启动任意数量实例，并且只在需要时使用它们。

长期运行的服务器的另一个问题是配置偏差。随时间推移应用的更改和软件修补程序可能会导致跨不同环境的未经测试和异构配置。可以使用不可变的基础架构结构模型模式解决此问题。使用这种方法方式，服务器一旦启动永远不会更新。相反，当出现问题或需要更新时，问题服务器将替换为具有最新配置的新服务器。这使资源始终处于一致（和测试）状态，并使回滚更容易执行。使用无状态体系结构更容易支持这一点。

4.2.1 实例化计算资源

无论是部署新环境进行测试，还是增加现有系统的容量来应对额外负载，你都不希望使用其配置和代码手动设置新资源。重要的是，你要使其成为一个自动化且可重复的过程，以避免较长的交付周期，并且不会出现人为错误。有几种方法可以实现这一目标。

1）引导

启动AWS资源（如EC2实例或AmazonRelational Database Service（Amazon RDS）数据库实例）时，将启动默认配置。然后，可以执行自动引导操作，这些操作是安装软件或复制数据以将该资源带入特定状态的脚本。可以参数化在不同环境（例如生产或测试）之间变化的配置详细信息，以便可以重复使用相同的脚本而无需进行任何修改。

可以使用用户数据脚本和cloud-init指令设置新的EC2实例。可以使用简单的脚本和配置管理工具，例如Chef或Puppet。此外，通过自定义脚本和AWS API，或AWS AWS支持的自定义资源的AWS CloudFormation支持，可以编写几乎适用于任何AWS资源的配置逻辑。

2）黄金镜像

某些AWS资源类型（例如EC2实例，AmazonRDS数据库实例和Amazon Elastic Block Store，Amazon EBS）可以从黄金镜像启动，黄金镜像是该资源的特定状态的快照。与引导方法相比，黄金镜像可以缩短启动时间并消除对配置服务或第三方存储库的依赖性。这在自动扩展环境中非常重要，在这种环境中，你希望能够快速可靠地启动其他资源，以响应需求变化。

可以自定义EC2实例，然后通过创建Amazon Machine Image（AMI）来保存其配置。可以根据需要从AMI启动任意数量的实例，并且它们都将包括这些自定义项。每次要更改配置时，都必须创建一个新的黄金镜像，因此必须具有版本控制约定来管理你的黄金镜像。建议你使用脚本为你用于创建的EC2实例创建引导程序的AMI。这为你提供了一种灵活的方法来测试和修改这些镜像。

或者，如果你具有现有的本地虚拟化环境，则可以使用AWS的VM导入/导出将各种虚拟化格式转换为AMI。你还可以查找和使用AWS或AWS中的第三方提供的预封装共享AMI。

虽然启动新EC2实例时最常使用黄金镜像，但它们也可以应用于Amazon RDS数据库实例或Amazon EBS卷等资源。例如，当启动新的测试环境时，你可能希望通过从特定的Amazon RDS快照实例化数据库来预填充其数据库，而不是从冗长的SQL脚本中导入数据。

3）容器

开发人员喜欢的另一个选择是Docker，一种开源技术，允许你在软件容器内构建和部署分布式应用程序。Docker允许你将一个软件封装在Docker镜像中，这是一个软件开发的标准化单元，包含软件运行所需的所有内容：代码，运行时，系统工具，系统库等。AWS Elastic Beanstalk，Amazon ElasticContainer 服务（Amazon ECS）和AWSFargate允许你跨EC2实例集群部署和管理多个容器。你可以构建黄金Docker镜像并使用ECS容器注册表来管理它们。

另一种容器环境是Kubernetes和Kubernetes的亚马逊弹性容器服务（Amazon EKS）。借助Kubernetes和Amazon EKS，你可以轻松部署，管理和扩展容器化应用程序。

4）混合

你还可以使用这两种方法的组合：配置的某些部分在黄金镜像中捕获，而其他部分则通过引导操作动态配置。

不经常更改或引入外部依赖项的项目通常是你的黄金镜像的一部分。一个好的候选者的例子是你的Web服务器软件，否则每次启动实例时都必须由第三方存储库下载。

可以通过引导操作动态设置在不同环境之间经常更改或不同的项目。例如，如果要经常部署应用程序的新版本，则为每个应用程序版本创建新的AMI可能不切实际。你也不希望将数据库主机名配置硬编码到AMI，因为测试和生产环境之间会有所不同。用户数据或标签允许你使用可在启动时修改的更通用的AMI。例如，如果你为各种小型企业运行Web服务器，则它们都可以使用相同的AMI，并从启动时在用户数据中指定的S3存储桶位置检索其内容。

AWS Elastic Beanstalk遵循混合模型。它提供预配置的运行时环境，每个环境都是从其自己的AMI11启动的，但允许你通过ebextensions配置文件运行引导操作，并配置环境变量以参数化环境差异。

4.2.2 基础架构即代码

我们讨论的原则的应用不必限于单个的资源水平。由于AWS资源是可编程的，因此你可以应用软件开发中的技术，实践和工具，使你的整个基础架构可重用，可维护，可扩展和可测试。

AWS CloudFormation模板为你提供了一种简单的方法来创建和管理相关AWS资源的集合，并以有序和可预测的方式提供和更新它们。你可以描述运行应用程序所需的AWS资源，以及任何关联的依赖项或运行时参数。你的CloudFormation模板可以与你的版本控制存储库中的应用程序一起使用，这样你就可以重用架构并可靠地克隆生产环境以进行测试。

4.3 自动化

在传统的IT基础架构中，你通常必须手动对各种事件做出反应。在AWS上部署时，你可以进行自动化。

为了提高系统的稳定性和组织的效率，考虑将一种或多种这类自动化引入你的应用程序体系结构，以确保更高的弹性，可伸缩性和性能。

4.3.1 无服务器管理和部署

采用无服务器模式时，操作重点是部署自动化流水线。AWS管理基础服务，规模和可用性。AWS CodePipeline，AWS CodeBuild和AWS CodeDeploy支持这些流程部署的自动化。

4.3.2 基础架构管理和部署

AWS Elastic Beanstalk：你可以使用此服务在熟悉的服务器（如Apache，Nginx，Passenger和服务器）上部署和扩展使用Java，.NET，PHP，Node.js，Python，Ruby，Go和Docker开发的Web应用程序和服务。IIS开发人员可以简单地上传他们的应用程序代码，该服务自动处理所有细节，例如资源配置，负载平衡，自动扩展和监视。

Amazon EC2自动恢复：你可以创建监控EC2实例的Amazon CloudWatch警报，并在其受损时自动恢复。恢复的实例与原始实例相同，包括实例ID，私有IP地址，弹性IP地址，和所有实例元数据。但是，此功能仅适用于适用的实例配置。有关这些前提条件的最新说明，请参阅Amazon EC2文档。此外，在实例恢复期间，实例将通过实例重新引导进行迁移，并且内存中的所有数据都将丢失。

AWS Systems Manager：你可以自动收集软件清单，应用操作系统补丁，创建系统镜像以配置Windows和Linux操作系统，以及执行任意命令。提供这些服务简化了操作模型并确保了最佳的环境配置。

Auto Scaling：你可以根据你定义的条件自动维护应用程序可用性，并自动扩展Amazon EC2，Amazon DynamoDB，Amazon ECS，适用于Kubernetes的Amazon Elastic Container Service，（Amazon EKS）容量。你可以使用Auto Scaling帮助确保跨多个可用区运行所需数量的健康EC2实例。Auto Scaling还可以在需求峰值期间自动增加EC2实例的数量，在不太繁忙的时期保持性能并降低容量以优化成本。

4.3.3 警报和事件

Amazon CloudWatch警报：你可以创建CloudWatch警报，当特定指标超过指定阈值达指定数量的时段时，该警报会发送AmazonSimple Notification Service（Amazon SNS）消息。这些Amazon SNS消息可以自动启动执行订阅的Lambda函数，将通知消息排入Amazon SQS队列，或者对HTTP或HTTPS端点执行POST请求。

Amazon CloudWatchEvents：提供近乎实时的系统事件流，描述AWS资源中的变更.使用简单规则，你可以将每种类型的事件路由到一个或多个目标，例如Lambda函数，Kinesis流和SNS主题。

AWS Lambda预定事件：你可以创建Lambda函数并配置AWS Lambda以定期执行它。

AWS WAF安全自动化：AWS WAF是一种Web应用程序防火墙，使你能够创建自定义的特定于应用程序的规则，以阻止可能影响应用程序可用性，危及安全性或消耗过多资源的常见攻击模式。你可以通过API完全管理AWS WAF，从而简化安全自动化，实现快速规则传播和快速事件响应。

4.4 松耦合

随着应用程序复杂性的增加，IT系统的理想属性是可以将其分解为更小，松耦合的组件。这意味着IT系统的设计应该能够减少相互依赖性，一个组件中的更改或故障不应该级联到其他组件。

4.4.1 定义明确的接口

减少系统中相互依赖性的一种方法是允许各种组件仅通过特定的，与技术无关的接口（例如RESTful API）相互交互。通过这种方式，隐藏了技术实现细节，以便团队可以修改底层实现而不影响其他组件。只要这些接口保持向后兼容性，差异组件的部署就会分离。这种粒度设计模式通常被称为微服务架构。

Amazon API Gateway是一种完全托管的服务，使开发人员可以轻松地以任何规模创建，发布，维护，监控和保护API。它处理接受和处理多达数十万个并发API调用所涉及的所有任务，包括流量管理，授权和访问控制，监控和API版本管理。

4.4.2 服务发现

部署为一组较小服务的应用程序取决于这些服务相互交互的能力。因为每个服务都可以跨多个计算资源运行，所以需要有一种方法来解决每个服务。例如，在传统基础结构中，如果你的前端Web服务需要与后端Web服务连接，则可以对运行此服务的计算资源的IP地址进行硬编码。虽然这种方法仍然适用于云计算，但如果这些服务是松耦合的，那么它们应该能够在不事先了解其网络拓扑细节的情况下使用。除了隐藏复杂性之外，这还允许基础架构细节随时更改。如果你想利用云计算的弹性，可以在任何时间点启动或终止新资源，那么松耦合是一个至关重要的因素。为了实现这一目标，你需要一些实现服务发现的方法。

实施服务发现

对于Amazon EC2托管的服务，实现服务发现的一种简单方法是通过Elastic LoadBalancing（ELB）。由于每个负载均衡器都有自己的主机名，因此你可以通过稳定的endpoint使用服务。这可以与DNS和私有Amazon Route 53区域结合使用，以便可以随时抽象和修改特定负载均衡器的endpoint。

另一种选择是使用服务注册和发现方法来允许检索任何服务的endpoint IP地址和端口号。由于服务发现成为组件之间的粘合剂，因此高度可用且可靠性非常重要。如果未使用负载平衡器，则还应该进行服务发现允许健康检查等选项。Amazon Route 53支持自动命名，以便更轻松地为微服务配置实例。自动命名允许你根据定义的配置自动创建DNS记录。其他示例实现包括使用标签组合的自定义解决方案，高可用性数据库，调用AWSAPI的自定义脚本，或Netflix Eureka，AirbnbSynapse或HashiCorp Consul等开源工具。

4.4.3 异步集成

异步集成是服务之间松耦合的另一种形式。此模型适用于任何不需要立即响应的交互，以及已经注册请求的确认就足够了。它涉及一个生成事件的组件和另一个消耗它们的组件。这两个组件不通过直接的点对点交互进行集成，而是通过中间持久存储层进行集成，例如SQS队列或流式数据平台（如Amazon Kinesis），级联Lambda事件，AWS步骤功能或AmazonSimple Workflow服务。

图1：紧耦合和松耦合

这种方法将两个组件分离，并引入了额外的弹性。因此，例如，如果正在从队列中读取消息的进程失败，则仍可以将消息添加到队列中并在系统恢复时进行处理。它还允许你保护不太可扩展的后端服务免受前端尖峰的攻击，并找到正确的成本和处理滞后之间的权衡。例如，你可以决定不需要扩展数据库以适应偶尔的写入查询峰值，只要你最终以一些延迟异步处理这些查询。最后，通过从交互式请求路径中删除慢速操作，你还可以改善最终用户体验。

异步集成的示例包括：

前端应用程序将作业插入队列系统（如Amazon SQS）。后端系统检索这些作业并按照自己的进度处理它们。API生成事件并将其推送到Kinesis流中。后端应用程序批量处理这些事件以创建存储在数据库中的聚合时间序列数据。多个异构系统使用AWS步骤函数来传达它们之间的工作流，而无需直接相互交互。Lambda函数可以使用来自各种AWS源的事件，例如Amazon DynamoDB更新流和Amazon S3事件通知。你不必担心实现排队或其他异步集成方法，因为Lambda会为你处理此问题。

4.4.4 分布式系统最佳实践

增加松耦合的另一种方法是构建以优雅方式处理组件故障的应用程序。你可以确定减少对最终用户的影响的方法，并提高你在脱机过程中取得进展的能力，即使在某些组件发生故障时也是如此。

实践中优雅的应对失败

失败的请求可以使用指数退避和抖动策略重试，也可以存储在队列中以供以后处理。对于前端接口，可以提供替代或缓存的内容，而不是完全失败，例如，你的数据库服务器变得不可用。Amazon Route 53 DNS故障转移功能还使你能够监控你的网站，并在主站点不可用时自动将访问者路由到备份站点。你可以将备份站点作为Amazon S3上的静态网站托管，也可以作为单独的动态环境托管。

4.4.5 服务，而不是服务器

开发，管理和运维应用程序，尤其是大规模应用程序，需要各种各样的底层技术组件。对于传统的IT基础架构，公司必须构建和运行所有这些组件。

AWS提供广泛的计算，存储，数据库，分析，应用程序和部署服务，可帮助组织更快地移动并降低IT成本。

不利用这种广度的架构（例如，如果它们仅使用AmazonEC2）可能无法充分利用云计算，并且可能错失了提高开发人员生产力和运营效率的机会。

4.4.5.1 管理服务

AWS托管服务提供开发人员可以使用的构建块来为其应用程序供电。这些托管服务包括数据库，机器学习，分析，排队，搜索，电子邮件，通知等。例如，使用Amazon SQS，你可以减轻运维和扩展高可用性消息传递群集的管理负担，同时仅为你使用的内容支付低价。Amazon SQS本身也具有可扩展性和可靠性。这同样适用于Amazon S3，它使你可以根据需要存储尽可能多的数据，并在需要时访问它，而无需考虑容量，硬盘配置，复制和其他相关问题。

为你的应用程序提供支持的托管服务的其他示例包括：

用于内容交付的AmazonCloudFront用于负载平衡的ELB用于NoSQL数据库的Amazon DynamoDB用于搜索工作负载的AmazonCloudSearch用于视频编码的Amazon ElasticTranscoder用于发送和接收电子邮件的AmazonSimple Email Service（Amazon SES）

4.4.5.2 无服务器计算架构

无服务器计算架构可以降低运行应用程序的操作复杂性。无需管理任何服务器基础架构，就可以为移动，Web，分析，CDN业务逻辑和物联网构建事件驱动和同步服务。这些体系结构可以降低成本，因为你无需管理或支付未充分利用的服务器，也无需配置冗余基础架构来实现高可用性。

例如，你可以将代码上载到AWS Lambda计算服务，并且该服务可以使用AWS基础结构代表你运行代码。使用AWS Lambda，你需要为代码执行的每100毫秒以及触发代码的次数付费。通过使用Amazon API Gateway，你可以开发由AWS Lambda支持的几乎无限可扩展的同步API。与Amazon S3结合使用以提供静态内容资产时，此模式可以提供完整的Web应用程序。

在移动和Web应用程序方面，你可以使用Amazon Cognito，这样你就无需管理后端解决方案来处理用户身份验证，网络状态，存储和同步。Amazon Cognito为你的用户生成唯一标识符。

可以在访问策略中引用这些标识符，以基于每个用户启用或限制对其他AWS资源的访问。Amazon Cognito为你的用户提供临时AWS凭证，允许设备上运行的移动应用程序直接与受AWS身份和访问管理（IAM）保护的AWS服务进行交互。例如，使用IAM，你可以将对S3存储桶中的文件夹的访问权限限制为特定的最终用户。

对于物联网应用，组织传统上必须配置，操作，扩展和维护自己的服务器作为设备网关，以处理连接设备与其服务之间的通信。AWS IoT提供完全受管理的设备网关，可根据你的使用情况自动扩展，无需任何操作开销。

无服务器计算架构还使得在边缘计算运行响应式服务成为可能。

4.5 数据库

对于传统的IT基础架构，组织通常仅限于可以使用的数据库和存储技术。可能存在基于许可成本和支持各种数据库引擎的能力的约束。在AWS上，这些约束由托管数据库服务解除，这些服务以开源成本提供企业性能。因此，应用程序在多语言数据层之上运行并为每个工作负载选择正确的技术并不罕见。

4.5.1 为每项业务负载选择正确的数据库技术

下面的问题可以帮助你决定在架构中包含哪些解决方案：

这是一个读多，写多或读写平衡的业务负载吗？你需要每秒多少次读写操作？如果用户数量增加，这些值将如何变化？你需要存储多少数据以及存储多长时间？会增长多快？在不久的将来是否有上限？每个对象的大小（平均值，最小值，最大值）是多少？如何访问这些对象？数据持久性方面的要求是什么？这个数据存储是否“真实来源？”你的延迟要求是什么？你需要支持多少并发用户？你的数据模型是什么以及如何查询数据？你的查询本质上是关系型的（例如，多个表之间的JOIN）？你可以对模型进行非规范化，以创建更容易扩展的更平坦的数据结构吗？你需要什么样的功能？你是否需要强大的完整性控制，或者你是否在寻求更大的灵活性（例如，无架构数据存储）？你需要复杂的报告或搜索功能吗？你的开发人员是否比NoSQL更熟悉关系数据库？相关的数据库技术许可成本是多少？这些成本是否会考虑应用程序开发投资，存储和使用成本？许可模式是否支持预计的增长？你是否可以使用Amazon Aurora等云原生数据库引擎来获得开源数据库的简单性和成本效益？

4.5.2 关系数据库

关系数据库（也称为RDBS或SQL数据库）将数据规范化为称为表的明确表格结构，表格由行和列组成。它们提供强大的查询语言，灵活的索引功能，强大的完整性控制，以及快速有效地组合来自多个表的数据的能力。Amazon RDS可以轻松地在云中设置，操作和扩展关系数据库，并支持许多熟悉的数据库引擎。

4.5.2.1 可扩展性

关系数据库可以通过升级到更大的Amazon RDS数据库实例或添加更多更快的存储来垂直扩展。此外，请考虑使用Amazon Aurora，它是一种数据库引擎，与在同一硬件上运行的标准MySQL相比，可提供更高的吞吐量。对于读取繁重的应用程序，你还可以通过创建一个或多个只读副本来横向扩展超出单个数据库实例的容量限制。

只读副本是异步复制的单独数据库实例。因此，它们会受到复制滞后的影响，可能会丢失一些最新的事务。应用程序设计人员需要考虑哪些查询对稍微陈旧的数据具有容忍度。这些查询可以在只读副本上执行，而其余查询应该在主节点上运行。只读副本也不能接受任何写入查询。

需要将其写入容量扩展到单个数据库实例的约束之外的关系数据库工作负载需要使用称为数据分区或分片的不同方法。使用此模型，数据分别跨多个数据库模式在自己的主要数据库实例中运行。尽管Amazon RDS消除了运行这些实例的操作开销，但分片会为应用程序带来一些复杂性。需要修改应用程序的数据访问层，以了解数据的分割方式，以便将查询定向到正确的实例。此外，必须跨多个数据库模式执行模式更改，因此值得投入一些精力来自动执行此过程。

4.5.2.2 高可用性

对于任何生产关系数据库，我们建议使用Amazon RDS MultiAZ部署功能，该功能在不同的可用区中创建同步复制的备用实例。如果主节点发生故障，Amazon RDS会自动故障转移到备用节点，而无需手动管理干预。执行故障转移时，会有一段短时间内无法访问主节点。通过使用只读副本提供减少的功能（例如只读模式），可以为弹性应用程序设计弹性应用程序。Amazon Aurora提供多主机功能，可以在可用区域之间扩展读取和写入，还支持跨区域复制。

4.5.2.3 非标准模型

如果你的应用程序主要索引和查询数据而不需要连接或复杂事务，特别是如果你希望写入吞吐量超出单个实例的约束，请考虑使用NoSQL数据库。如果你有大型二进制文件（音频，视频和图像），则在Amazon S3中存储实际文件并仅保存数据库中文件的元数据会更有效。

4.5.3 NoSQL数据库

NoSQL数据库交换关系数据库的一些查询和事务功能，以获得更灵活的数据模型，可以无缝地水平扩展。NoSQL数据库使用各种数据模型，包括图形，键值对和JSON文档，并且因易于开发，可扩展性能，高可用性和弹性而广受认可。Amazon DynamoDB是一种快速灵活的NoSQL数据库服务，适用于任何规模都需要一致，一位数，毫秒级延迟的应用程序.它是一个完全托管的云数据库，支持文档和键值存储模型。

4.5.3.1 可扩展性

NoSQL数据库引擎通常会执行数据分区和复制，以便以水平方式扩展读取和写入。它们透明地执行此操作，并且不需要在应用程序的数据访问层中实现的数据分区逻辑。特别是Amazon DynamoDB自动管理表分区，随着表的大小增加或者读取配置和写入配置容量更改而添加新分区。Amazon DynamoDB Accelerator（DAX）是DynamoDB的托管，高可用内存缓存，可充分利用性能提升。

4.5.3.2 高可用性

Amazon DynamoDB在AWS区域中的三个设施之间同步复制数据，在服务器发生故障或可用区域中断时提供容错功能。Amazon DynamoDB还支持全局表，以提供完全托管的多区域，多主数据库，为大规模扩展的全局应用程序提供快速，本地，读取和写入性能。全局表在所选AWS区域中复制。

4.5.3.3 非标准模型

如果你的模型无法规范化，并且你的应用程序需要连接或复杂事务，请考虑使用关系数据库。如果你有大型二进制文件（音频，视频和图像），请考虑将文件存储在Amazon S3中，并将文件的元数据存储在数据库中。

4.5.4 数据仓库

数据仓库是一种特殊类型的关系数据库，它针对大量数据的分析和报告进行了优化。它可用于组合来自不同来源的交易数据（例如Web应用程序中的用户行为，来自财务和计费系统的数据，或客户关系管理或CRM），以使其可用于分析和决策。

传统上，设置，运行和扩展数据仓库既复杂又昂贵。在AWS上，你可以利用Amazon Redshift，这是一种托管数据仓库服务，其运行成本仅为传统解决方案的十分之一。

4.5.4.1 可扩展性

Amazon Redshift通过大规模并行处理（MPP），列式数据存储和目标数据压缩编码方案的组合实现了高效存储和最佳查询性能。它特别适用于针对超大型数据集的分析和报告工作负载。Amazon Redshift MPP体系结构使你可以通过增加数据仓库集群中的节点数来提高性能。Amazon Redshift Spectrum支持Amazon RedshiftSQL查询，以防止Amazon S3中的数据数据，从而将AmazonRedshift的分析功能从存储在数据仓库中本地磁盘上的数据扩展到非结构化数据，而无需加载或转换数据。

4.5.4.2 高可用性

Amazon Redshift具有多种功能，可增强数据仓库集群的可靠性。我们建议你在多节点群集中部署生产工作负载，以便将写入节点的数据自动复制到群集中的其他节点。数据也会持续备份到Amazon S3。Amazon Redshift持续监视群集的运行状况，并自动重新启动故障驱动器中的数据，并根据需要替换节点。

4.5.4.3 非标准模型

由于Amazon Redshift是基于SQL的关系数据库管理系统（RDBMS），因此它与其他RDBMS应用程序和商业智能工具兼容。虽然Amazon Redshift提供典型RDBMS的功能，包括在线事务处理（OLTP）功能，但它并非针对这些工作负载而设计。如果你期望高并发工作负载通常涉及一次读取和写入少量记录的所有列，则应考虑使用Amazon RDS或Amazon DynamoDB。

4.5.5 搜索

搜索经常与查询混淆。查询是正式的数据库查询，以正式术语表示特定数据集。搜索可以查询未精确构建的数据集。因此，需要复杂搜索功能的应用程序通常会超出关系数据库或NoSQL数据库的功能。搜索服务可用于索引和搜索结构化和自由文本格式，并且可以支持其他数据库中不可用的功能，例如可自定义的结果排名，过滤的分面，同义词和词干。

在AWS上，你可以选择Amazon CloudSearch和Amazon ElasticsearchService（Amazon ES）。AmazonCloudSearch是一项托管服务，几乎不需要配置，并且会自动扩展。Amazon ES提供开源API，使你可以更好地控制配置详细信息。亚马逊ES也已经发展成为一个不仅仅是一个搜索解决方案。它通常用作日志分析，实时应用程序监控和点击流分析等用例的分析引擎。

4.5.5.1 可扩展性

Amazon CloudSearch和Amazon ES都使用数据分区和复制来横向扩展。不同之处在于，使用Amazon CloudSearch，你无需担心需要多少分区和副本，因为该服务会自动处理该分区和副本。

4.5.5.2 高可用性

Amazon CloudSearch和Amazon ES都包含跨可用区冗余存储数据的功能。

4.5.6 图数据库

图形数据库使用图形结构进行查询。图形被定义为由边（关系）组成，其直接与商店中的节点（数据实体）相关。这些关系使商店中的数据可以直接链接在一起，从而可以快速检索关系系统中复杂的层次结构。出于这个原因，图形数据库是专门用于存储和导航关系的，通常用于社交网络，推荐引擎和欺诈检测等用例中，你需要能够在数据之间创建关系并快速查询这些关系。

Amazon Neptune是一个完全托管的图形数据库服务。

4.5.6.1 可扩展性

Amazon Neptune是专为处理图形查询而优化的专用高性能图形数据库。

4.5.6.2 高可用性

Amazon Neptune具有高可用性，具有只读副本，时间点恢复，连续备份到Amazon S3以及跨可用区复制。海王星是安全的，支持静止和传输中的加密。

4.5.7 管理不断增加的数据量

传统的数据存储和分析工具无法再提供提供相关业务洞察所需的灵活性和灵活性。这就是为什么许多组织正在转向数据湖架构。数据湖是一种架构方法，允许你将大量数据存储在中央位置，以便你可以随时对组织内的不同组进行分类，处理，分析和使用。由于数据可以按原样存储，因此你无需将其转换为预定义的架构，并且你不再需要事先了解有关数据的问题。这使你可以选择正确的技术来满足你的特定分析要求。

4.5.8 消除单点故障

生产系统通常具有定义或隐含的正常运行时间目标。当系统能够承受单个组件或多个组件（例如硬盘，服务器和网络链路）的故障时，该系统具有高可用性。为了帮助你创建具有高可用性的系统，你可以考虑自动化恢复的方法，并减少架构每一层的中断。

4.5.8.1 引入冗余

通过引入冗余可以消除单点故障，这意味着你可以为同一任务提供多个资源。冗余可以在待机或主动模式下实现。

在主备冗余中，当资源发生故障时，将使用故障转移过程在备用资源上恢复功能。故障转移通常需要一些时间才能完成，在此期间资源仍然不可用。备用资源既可以在需要时自动启动（以降低成本），也可以已经空闲运行（以加速故障转移并最大限度地减少中断）。主备冗余通常用于有状态组件，例如关系数据库。

在主主冗余中，请求被分发到多个冗余计算资源。当其中一个失败时，其余的可以简单地吸收更大份额的工作量。与备用冗余相比，主动冗余可以实现更好的使用，并在出现故障时影响较小的人口。

4.5.8.2 检测失败

你应该在检测和响应故障时尽可能多地构建自动化。你可以使用ELB和Amazon Route 53等服务通过将流量路由到健康端点来配置运行状况检查和屏蔽故障。此外，你可以使用Auto Scaling或使用Amazon EC2自动恢复功能或AWS Elastic Beanstalk等服务自动替换不健康的节点。无法在第一天预测每种可能的故障情况。确保收集足够的日志和指标以了解正常的系统行为。了解之后，你将能够设置警报以进行手动干预或自动响应。

设计良好的健康检查

为应用程序配置正确的运行状况检查有助于确定你是否能够正确，及时地响应各种故障情况。指定错误的运行状况检查实际上可能会降低应用程序的可用性。

在典型的三层应用程序中，你可以在ELB上配置运行状况检查。设计你的运行状况检查，目的是可靠地评估后端节点的运行状况。简单的TCP运行状况检查不会检测实例本身是否正常但Web服务器进程是否已崩溃。相反，你应该评估Web服务器是否可以针对某个简单请求返回HTTP 200响应。

在此层，配置深层运行状况检查可能不是一个好主意，这是一种依赖于应用程序的其他层成功的测试，因为可能会导致误报。例如，如果你的运行状况检查还评估实例是否可以连接到后端数据库，则当该数据库节点很快不可用时，你可能会将所有Web服务器标记为不健康。分层方法通常是最好的。深度健康检查可能适合在亚马逊Route53级实施。通过运行更全面的检查来确定该环境是否能够实际提供所需的功能，你可以将Amazon Route 53配置为故障转移到网站的静态版本，直到数据库启动并再次运行。

4.5.8.3 可靠的数据存储

你的应用程序和用户将创建和维护各种数据。你的体系结构保护数据可用性和完整性至关重要。数据复制是引入冗余数据副本的技术。它可以帮助水平扩展读取容量，但它也提高了数据的耐用性和可用性。复制可以在几种不同的模式下进行。

同步复制仅在主要位置及其副本中持久存储之后才确认事务。它是保护主节点发生故障时数据完整性的理想选择。同步复制还可以扩展需要最新数据（强一致性）的查询的读取容量。同步复制的缺点是主节点耦合到副本。在所有副本执行写入之前，无法确认事务。这可能会影响性能和可用性，尤其是在运行不可靠或高延迟网络连接的拓扑中。出于同样的原因，不建议维护许多同步副本。

无论你的解决方案的耐用性如何，这都不能替代备份。同步复制冗余地存储你的数据的所有更新，甚至是那些由软件错误或人为错误导致的更新。但是，特别是对于存储在Amazon S3上的对象，你可以使用版本控制来保留，检索和还原其任何版本，通过版本控制，你可以从非预期的用户操作和应用程序故障中恢复。

异步复制以引入复制延迟为代价将主节点与其副本解耦。这意味着主节点上的更改不会立即反映在其副本上。异步副本用于水平扩展系统对可以容忍复制延迟的查询的读取容量。当故障转移期间可以容忍某些最近事务丢失时，它还可用于提高数据持久性。例如，你可以在单独的AWS区域中维护数据库的异步副本作为灾难恢复解决方案。

基于Quorum的复制结合了同步和异步复制，以克服大规模分布式数据库系统的挑战。

可以通过定义必须参与成功写入操作的最小数量的节点来管理到多个节点的复制。详细讨论分布式数据存储超出了本文档的范围。有关分布式数据存储的更多信息以及超可扩展且高度可靠的数据库系统的核心原则。

了解你使用的每种技术在这些数据存储模型中的位置非常重要。在各种故障转移或备份/还原方案期间，它们的行为应与恢复点目标（RPO）和恢复时间目标（RTO）保持一致。你必须确定你希望丢失的数据量以及恢复操作所需的速度。例如，AmazonElastiCache的Redis引擎支持使用自动故障转移进行复制，但Redis引擎的复制是异步的。在故障转移期间，很可能会丢失一些最近的事务。但是，具有多可用区功能的Amazon RDS旨在提供同步复制，以使备用节点上的数据与主节点保持同步。

4.5.8.4 自动化的多数据中心恢复能力

业务关键型应用程序还需要针对不仅影响单个磁盘，服务器或机架的中断方案进行保护。在传统基础架构中，你通常需要一个灾难恢复计划，以便在主要数据中心发生重大中断时允许故障转移到远程第二个数据中心。由于两个数据中心之间的距离很远，因此延迟使得维护数据的同步跨数据中心副本变得不切实际。因此，故障转移肯定会导致数据丢失或数据恢复过程非常昂贵。这使故障转移成为一种风险并且不总是经过充分测试的程序。尽管如此，这种模型可以提供出色的保护，防止低概率但具有巨大的影响风险，例如长期影响整个基础设施的自然灾害。

更可能的情况是数据中心中断时间更短。对于预计故障持续时间不长的短暂中断，执行故障转移的选择是困难的并且通常被避免。在AWS上，可以采用更简单，更有效的保护来防止此类故障。每个AWS区域包含多个不同的位置或可用区。每个可用区都设计为独立于其他可用区中的故障。可用区是数据中心，在某些情况下，可用区由多个数据中心组成。区域内的可用区域提供廉价，低延迟的网络连接到同一地区的其他区域。这允许你以同步方式跨数据中心复制数据，以便故障转移可以自动化并对用户透明。

也可以实现主动冗余。例如，一组应用程序服务器可以分布在多个可用区中，并附加到ELB。当特定可用区的EC2实例未通过运行状况检查时，ELB将停止向这些节点发送流量。此外，AWS Auto Scaling可确保正确数量的EC2实例可用于运行你的应用程序，根据需求启动和终止实例，并由你的扩展策略定义。如果你的应用程序由于可用区故障而不需要短期性能下降，那么你的体系结构应该是静态稳定的，这意味着它不需要更改工作负载的行为以容忍故障。在这种情况下，你的体系结构应该提供多余的容量来承受一个可用区的丢失。

AWS上的许多高级服务都是根据多可用区（多可用区）原则设计的。例如，AmazonRDS使用多可用区部署为数据库实例提供高可用性和自动故障转移支持，而对于Amazon S3和Amazon DynamoDB，你的数据跨多个设施进行冗余存储。

4.5.8.5 故障隔离与传统水平扩展

虽然主主冗余模式非常适合平衡流量和处理实例或可用区中断，但如果对请求本身有任何不利影响是不够的。例如，可能存在每个实例都受到影响的情况。如果某个特定请求碰巧触发导致系统故障转移的错误，则调用者可能会通过反复尝试针对所有实例的相同请求来触发级联故障。

随机分片

你可以对传统的水平缩放进行隔离改进，这称为分片。与传统上与数据存储系统一起使用的技术类似，你可以将实例分组为分片，而不是在每个节点上传播来自所有客户的流量。例如，如果你的服务有八个实例，则可以创建四个分片，每个分片包含两个实例（每个分片中有两个实例用于冗余），并将每个客户分配到特定分片。

就这样，你能够与你拥有的分片数量成正比地减少对客户的影响。但是，一些客户仍然会受到影响，因此关键是要使客户端容错。如果客户端可以尝试一组分片资源中的每个端点，直到成功，那么你将获得显着的改进。这种技术称为随机分片。

4.6 优化成本

当你将现有架构迁移到云中时，由于AWS的规模经济，你可以减少资本支出并节省成本。通过迭代和使用更多AWS功能，你可以有机会实现创建成本优化的云架构。

4.6.1 正确的实例

AWS为许多用例提供了广泛的资源类型和配置。例如，Amazon EC2，Amazon RDS，Amazon Redshift和Amazon ES等服务提供了许多实例类型。在某些情况下，你应该选择最适合你工作负载要求的类型。在其他情况下，使用较少实例类型的较少实例可能会降低总成本或提高性能。你应该对应用程序环境进行基准测试，并根据工作负载使用CPU，RAM，网络，存储大小和I / O的方式选择正确的实例类型。

同样，你可以通过选择适合你需求的存储解决方案来降低成本。例如，Amazon S3提供各种存储类，包括标准，简化冗余和标准 - 不常访问。其他服务（如Amazon EC2，Amazon RDS和Amazon ES）支持你应评估的不同EBS卷类型（磁性，通用SSD，预配置IOPS SSD）。

随着时间的推移，你可以通过持续监控和标记来继续降低成本。就像应用程序开发一样，成本优化是一个迭代过程。因为，你的应用程序及其使用将随着时间的推移而发展，并且由于AWS经常迭代并定期发布新选项，因此持续评估你的解决方案非常重要。

AWS提供的工具可帮助你识别这些节省成本的机会并使你的资源保持正确的大小。为了使这些工具的结果易于理解，你应该为AWS资源定义和实施标记策略。你可以使用AWS管理工具（如AWS Elastic Beanstalk和AWS OpsWorks）将标记作为构建过程的一部分进行自动化。你还可以使用AWS Config提供的托管规则来评估特定标记是否应用于你的资源。

4.6.2 充分利用弹性

使用AWS节省资金的另一种方法是利用平台的弹性。计划为尽可能多的Amazon EC2工作负载实施Auto Scaling，以便你在需要时横向扩展并缩小规模并在不再需要该容量时自动减少支出。此外，你可以在不使用时自动关闭非生产工作负载。最后，考虑你可以在AWS Lambda上实施哪些计算工作负载，以便你永远不会为空闲或冗余资源付费。

尽可能将AWS EC2工作负载替换为不需要你做出任何容量决策的AWS托管服务（例如ELB，Amazon CloudFront，Amazon SQS，Amazon Kinesis Firehose，AWS Lambda，Amazon SES，Amazon CloudSearch或Amazon EFS ）或使你能够在需要时轻松修改容量（例如Amazon DynamoDB，Amazon RDS或Amazon ES）。

4.6.3 充分利用各种采购方案

Amazon EC2 On-Demand实例定价为你提供最大的灵活性，无需长期承诺。另外两个可以帮助你减少开支的EC2实例是预留实例和竞价型实例。

4.6.3.1 预留实例

与按需实例定价相比，Amazon EC2预留实例允许你保留Amazon EC2计算容量，以换取大幅折扣的小时费率。这是具有可预测的最小容量要求的应用的理想选择。你可以利用AWS Trusted Advisor或Amazon EC2使用情况报告等工具来识别你最常使用且应考虑保留的计算资源。根据你的预留实例购买，折扣将反映在每月帐单中。按需EC2实例和预留实例在技术上没有区别。不同之处在于你为预留的实例付费的方式。

其他服务也存在预留容量选项（例如，Amazon Redshift，Amazon RDS，Amazon DynamoDB和Amazon CloudFront）。

提示：在对生产中的应用程序进行充分基准测试之前，不应提交预留实例购买。在你之后已购买预留容量，你可以使用预留实例利用率报告确保你仍在充分利用预留容量。

4.6.3.2 竞价实例

对于不太稳定的工作负载，请考虑使用竞价实例。Amazon EC2 Spot实例允许你使用备用Amazon EC2计算容量。由于与按需定价相比，竞价实例通常以折扣价格提供，因此你可以显着降低运行应用程序的成本。

竞价实例使你可以请求未使用的EC2实例，这可以显着降低你的Amazon EC2成本。竞价实例（每个可用区中的每个实例类型）的每小时价格由Amazon EC2设置，并根据竞价实例的长期供应和需求逐步调整。只要容量可用且你的请求的每小时最高价格超过竞价价格，你的竞价型实例就会运行。

因此，竞价实例非常适合可以容忍中断的工作负载。但是，当你需要更可预测的可用性时，也可以使用竞价型实例。例如，你可以将预留，按需和竞价型实例组合在一起，将可预测的最小容量与对其他计算资源的机会访问相结合，具体取决于竞价市场价格。这是提高吞吐量或应用程序性能的一种极具成本效益的方法。

4.7 缓存

缓存是一种存储先前计算的数据以供将来使用的技术。该技术用于提高应用程序性能并提高实现的成本效率。它可以应用于IT架构的多个层。

4.7.1 应用程序数据缓存

可以设计应用程序，以便它们从快速，托管，内存中的缓存中存储和检索信息。缓存信息可能包括I / O密集型数据库查询的结果，或计算密集型处理的结果。当在缓存中找不到结果集时，应用程序可以计算它，或者从数据库或昂贵的，缓慢变化的第三方内容中检索它，并将其存储在缓存中以用于后续请求。但是，当在缓存中找到结果集时，应用程序可以直接使用该结果，这可以改善最终用户的延迟并减少后端系统的负载。你的应用程序可以控制每个缓存项目保持有效的时间。在某些情况下，对于非常受欢迎的对象，即使几秒钟的缓存也会导致数据库负载的急剧下降。

Amazon ElastiCache是一种Web服务，可以轻松部署，操作和扩展云中的内存缓存。它支持两个开源的内存缓存引擎：Memcached和Redis。

Amazon DynamoDB Accelerator（DAX）是DynamoDB的完全托管，高可用性内存缓存，可提供从毫秒到微秒的性能改进，实现高吞吐量。DAX为你的DynamoDB表添加了内存加速，而无需管理缓存失效，数据填充或集群管理。

4.7.2 边缘缓存

静态内容（图像，CSS文件或流媒体预录制视频）和动态内容（响应式HTML，实时视频）的副本可以缓存在Amazon CloudFront边缘位置，这是一个在全球有多个存在点的CDN。边缘缓存允许内容由更接近的基础设施提供服务查看器，可以降低延迟并为你提供高大，持续的数据传输速率，从而为大规模的最终用户提供大型流行对象。

你的内容请求将智能地路由到Amazon S3或原始服务器。如果源在AWS上运行，请求将通过优化的网络路径传输，以获得更可靠和一致的体验。你可以使用Amazon CloudFront来交付整个网站，包括不可缓存的内容。在这种情况下，好处是Amazon CloudFront重用Amazon CloudFront边缘和源服务器之间的现有连接，这减少了每个源请求的连接设置延迟。还应用其他连接优化以避免互联网瓶颈并充分利用边缘位置和观看者之间的可用带宽。这意味着，当你浏览Web应用程序时，Amazon CloudFront可以加快你的动态内容的交付，并为你的查看者提供一致，可靠，个性化的体验。Amazon CloudFront还将上传请求应用于与下载动态内容请求相同的性能优势。安全

4.8 安全

你可能已经在传统IT基础架构中熟悉的大多数安全工具和技术都可以在云中使用。同时，AWS允许你以各种方式提高安全性。AWS是一个平台，允许你在平台本身中正式设计安全控制。它简化了管理员和IT部门的系统使用，使你的环境更容易以连续的方式进行审计。

4.8.1 使用AWS功能进行深度防御

AWS提供了许多功能，可以帮助你构建具有深度防御方法的体系结构。从网络级别开始，你可以构建VPC拓扑，通过使用子网，安全组和路由控制来隔离部分基础结构。AWS WAF（Web应用程序防火墙）等服务可以帮助保护你的Web应用程序免受SQL注入和应用程序代码中的其他漏洞的影响。对于访问控制，你可以使用IAM定义一组精细策略，并将其分配给用户，组和AWS资源。最后，AWS Cloud提供了许多选项来保护你的数据，无论是在运输途中还是静止状态。

4.8.2 与AWS共享安全责任

AWS在共享安全责任模型下运行：AWS负责底层云基础架构的安全性，你负责保护你在AWS中部署的工作负载。这有助于你通过使用AWS托管服务减少你的职责范围并专注于你的核心竞争力。例如，当你使用Amazon RDS和Amazon ElastiCache等服务时，安全补丁会自动应用于你的配置设置。这不仅可以降低团队的运营开销，还可以减少你的漏洞风险。

4.8.3 减少特权访问

当你的服务器是可编程资源时，你将获得许多安全优势。随时随地更改服务器的功能使你无需客户操作系统访问生产环境。如果实例遇到问题，你可以自动或手动终止并替换它。但是，在替换实例之前，你应该收集并集中存储日志数据，这些数据可以帮助你在开发环境中重新创建问题，并通过持续部署过程将它们部署为修复程序。此方法可确保日志数据有助于排除故障并提高安全事件的意识。这在服务器是临时的弹性计算环境中尤为重要。你可以使用Amazon CloudWatch Logs收集此信息。如果你没有直接访问权限，则可以实施AWS Systems Manager 55等服务，以获取统一视图并自动对资源组执行操作。你可以将这些请求与你的票务系统集成，以便仅在批准后跟踪和动态处理访问请求。

另一个常见的安全风险是使用存储的长期凭证或服务帐户。在传统环境中，服务帐户通常会分配存储在配置文件中的长期凭据。在AWS上，你可以使用IAM角色通过使用自动分发和轮换的短期凭据向EC2实例上运行的应用程序授予权限。对于移动应用程序，你可以使用Amazon Cognito允许客户端设备通过具有细粒度权限的临时令牌访问AWS资源。

作为AWS管理控制台用户，你可以类似地通过临时令牌提供联合访问，而不是在你的AWS账户中创建IAM用户。然后，当员工离开你的组织并从组织的身份目录中删除时，该员工也会自动失去对你的AWS账户的访问权限。

4.8.4 安全代码

传统的安全框架，法规和组织策略定义了与防火墙规则，网络访问控制，内部/外部子网和操作系统强化等项目相关的安全要求。你也可以在AWS环境中实现这些，但你现在有机会在定义黄金环境的模板中捕获它们。AWS CloudFormation使用此模板，并根据你的安全策略部署资源。作为持续集成管道的一部分，你可以在多个项目中重用安全性最佳实践。你可以在发布周期中执行安全测试，并自动发现应用程序差距并从安全策略中消失。

此外，为了获得更好的控制和安全性，可以将AWS CloudFormation模板作为产品导入AWS Service Catalog.5。这使你可以集中管理资源，以支持一致的治理，安全性和合规性要求，同时使你的用户能够快速部署他们需要批准的IT服务。你应用IAM权限来控制可以查看和修改产品的人员，并定义约束以限制可以为产品部署特定AWS资源的方式。

4.8.5 实时审计

测试和审核你的环境是保持安全的快速移动的关键。涉及定期（通常是手动或基于样本）检查的传统方法是不够的，尤其是在变化不变的敏捷环境中。在AWS上，你可以实施控制的持续监控和自动化，以最大限度地降低安全风险。AWS Config，Amazon Inspector和AWS Trusted Advisor等服务会持续监控合规性或漏洞，从而清楚地了解哪些IT资源符合要求，哪些不符合要求。使用AWS Config规则，你还可以了解资源是否在短时间内不合规，从而使得时间点和时间段审核非常有效。

你通过启用AWS CloudTrail，可以为你的应用程序（使用Amazon CloudWatch Logs）和实际的AWS API调用实施广泛的日志记录AWS CloudTrail是一种Web服务，它记录对AWS账户中受支持的AWS服务的API调用，并将日志文件传送到S3存储桶。然后，日志数据可以以不可变的方式存储，并自动处理以发送通知或代表你采取行动，从而保护你的组织免受不合规。你可以使用AWS Lambda，Amazon EMR，Amazon ES，Amazon Athena或AWS Marketplace中的第三方工具扫描日志数据，以检测未使用权限，特权帐户过度使用，密钥使用，异常登录，策略违规和系统等事件滥用。

5. 结论

在AWS中设计云架构时，重要的是要考虑AWS中的重要原则和设计模型，包括如何为应用程序选择正确的数据库，以及如何构建可以水平扩展且具有高可用性的应用程序。由于每项实现都是唯一的，因此你必须评估如何将此指南应用于你的实现。云计算体系结构是一个广泛而不断发展的主题。您可以使用AWS网站上提供的材料以及AWS培训和认证产品，随时了解AWS云产品的最新更改和添加。

如果本文对你有帮助，别忘记给我个3连 ，点赞，转发，评论，

，咱们下期见！答案获取方式：已赞 已评 已关~