AWS用户广泛，产品线复杂，AWS发布的白皮书《ArchitectingfortheCloud-AWSBestPractices》介绍了常见场景下云架构的最佳实践，不仅对于使用AWS的用户，对于广大使用云的用户都有参考意义，新钛云服工程师特意翻译了本白皮书，供广大使用云的用户参考。
请点击输入图片描述
1.摘要
本白皮书适用于在AmazonWebServices（AWS）上的构建解决方案的架构师和开发人员。本白皮书提供有关技术设计模型的架构指导和建议，以及如何应用于云计算环境中。本白皮书提供了在AWS上设计解决方案时的关键概念和差异。本白皮书还讨论了如何利用特定于云计算动态特性的属性，如弹性和基础设施自动化。这些模型可以为对选择、操作状态和实现状态进行更详细的审查提供上下文，就像《AWSWell-ArchitectedFramework》中详细描述的那样.
2.介绍
将应用程序迁移到AWS，即使没有重大更改（称为直接迁移的方法），也可为组织提供安全且经济高效的基础架构优势。但是，为了充分利用云计算可能带来的弹性和灵活性，工程师必须改进其架构以利用AWS功能。
对于新应用程序，基于云的IT体系架构模型可以帮助提高效率和可伸缩性。这些新架构可以支撑从互联网规模数据的实时分析到具有数千个连接的物联网（IoT），或移动设备的不可预测流量的应用程序的任何内容。
无论是重新架构在本地环境中运行的当前应用程序以在AWS上运行，还是设计云原生应用程序，你都必须考虑传统环境与云计算环境之间的差异。这包括体系架构选择，可伸缩性，资源类型，自动化以及灵活的组件，服务和数据库。如果你不熟悉AWS，我们建议你查看“AboutAWS”页面上的信息，以便基本了解AWS服务。
3.传统环境和云计算环境之间的差异
云计算在许多方面不同于传统的本地环境，包括灵活，全局和可扩展的容量，托管服务，内置安全性，成本优化选项以及各种操作模型。
3.1IT资产作为可配置资源
在传统计算环境中，可以基于理论最大峰值的估计来提供容量。这可能导致阶段性昂贵的资源闲置或容量不足。借助云计算，可以根据需要访问尽可能多的容量，并动态扩展以满足实际需求，同时只需为使用的资源付费。
在AWS上，可以在几秒钟内实例化服务器，数据库，存储和更高级别的应用程序组件。可以将这些视为临时资源，而不受固定和有限IT基础架构的不灵活性和限制。这会重置处理变更管理，测试，可靠性和容量规划的方式。这种方法的改变通过引入流程中快速失败和快速迭代的能力来鼓励体验。
3.2全球，可用和可扩展的容量
使用AWS的全局基础架构，可以将应用程序部署到最符合你要求的AWS可用区域（例如，与最终用户的接近程度，合规性，数据驻留限制和成本）。对于全局应用程序，可以使用AmazonCloudFront内容交付网络（CDN）在全球范围内减少到终端用户的延时。这也使得跨多个数据中心操作生产应用程序和数据库变得更加容易，从而实现高可用性和容错性。AWS的全球基础架构以及根据需要配置容量的能力，使你可以根据对应用程序的需求和服务范围的扩展，来对你的基础架构进行不同的思考。
3.3更高级的托管服务
除了AmazonElasticComputeCloud（AmazonEC2）的计算资源外，还可以访问各种存储，数据库，分析，应用程序和部署服务。由于这些服务可立即供开发人员使用，因此可减少对内部专业技能的依赖，并使组织能够更快地交付新解决方案。管理的AWS服务可以降低运营复杂性和成本。它们还具有可扩展性和高可用性，因此可以降低实施风险。
3.4内置安全性
在传统IT环境中，基础架构安全审核可以是定期和手动过程。相比之下，AWSCloud提供的治理功能可以持续监控IT资源的配置更改。AWS的安全性是最高优先级，这意味着可以从为满足大多数安全敏感组织的要求而构建的数据中心和网络体系结构中受益。
由于AWS资源可使用工具和API进行编程，因此可以将安全策略正式化并嵌入基础架构设计中。由于能够启动临时环境，安全测试现在可以成为持续交付流水线的一部分。最后，可以利用各种云原生的AWS安全和加密功能，这些功能可以帮助你实现更高级别的数据保护和合规性。
3.5成本架构
3.6AWS上的运维
在AWS上运行服务时，有几种常见的运维模型：
支持这些转变不仅会改变所使用的技术，还会改变开发和运维团队管理方式的文化变化。
AWS提供工具，流程和最佳实践，以支持运维实践的转变，从而最大限度地利用云计算带来的收益。
4.设计原则
AWS包含许多可应用于各种用例的设计模式和体系结构选项。AWS的一些关键设计原则包括可扩展性，可支配资源，自动化，用松耦合管理服务，以及灵活的数据存储选项。
4.1可扩展性
通常有两种扩展IT架构的方法：纵向扩展和横向扩展。
4.1.1纵向扩展
纵向扩展通过增加单个资源的规模来实现，例如升级具有更大硬盘驱动器或更快CPU的服务器。使用AmazonEC2，你可以停止实例并将其调整为具有更多RAM，CPU，I/O或网络功能的实例类型。这种缩放方式最终将达到极限，并且它并不总是具有成本效益或高度可用的方法。但是，它很容易实现，并且对于许多用例来说已经足够了，特别是在短期内。
4.1.2横向扩展
通过增加资源数量来横向扩展，例如向存储阵列添加更多硬盘驱动器，或添加更多服务器以支持应用程序。这是构建利用云弹性的互联网规模应用程序的好方法。并非所有体系结构都旨在将其工作负载分配给多个资源，因此让我们检视一些可能的情况。
1)无状态应用
当用户或服务与应用程序交互时，通常会执行一系列形成会话的交互。会话是用户在使用应用程序时在请求之间保持不变的唯一数据。无状态应用程序是不需要先前交互知识，且不存储会话信息的应用程序。例如，给定相同输入，向任何最终用户提供相同响应的应用程序是无状态应用程序。无状态应用程序可以横向扩展，因为任何可用的计算资源（例如EC2实例和AWSLambda函数）都可以为任何请求提供服务。如果没有存储会话数据，可以根据需要添加更多计算资源。当不再需要该容量时，可以在运行任务耗尽后安全地终止这些单独的资源。这些资源不需要知道同伴的存在，所需要的只是将工作负载分配给它们的方法。
2)将负载分配给多个节点
要将工作负载分配到环境中的多个节点，可以选择推模型或拉模型。
可以为异步，事件驱动的工作负载实现拉模型，而不是负载平衡解决方案。在拉模型中，需要执行的任务或需要处理的数据可以使用AmazonSimpleQueueService（AmazonSQS）作为消息存储在队列中，也可以作为流数据解决方案存储
比如亚马逊Kinesis，多个计算资源可以提取和使用这些消息，以分布式方式处理它们。
3)无状态组件
例如，Web应用程序可以使用HTTPcookie在Web客户端缓存中存储会话信息（如购物车项目）。浏览器在每个后续请求时将该信息传递回服务器，以便应用程序不需要存储它。但是，这种方法有两个缺点。首先，HTTPcookie的内容可能会在客户端被篡改，因此你应始终将其视为必须经过验证的不可信数据。其次，HTTPcookie随每个请求一起传输，这意味着你应该将其大小保持在最小，以避免不必要的延迟。
考虑仅在HTTPcookie中存储唯一的会话标识符，并在服务器端存储更详细的用户会话信息。大多数编程平台都提供以这种方式工作的本机会话管理机制。但是，默认情况下，用户会话信息通常存储在本地文件系统中，从而形成有状态架构。此问题的常见解决方案是将此信息存储在数据库中。AmazonDynamoDB是一个很好的选择，因为它具有可扩展性，高可用性和耐用性特征。对于许多平台，有一些开源替代库，允许你在AmazonDynamoDB中存储本机会话。
其他方案需要存储较大的文件（例如用户上载和批处理的中间结果）。通过将这些文件放在共享存储层（如AmazonSimpleStorageService，AmazonS3；或AmazonElasticFileSystem，AmazonEFS））中，可以避免引入有状态组件。
最后，复杂的多步骤工作流是另一个必须跟踪每个执行的当前状态的示例。可以使用AWS步骤功能集中存储执行历史记录，并使这些工作负载无状态。
4)有状态组件
仍然可以通过将负载分配到具有会话亲缘关系的多个节点来水平扩展这些组件。在此模型中，将会话的所有事务绑定到特定的计算资源。但是，这个模型确实有一些局限性。现有会话不会直接受益于新启动的计算节点的引入。更重要的是，无法保证会话亲和力。例如，当节点终止或变得不可用时，绑定到该节点的用户将断开连接并遇到特定于会话的数据丢失，这些数据不会存储在共享资源，如AmazonS3，AmazonEFS或a数据库。
5)实现会话亲和性
6)分布式处理
涉及处理大量数据的用例，无法及时处理单个计算资源的任何事物，需要采用分布式处理方法。通过将任务及其数据划分为许多小的工作片段，可以跨一组计算资源并行执行它们。
7）实施分布式处理
通过使用AWSBatch，AWSGlue和ApacheHadoop等分布式数据处理引擎，可以水平扩展脱机批处理作业。在AWS上，可以使用AmazonEMR在一组EC2实例之上运行Hadoop工作负载，而无需运维复杂性。对于流数据的实时处理，AmazonKinesis将数据分成多个分片，然后由多个AmazonEC2或AWSLambda资源使用，以实现可扩展性。
有关这些类型工作负载的更多信息，请参阅《BigDataAnalyticsOptionsonAWS》和《CoreTenetsofIoT》白皮书。
4.2一次性资源而不是固有服务器
在为AWS设计时，可以利用云计算的动态配置特性。可以将服务器和其他组件视为临时资源。可以根据需要启动任意数量实例，并且只在需要时使用它们。
4.2.1实例化计算资源
无论是部署新环境进行测试，还是增加现有系统的容量来应对额外负载，你都不希望使用其配置和代码手动设置新资源。重要的是，你要使其成为一个自动化且可重复的过程，以避免较长的交付周期，并且不会出现人为错误。有几种方法可以实现这一目标。
1）引导
启动AWS资源（如EC2实例或AmazonRelationalDatabaseService（AmazonRDS）数据库实例）时，将启动默认配置。然后，可以执行自动引导操作，这些操作是安装软件或复制数据以将该资源带入特定状态的脚本。可以参数化在不同环境（例如生产或测试）之间变化的配置详细信息，以便可以重复使用相同的脚本而无需进行任何修改。
可以使用用户数据脚本和cloud-init指令设置新的EC2实例。可以使用简单的脚本和配置管理工具，例如Chef或Puppet。此外，通过自定义脚本和AWSAPI，或AWSAWS支持的自定义资源的AWSCloudFormation支持，可以编写几乎适用于任何AWS资源的配置逻辑。
2）黄金镜像
可以自定义EC2实例，然后通过创建AmazonMachineImage（AMI）来保存其配置。可以根据需要从AMI启动任意数量的实例，并且它们都将包括这些自定义项。每次要更改配置时，都必须创建一个新的黄金镜像，因此必须具有版本控制约定来管理你的黄金镜像。建议你使用脚本为你用于创建的EC2实例创建引导程序的AMI。这为你提供了一种灵活的方法来测试和修改这些镜像。
或者，如果你具有现有的本地虚拟化环境，则可以使用AWS的VM导入/导出将各种虚拟化格式转换为AMI。你还可以查找和使用AWS或AWS中的第三方提供的预封装共享AMI。
虽然启动新EC2实例时最常使用黄金镜像，但它们也可以应用于AmazonRDS数据库实例或AmazonEBS卷等资源。例如，当启动新的测试环境时，你可能希望通过从特定的AmazonRDS快照实例化数据库来预填充其数据库，而不是从冗长的SQL脚本中导入数据。
3）容器
开发人员喜欢的另一个选择是Docker，一种开源技术，允许你在软件容器内构建和部署分布式应用程序。Docker允许你将一个软件封装在Docker镜像中，这是一个软件开发的标准化单元，包含软件运行所需的所有内容：代码，运行时，系统工具，系统库等。AWSElasticBeanstalk，AmazonElasticContainer服务（AmazonECS）和AWSFargate允许你跨EC2实例集群部署和管理多个容器。你可以构建黄金Docker镜像并使用ECS容器注册表来管理它们。
另一种容器环境是Kubernetes和Kubernetes的亚马逊弹性容器服务（AmazonEKS）。借助Kubernetes和AmazonEKS，你可以轻松部署，管理和扩展容器化应用程序。
4）混合
你还可以使用这两种方法的组合：配置的某些部分在黄金镜像中捕获，而其他部分则通过引导操作动态配置。
不经常更改或引入外部依赖项的项目通常是你的黄金镜像的一部分。一个好的候选者的例子是你的Web服务器软件，否则每次启动实例时都必须由第三方存储库下载。
可以通过引导操作动态设置在不同环境之间经常更改或不同的项目。例如，如果要经常部署应用程序的新版本，则为每个应用程序版本创建新的AMI可能不切实际。你也不希望将数据库主机名配置硬编码到AMI，因为测试和生产环境之间会有所不同。用户数据或标签允许你使用可在启动时修改的更通用的AMI。例如，如果你为各种小型企业运行Web服务器，则它们都可以使用相同的AMI，并从启动时在用户数据中指定的S3存储桶位置检索其内容。
AWSElasticBeanstalk遵循混合模型。它提供预配置的运行时环境，每个环境都是从其自己的AMI11启动的，但允许你通过ebextensions配置文件运行引导操作，并配置环境变量以参数化环境差异。
4.2.2基础架构即代码
我们讨论的原则的应用不必限于单个的资源水平。由于AWS资源是可编程的，因此你可以应用软件开发中的技术，实践和工具，使你的整个基础架构可重用，可维护，可扩展和可测试。
4.3自动化
在传统的IT基础架构中，你通常必须手动对各种事件做出反应。在AWS上部署时，你可以进行自动化。
为了提高系统的稳定性和组织的效率，考虑将一种或多种这类自动化引入你的应用程序体系结构，以确保更高的弹性，可伸缩性和性能。
4.3.1无服务器管理和部署
采用无服务器模式时，操作重点是部署自动化流水线。AWS管理基础服务，规模和可用性。AWSCodePipeline，AWSCodeBuild和AWSCodeDeploy支持这些流程部署的自动化。
4.3.2基础架构管理和部署
AWSElasticBeanstalk：你可以使用此服务在熟悉的服务器（如Apache，Nginx，Passenger和服务器）上部署和扩展使用Java，.NET，PHP，Node.js，Python，Ruby，Go和Docker开发的Web应用程序和服务。IIS开发人员可以简单地上传他们的应用程序代码，该服务自动处理所有细节，例如资源配置，负载平衡，自动扩展和监视。
AmazonEC2自动恢复：你可以创建监控EC2实例的AmazonCloudWatch警报，并在其受损时自动恢复。恢复的实例与原始实例相同，包括实例ID，私有IP地址，弹性IP地址，和所有实例元数据。但是，此功能仅适用于适用的实例配置。有关这些前提条件的最新说明，请参阅AmazonEC2文档。此外，在实例恢复期间，实例将通过实例重新引导进行迁移，并且内存中的所有数据都将丢失。
AWSSystemsManager：你可以自动收集软件清单，应用操作系统补丁，创建系统镜像以配置Windows和Linux操作系统，以及执行任意命令。提供这些服务简化了操作模型并确保了最佳的环境配置。
AutoScaling：你可以根据你定义的条件自动维护应用程序可用性，并自动扩展AmazonEC2，AmazonDynamoDB，AmazonECS，适用于Kubernetes的AmazonElasticContainerService，（AmazonEKS）容量。你可以使用AutoScaling帮助确保跨多个可用区运行所需数量的健康EC2实例。AutoScaling还可以在需求峰值期间自动增加EC2实例的数量，在不太繁忙的时期保持性能并降低容量以优化成本。
4.3.3警报和事件
AmazonCloudWatch警报：你可以创建CloudWatch警报，当特定指标超过指定阈值达指定数量的时段时，该警报会发送AmazonSimpleNotificationService（AmazonSNS）消息。这些AmazonSNS消息可以自动启动执行订阅的Lambda函数，将通知消息排入AmazonSQS队列，或者对HTTP或HTTPS端点执行POST请求。
AmazonCloudWatchEvents：提供近乎实时的系统事件流，描述AWS资源中的变更.使用简单规则，你可以将每种类型的事件路由到一个或多个目标，例如Lambda函数，Kinesis流和SNS主题。
AWSLambda预定事件：你可以创建Lambda函数并配置AWSLambda以定期执行它。
AWSWAF安全自动化：AWSWAF是一种Web应用程序防火墙，使你能够创建自定义的特定于应用程序的规则，以阻止可能影响应用程序可用性，危及安全性或消耗过多资源的常见攻击模式。你可以通过API完全管理AWSWAF，从而简化安全自动化，实现快速规则传播和快速事件响应。
4.4松耦合
随着应用程序复杂性的增加，IT系统的理想属性是可以将其分解为更小，松耦合的组件。这意味着IT系统的设计应该能够减少相互依赖性，一个组件中的更改或故障不应该级联到其他组件。
4.4.1定义明确的接口
减少系统中相互依赖性的一种方法是允许各种组件仅通过特定的，与技术无关的接口（例如RESTfulAPI）相互交互。通过这种方式，隐藏了技术实现细节，以便团队可以修改底层实现而不影响其他组件。只要这些接口保持向后兼容性，差异组件的部署就会分离。这种粒度设计模式通常被称为微服务架构。
4.4.2服务发现
实施服务发现
对于AmazonEC2托管的服务，实现服务发现的一种简单方法是通过ElasticLoadBalancing（ELB）。由于每个负载均衡器都有自己的主机名，因此你可以通过稳定的endpoint使用服务。这可以与DNS和私有AmazonRoute53区域结合使用，以便可以随时抽象和修改特定负载均衡器的endpoint。
另一种选择是使用服务注册和发现方法来允许检索任何服务的endpointIP地址和端口号。由于服务发现成为组件之间的粘合剂，因此高度可用且可靠性非常重要。如果未使用负载平衡器，则还应该进行服务发现允许健康检查等选项。AmazonRoute53支持自动命名，以便更轻松地为微服务配置实例。自动命名允许你根据定义的配置自动创建DNS记录。其他示例实现包括使用标签组合的自定义解决方案，高可用性数据库，调用AWSAPI的自定义脚本，或NetflixEureka，AirbnbSynapse或HashiCorpConsul等开源工具。
4.4.3异步集成
异步集成是服务之间松耦合的另一种形式。此模型适用于任何不需要立即响应的交互，以及已经注册请求的确认就足够了。它涉及一个生成事件的组件和另一个消耗它们的组件。这两个组件不通过直接的点对点交互进行集成，而是通过中间持久存储层进行集成，例如SQS队列或流式数据平台（如AmazonKinesis），级联Lambda事件，AWS步骤功能或AmazonSimpleWorkflow服务。
图1：紧耦合和松耦合
这种方法将两个组件分离，并引入了额外的弹性。因此，例如，如果正在从队列中读取消息的进程失败，则仍可以将消息添加到队列中并在系统恢复时进行处理。它还允许你保护不太可扩展的后端服务免受前端尖峰的攻击，并找到正确的成本和处理滞后之间的权衡。例如，你可以决定不需要扩展数据库以适应偶尔的写入查询峰值，只要你最终以一些延迟异步处理这些查询。最后，通过从交互式请求路径中删除慢速操作，你还可以改善最终用户体验。
异步集成的示例包括：
4.4.4分布式系统最佳实践
增加松耦合的另一种方法是构建以优雅方式处理组件故障的应用程序。你可以确定减少对最终用户的影响的方法，并提高你在脱机过程中取得进展的能力，即使在某些组件发生故障时也是如此。
实践中优雅的应对失败
失败的请求可以使用指数退避和抖动策略重试，也可以存储在队列中以供以后处理。对于前端接口，可以提供替代或缓存的内容，而不是完全失败，例如，你的数据库服务器变得不可用。AmazonRoute53DNS故障转移功能还使你能够监控你的网站，并在主站点不可用时自动将访问者路由到备份站点。你可以将备份站点作为AmazonS3上的静态网站托管，也可以作为单独的动态环境托管。
4.4.5服务，而不是服务器
开发，管理和运维应用程序，尤其是大规模应用程序，需要各种各样的底层技术组件。对于传统的IT基础架构，公司必须构建和运行所有这些组件。
AWS提供广泛的计算，存储，数据库，分析，应用程序和部署服务，可帮助组织更快地移动并降低IT成本。
不利用这种广度的架构（例如，如果它们仅使用AmazonEC2）可能无法充分利用云计算，并且可能错失了提高开发人员生产力和运营效率的机会。
4.4.5.1管理服务
为你的应用程序提供支持的托管服务的其他示例包括：
4.4.5.2无服务器计算架构
无服务器计算架构可以降低运行应用程序的操作复杂性。无需管理任何服务器基础架构，就可以为移动，Web，分析，CDN业务逻辑和物联网构建事件驱动和同步服务。这些体系结构可以降低成本，因为你无需管理或支付未充分利用的服务器，也无需配置冗余基础架构来实现高可用性。
例如，你可以将代码上载到AWSLambda计算服务，并且该服务可以使用AWS基础结构代表你运行代码。使用AWSLambda，你需要为代码执行的每100毫秒以及触发代码的次数付费。通过使用AmazonAPIGateway，你可以开发由AWSLambda支持的几乎无限可扩展的同步API。与AmazonS3结合使用以提供静态内容资产时，此模式可以提供完整的Web应用程序。
在移动和Web应用程序方面，你可以使用AmazonCognito，这样你就无需管理后端解决方案来处理用户身份验证，网络状态，存储和同步。AmazonCognito为你的用户生成唯一标识符。
可以在访问策略中引用这些标识符，以基于每个用户启用或限制对其他AWS资源的访问。AmazonCognito为你的用户提供临时AWS凭证，允许设备上运行的移动应用程序直接与受AWS身份和访问管理（IAM）保护的AWS服务进行交互。例如，使用IAM，你可以将对S3存储桶中的文件夹的访问权限限制为特定的最终用户。
对于物联网应用，组织传统上必须配置，操作，扩展和维护自己的服务器作为设备网关，以处理连接设备与其服务之间的通信。AWSIoT提供完全受管理的设备网关，可根据你的使用情况自动扩展，无需任何操作开销。
无服务器计算架构还使得在边缘计算运行响应式服务成为可能。
4.5数据库
对于传统的IT基础架构，组织通常仅限于可以使用的数据库和存储技术。可能存在基于许可成本和支持各种数据库引擎的能力的约束。在AWS上，这些约束由托管数据库服务解除，这些服务以开源成本提供企业性能。因此，应用程序在多语言数据层之上运行并为每个工作负载选择正确的技术并不罕见。
4.5.1为每项业务负载选择正确的数据库技术
下面的问题可以帮助你决定在架构中包含哪些解决方案：
4.5.2关系数据库
关系数据库（也称为RDBS或SQL数据库）将数据规范化为称为表的明确表格结构，表格由行和列组成。它们提供强大的查询语言，灵活的索引功能，强大的完整性控制，以及快速有效地组合来自多个表的数据的能力。AmazonRDS可以轻松地在云中设置，操作和扩展关系数据库，并支持许多熟悉的数据库引擎。
4.5.2.1可扩展性
关系数据库可以通过升级到更大的AmazonRDS数据库实例或添加更多更快的存储来垂直扩展。此外，请考虑使用AmazonAurora，它是一种数据库引擎，与在同一硬件上运行的标准MySQL相比，可提供更高的吞吐量。对于读取繁重的应用程序，你还可以通过创建一个或多个只读副本来横向扩展超出单个数据库实例的容量限制。
只读副本是异步复制的单独数据库实例。因此，它们会受到复制滞后的影响，可能会丢失一些最新的事务。应用程序设计人员需要考虑哪些查询对稍微陈旧的数据具有容忍度。这些查询可以在只读副本上执行，而其余查询应该在主节点上运行。只读副本也不能接受任何写入查询。
需要将其写入容量扩展到单个数据库实例的约束之外的关系数据库工作负载需要使用称为数据分区或分片的不同方法。使用此模型，数据分别跨多个数据库模式在自己的主要数据库实例中运行。尽管AmazonRDS消除了运行这些实例的操作开销，但分片会为应用程序带来一些复杂性。需要修改应用程序的数据访问层，以了解数据的分割方式，以便将查询定向到正确的实例。此外，必须跨多个数据库模式执行模式更改，因此值得投入一些精力来自动执行此过程。
4.5.2.2高可用性
4.5.2.3非标准模型
如果你的应用程序主要索引和查询数据而不需要连接或复杂事务，特别是如果你希望写入吞吐量超出单个实例的约束，请考虑使用NoSQL数据库。如果你有大型二进制文件（音频，视频和图像），则在AmazonS3中存储实际文件并仅保存数据库中文件的元数据会更有效。
4.5.3NoSQL数据库
NoSQL数据库交换关系数据库的一些查询和事务功能，以获得更灵活的数据模型，可以无缝地水平扩展。NoSQL数据库使用各种数据模型，包括图形，键值对和JSON文档，并且因易于开发，可扩展性能，高可用性和弹性而广受认可。AmazonDynamoDB是一种快速灵活的NoSQL数据库服务，适用于任何规模都需要一致，一位数，毫秒级延迟的应用程序.它是一个完全托管的云数据库，支持文档和键值存储模型。
4.5.3.1可扩展性
NoSQL数据库引擎通常会执行数据分区和复制，以便以水平方式扩展读取和写入。它们透明地执行此操作，并且不需要在应用程序的数据访问层中实现的数据分区逻辑。特别是AmazonDynamoDB自动管理表分区，随着表的大小增加或者读取配置和写入配置容量更改而添加新分区。AmazonDynamoDBAccelerator（DAX）是DynamoDB的托管，高可用内存缓存，可充分利用性能提升。
4.5.3.2高可用性
AmazonDynamoDB在AWS区域中的三个设施之间同步复制数据，在服务器发生故障或可用区域中断时提供容错功能。AmazonDynamoDB还支持全局表，以提供完全托管的多区域，多主数据库，为大规模扩展的全局应用程序提供快速，本地，读取和写入性能。全局表在所选AWS区域中复制。
4.5.3.3非标准模型
如果你的模型无法规范化，并且你的应用程序需要连接或复杂事务，请考虑使用关系数据库。如果你有大型二进制文件（音频，视频和图像），请考虑将文件存储在AmazonS3中，并将文件的元数据存储在数据库中。
4.5.4数据仓库
传统上，设置，运行和扩展数据仓库既复杂又昂贵。在AWS上，你可以利用AmazonRedshift，这是一种托管数据仓库服务，其运行成本仅为传统解决方案的十分之一。
4.5.4.1可扩展性
AmazonRedshift通过大规模并行处理（MPP），列式数据存储和目标数据压缩编码方案的组合实现了高效存储和最佳查询性能。它特别适用于针对超大型数据集的分析和报告工作负载。AmazonRedshiftMPP体系结构使你可以通过增加数据仓库集群中的节点数来提高性能。AmazonRedshiftSpectrum支持AmazonRedshiftSQL查询，以防止AmazonS3中的数据数据，从而将AmazonRedshift的分析功能从存储在数据仓库中本地磁盘上的数据扩展到非结构化数据，而无需加载或转换数据。
4.5.4.2高可用性
AmazonRedshift具有多种功能，可增强数据仓库集群的可靠性。我们建议你在多节点群集中部署生产工作负载，以便将写入节点的数据自动复制到群集中的其他节点。数据也会持续备份到AmazonS3。AmazonRedshift持续监视群集的运行状况，并自动重新启动故障驱动器中的数据，并根据需要替换节点。
4.5.4.3非标准模型
由于AmazonRedshift是基于SQL的关系数据库管理系统（RDBMS），因此它与其他RDBMS应用程序和商业智能工具兼容。虽然AmazonRedshift提供典型RDBMS的功能，包括在线事务处理（OLTP）功能，但它并非针对这些工作负载而设计。如果你期望高并发工作负载通常涉及一次读取和写入少量记录的所有列，则应考虑使用AmazonRDS或AmazonDynamoDB。
4.5.5搜索
搜索经常与查询混淆。查询是正式的数据库查询，以正式术语表示特定数据集。搜索可以查询未精确构建的数据集。因此，需要复杂搜索功能的应用程序通常会超出关系数据库或NoSQL数据库的功能。搜索服务可用于索引和搜索结构化和自由文本格式，并且可以支持其他数据库中不可用的功能，例如可自定义的结果排名，过滤的分面，同义词和词干。
在AWS上，你可以选择AmazonCloudSearch和AmazonElasticsearchService（AmazonES）。AmazonCloudSearch是一项托管服务，几乎不需要配置，并且会自动扩展。AmazonES提供开源API，使你可以更好地控制配置详细信息。亚马逊ES也已经发展成为一个不仅仅是一个搜索解决方案。它通常用作日志分析，实时应用程序监控和点击流分析等用例的分析引擎。
4.5.5.1可扩展性
AmazonCloudSearch和AmazonES都使用数据分区和复制来横向扩展。不同之处在于，使用AmazonCloudSearch，你无需担心需要多少分区和副本，因为该服务会自动处理该分区和副本。
4.5.5.2高可用性
AmazonCloudSearch和AmazonES都包含跨可用区冗余存储数据的功能。
4.5.6图数据库
AmazonNeptune是一个完全托管的图形数据库服务。
4.5.6.1可扩展性
AmazonNeptune是专为处理图形查询而优化的专用高性能图形数据库。
4.5.6.2高可用性
4.5.7管理不断增加的数据量
4.5.8消除单点故障
4.5.8.1引入冗余
通过引入冗余可以消除单点故障，这意味着你可以为同一任务提供多个资源。冗余可以在待机或主动模式下实现。
在主主冗余中，请求被分发到多个冗余计算资源。当其中一个失败时，其余的可以简单地吸收更大份额的工作量。与备用冗余相比，主动冗余可以实现更好的使用，并在出现故障时影响较小的人口。
4.5.8.2检测失败
你应该在检测和响应故障时尽可能多地构建自动化。你可以使用ELB和AmazonRoute53等服务通过将流量路由到健康端点来配置运行状况检查和屏蔽故障。此外，你可以使用AutoScaling或使用AmazonEC2自动恢复功能或AWSElasticBeanstalk等服务自动替换不健康的节点。无法在第一天预测每种可能的故障情况。确保收集足够的日志和指标以了解正常的系统行为。了解之后，你将能够设置警报以进行手动干预或自动响应。
设计良好的健康检查
为应用程序配置正确的运行状况检查有助于确定你是否能够正确，及时地响应各种故障情况。指定错误的运行状况检查实际上可能会降低应用程序的可用性。
在典型的三层应用程序中，你可以在ELB上配置运行状况检查。设计你的运行状况检查，目的是可靠地评估后端节点的运行状况。简单的TCP运行状况检查不会检测实例本身是否正常但Web服务器进程是否已崩溃。相反，你应该评估Web服务器是否可以针对某个简单请求返回HTTP200响应。
在此层，配置深层运行状况检查可能不是一个好主意，这是一种依赖于应用程序的其他层成功的测试，因为可能会导致误报。例如，如果你的运行状况检查还评估实例是否可以连接到后端数据库，则当该数据库节点很快不可用时，你可能会将所有Web服务器标记为不健康。分层方法通常是最好的。深度健康检查可能适合在亚马逊Route53级实施。通过运行更全面的检查来确定该环境是否能够实际提供所需的功能，你可以将AmazonRoute53配置为故障转移到网站的静态版本，直到数据库启动并再次运行。
4.5.8.3可靠的数据存储
你的应用程序和用户将创建和维护各种数据。你的体系结构保护数据可用性和完整性至关重要。数据复制是引入冗余数据副本的技术。它可以帮助水平扩展读取容量，但它也提高了数据的耐用性和可用性。复制可以在几种不同的模式下进行。
同步复制仅在主要位置及其副本中持久存储之后才确认事务。它是保护主节点发生故障时数据完整性的理想选择。同步复制还可以扩展需要最新数据（强一致性）的查询的读取容量。同步复制的缺点是主节点耦合到副本。在所有副本执行写入之前，无法确认事务。这可能会影响性能和可用性，尤其是在运行不可靠或高延迟网络连接的拓扑中。出于同样的原因，不建议维护许多同步副本。
无论你的解决方案的耐用性如何，这都不能替代备份。同步复制冗余地存储你的数据的所有更新，甚至是那些由软件错误或人为错误导致的更新。但是，特别是对于存储在AmazonS3上的对象，你可以使用版本控制来保留，检索和还原其任何版本，通过版本控制，你可以从非预期的用户操作和应用程序故障中恢复。
异步复制以引入复制延迟为代价将主节点与其副本解耦。这意味着主节点上的更改不会立即反映在其副本上。异步副本用于水平扩展系统对可以容忍复制延迟的查询的读取容量。当故障转移期间可以容忍某些最近事务丢失时，它还可用于提高数据持久性。例如，你可以在单独的AWS区域中维护数据库的异步副本作为灾难恢复解决方案。
基于Quorum的复制结合了同步和异步复制，以克服大规模分布式数据库系统的挑战。
可以通过定义必须参与成功写入操作的最小数量的节点来管理到多个节点的复制。详细讨论分布式数据存储超出了本文档的范围。有关分布式数据存储的更多信息以及超可扩展且高度可靠的数据库系统的核心原则。
4.5.8.4自动化的多数据中心恢复能力
业务关键型应用程序还需要针对不仅影响单个磁盘，服务器或机架的中断方案进行保护。在传统基础架构中，你通常需要一个灾难恢复计划，以便在主要数据中心发生重大中断时允许故障转移到远程第二个数据中心。由于两个数据中心之间的距离很远，因此延迟使得维护数据的同步跨数据中心副本变得不切实际。因此，故障转移肯定会导致数据丢失或数据恢复过程非常昂贵。这使故障转移成为一种风险并且不总是经过充分测试的程序。尽管如此，这种模型可以提供出色的保护，防止低概率但具有巨大的影响风险，例如长期影响整个基础设施的自然灾害。
也可以实现主动冗余。例如，一组应用程序服务器可以分布在多个可用区中，并附加到ELB。当特定可用区的EC2实例未通过运行状况检查时，ELB将停止向这些节点发送流量。此外，AWSAutoScaling可确保正确数量的EC2实例可用于运行你的应用程序，根据需求启动和终止实例，并由你的扩展策略定义。如果你的应用程序由于可用区故障而不需要短期性能下降，那么你的体系结构应该是静态稳定的，这意味着它不需要更改工作负载的行为以容忍故障。在这种情况下，你的体系结构应该提供多余的容量来承受一个可用区的丢失。
AWS上的许多高级服务都是根据多可用区（多可用区）原则设计的。例如，AmazonRDS使用多可用区部署为数据库实例提供高可用性和自动故障转移支持，而对于AmazonS3和AmazonDynamoDB，你的数据跨多个设施进行冗余存储。
4.5.8.5故障隔离与传统水平扩展
虽然主主冗余模式非常适合平衡流量和处理实例或可用区中断，但如果对请求本身有任何不利影响是不够的。例如，可能存在每个实例都受到影响的情况。如果某个特定请求碰巧触发导致系统故障转移的错误，则调用者可能会通过反复尝试针对所有实例的相同请求来触发级联故障。
随机分片
你可以对传统的水平缩放进行隔离改进，这称为分片。与传统上与数据存储系统一起使用的技术类似，你可以将实例分组为分片，而不是在每个节点上传播来自所有客户的流量。例如，如果你的服务有八个实例，则可以创建四个分片，每个分片包含两个实例（每个分片中有两个实例用于冗余），并将每个客户分配到特定分片。
就这样，你能够与你拥有的分片数量成正比地减少对客户的影响。但是，一些客户仍然会受到影响，因此关键是要使客户端容错。如果客户端可以尝试一组分片资源中的每个端点，直到成功，那么你将获得显着的改进。这种技术称为随机分片。
4.6优化成本
当你将现有架构迁移到云中时，由于AWS的规模经济，你可以减少资本支出并节省成本。通过迭代和使用更多AWS功能，你可以有机会实现创建成本优化的云架构。
4.6.1正确的实例
AWS为许多用例提供了广泛的资源类型和配置。例如，AmazonEC2，AmazonRDS，AmazonRedshift和AmazonES等服务提供了许多实例类型。在某些情况下，你应该选择最适合你工作负载要求的类型。在其他情况下，使用较少实例类型的较少实例可能会降低总成本或提高性能。你应该对应用程序环境进行基准测试，并根据工作负载使用CPU，RAM，网络，存储大小和I/O的方式选择正确的实例类型。
同样，你可以通过选择适合你需求的存储解决方案来降低成本。例如，AmazonS3提供各种存储类，包括标准，简化冗余和标准-不常访问。其他服务（如AmazonEC2，AmazonRDS和AmazonES）支持你应评估的不同EBS卷类型（磁性，通用SSD，预配置IOPSSSD）。
AWS提供的工具可帮助你识别这些节省成本的机会并使你的资源保持正确的大小。为了使这些工具的结果易于理解，你应该为AWS资源定义和实施标记策略。你可以使用AWS管理工具（如AWSElasticBeanstalk和AWSOpsWorks）将标记作为构建过程的一部分进行自动化。你还可以使用AWSConfig提供的托管规则来评估特定标记是否应用于你的资源。
4.6.2充分利用弹性
使用AWS节省资金的另一种方法是利用平台的弹性。计划为尽可能多的AmazonEC2工作负载实施AutoScaling，以便你在需要时横向扩展并缩小规模并在不再需要该容量时自动减少支出。此外，你可以在不使用时自动关闭非生产工作负载。最后，考虑你可以在AWSLambda上实施哪些计算工作负载，以便你永远不会为空闲或冗余资源付费。
尽可能将AWSEC2工作负载替换为不需要你做出任何容量决策的AWS托管服务（例如ELB，AmazonCloudFront，AmazonSQS，AmazonKinesisFirehose，AWSLambda，AmazonSES，AmazonCloudSearch或AmazonEFS）或使你能够在需要时轻松修改容量（例如AmazonDynamoDB，AmazonRDS或AmazonES）。
4.6.3充分利用各种采购方案
AmazonEC2On-Demand实例定价为你提供最大的灵活性，无需长期承诺。另外两个可以帮助你减少开支的EC2实例是预留实例和竞价型实例。
4.6.3.1预留实例
与按需实例定价相比，AmazonEC2预留实例允许你保留AmazonEC2计算容量，以换取大幅折扣的小时费率。这是具有可预测的最小容量要求的应用的理想选择。你可以利用AWSTrustedAdvisor或AmazonEC2使用情况报告等工具来识别你最常使用且应考虑保留的计算资源。根据你的预留实例购买，折扣将反映在每月帐单中。按需EC2实例和预留实例在技术上没有区别。不同之处在于你为预留的实例付费的方式。
其他服务也存在预留容量选项（例如，AmazonRedshift，AmazonRDS，AmazonDynamoDB和AmazonCloudFront）。
提示：在对生产中的应用程序进行充分基准测试之前，不应提交预留实例购买。在你之后已购买预留容量，你可以使用预留实例利用率报告确保你仍在充分利用预留容量。
4.6.3.2竞价实例
对于不太稳定的工作负载，请考虑使用竞价实例。AmazonEC2Spot实例允许你使用备用AmazonEC2计算容量。由于与按需定价相比，竞价实例通常以折扣价格提供，因此你可以显着降低运行应用程序的成本。
竞价实例使你可以请求未使用的EC2实例，这可以显着降低你的AmazonEC2成本。竞价实例（每个可用区中的每个实例类型）的每小时价格由AmazonEC2设置，并根据竞价实例的长期供应和需求逐步调整。只要容量可用且你的请求的每小时最高价格超过竞价价格，你的竞价型实例就会运行。
因此，竞价实例非常适合可以容忍中断的工作负载。但是，当你需要更可预测的可用性时，也可以使用竞价型实例。例如，你可以将预留，按需和竞价型实例组合在一起，将可预测的最小容量与对其他计算资源的机会访问相结合，具体取决于竞价市场价格。这是提高吞吐量或应用程序性能的一种极具成本效益的方法。
4.7缓存
缓存是一种存储先前计算的数据以供将来使用的技术。该技术用于提高应用程序性能并提高实现的成本效率。它可以应用于IT架构的多个层。
4.7.1应用程序数据缓存
AmazonElastiCache是一种Web服务，可以轻松部署，操作和扩展云中的内存缓存。它支持两个开源的内存缓存引擎：Memcached和Redis。
AmazonDynamoDBAccelerator（DAX）是DynamoDB的完全托管，高可用性内存缓存，可提供从毫秒到微秒的性能改进，实现高吞吐量。DAX为你的DynamoDB表添加了内存加速，而无需管理缓存失效，数据填充或集群管理。
4.7.2边缘缓存
静态内容（图像，CSS文件或流媒体预录制视频）和动态内容（响应式HTML，实时视频）的副本可以缓存在AmazonCloudFront边缘位置，这是一个在全球有多个存在点的CDN。边缘缓存允许内容由更接近的基础设施提供服务查看器，可以降低延迟并为你提供高大，持续的数据传输速率，从而为大规模的最终用户提供大型流行对象。
你的内容请求将智能地路由到AmazonS3或原始服务器。如果源在AWS上运行，请求将通过优化的网络路径传输，以获得更可靠和一致的体验。你可以使用AmazonCloudFront来交付整个网站，包括不可缓存的内容。在这种情况下，好处是AmazonCloudFront重用AmazonCloudFront边缘和源服务器之间的现有连接，这减少了每个源请求的连接设置延迟。还应用其他连接优化以避免互联网瓶颈并充分利用边缘位置和观看者之间的可用带宽。这意味着，当你浏览Web应用程序时，AmazonCloudFront可以加快你的动态内容的交付，并为你的查看者提供一致，可靠，个性化的体验。AmazonCloudFront还将上传请求应用于与下载动态内容请求相同的性能优势。安全
4.8安全
你可能已经在传统IT基础架构中熟悉的大多数安全工具和技术都可以在云中使用。同时，AWS允许你以各种方式提高安全性。AWS是一个平台，允许你在平台本身中正式设计安全控制。它简化了管理员和IT部门的系统使用，使你的环境更容易以连续的方式进行审计。
4.8.1使用AWS功能进行深度防御
AWS提供了许多功能，可以帮助你构建具有深度防御方法的体系结构。从网络级别开始，你可以构建VPC拓扑，通过使用子网，安全组和路由控制来隔离部分基础结构。AWSWAF（Web应用程序防火墙）等服务可以帮助保护你的Web应用程序免受SQL注入和应用程序代码中的其他漏洞的影响。对于访问控制，你可以使用IAM定义一组精细策略，并将其分配给用户，组和AWS资源。最后，AWSCloud提供了许多选项来保护你的数据，无论是在运输途中还是静止状态。
4.8.2与AWS共享安全责任
AWS在共享安全责任模型下运行：AWS负责底层云基础架构的安全性，你负责保护你在AWS中部署的工作负载。这有助于你通过使用AWS托管服务减少你的职责范围并专注于你的核心竞争力。例如，当你使用AmazonRDS和AmazonElastiCache等服务时，安全补丁会自动应用于你的配置设置。这不仅可以降低团队的运营开销，还可以减少你的漏洞风险。
4.8.3减少特权访问
当你的服务器是可编程资源时，你将获得许多安全优势。随时随地更改服务器的功能使你无需客户操作系统访问生产环境。如果实例遇到问题，你可以自动或手动终止并替换它。但是，在替换实例之前，你应该收集并集中存储日志数据，这些数据可以帮助你在开发环境中重新创建问题，并通过持续部署过程将它们部署为修复程序。此方法可确保日志数据有助于排除故障并提高安全事件的意识。这在服务器是临时的弹性计算环境中尤为重要。你可以使用AmazonCloudWatchLogs收集此信息。如果你没有直接访问权限，则可以实施AWSSystemsManager55等服务，以获取统一视图并自动对资源组执行操作。你可以将这些请求与你的票务系统集成，以便仅在批准后跟踪和动态处理访问请求。
另一个常见的安全风险是使用存储的长期凭证或服务帐户。在传统环境中，服务帐户通常会分配存储在配置文件中的长期凭据。在AWS上，你可以使用IAM角色通过使用自动分发和轮换的短期凭据向EC2实例上运行的应用程序授予权限。对于移动应用程序，你可以使用AmazonCognito允许客户端设备通过具有细粒度权限的临时令牌访问AWS资源。
作为AWS管理控制台用户，你可以类似地通过临时令牌提供联合访问，而不是在你的AWS账户中创建IAM用户。然后，当员工离开你的组织并从组织的身份目录中删除时，该员工也会自动失去对你的AWS账户的访问权限。
4.8.4安全代码
此外，为了获得更好的控制和安全性，可以将AWSCloudFormation模板作为产品导入AWSServiceCatalog.5。这使你可以集中管理资源，以支持一致的治理，安全性和合规性要求，同时使你的用户能够快速部署他们需要批准的IT服务。你应用IAM权限来控制可以查看和修改产品的人员，并定义约束以限制可以为产品部署特定AWS资源的方式。
4.8.5实时审计
5.结论
在AWS中设计云架构时，重要的是要考虑AWS中的重要原则和设计模型，包括如何为应用程序选择正确的数据库，以及如何构建可以水平扩展且具有高可用性的应用程序。由于每项实现都是唯一的，因此你必须评估如何将此指南应用于你的实现。云计算体系结构是一个广泛而不断发展的主题。您可以使用AWS网站上提供的材料以及AWS培训和认证产品，随时了解AWS云产品的最新更改和添加。
说明：
本文由新钛云服运维工程师傅雨斌翻译，新钛云服拥有八名认证的AWS工程师，在AWS使用和维护方面拥有丰富的经验，已经为多家用户提供AWS上云支持。