微服务拆分七大原则与反例详解：从分布式大单体到云原生架构

从单体应用架构发展为 SOA 架构，再到微服务架构，以及云原生时代的微服务架构、服务网格（Service Mesh）、无服务架构（Serverless），应用架构经历了多年不断地演进。

如今，云原生微服务架构被广泛使用，但在实践中，许多系统并未正确运用其理念，最终形成了一套“披着微服务外衣的分布式大单体”。

软件架构并不是被发明出来的，而是持续演进的结果。

本文将分享一个从「分布式单体」演化为云原生微服务的架构设计与重构历程。

单体应用架构的审视

在探讨云原生微服务之前，有必要先回顾单体应用架构。理解架构为何演进、解决了哪些问题，才能为具体业务场景选择合理方案。

单体架构在很长一段时间内是软件架构的主流风格，也是大多数开发者学习和实践过的模式。即便在今天，对于小型系统（如工单提交系统），它依然适用。单体应用部署、测试相对简单，模块间的调用在进程内完成，效率高于分布式系统。

需要注意的是，单体架构并非意味着代码铁板一块、不可拆分。无论是单体还是微服务，通常都会在代码结构上进行纵向分层。

按照调用顺序，从上到下可分为：

• 表示层：负责用户体验与界面展示。
• 业务逻辑层：负责核心业务处理，图中多个模块均集成于同一系统内。
• DAO数据访问层：负责数据库的增删改查操作。
• DB层：数据库。

然而，随着业务发展，所有功能模块打包于一个WAR包中，导致每次代码提交都需经历冗长的编译和启动过程，研发效率低下。多人协作于同一主干分支，合并代码冲突频发，沟通成本巨大。

由于所有代码共享同一进程空间，无法隔离，无法单独停止或升级某个模块。一旦部分代码出现缺陷（如内存溢出），可能耗尽公共资源，导致整个系统崩溃。

单体架构隐含一个理想化前提：系统的每个部件和每行代码都高度可靠。 但现实是，交付一个高质量可靠的单体系统本质是一个挑战。在多数开发场景中，平衡工期、成本与代码质量是常态。

微服务架构的核心与挑战

面对单体架构在复杂项目中的构建部署慢、可靠性差等问题，微服务架构应运而生。

微服务是一种通过多个小型服务组合来构建应用的架构风格，这些服务围绕业务能力而非特定技术标准构建。各服务可采用不同的编程语言、数据存储技术，并运行于独立进程中，通过轻量级通信机制和自动化部署实现协作。

每个微服务拥有独立的代码库和数据库，通常由一个小型全功能团队负责，具备独立演进和部署的能力。

其中涉及的核心组件包括：

• 服务注册与发现：提供者注册地址，消费者动态发现服务。
• 负载均衡：在多个服务实例间分配请求。
• 配置中心：统一管理多环境配置。
• 服务网关：作为系统唯一入口，处理鉴权、流控等。
• 调用链追踪：可视化请求路径，便于故障定位。

微服务的优势：

1. 应用拆分为模块，更易于开发、理解和维护。
2. 团队可独立选择技术栈，专注API提供。
3. 服务独立部署，加快迭代速度，支持AB测试等。

微服务面临的挑战：

• 运维要求高：需保障数十甚至上百个服务的稳定与协作。
• 分布式复杂性：需处理系统容错、网络延迟、分布式事务等问题。
• 接口调整成本高：修改某个服务的API可能影响所有调用方。

迈向云原生：微服务的支撑平台

将单体拆分为微服务后，团队并未立即感到轻松，因为配置中心、服务发现、网关、熔断等分布式问题亟待解决。过去，我们选择在应用层而非基础设施层解决这些问题，很大程度上是因为硬件基础设施的灵活性不足。

为此，微服务进入了云原生时代。

云原生应用具备三大特征：

• 容器化封装：以容器为基础，提升开发水平与组件复用，简化维护。
• 动态管理：通过集中式编排系统动态调度。
• 面向微服务：明确并解耦服务间依赖。

云原生是释放云计算价值的最短路径。以容器技术为代表，结合 Kubernetes 作为容器编排的事实标准，它将业务从传统虚拟机部署转变为容器化方式，运行于K8s之上，最大化享受弹性、敏捷等技术红利。

一个经典的微服务拆分反例

微服务拆分并非简单地将应用切割。以下是一个亲身经历的反例：一个旨在打造标准化“平台”的供应链金融系统。

负责人宣称这是微服务架构，但查看代码后发现，这是一个披着微服务外衣的大单体。

该系统拆分为十几个“微服务”，但业务压力全部集中于一个核心的platform-xxx-service。其他被拆分出的服务仅是接收请求、转换参数的接口层，基本没有业务逻辑和独立数据库，最终将所有请求透传至核心服务。

这导致platform-xxx-service承载了所有繁重业务，接口庞大、功能耦合。初衷是避免修改核心服务，但结果却是核心服务被迫不断改动，成为一个巨型单体。服务拆分失去了意义，违背了领域驱动设计中拆分领域和子域的理念。

微服务拆分的七大原则

为避免上述问题，设计微服务架构时可遵循以下七大原则：

1. 单一职责原则

简单的就是最好的。每个微服务应只负责一个单一且完整的业务功能，并拥有自己的独立数据库，确保在数据层解耦，便于维护、测试、部署和扩展。

2. 基于可靠性拆分

将可靠性要求高的核心服务与要求低的非核心服务拆分开，重点保障核心服务的高可用。这样，非核心服务故障不会波及核心系统。例如，将登录、支付等要害模块独立成服务并集群化。

3. DDD领域驱动原则

微服务设计与DDD（领域驱动设计）天然契合。通过战略设计划分业务领域边界（限界上下文），限界上下文可转化为微服务边界；通过战术设计实现领域模型。利用“事件风暴”等方法识别领域事件，找到系统边界。

4. 按照业务稳定性拆分

区分系统中稳定与易变的部分。通常，80%的功能相对稳定，20%经常变动。将稳定部分拆分为公共服务，易变部分独立以满足快速迭代，避免稳定服务频繁发布。

5. 基于吞吐量拆分

针对高并发、高性能要求的特定场景（如秒杀、抢购），将这部分业务拆分出来，既能保证性能，又能通过隔离避免雪崩效应影响其他业务。

6. 演进式原则

拆分应循序渐进。初期可粗粒度划分，随着业务复杂度和团队规模增长，再逐步细化。一个微服务由3人左右的团队维护是一个比较合理的平衡点，兼顾了系统理解、团队备份和技术讨论。

7. 避免环形与双向依赖

服务间的环形或双向依赖会加剧耦合，使升级和维护变得困难。这通常源于功能划分不清或通用功能未下沉。解决方法是明确服务上下游关系，通过领域事件进行异步通信，并将为满足前端而增加的调用逻辑放到BFF层编排。