服务化架构是什么
服务化架构把系统拆成数量较少、边界清晰的粗粒度服务，通常按业务域划分，服务内部仍可保持分层结构，共享数据库或按服务分库都能接受。它的复杂度明显低于微服务，独立部署与弹性也弱一些，但对多数团队而言是被低估的折中方案：先划清业务边界拿到解耦收益，再视需要在压力点上继续拆细。
基本信息
| 粒度 | 粗粒度、数量可控，服务内部仍可分层 |
|---|---|
| 数据 | 可共享数据库，也可按服务拆分，视团队能力与耦合程度决定 |
| 对比微服务 | 独立部署与弹性较弱，但运维与一致性成本低得多 |
| 典型规模 | 常见为 4 到 12 个服务，便于整体理解与协调 |
| 适用团队 | 中等规模团队、业务边界相对稳定、运维自动化程度一般 |
粒度调整信号
| 问题 | 信号 | 动作 |
|---|---|---|
| 服务过粗 | 变更互相干扰、发布排队 | 按业务能力再拆一层 |
| 服务过细 | 一次用例跨多个服务且需强事务 | 合并或引入组合服务 |
| 数据共享 | 跨服务联表查询频繁 | 先拆读写边界，再谈分库 |
| 发布耦合 | 任一处改动要整体回归 | 补齐自动化测试后再拆分 |
典型使用场景
- 中型系统落地：团队无足够运维能力支撑微服务，先要解耦收益
- 单体拆分第一步：把与主流程耦合度低的模块先独立出去
- 多团队协作：按业务域划分发布与责任边界，减少互相阻塞
- 遗留系统过渡：以粗粒度服务承载新功能，逐步替换旧模块
- 共享数据库治理：先统一访问入口与服务边界，再逐步分库
- 预算受限项目：在可控成本下取得模块化与独立发布能力
服务化与微服务的差别不在技术栈，而在粒度与自治程度：服务内部还可以只是一个模块化的单体，团队按业务域端到端负责。
共享数据库会让服务间存在隐式耦合，schema 变更需要多方协调，应先把访问入口收敛到服务接口再逐步分库。