工作中，想必大家常遇到这样的情况：初期，急于满足业务需求，项目需要尽快上线，所以采用了最简单的单体服务实现业务需求。项目允许一段时间后，发现诸多问题：耦合严重，不易于扩展，与公司技术栈不统一等问题。这时，就需要把单体服务拆分成微服务。以下，简单梳理下拆分的原则、方法、步骤。
一、单体服务与微服务
1. 单体服务
单体服务是所有业务代码、功能模块全部整合在一个项目里，打成一个包统一部署运行。
结构特点：
- 代码统一仓库，不分服务
- 共用同一个数据库
- 只部署一个应用实例
- 所有功能共享服务器资源
适用场景：小型项目、初创项目、业务简单、用户量少、迭代节奏快的系统。
优点 ：架构简单易维护。
缺点：体量增大后存在迭代慢、无法独立扩容、故障影响面大等弊端。
2. 微服务
微服务是按业务领域 拆分，拆分成多个独立小型服务，每个服务独立开发、独立部署、独立运行，通过接口互相调用协同完成整体业务。
核心特点：
- 服务拆分，职责单一，高内聚低耦合
- 各服务独立数据库，数据隔离
- 可单独扩缩容、单独发布上线
- 服务之间通过网关、远程调用、消息队列通信
- 支持不同服务使用不同技术栈
优点：实现解耦拆分、独立运维扩容，提升系统弹性与迭代效率
缺点：架构与运维复杂度显著提升。
二、拆分原则
- 按业务领域拆分（领域驱动 DDD）
- 高内聚、低耦合，相近业务放一起
- 单一职责，一个服务只负责一类业务
- 数据尽量隔离，优先独立库，避免多服务共用库
- 先粗分再细化，循序渐进，不一次性全切
三、常用拆分维度
1. 按业务模块：用户、订单、商品、支付、物流、风控
**2. 按功能职责：**业务服务、定时任务、文件服务、消息服务
**3. 按访问流量：**高并发单独拆出独立扩容
**4. 按读写分离：**查询服务、写入服务拆分
四、拆分步骤
- 业务梳理：梳理业务流程、模块、依赖关系
- 领域划分：划定服务边界，拆分用户、订单、商品、支付等服务
- 公共抽取：抽出登录、文件、短信、定时任务等通用基础服务
- 数据库拆分：分库分表，设计数据表与字段映射
- 接口改造：统一接口规范，定义远程调用接口
- 引入微服务组件：注册中心、网关、配置中心、远程调用
- 数据迁移：全量 + 增量迁移，保证数据一致
- 灰度双跑：单体与微服务并行，逐步切换流量
- 全量切换：流量切完，下线单体旧服务
- 完善治理：熔断、限流、链路追踪、日志监控
五、重点注意问题
- 避免循环依赖，通过 MQ 或聚合服务解耦
- 解决分布式事务，优先使用最终一致性方案
- 跨服务查询，禁止远程联表，用数据同步、聚合查询
- 做好接口兼容，平滑过渡不影响线上业务
- 控制拆分粒度，不拆分过细造成服务臃肿
- 预留回滚方案，上线异常快速切回单体
- 提前处理幂等、超时、重试等分布式问题