背景
我在做订单 + 履约中台，按 DDD 拆了 6 个服务，跑了 3 年。最近一次 P99 抖动复盘，根因是「读流量集中在 2 个服务，把写路径的 HikariCP 连接池和 JVM 老年代都挤爆了」——读 QPS 10 万、写 QPS 500，但两者共用同一进程的 CPU / 连接池 / GC 周期，读流量一来，写路径的 P99 直接从 30ms 抖到 800ms。
拆完之后，资源争用反而比单体时更难观测：争用发生在不同服务、不同实例、不同 GC 周期上，日志根本拼不起来。于是我开始想一个问题：我们「按域拆」的对不对？还是该按流量特征拆？
常见分歧
派 A：按业务域拆（DDD 正统）
- 边界清晰，团队可以独立演进、独立发布
- 业务一致性靠「域内强一致 + 跨域最终一致」，模型简单
- 反对流量拆的理由：把「流量特征」当拆分依据，会切碎业务逻辑，跨服务调用成本上升，最后变成「分布式单体」——改一个字段要动 2 个仓库
派 B：按流量特征拆（CQRS 读模型 + 同步/异步分离）
- 读多写少、同步异步、重计算轻 IO——按这个切，容量规划简单，P99 可控
- 热点读路径独立扩容，写路径不受读流量干扰
- 反对域拆的理由：域边界是「逻辑上的」，但资源争用是「物理上的」，域拆不解决争用问题
派 C（少数派）：不拆，用进程内隔离
- 线程池隔离、连接池隔离、信号量限流，把读和写切到不同线程池
- 反对拆的理由：拆了之后运维复杂度指数上升，不如在进程内做好隔离
我的倾向
我站「混合派」：主干按域拆（保持业务边界清晰），但热点读路径再按流量切一层（CQRS 读模型），同步链路和异步链路也分开。
但前提是「资源争用可观测」——至少要有线程池饱和度、连接池等待、GC 停顿这三类信号，否则切了也是白切。因为争用还是会发生，只是从「进程内」变成「进程间」，更难 debug。
具体判据：
- 读 QPS > 写 QPS 10 倍，且读写共享同一连接池 → 切
- 同步链路 P99 抖动主要来自异步链路的 GC / IO → 切
- 读写流量比 < 5 倍，且资源争用可观测 → 不切，进程内隔离够用
想听大家
- 什么场景下你选了「流量拆」而不是「域拆」？是读流量 > 写流量 10 倍？还是有重计算？
- 切完之后，业务一致性怎么保？MQ 同步的延迟你们能接受多少？
- 有没有「切错了」的教训？切了之后反而更难维护的案例？
- 派 C 的朋友：进程内隔离做到什么粒度，能真正解决读写争用？
欢迎贴你们的架构图 / 拆分决策记录，比空谈有营养。
0赞
0收藏
0楼层