微服务拆分原则#

拆分原则：

1. 业务驱动：按 DDD 限界上下文（订单/用户/商品）
2. 高内聚低耦合：相关功能在一起，减少跨服务调用
3. 数据自治：每个服务拥有自己的数据库
4. 渐进式：先拆核心/变化频繁的模块

反模式： 拆太细(调用链长) / 数据库共享 / 循环依赖

微服务拆分的核心原则是按 DDD 限界上下文来划分服务边界，比如电商系统拆成订单服务、用户服务、商品服务、支付服务，每个服务对应一个业务领域。拆分要遵循三个关键原则：高内聚低耦合，相关功能放在同一个服务内减少跨服务调用；数据自治，每个服务拥有自己独立的数据库，通过 API 交互而不是共享数据库，否则数据库变更会互相影响耦合又回去了；渐进式拆分，先拆核心模块和变化频繁的模块，不要一上来就把系统拆成几十个微服务。常见的反模式有三个：拆太细导致调用链过长像蜘蛛网，一个请求需要跨十几个服务严重影响性能和排查难度；多个服务共享同一个数据库，表面上是微服务实际上还是耦合的；服务间循环依赖 A 调 B、B 调 A。另外不要在单体还没优化好的时候就急着拆，很多时候单体的性能问题是代码和架构问题，拆微服务只会引入更多复杂度。

追问方向：

• “拆分后带来什么新问题？”→ 分布式事务（跨服务数据一致性）、服务间调用复杂度增加、运维成本上升（部署/监控/排障）、分布式调试困难、数据冗余和同步问题
• “什么时候不应该拆分？”→ 团队规模小（3-5人维护单体就够）、业务边界不清晰（拆了还要频繁跨服务调用）、没有足够的基础设施（缺少注册中心/配置中心/监控/CI-CD），强行拆分只会增加复杂度
• “你们怎么拆分的？”→ 按业务领域拆分（DDD 限界上下文）：先识别核心域/支撑域/通用域，沿着领域边界拆服务；渐进式拆分，先把变化最快的模块拆出来，逐步演进，避免一次性大拆

易错点：

• ❌ 微服务越多越好——过度拆分导致调用链长
• ❌ 先拆分再优化——应先优化单体