单一服务内部功能高内聚低耦合

每个服务仅负责自身职责范围内的任务，非自身职责的功能交由其他对应服务处理，避免功能混杂、边界模糊。

电商系统中，“订单服务”仅处理订单的创建、修改、查询、取消等订单相关操作；用户注册、登录由“用户服务”负责，支付由“支付服务”负责，订单服务不参与用户信息管理或支付流程。

闭包原则（CCP）

当需要修改某个微服务时，所有相关依赖、修改点均在该服务内部，无需改动其他微服务，降低修改带来的连锁影响。

“商品服务”负责商品信息（名称、价格、库存）的管理，若需新增“商品标签”字段，仅需修改商品服务的数据库、接口及内部逻辑，无需改动调用它的订单服务、首页服务。

服务自治、接口隔离原则

消除服务间的强依赖，通过标准接口对外提供服务，隐藏内部实现细节，实现服务独立开发、测试、部署、运行，降低沟通成本，提升稳定性。

“短信服务”通过标准HTTP接口对外提供“发送短信”“查询短信发送状态”功能，其他服务（如注册服务、订单服务）仅需调用该接口，无需知道短信服务内部是用阿里云还是腾讯云短信通道，也无需关注其代码实现。

持续演进原则

服务拆分初期无需追求“完美拆分”，应结合业务认知逐步划分、持续优化，避免服务数量爆炸性增长，防止过度拆分增加管理成本。

初期将电商系统拆分为“用户服务”“订单服务”“商品服务”3个核心服务；随着业务发展，发现“商品评价”功能日益复杂，再将其从商品服务中拆分出来，独立为“评价服务”，逐步完善服务边界。

拆分避免影响产品日常功能迭代

拆分与产品功能迭代并行，优先剥离独立边界服务、非核心服务，减少拆分对现有业务的影响，同时给团队提供试错、练习机会；有依赖关系时，优先拆分被依赖服务。

电商系统拆分时，优先剥离“短信服务”“日志服务”等非核心、边界清晰的服务，不影响核心的订单下单、商品浏览功能；若订单服务依赖商品服务，先拆分商品服务，再逐步拆分订单服务。

避免环形依赖与双向依赖

禁止服务间出现A依赖B、B依赖A的环形依赖或双向依赖，出现此类情况说明功能边界划分不清，或存在未下沉的通用功能。

错误示例：订单服务依赖商品服务查询商品价格，商品服务又依赖订单服务查询商品销量；正确做法：将“商品价格”“商品销量”统一放在商品服务，订单服务仅调用商品服务接口，消除双向依赖。

阶段性合并

当业务逻辑变化、对领域边界理解加深，或原有拆分不合理导致服务边界混乱时，需重新梳理边界，对服务进行阶段性合并，纠正拆分偏差。

初期将“地址管理”拆分为独立服务，但后续发现该服务功能简单、调用频率低，且主要被用户服务调用，边界模糊，此时将地址管理功能合并到用户服务，减少服务数量，简化管理。

自动化驱动

服务数量增多会导致部署、运维成本指数级上升，拆分前需构建自动化工具及环境，简化服务创建、开发、测试、部署、运维的重复性工作，降低管理复杂度。

搭建Jenkins自动化部署工具，实现服务代码提交后自动构建、自动测试、自动部署；使用ELK日志收集分析工具，统一管理所有服务的日志；通过Prometheus实现服务监控自动化，减少人工运维成本。

服务接口具备可扩展性

接口设计需考虑后续升级，避免因参数变更导致调用方报错，推荐使用封装类作为接口参数，新增参数时无需变更接口签名。

错误示例：用户注册接口最初设计为（username, password）两个参数，后续新增“phone”参数时，修改接口签名为（username, password, phone），导致所有调用该接口的服务报错；正确做法：将参数封装为“UserRegisterDTO”类，接口参数仅为该类，新增“phone”字段时，仅修改DTO类，接口签名不变。

一、核心拆分总原则

核心逻辑

按业务复杂度选型拆分模式，不局限单一方式，可灵活组合

选型标准

1. 业务复杂度低 → 数据驱动拆分（自下而上）；2. 业务复杂度高 → 领域驱动DDD拆分（自上而下）

二、两大业务驱动拆分方式

1. 数据驱动拆分（简单业务首选）

设计思路：自下而上，先定数据表结构，按数据关系划服务；拆分流程：需求分析→抽象数据结构→划分服务→确定调用关系→流程验证

2. 领域驱动DDD拆分（复杂核心业务首选）

设计思路：自上而下，对齐业务专家统一语言，划定业务边界；核心优势：贴合真实业务目标，避免技术脱离业务；拆分流程：统一领域语言→业务场景分析→寻找业务聚合→划定限界上下文→确定服务调用→流程验证+持续优化；落地规则：一个限界上下文=一个微服务

3. 单体系统渐进式拆分

拆分顺序：前后端分离→抽取公共基础服务（登录、配置等）→优先垂直业务拆分→辅以水平通用切分→逐步剥离老系统业务

三、非功能维度六大拆分策略

1. 扩展性拆分

区分变/不变业务：稳定通用功能抽公共服务，高频迭代业务独立拆分；二八原则：20%变动业务独立拆分，80%稳定业务统一复用，互不影响发布

2. 复用性拆分

抽取通用重复能力：鉴权、限流、日志、监控、网关能力统一下沉为公共服务，全业务复用

3. 高性能拆分

1. 高压力模块独立拆分（如电商抢购排队服务）；2. 读写分离拆分：读多写少业务拆读服务、写服务；3. 数据一致性原则：强一致数据尽量同服务，弱一致数据可跨服务拆分

4. 高可用拆分

核心业务与非核心业务物理拆分，集中资源保障核心服务稳定性；遵循三个火枪手原则控制核心服务数量

5. 安全性拆分

高密级安全业务独立拆分，分区部署（DMZ隔离），精准管控安全权限，降低安全设备压力

6. 异构性拆分

按技术栈/开发语言拆分，不同语言实现的业务独立成服务，适配技术异构场景

四、微服务拆分核心风险与避坑

1. 团队能力先行

先评估团队微服务技术栈驾驭能力，再落地拆分

2. 拒绝追求最优方案

只做当下最合适拆分，预留后期调整空间

3. 落地优先理论

先拆分落地，不合适再调整，搭建服务治理、双写迁移等配套能力

4. 杜绝只拆不合

服务过多、粒度过细、维护成本飙升需及时合并；多服务打包同机部署降资源损耗，内部依旧保持微服务边界，方便后续再次拆分

5. 组织架构适配

拆分后匹配独立小团队专职维护对应服务