如果你正在设计大型并发应用或者准备拆解旧系统再拆解，我想你首先考虑的是微服务架构。早些时候我们了解到，微服务架构将应用程序构建为一系列松散耦合的服务，以通过实现持续交付和灵活部署来加速软件开发。出于多种原因，分解对于促进劳动分工和知识共享很重要。使用它，具有专业知识的多个人（或团队）可以在单个应用程序上高效协作。它描述了多个元素如何相互作用。在微服务下，有两类项目需要重新开发。Projects——外文译名：Brownfieldprojects是指在现有或遗留系统的背景下开发和部署新的软件系统。因此，将单体应用程序转换为微服务就是这样一个项目。新项目-指的是从头开始构建一个全新的系统，不使用任何遗留代码。当您从头开始时，没有任何限制或依赖性。1.按业务能力模型分解为了创建微服务架构，一种策略是基于业务能力进行分解。作为一项业务，项目就是创造价值。例如，在电子商务业务中，订单管理、库存管理、支付、发货等都涉及到。这种模式有以下优点：业务能力比较稳定，架构所依赖的业务逻辑比较稳定。开发团队是跨职能的、自治的，并且围绕交付业务价值而不是技术功能进行组织。服务是松耦合和内聚的。2.按子域模式分解域驱动设计(DDD)方法论是一种构建复杂软件应用程序的方法，它是基于面向对象域模型的开发。DDD为每个子域定义了一个单独的区域模型。每个子域都属于一个域。识别子领域类似于识别业务能力的过程，即分析业务和识别专业领域。最有可能的是，大多数是企业熟悉的子域。域模型的范围在DDD中称为有界上下文。有界上下文包括实现模型的代码组件。子域可以分类如下：核心——业务最大的差异化因素和应用程序中最有价值的部分。在一些公司，往往有核心系统项目，由核心报价子系统、核心定价子系统等支撑——不是差异化因素，而是与业务提供的内容有关。通常在内部或外包实施。通用-不特定于业务，最好使用现成的软件实施。这种模式有以下优点：子域功能比较稳定，结构比较稳定。开发团队（通常旨在形成虚拟团队）是跨职能的、自治的，并且专注于提供业务价值而不是技术功能。服务是松耦合和内聚的。3.将单体应用程序分解为微服务时的挑战将单体应用程序分解时，可能会出现挑战。网络延迟——在分布式系统中，网络延迟是一个持续关注的问题。您可能会发现服务的特定分解会导致两个服务之间的大量往返。数据一致性——每个服务都有自己的数据库，因此跨服务保持数??据一致性可能非常困难。上帝类（捂脸哭）——上帝类是系统中控制太多其他对象的对象，它超越逻辑成为万能类。由于其规模和复杂性，它是一个集中系统智能并使用来自其他类的信息的类。4.Strangler模式在将遗留的单体应用程序迁移到微服务架构时，会使用Strangler模式。此模式可用于通过用新服务替换特定功能来逐步转换单体应用程序。新服务一准备好，旧组件就被杀死，新服务投入使用，旧组件下线。整体式应用程序最终会缩减功能，而微服务会接管整体式功能。
