# REL03-BP01 选择如何划分工作负载
在确定应用程序的弹性要求时，工作负载划分很重要。应尽量避免使用整体架构，仔细考虑哪些应用程序组件可以分解为多项微服务。应用程序具体需求各异，架构到最后往往会将服务导向型架构（SOA）与微服务架构两者结合起来。能够实现无状态的工作负载更容易部署为微服务。
**期望结果：**工作负载应该可支持、可扩展，并且尽量做到松耦合。
在选择如何划分工作负载时，要权衡其优点和复杂性。适用于即将首次发布的新产品的功能，有别于从一开始就构建用于扩展的工作负载的需求。重构一个现有的整体架构时，您需要考虑应用程序对无状态分解的支持程度。通过将服务分解为较小的部分，可以让职责明确的小型团队来开发和管理它们。然而，较小的服务会带来复杂性，包括可能会增加延迟，调试变得更复杂，而且加重运营负担。
**常见反模式：**
+ [微服务 *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) 是这样一种情况：原子组件变得高度相互依赖，牵一发而动全身，使组件像一块整体一样死板而又脆弱。
**建立此最佳实践的好处：**
+ 更多特定分段可以提高敏捷性、组织灵活性和可扩展性。
+ 减小了服务中断的影响。
+ 应用程序组件可能有不同的可用性要求，可通过更加原子化的分段来满足这些要求。
+ 支持工作负载的团队职责分明。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
请根据工作负载的分段方式选择架构类型。选择 SOA 或微服务架构（极少数情况下是整体架构）。即便在刚开始选择整体架构，您必须确保它是模块化的，而且由于您的产品随着采用的用户增加而扩展，它最终也可转变成为 SOA 或微服务架构。SOA 和微服务各自提供较小的区段，它们是现代可扩展和可靠架构的首选，但您需要认真权衡利弊，尤其在部署微服务架构时。
一项主要的权衡是您现在使用的是分布式计算架构，可能更难实现用户延迟要求，还增加了调试和跟踪用户交互的复杂性。您可以使用 AWS X-Ray 来帮助解决此问题。需要考虑的另一个影响是，您管理的应用程序数量增加时，运营复杂性也会随之增加，这要求部署多个相互独立组件。
![\[图中显示了整体架构、服务导向型架构和微服务架构之间的比较\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/monolith-soa-microservices-comparison.png)
## 实施步骤
+ 确定构建或重构应用程序所需的适当架构。SOA 和微服务分别提供较小分段，这是现代可扩展的可靠架构的首选。要在实现较小分段的同时避免一些微服务复杂性，SOA 是很好的折中方案。有关更多详细信息，请参阅 [Microservice Trade-Offs](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) 充当增量重构的起点。有关更多详细信息，请参阅 [Seamlessly migrate on-premises legacy workloads using a strangler pattern](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)。
**实施计划的工作量级别：**高
## 资源
**相关最佳实践：**
+ [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/)
+ [Bounded Context (a central pattern in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [在 AWS 上实施微服务](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](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)
**相关示例：**
+ [Iterative App Modernization 讲习会](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**相关视频：**
+ [Delivering Excellence with Microservices on AWS](https://www.youtube.com/watch?v=otADkIyugzY)