SPS/CPS单体拆Java微服务：边界定不好，代码全白搞

如果你所在的电商团队，手头维护着一个同时承载SPS商家服务和CPS联盟推广结算的Java单体项目，而且最近每次上线都像拆炸弹——改了商家入驻的代码，结果CPS归因那边跟着报错，数据库里一张订单表被十几个服务拽着不放，那这篇文章你大概率用得上。

今天想聊的，是这种SPS/CPS混合单体在向Java微服务拆分演进时，最容易被忽略也最致命的一环：边界怎么定，以及边界定完之后，Java工程里那些几乎每天都会踩的实操坑该怎么绕。先说明白，我讲的是实操技巧，不是架构PPT——该画的边界会画，该给的代码会给你看，该避的坑一个不落。适合正在做服务化改造的Java后端开发者和技术负责人看，也适合想搞懂微服务拆分底层逻辑的同学当作一份拆解前手记来读。

我在实际项目里见过太多团队，把Spring Cloud全家桶装起来，Nacos、Feign、Sentinel该上全上，结果服务拆了二十个，线上事故反而翻倍。问题基本都出在两个地方：一是边界根本没想清楚，按Controller拆、按表拆、按心情拆；二是拆完以后，分布式环境下的事务、锁、序列化、日志追踪这些Java基本功没跟上。所以下面这套拆法，不是我拍脑袋总结的，是踩过坑之后复盘出来的。

1. 为什么要拆：SPS/CPS单体应用的失控现场

1.1 从“能跑就行”到“大泥球”

大部分电商平台的SPS（商家/供应商绩效与商品管理）和CPS（按效果付费的联盟推广结算）系统，早期都长在同一个Java单体应用里。一开始业务简单，一个订单进来，商家那边要扣库存，推广那边要记佣金，同一个事务里顺手写完，逻辑链路短，部署也省事。但业务跑两三年以后，问题就藏不住了。

我接手那会儿，这个单体项目大概有四十多万行Java代码，三百多张表，WAR包扔在Tomcat里，启动要五六分钟。SPS的商家资质审核和CPS的推广链接点击统计，从代码上看起来井水不犯河水，实际上共用了一套会员体系、一套订单表、一套支付回调逻辑。每次需求排期，只要有人动订单相关的Service，两边测试都得回归一遍，因为谁也不知道这段改动会顺着哪个函数引用捅到哪儿去。

这种状态有个很形象的名字，叫大泥球。不是代码写得烂，而是业务边界长期没有梳理，模块之间像藤蔓一样缠在一起。这时候谈微服务拆分，不是赶时髦，是结构性问题逼着你必须动手。

1.2 哪些信号说明必须拆了

不是所有单体都该拆。如果团队五个人，业务规模一天几千单，老老实实把单体代码写干净比什么都强。但SPS/CPS混合系统一旦出现下面几个信号，基本就到了拆分窗口期：

• 发布互相牵连。SPS新增一个商品字段，结果CPS结算那边因为依赖同一个工具类，也要跟着一起发版。
• 数据库耦合严重。一张订单扩展表上挂着商家ID、推广位ID、媒体主ID、结算状态，报表SQL跨域join几十行，慢查询把CPU打满，连带着CPS的点击计费也跟着延迟。
• 团队协作互相踩脚。SPS组和CPS组改同一个Git仓库，每天最大的成本是解决合并冲突，而不是写业务代码。
• 硬件资源没法分级保障。SPS那边跑一个绩效大报表，直接把机器内存吃满，CPS这边的实时点击统计跟着一起遭殃。拆开以后，重资源、高并发的服务可以独立扩容，这才是微服务最大的红利之一。

这里多说一句，我在不少Java交流群里看到有人问“我们应用有二十万行代码，该不该拆”，其实代码行数不是核心指标，核心指标是变更频率和故障半径。一个模块每天被三个团队改、每次改都要全量回归，不管多少行代码，都该拆。

2. 边界界定：先把SPS和CPS的业务地图画出来

2.1 SPS/CPS到底是什么，各自管哪些事

做微服务拆分，第一件事不是打开IDEA准备抽代码，而是跟产品和运营坐在一起，把业务地图画出来。我在文章里说的SPS，指商家/供应商的绩效与商品管理相关子系统，CPS指联盟推广按效果付费的结算系统，也就是大家常说的淘宝客类分佣体系。这两块业务天然分属两个不同的业务域，是拆分的“第一刀”最合适的切入点。

拿我们当时的梳理结果举例，两边的核心域和表归属是这样切的：

这张表看着简单，但它是后面所有拆分动作的锚点。每个表都必须有明确的业务域归属，不允许出现“这张表两个域都在用，先留着公共”的模糊地带。我们当时定了一条硬规矩：跨域场景一律通过接口访问，不允许直接查对方库表。

2.2 判定服务边界的三个黄金问题

边界定得准不准，可以用三个问题自测。团队里每个人对这三个问题给出不同答案，那说明边界还没理清，先别急着动手。

第一个问题：这份数据到底是谁的？数据归谁，谁就有权修改和对外提