在设计大型高并发应用或重构遗留系统时，微服务架构往往是首要考虑的方向。它将应用程序构建为一系列松散耦合的服务，旨在通过实现持续交付和灵活部署来加速软件开发。
分解为何至关重要
- 促进分工与知识共享：拥有不同专业知识的多个人或团队可以围绕同一个应用高效协作。
- 明确交互关系：它清晰地定义了系统中各个组件之间是如何交互的。
微服务项目的两种类型
- 遗留系统重构项目 (Brownfield)：指在现有或遗留系统的背景下开发和部署新软件。将单体应用迁移到微服务就属于此类。
- 全新开发项目 (Greenfield)：指从头开始为一个全新系统进行开发，没有遗留代码的约束或依赖。
一、按业务能力分解模式
创建微服务架构的一种核心策略是基于业务能力进行划分。企业的存在是为了创造价值。以电商业务为例，其核心能力通常包括订单管理、库存管理、支付处理、物流运输等。
此模式的优势：
- 稳定性高：业务能力本身相对稳定，因此依赖于此的架构设计也更为稳固。
- 团队组织优化：可以组建跨职能、自主的开发团队，团队目标聚焦于交付业务价值，而非单纯实现技术特性。
- 服务特性优良：由此产生的服务具有松耦合、高内聚的特点。
二、按子域模式分解
领域驱动设计 (DDD) 是一种构建复杂软件的方法论，其核心是围绕领域模型进行开发。在DDD中，每个子域都拥有独立的领域模型，而整个领域则由若干子域构成。识别子域的过程与识别业务能力类似，都需要深入分析业务并划分专业领域。大多数子域都是业务方所熟悉的。在DDD中，领域模型的边界被称为“限界上下文”，它包含了实现该模型的所有代码组件。
子域通常可分为三类：
- 核心子域：这是业务的最大差异化所在，也是应用最具价值的部分。许多公司的“核心系统”项目（如核心报价、核心定价子系统）便属于此类。
- 支撑子域：这类子域虽非业务的直接差异化因素，但与业务运作紧密相关，通常由内部团队或外包方式实现。
- 通用子域：这类子域不具业务特殊性，最佳实践是采用成熟的现成软件或解决方案。
此模式的优势：
- 架构稳定：由于子域职能稳定，基于其构建的架构也相对稳定。
- 团队目标清晰：开发团队（常需组建虚拟团队）能够跨职能、自主地工作，专注于交付业务价值。
- 服务结构合理：最终形成的服务同样是松耦合且高内聚的。
三、单体应用分解为微服务的挑战
在拆分单体应用的过程中，会不可避免地遇到一些挑战。
- 网络延迟：在分布式系统中，网络延迟是一个持续存在的问题。不当的服务划分可能导致两个服务间产生大量不必要的网络往返通信。
- 数据一致性：每个微服务都拥有独立的数据库，这使得维护跨服务的数据一致性变得极具挑战性。
- 上帝类 (God Class)：上帝类是指一个过度庞大、控制了系统中过多其他对象、集中了过多系统智能的类。由于其规模和复杂性，它超越了合理的业务逻辑边界，成为了难以拆分和理解的“全能类”。
四、Strangler（绞杀者）模式
在将遗留的单体应用迁移至微服务架构时，Strangler模式是一种常用策略。该模式通过逐步用新的微服务替换单体应用中的特定功能来实现渐进式迁移。当新服务就绪后，旧的对应组件即被“绞杀”并下线，新服务随之接管其职责。
最终，单体应用的功能范围会不断缩小，而微服务将逐步接管整体业务功能。
通过结合业务能力分解、领域驱动设计的子域划分以及Strangler迁移模式，团队可以更系统、更稳健地完成向微服务架构的演进。如果你对系统架构设计与重构有更多兴趣，欢迎在云栈社区与其他开发者交流探讨。 | 
发表于 19 小时前
|
查看: 3|
回复: 0
