微服务架构分解：从单体到服务的核心策略、模式与落地挑战

如果你正在设计大型高并发应用，或是准备对陈旧的遗留系统进行现代化改造，采用微服务架构往往是首要考虑的方向。

微服务架构的核心在于将单体应用拆分为一系列松散耦合的独立服务，其目标是通过实现持续交付与灵活的独立部署来加速软件开发进程。

为何分解如此重要？

• 促进分工与知识共享：它允许多个具备特定专长的人或团队在一个应用上高效协作。
• 明确定义交互边界：架构清晰地描述了系统中各个组件（服务）之间如何交互。

微服务项目的两种类型

1. 遗留系统重构项目：指在现有或遗留系统的背景下开发和部署新软件。例如，将单体应用改造为微服务就属于此类。
2. 全新开发项目：指完全从零开始构建一个全新的系统，不受任何遗留代码的约束和依赖。

一、按业务能力模式分解

创建微服务架构的一种常见策略是基于业务能力进行分解。企业的存在是为了创造价值，其业务能力是相对稳定的。以电子商务为例，其核心业务能力包括订单管理、库存管理、支付、物流运输等。

这种模式的优势在于：

1. 架构稳定：业务能力本身变化较慢，因此依赖它的架构也更为稳定。
2. 团队导向明确：开发团队是跨职能、自主的，其组织核心是交付业务价值，而非实现技术特性。
3. 服务设计合理：由此产生的服务天然具备松耦合和高内聚的特性。

二、按子域模式分解

这是领域驱动设计（DDD）倡导的方法。DDD为复杂业务领域中的每个子域定义独立的领域模型。识别子域的过程与识别业务能力类似，都需要深入分析业务并找出专业领域。在DDD中，领域模型的边界被称为“限界上下文”，它包含了实现该模型的所有代码组件。

子域通常可以分为三类：

1. 核心子域：业务的最大差异化因素，是应用程序最具价值的部分。例如某些公司的核心报价系统、核心定价引擎。
2. 支撑子域：虽非差异化核心，但与业务紧密相关。这类子域通常由内部团队或外包实现。
3. 通用子域：不特定于业务，属于行业通用问题，最佳实践是直接采用成熟的现成软件或解决方案。

按子域分解同样能带来显著好处：

1. 子域职能稳定：与业务能力一样，子域的划分也相对稳定，有助于架构的长期演进。
2. 团队聚焦价值：开发团队（可能涉及组建虚拟团队）能够跨职能协作，专注于交付业务价值。
3. 服务解耦内聚：最终构建出的服务自然保持松耦合和高内聚。

三、单体应用分解为微服务的挑战

在拆分一个庞杂的单体应用时，我们不可避免地会面临一些工程挑战：

1. 网络延迟：在分布式系统中，网络延迟是一个持续存在的关注点。不合理的服务划分可能导致两个服务之间产生大量不必要的网络往返调用。
2. 数据一致性：每个微服务都拥有自己独立的数据库，这使得维护跨多个服务的数据一致性变得异常复杂，通常需要引入最终一致性、Saga模式等分布式事务解决方案。
3. 上帝类：在单体应用中，常常存在一种“上帝类”（God Class），它知晓和控制了系统中过多的其他对象，集中了过多的业务逻辑。由于其规模和复杂性，它往往成为拆分过程中最难处理的部分。

四、扼杀者模式

在将遗留的单体应用迁移到微服务架构时，“扼杀者模式”（Strangler Pattern）是一种被广泛采用的策略。该模式通过逐步用新的微服务替换单体应用中的特定功能块来实现平滑迁移。一旦新服务准备就绪，对应的旧组件就被“扼杀”并下线，新服务随之接管其职责。

最终，单体应用的功能范围会不断缩小，而微服务集群将逐步接管整个系统的功能。