不少团队在业务复杂后急于拆微服务，拆完发现问题定位反而更难，故障频率上升。一个常被忽略的前置条件是：单体阶段的监控能力必须先立起来。
## 监控是拆分的前置条件
微服务把一次请求的处理分散到多个进程与机器，没有贯穿链路的观测能力，故障定位从看一台机器的日志变成看十几处日志，效率急剧下降。反过来，单体能观测清楚，说明关键指标、依赖关系与流量画像已经明确，这些认知直接决定拆分的边界画在哪里。监控不是拆分的附属品，而是导航仪。
## 背后的原理
拆分的收益来自独立部署与独立扩容，前提是知道哪个模块最该独立。这个判断的依据全部来自监控数据：哪个接口消耗了大部分 CPU，哪个模块的故障率最高，哪个表被跨模块乱用。没有这些数据，拆分边界只能按组织直觉画，出现服务间高频调用、分布式事务遍地的情况并不少见。监控体系的建设顺序应当是资源指标、进程指标、接口指标、依赖拓扑，四层齐备后，拆分方案的讨论才有共同语言。
## 最小实操
从四类监控做起。基础资源：CPU、内存、磁盘、带宽，控制台自带的能力就够。进程存活：每个服务进程配存活探测与自动拉起。接口指标：按路径统计吞吐量、耗时与错误率，落到日志或指标系统。依赖视图：梳理对外依赖的数据库、缓存、第三方接口，为每个依赖配健康状态。跑一个季度，数据积累后再评估拆分顺序，通常结论会与拍脑袋的方案不同。
## 常见错误
只监控资源不看接口，容量判断失真；日志有了不做结构化，出问题靠肉眼翻；拆分先行监控后补，定位能力反而退化。顺云的监控告警可以直接覆盖资源与存活两层，接口与依赖层配合日志方案补齐，先把观测做扎实再动架构。