REL03-BP01 选择如何划分工作负载
在确定应用程序的弹性要求时，工作负载划分很重要。应尽量避免使用整体架构，仔细考虑哪些应用程序组件可以分解为多项微服务。应用程序具体需求各异，架构到最后往往会将服务导向型架构（SOA）与微服务架构两者结合起来。能够实现无状态的工作负载更容易部署为微服务。
期望结果：工作负载应该可支持、可扩展，并且尽量做到松耦合。
在选择如何划分工作负载时，要权衡其优点和复杂性。适用于即将首次发布的新产品的功能，有别于从一开始就构建用于扩展的工作负载的需求。重构一个现有的整体架构时，您需要考虑应用程序对无状态分解的支持程度。通过将服务分解为较小的部分，可以让职责明确的小型团队来开发和管理它们。然而，较小的服务会带来复杂性，包括可能会增加延迟，调试变得更复杂，而且加重运营负担。
常见反模式：
-
微服务 Death Star
是这样一种情况：原子组件变得高度相互依赖，牵一发而动全身，使组件像一块整体一样死板而又脆弱。
建立此最佳实践的好处：
-
更多特定分段可以提高敏捷性、组织灵活性和可扩展性。
-
减小了服务中断的影响。
-
应用程序组件可能有不同的可用性要求，可通过更加原子化的分段来满足这些要求。
-
支持工作负载的团队职责分明。
在未建立这种最佳实践的情况下暴露的风险等级：高
实施指导
请根据工作负载的分段方式选择架构类型。选择 SOA 或微服务架构（极少数情况下是整体架构）。即便在刚开始选择整体架构，您必须确保它是模块化的，而且由于您的产品随着采用的用户增加而扩展，它最终也可转变成为 SOA 或微服务架构。SOA 和微服务各自提供较小的区段，它们是现代可扩展和可靠架构的首选，但您需要认真权衡利弊，尤其在部署微服务架构时。
一项主要的权衡是您现在使用的是分布式计算架构，可能更难实现用户延迟要求，还增加了调试和跟踪用户交互的复杂性。您可以使用 AWS X-Ray 来帮助解决此问题。需要考虑的另一个影响是，您管理的应用程序数量增加时，运营复杂性也会随之增加，这要求部署多个相互独立组件。
整体架构、服务导向型架构和微服务架构
实施步骤
-
确定构建或重构应用程序所需的适当架构。SOA 和微服务分别提供较小分段，这是现代可扩展的可靠架构的首选。要在实现较小分段的同时避免一些微服务复杂性，SOA 是很好的折中方案。有关更多详细信息，请参阅 Microservice Trade-Offs
。 -
如果工作负载适合，并且组织可以支持，则应使用微服务架构来实现最佳敏捷性和可靠性。有关更多详细信息，请参阅在 AWS 上实施微服务。
-
考虑按照 Strangler Fig 模式
将整体重构为较小的组件。这包括使用新的应用程序和服务逐步替换特定的应用程序组件。AWS Migration Hub Refactor Spaces 充当增量重构的起点。有关更多详细信息，请参阅 Seamlessly migrate on-premises legacy workloads using a strangler pattern 。 -
实施微服务可能需要服务发现机制，让这些分布式服务间能够相互通信。AWS App Mesh 可用于服务导向型架构，提供对服务的可靠发现和访问。AWS Cloud Map
也可以用于基于 DNS 的动态服务发现。 -
如果要从整体架构迁移到 SOA，Amazon MQ 可以在重新设计云中的传统应用程序时作为服务总线帮助缩小差距。
-
对于具有单个共享数据库的现有整体架构，请选择将数据重组为较小分段的方式。可以按业务部门、访问模式或数据结构来划分。在重构过程的这一阶段，应选择是使用关系型还是非关系型（NoSQL）数据库来继续操作。有关更多详细信息，请参阅从 SQL 到 NoSQL。
实施计划的工作量级别：高
资源
相关最佳实践：
相关文档：
相关示例：
相关视频：
