【.com快译】如果你的组织正在考虑采用和实施微服务，那么你一定听过这样的名词：领域驱动设计（Domain-DrivenDesign）、事件驱动架构（Event-DrivenArchitecture）、核心域（CoreDomain）、子域（Subdomain）、限界上下文（BoundedContext）、反腐败层（Anti-corruptionLayer）等概念。同时，你的团队是否有能力将业务领域逻辑（或业务空间）以正确的方式进行分解，并与微服务架构（或代码空间）进行映射，从而受益于微服务架构带来的优势什么？微服务分解架构逻辑图在本文中，我将为大家总结出分解微服务的十大原则和相关策略。1.使用BoundedContext和UbiquitousLanguage（无处不在的语言）来查看业务领域。在分解之前，我们首先要做的是拉近产品负责人和开发人员之间的距离。产品负责人可能不理解技术术语，技术团队可能不理解术语在解释业务时的重要性。因此，要弥合这种鸡鸭相隔的鸿沟，我们需要采取以下步骤：将产品负责人召集到看板前，问他们：“业务目标是什么？”、“在其中的角色是什么？”一个特定的功能？'，“他们在定义功能时使用了什么术语？”这些问题将帮助技术人员清除可能具有误导性的业务术语。例如“OrderContextCustomer”和“SchemaSupportContextCustomer”之间的区别。一旦您理解了歧义术语，请绘制出具有相关特征的上下文，以确保名称每个领域实体在每个上下文中都足够清晰。为每个上下文定义一种通用语言，这样当业务和技术团队进行交流时，他们可以使用相同的通用语言进行同步。从粗粒度的限界上下文开始。限界上下文是没有除非后来出现令人信服的业务原因，否则不再细分。2.确定核心领域并应用创新思想核心领域是那些可以为您的业务带来收益的部分。对于B2C在线购物应用程序，购物车模块属于核心领域。我们需要通过思考如何改进竞争对手没有的模块来充分了解我们的核心模块。任何自动化或创新都会增加你的收入和优势，因此你需要专注于核心领域的研发和投资，以保持自身的竞争优势。3.成本优化通用域通用域是每个企业的公共部分。通常，不同的第三方会为商业市场提供通用的解决方案。比如每个业务的通知模块，或者广告推送模块。为了避免重复“发明轮子”，我们需要以成本优化的方式创建公共域，或者以相对便宜的价格使用第三方解决方案。4.适当考虑支撑域通常，核心域需要借助支撑域来充实自己。当然，在某些情况下，支撑域不仅能带来收益，未来还可能转化为核心域。例如，在前面的示例中，与购物车域相比，库存管理是一个支持域。然后，通过投资支持领域，您还可以产生收入。例如，为了降低运输成本，我们不仅可以选择站点增加库存，还可以通过算法为客户订单识别最近的库存位置。5.引入防腐层防腐层是微服务设计中不可或缺的一部分，可以保护微服务免受外部变化的影响。比如在实践中，一些老项目会受到主机环境的限制，或者依赖某种语言来构建。因为它们是微服务输入数据的重要来源，所以它们不仅需要与微服务架构共存，甚至会阻碍系统的分解。因此，在遗留架构和微服务通信之间创建一个门面比直接使用遗留中的数据并在微服务和遗留架构之间创建耦合要好得多。同时，由于一般领域都会调用第三方库，与其直接按照合约消费/发布数据，不如引入一个防腐层，将微服务与外部合约的API隔离开来，端口和集线器模式。也就是说，我们可以通过创建契约和防腐层来充当微服务与第三方连接的“翻译器”，协助调用第三方库。6.识别数据通信模式一旦你根据功能分解了微服务，并在核心服务中封装了你自己的数据库和持久层（即每个服务的数据库），接下来要了解的重要事情是UI视图/组件将如何与每个组件（包括流）通信。例如：当用户异步获取某个功能时，你可以在执行完某些功能后创建一个中间状态，让另一个系统处理这个中间状态，通过回调通知用户继续后续操作。7.引入事件驱动架构（EDA）在实时应用中，您的业务用例可能有复杂的工作流，您需要根据数据的状态变化在工作流上生成许多分支。由于工作流可以采取不同的策略，如果您需要通过RestAPI公开所有内容，您会发现每个微服务都需要与其他微服务耦合。这将不可避免地导致“意大利面条”代码和分布式“泥球”。可见我们需要的是一个干净的架构。这些微服务中的每一个都可以独立运行而无需耦合。这就是事件驱动架构可以发挥作用的地方——每个事件都可以包含一些状态变化。微服务通过遵循发布/订阅模型生成状态更改，并以事件的形式包含必要的数据。其他微服务会监听这个事件，并可以根据事件中的数据采取相应的策略。由于事件是不可变的，它还保存着实体或聚合器的历史。基于此，如果您要使用事件存储和事件风暴，则会生成相应的统计信息和事件报告。8.让API契约简洁明了在微服务中，经常需要以API的形式发布契约。那么，在发布您的API时，请确保您的API不会发布内部状态信息。考虑到网络调用和封装，发布API实际上是其他服务获取足够信息以继续其流程的一种方式。但是，他们不应多次返回以获取派生信息。因此，在策划活动时，应该考虑哪些活动可以发布，哪些活动需要内部保存。您甚至可以只发布一个粗粒度事件而不是多个小的内部事件。例如：如果你内部产生了地址变更事件和个人信息变更事件，你应该发布一个名为CustomerUpdateEvent的粗粒度事件，而不是同时发布在API契约中。9.将相关的微服务合并成更大的服务分解后，你可能会遇到一些微服务在需要添加或更新功能时总是会一起变化的情况。那是当你意识到你以错误的方式分解它的时候。由于它们是同一逻辑单元的不同部分，因此不能将它们隔离为更小的服务。为此，您可以将它们组合成一个大服务，以减少不必要的耦合和网络调用。10.引入支持无缝开发的工具通过采用微服务，我们可以提高可扩展性和高可用性，同时缩短上市时间。但是，由于该架构是基于分布式网络，我们需要提前购买各种配套软件，以免出现不可避免的故障。例如，您可以在CI/CD管道上采用云基础设施，使用配套的跟踪工具，使用日志聚合器来搜索日志，以及使用各种混沌工具（chaostools）来检测各种故障。原标题：10CommandmentsofMicroserviceDecomposition，作者：ShamikMitradecomposition
