服务拆分从业务边界开始
成熟的微服务拆分通常以业务能力为边界，而不是按控制器、数据表或技术分层切割。订单、库存、会员、结算、风控等业务域应拥有相对独立的数据和规则，接口只暴露稳定契约，避免内部表结构被其他服务直接依赖。
在早期阶段，团队可以先通过模块化单体、清晰包结构和领域接口验证边界，再逐步拆成独立服务。这样可以降低一次性拆分带来的分布式复杂度。
- 领域边界优先
- 数据所有权清晰
- 避免过早过细拆分
接口契约决定协作成本
服务之间的依赖越多，接口契约越重要。请求模型、错误码、幂等策略、超时重试、分页方式和版本兼容规则都需要统一，否则联调、回归和故障定位会迅速变复杂。
建议建立接口评审机制，并用 OpenAPI、契约测试和模拟服务支撑并行开发。对于核心链路，还应明确降级返回、重试上限和补偿流程。
- 契约先行
- 兼容策略明确
- 契约测试自动化
治理能力要覆盖运行全链路
微服务数量增加后，配置管理、服务注册发现、网关路由、熔断限流、链路追踪、日志关联和指标监控会成为稳定性的基础设施。缺少这些能力时，服务拆得越多，线上不确定性越高。
治理体系不宜只停留在平台组件层面，还要落到研发规范中，例如统一 traceId、统一日志字段、统一异常分类、统一告警分级和统一发布窗口。
- 配置与注册治理
- 熔断限流保护
- 日志指标链路统一
发布与回滚机制是最后一道保险
微服务带来的高频发布必须配套灰度、金丝雀、蓝绿或分批发布策略。关键服务上线前应有自动化测试、数据库变更审查、接口兼容检查和容量评估。
当变更出现异常时，团队需要能快速定位影响范围并完成回滚。回滚方案不仅包括应用镜像，也包括配置、数据脚本、任务调度和消息消费位点。
- 灰度发布
- 变更审计
- 可执行回滚预案