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