万字长文：云架构设计原则

译者序

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云产品的最新更改和添加。

 

说明：

本文由新钛云服运维工程师傅雨斌翻译，新钛云服拥有八名认证的AWS工程师，在AWS使用和维护方面拥有丰富的经验，已经为多家用户提供AWS上云支持。

 

原文连接：

https://d1.awsstatic.com/whitepapers/AWS_Cloud_Best_Practices.pdf 

 

 

 

请点击输入图片描述