服务边界与拆分

服务边界首先是业务边界，不是按 Controller、Service、DAO 技术层拆分。订单、库存、支付等服务应能表达独立业务能力，而不是形成只能互相调用才能完成任何工作的“分布式单体”。

判断一个边界

问题	说明
谁拥有这份数据	一个核心业务实体应有明确写入方，其他服务通过 API/事件使用
是否能独立发布	修改内部实现不应要求所有消费者同时升级
失败是否可隔离	非核心服务故障不应拖垮主交易链
扩容特征是否不同	计算密集、读热点、批处理可有不同扩容策略
团队是否真正负责	负责代码、运行、告警、容量和恢复，而不只是开发

推荐拆分过程

业务流程和领域对象
  → 找出能力边界与数据归属
  → 标出同步依赖和异步事件
  → 评估发布频率、负载和故障影响
  → 先在单体内部模块化
  → 选择收益明确的边界逐步拆出

不要一次重写整个系统。先建立调用量、错误率、数据库依赖和发布关系基线，再选择耦合较低或扩容收益明显的模块。

数据所有权

理想情况下，每个服务拥有自己的数据模型和写入入口。共享同一批表会导致：

• 一个服务改表破坏其他服务。
• 绕过 API 后无法执行业务校验和审计。
• 服务无法独立扩缩容、迁移或回滚。
• 故障和锁竞争跨服务扩散。

“每服务独立数据库”表达的是所有权边界，不要求每个服务都部署一套物理数据库。可以共享数据库集群，但账号、Schema、权限和变更责任必须清楚。

常见错误

错误	结果
按技术层拆成用户 API、用户逻辑、用户数据库服务	每次请求跨多次网络，无法独立演进
服务过细	调用链过长、部署对象爆炸、排障困难
多个服务直接写同一张表	所有权和一致性失控
共享公共代码包含大量业务逻辑	升级仍要求所有服务同步发布
只拆应用不拆团队职责	出故障时没有端到端负责人

拆分验收

• 输入、输出、错误码和版本策略是否明确。
• 数据由谁写、谁读、怎样迁移是否明确。
• 下游不可用时服务怎样降级。
• 是否有独立构建、部署、回滚和监控。
• 是否能在测试环境做契约和故障测试。
• 拆分后是否真的降低耦合或获得独立扩容收益。