此内容已过时。此版本的架构完善的框架现在可在以下位置找到： https://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/reliability.html

REL 3: 如何设计工作负载服务架构？

使用面向服务的架构 (SOA) 或微服务架构构建高度可扩展的可靠工作负载。面向服务的架构 (SOA) 可通过服务接口使软件组件可重复使用。微服务架构则进一步让组件变得更小、更简单。

资源

选择如何划分工作负载: 应避免使用整体式架构。您应该在 SOA 和微服务之中做选择。在做选择时，权衡优点和复杂性 – 适用于即将首次发布的新产品的功能有别于从一开始就构建用于扩展的工作负载的需求。使用较小分段的好处包括提高敏捷性、组织灵活性和可扩展性。复杂性则包括可能会增加延迟，调试变得更复杂，而且加重运营负担
构建专注于特定业务领域和功能的服务: SOA 采用由业务需求定义的划分明确的功能来构建服务。微服务则使用领域模型和有界上下文对此进行进一步限制，使每项服务都只用于一种用途。专注于特定功能让您可以区分不同服务的可靠性要求，并且更有针对性地锁定投资目标。简洁的业务问题和与每项服务关联的小型团队也简化了组织扩展。
根据 API 提供服务合同: 服务合同是团队之间关于服务集成的成文协议，它包括机器可读的 API 定义、速率限制和性能预期。版本控制策略让客户能够继续使用现有的 API，并在更新的 API 准备就绪时将他们的应用程序迁移到此类 API。只要遵守合同，即可随时进行部署。服务提供商团队可以使用自己选择的技术堆栈来满足 API 合同要求。同样，服务使用者可以使用自己的技术。

选择如何划分工作负载

请根据工作负载的分段方式选择架构类型: 选择面向服务的架构 (SOA) 或微服务架构（有些情况下是整体式架构）。

SOA 和微服务分别提供较小分段，这是现代可扩展的可靠架构的首选。但是，如果您有足够的理由选择整体式架构，则必须确保它是模块化架构，而且由于您的产品随着采用用户的增加而扩展，它最终也可转变成为 SOA 或微服务架构。
要在实现较小分段的同时避免一些微服务复杂性，SOA 是很好的折中方案。
Microservice Trade-Offs
如果您的工作负载适合，并且您的组织可以支持，则应使用微服务架构来实现最佳敏捷性和可靠性。
Implementing Microservices on AWS
AWS App Mesh 可用于面向服务的架构，以实现可靠的发现和服务访问。
What is AWS App Mesh?

构建专注于特定业务领域和功能的服务

根据业务领域及各自的功能设计工作负载: 专注于特定功能让您可以区分不同服务的可靠性要求，并且更有针对性地锁定投资目标。简洁的业务问题和与每项服务关联的小型团队也简化了组织扩展。

将服务分解成尽可能小的组件: 借助微服务架构，您可以将工作负载分解成功能最小的组件，以便支持组织的可扩展性和敏捷性。

根据 API 提供服务合同

根据 API 提供服务合同: 服务合同是团队之间关于服务集成的成文协议，它包括机器可读的 API 定义、速率限制和性能预期。
Amazon API Gateway: Configuring a REST API Using OpenAPI

版本控制策略让客户能够继续使用现有的 API，并在更新的 API 准备就绪时将他们的应用程序迁移到此类 API。
Amazon API Gateway 是一种完全托管的服务，可以帮助开发人员轻松创建任意规模的 API。采用 OpenAPI 规范（OAS，以前成为 Swagger 规范），您可以定义 API 合同并将其导入到 API Gateway。然后，您便可以通过 API Gateway 对 API 进行版本控制与部署。