4、服务化拆分：从单体到微服务的驱动力、服务拆分的粒度原则、服务间通信方式（RPC vs 消息队列）、我经历的一次痛苦拆分。
4.1 为什么必须拆？—— 驱动力分析
说实话，我见过太多团队把单体应用硬撑到几千行代码。一开始挺爽的，开发快、部署简单。但到了某个临界点，问题就全冒出来了。
我经历过一个典型的场景：一个交易核心系统，所有逻辑都揉在一个进程里。订单、支付、风控、清算，全在一起。每次上线，哪怕改一行日志，也得全量部署。更可怕的是，某个模块内存泄漏，整台机器都挂了。
拆分的驱动力，说白了就三点：
- 团队规模膨胀：十几个人同时改一个仓库，合并冲突能让你崩溃。我见过一个团队，每天光解决冲突就要花两小时。
- 部署频率受限：单体应用启动就要5分钟，每次发布都得挑凌晨。你想想看，业务方催着上线，你却说「今晚发不了，得排队」。
- 故障隔离失效：一个模块的OOM，能把整个交易链路拖垮。我记得有一次，清算模块的批量任务把CPU吃满，订单模块的响应时间直接飙到10秒。
核心观点：拆分的本质不是技术炫技，而是为了控制复杂度和提升交付效率。如果团队只有3个人，业务也不复杂，别急着拆。
4.2 拆到什么程度？—— 粒度原则
很多新手容易走极端。要么拆得太粗，跟没拆一样；要么拆得太细，一个订单服务拆成十几个，结果通信成本比业务逻辑还高。
我个人习惯用三个维度来判断粒度：
| 维度 | 原则 | 反面案例 |
|---|---|---|
| 业务边界 | 一个服务只做一件事，且做完整 | 把「订单创建」和「订单查询」拆成两个服务 |
| 数据独立性 | 每个服务拥有自己的数据库 | 多个服务共享同一个订单库 |
| 变更频率 | 经常一起变的功能，放在一个服务里 | 支付和退款逻辑频繁联动，却拆成两个服务 |
嗯，这里要注意一个坑：不要为了微服务而微服务。我曾经见过一个团队，把用户服务拆成了「用户基本信息服务」「用户地址服务」「用户偏好服务」。结果每次查询用户详情，要调三个接口。这其实是在用分布式系统的复杂度，换取根本不存在的收益。
我的建议：先按业务领域拆，每个服务对应一个限界上下文。如果两个功能的数据必须强一致，就别拆。如果它们可以接受最终一致，再考虑拆分。
4.3 服务间怎么聊？—— RPC vs 消息队列
服务拆开了，通信就成了大问题。我见过最糟糕的做法：服务之间直接通过HTTP调用来同步数据，结果一个服务挂了，整条链路都卡住。
通信方式的选择，其实取决于你对一致性和可用性的取舍。
RPC（同步调用）
适合那些需要实时响应的场景。比如用户下单时，需要实时校验库存。这时候用gRPC或者Dubbo，延迟低、语义清晰。
// 伪代码：RPC调用库存服务
StockResponse resp = stockService.deductStock(order.getSkuId(), order.getQuantity());
if (!resp.isSuccess()) {
throw new BusinessException("库存不足");
}但RPC有个致命问题：强耦合。调用方必须知道被调用方的接口，而且被调用方挂了，调用方也得跟着处理异常。
消息队列（异步解耦）
适合那些可以延迟处理的场景。比如订单创建成功后，发送一条消息给积分服务，让它慢慢加积分。这时候用RocketMQ或者Kafka，削峰填谷，效果很好。
// 伪代码：发送消息到MQ
OrderCreatedEvent event = new OrderCreatedEvent(orderId, userId, amount);
mqProducer.send("order_created_topic", event);我个人的经验是：核心链路用RPC，非核心链路用MQ。比如支付扣款必须实时，那就用RPC；发送通知、更新报表，用MQ就够了。
避坑指南：我曾经在一个项目里，把所有服务间通信都改成了MQ。结果排查问题时，消息轨迹乱成一团，一个订单的流转要查五六个Topic。后来我学乖了：能用RPC解决的，别硬上MQ。
4.4 我经历的一次痛苦拆分
讲个真实的故事。几年前，我接手了一个交易系统。这个系统已经跑了三年，代码量超过50万行。业务方天天抱怨：加个新支付渠道要两周，修个Bug要三天。
我们决定拆分。但第一次拆分，就踩了大坑。
我们按功能模块拆：订单、支付、商品、用户。听起来挺合理对吧？但实际跑起来，问题全出来了：
- 数据耦合：订单服务直接查用户表，因为用户服务还没建好。结果用户服务上线后，订单服务还在用老的表结构。
- 事务问题：一个下单流程，要调订单服务、库存服务、支付服务。如果支付失败，订单已经创建了，库存也扣了。回滚？分布式事务搞了两个月，最后还是用了补偿机制。
- 调用链爆炸：一个简单的查询订单详情，要调用户服务、商品服务、物流服务。接口响应时间从50ms变成了500ms。
后来我们痛定思痛，重新制定了拆分策略：
- 先拆数据，再拆代码：先把数据库按领域拆分，确保每个服务有自己的数据源。代码可以慢慢迁移，但数据必须先解耦。
- 引入BFF层：对于前端需要的聚合查询，在BFF层做编排，而不是让前端直接调多个微服务。
- 逐步灰度：先拆一个非核心模块（比如通知服务），跑一个月没问题，再拆核心模块。
这次拆分，前后花了半年。虽然过程痛苦，但结果值得：部署频率从两周一次变成了每天多次，故障恢复时间从小时级降到了分钟级。
总结一句话：拆分不是一蹴而就的。它更像是一场手术，需要先诊断、再规划、最后动刀。别想着一天搞定，也别因为怕痛就不拆。