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