# REL 3  如何设计工作负载服务架构？
<a name="w2aac19b9b7b5"></a>

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

**Topics**
+ [REL03-BP01 选择如何划分工作负载](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 构建专注于特定业务领域和功能的服务](rel_service_architecture_business_domains.md)
+ [REL03-BP03 根据 API 提供服务合同](rel_service_architecture_api_contracts.md)

# REL03-BP01 选择如何划分工作负载
<a name="rel_service_architecture_monolith_soa_microservice"></a>

 在确定应用程序的弹性要求时，工作负载划分很重要。应尽可能避免使用整体式架构。相反，应仔细考虑哪些应用程序组件可以分解为多项微服务。根据您的应用程序要求，最终应尽可能采用服务导向型架构（SOA）与微服务组合的形式。能够实现无状态的工作负载更容易部署为微服务。 

 **期望结果：** 工作负载应该可支持、可扩展，并尽可能地松散耦合。 

 在选择如何划分工作负载时，要权衡其优点和复杂性。适用于即将首次发布的新产品的功能有别于从一开始就构建用于扩展的工作负载的需求。重构一个现有的整体架构时，您需要考虑应用程序对无状态分解的支持程度。通过将服务分解为较小的部分，可以让职责明确的小型团队来开发和管理它们。然而，较小的服务会带来复杂性，包括可能会增加延迟，调试变得更复杂，而且加重运营负担。 

 **常见反模式：** 
+  如示例所示， [微服务 *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) 是这样一种情况：原子组件变得高度相互依赖，牵一发而动全身，使组件像一块整体一样死板而又脆弱。

 **建立此实践的好处：** 
+  更多特定分段可以提高敏捷性、组织灵活性和可扩展性。 
+  减小了服务中断的影响。 
+  应用程序组件可能有不同的可用性要求，可通过更加原子化的分段来满足这些要求。 
+  支持工作负载的团队职责分明。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 高 

## 实施指导
<a name="implementation-guidance"></a>

 请根据工作负载的分段方式选择架构类型。选择 SOA 或微服务架构（极少数情况下是整体架构）。即便在刚开始选择整体架构，您必须确保它是模块化的，而且由于您的产品随着采用的用户增加而扩展，它最终也可转变成为 SOA 或微服务架构。SOA 和微服务各自提供较小的区段，它们是现代可扩展和可靠架构的首选，但您需要认真权衡利弊，尤其在部署微服务架构时。 

 一项主要的权衡是您现在使用的是分布式计算架构，可能更难实现用户延迟要求，还增加了调试和跟踪用户交互的复杂性。您可以使用 AWS X-Ray 来帮助解决此问题。需要考虑的另一个影响是，您管理的应用程序数量增加时，运营复杂性也会随之增加，这要求部署多个相互独立组件。 

![\[整体架构、服务导向型架构和微服务架构之间的比较图\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)


## 实施步骤
<a name="implementation-steps"></a>
+  确定构建或重构应用程序所需的适当架构。SOA 和微服务分别提供较小分段，这是现代可扩展的可靠架构的首选。要在实现较小分段的同时避免一些微服务复杂性，SOA 是很好的折中方案。有关更多详细信息，请参阅 [微服务利弊权衡](https://martinfowler.com/articles/microservice-trade-offs.html). 
+  如果您的工作负载适合，并且您的组织可以支持，则应使用微服务架构来实现最佳敏捷性和可靠性。有关更多详细信息，请参阅 [在 AWS 上实施微服务。](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  考虑遵循 [*Strangler Fig* 模式，](https://martinfowler.com/bliki/StranglerFigApplication.html) 将整体架构重构为较小的组件。这包括逐步用新的应用程序和服务替换特定的应用程序组件。[AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) 作为增量重构的起点。有关更多详细信息，请参阅 [使用绞杀者模式无缝迁移本地传统工作负载](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/)。
+  实施微服务可能需要采用一种服务发现机制，让这些分布式服务能够相互通信。[AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) 可用于服务导向型架构，以实现可靠的发现和服务访问。 [AWS Cloud Map](https://aws.amazon.com/cloud-map/) 也可用于动态的基于 DNS 的服务发现。
+  如果您要从整体架构迁移到 SOA，[Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) 可作为服务总线来帮助弥合这一差距（在云中重新设计传统应用程序时）。
+  对于具有单个共享数据库的现有整体架构，请选择将数据重组为较小分段的方式。可以按业务部门、访问模式或数据结构来划分。在重构过程的这一阶段，应选择是使用关系型还是非关系型（NoSQL）数据库来继续操作。有关更多详细信息，请参阅 [从 SQL 到 NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).

 **实施计划的工作量级别：** 高 

## 资源
<a name="resources"></a>

 **相关最佳实践：** 
+  [REL03-BP02 构建专注于特定业务领域和功能的服务](rel_service_architecture_business_domains.md) 

 **相关文档：** 
+  [Amazon API Gateway：使用 OpenAPI 配置 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
+  [什么是服务导向型架构？](https://aws.amazon.com/what-is/service-oriented-architecture/) 
+  [边界上下文（领域驱动设计的中心模式）](https://martinfowler.com/bliki/BoundedContext.html) 
+  [在 AWS 上实施微服务](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [微服务利弊权衡](https://martinfowler.com/articles/microservice-trade-offs.html) 
+  [微服务 – 一个全新架构术语的定义](https://www.martinfowler.com/articles/microservices.html) 
+  [AWS 上的微服务](https://aws.amazon.com/microservices/) 
+  [什么是 AWS App Mesh？](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) 

 **相关示例：** 
+  [迭代应用程序现代化研讨会](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro) 

 **相关视频：** 
+  [利用 AWS 上的微服务实现卓越](https://www.youtube.com/watch?v=otADkIyugzY) 

# REL03-BP02 构建专注于特定业务领域和功能的服务
<a name="rel_service_architecture_business_domains"></a>

 面向服务的架构（SOA，Service-Oriented Architecture）采用由业务需求定义的划分明确的功能来构建服务。微服务则使用领域模型和有界上下文对此进行进一步限制，使每项服务都只用于一种用途。专注于特定功能让您可以区分不同服务的可靠性要求，并且更有针对性地锁定投资目标。简洁的业务问题和与每项服务关联的小型团队也简化了组织扩展。 

 在设计微服务架构时，借助于领域驱动设计 (DDD) 对使用实体的业务问题进行建模十分有帮助。以 Amazon.com 网站为例，实体可能包括包装、配送、时间表、价格、折扣和货币。然后，该模型会使用 [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)进一步细分为更小的模型，具有相似功能和属性的实体在边界上下文中被分到一组。因此，在 Amazon.com 例子中，包装、配送和时间表是装运上下文的一部分，而价格、折扣和货币是定价上下文的一部分。通过将模型细分为不同的上下文，即可得到如何确定微服务边界的模板。 

![\[如何确定微服务边界的模型模板\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/building-services.png)


 **未建立这种最佳实践的情况下暴露的风险等级：** 高 

## 实施指导
<a name="implementation-guidance"></a>
+  根据业务领域及各自的功能设计工作负载。专注于特定功能让您可以区分不同服务的可靠性要求，并且更有针对性地锁定投资目标。简洁的业务问题和与每项服务关联的小型团队也简化了组织扩展。 
  +  执行领域分析，为您的工作负载制定领域驱动设计 (DDD) 方案。然后，您可以选择一个架构类型，以满足您的工作负载需求。
    +  [如何将整体式架构分解为多项微服务](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
    +  [在被遗留系统包围时通过 DDD 开始着手](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
    +  [Eric Evans“领域驱动设计：解决软件核心的复杂性”](https://www.amazon.com/gp/product/0321125215) 
    +  [在 AWS 上实施微服务](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+ 将服务分解成尽可能小的组件。借助微服务架构，您可以将工作负载分解成功能最小的组件，以便支持组织的可扩展性和敏捷性。
  +  根据工作负载及其设计目标、限制和任何其他使用注意事项来定义 API。
    +  定义 API。
      +  API 定义应允许增加参数。 
    +  定义设计可用性。
      + 您的 API 可以具有针对不同功能的多个设计目标。
    +  设置限制 
      +  通过测试来确定工作负载的功能限制。

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [Amazon API Gateway：使用 OpenAPI 配置 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
+  [边界上下文（领域驱动设计的中心模式）](https://martinfowler.com/bliki/BoundedContext.html) 
+  [Eric Evans“领域驱动设计：解决软件核心的复杂性”](https://www.amazon.com/gp/product/0321125215) 
+  [在被遗留系统包围时通过 DDD 开始着手](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
+  [如何将整体式架构分解为多项微服务](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
+  [在 AWS 上实施微服务](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [微服务利弊权衡](https://martinfowler.com/articles/microservice-trade-offs.html) 
+  [微服务 – 一个全新架构术语的定义](https://www.martinfowler.com/articles/microservices.html) 
+  [AWS 上的微服务](https://aws.amazon.com/microservices/) 

# REL03-BP03 根据 API 提供服务合同
<a name="rel_service_architecture_api_contracts"></a>

 服务合同是团队之间关于服务集成的成文协议，它包括机器可读的 API 定义、速率限制和性能预期。版本控制策略让客户能够继续使用现有的 API，并在更新的 API 准备就绪时将他们的应用程序迁移到此类 API。只要遵守合同，即可随时进行部署。服务提供商团队可以使用自己选择的技术堆栈来满足 API 合同要求。同样，服务使用者可以使用自己的技术。 

 微服务将面向服务的架构（SOA，Service-Oriented Architecture）的概念提升到创建具有最小功能集的服务。每项服务都会发布一个 API，以及使用相应服务的设计目标、限制和其他注意事项。这会通过调用 *应用程序* 建立合同。这可以实现三个主要优势： 
+  服务具有一个需要解决的简明的业务问题，以及出现该业务问题的小型团队。这有助于更好地扩展组织。 
+  只要满足 API 和其他合同要求，团队就可以随时进行部署。 
+  只要满足 API 和其他合同要求，团队就可以使用他们想用的任何技术堆栈。 

 Amazon API Gateway 是一种完全托管式服务，可以帮助开发人员轻松创建、发布、维护、监控和保护任意规模的 API。它负责处理多达数十万个并发 API 调用的接受和处理过程中涉及的所有任务，包括流量管理、授权和访问控制、监控以及 API 版本管理。采用 OpenAPI 规范 (OAS)，亦即之前的 Swagger 规范，您可以定义 API 合同并将其导入到 API Gateway。然后，您便可以通过 API Gateway 对 API 进行版本控制与部署。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 低 

## 实施指导
<a name="implementation-guidance"></a>
+  按照不同 API 提供服务合同：服务合同是团队之间关于服务集成的记录在案的协议，它包括机器可读的 API 定义、速率限制和性能预期等。 
  +  [Amazon API Gateway：使用 OpenAPI 配置 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
    +  版本控制策略让客户能够继续使用现有的 API，并在更新的 API 准备就绪时将他们的应用程序迁移到此类 API。
    +  Amazon API Gateway 是一种完全托管式服务，可以帮助开发人员轻松创建任意规模的 API。采用 OpenAPI 规范（OAS，OpenAPI Specification），亦即之前的 Swagger 规范，您可以定义 API 合同并将其导入到 API Gateway。然后，您便可以通过 API Gateway 对 API 进行版本控制与部署。

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [Amazon API Gateway：使用 OpenAPI 配置 REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
+  [边界上下文（领域驱动设计的中心模式）](https://martinfowler.com/bliki/BoundedContext.html) 
+  [在 AWS 上实施微服务](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [微服务利弊权衡](https://martinfowler.com/articles/microservice-trade-offs.html) 
+  [微服务 – 一个全新架构术语的定义](https://www.martinfowler.com/articles/microservices.html) 
+  [AWS 上的微服务](https://aws.amazon.com/microservices/)