Day44-01｜综合训练：服务化架构的边界、通信、数据与治理

一、服务化的目标

服务化不是为了拆得越细越先进，而是为了让业务能力边界清晰、团队能够独立演进、故障能够隔离、接口能够复用。拆分前要分析业务能力、数据归属、变化原因、团队边界和非功能要求。

二、治理闭环

服务治理包括注册发现、配置、通信、负载、限流、熔断、重试、链路追踪、日志、指标、版本和发布。服务越多，治理越重要。同步调用适合低延迟、强交互场景；异步事件适合削峰、解耦和最终一致性场景。

三、数据一致性

服务独立数据后，不能随意跨库事务。可采用本地事务加消息、事务消息、Saga、TCC、补偿和对账。幂等是重试的前提，消息必须考虑重复、乱序、积压、死信和回放。

四、练习

问：服务粒度过细有什么问题？答：调用链变长、部署和监控成本上升、事务复杂、团队认知负担增加。问：何时使用同步？答：调用方必须立即得到结果且链路短、依赖稳定时；否则应考虑异步。

五、小结

微服务题要把拆分原则和治理机制放在同等重要的位置，服务数量本身不是架构质量指标。

六、服务边界的详细判断

服务边界可以从业务能力、数据所有权、事务边界、变化原因、团队职责和故障隔离六个方面判断。订单服务拥有订单状态，库存服务拥有库存数量，营销服务拥有优惠规则；它们可以协作，但不应互相直接修改对方的数据表。若两个模块总是同时发布、同时扩容、共享大量事务，说明边界可能过细或划分依据错误。

服务拆分还要看调用方向。理想状态是调用关系相对稳定、依赖层次清楚。若形成订单调用库存、库存调用营销、营销又回调订单的环路，故障和事务都会变复杂。可以通过领域事件降低直接耦合，但事件也不能成为隐藏的循环依赖。

七、通信与容错设计

同步接口应设置连接超时、读超时和整体超时，并把超时预算向下游传递。重试只适用于可重试错误，且必须有次数上限、退避和幂等键；对已经提交成功但响应丢失的写请求，应使用查询确认而不是盲目重试。熔断后要有友好的降级结果，恢复时应采用半开状态逐步放量。

异步消息要考虑生产可靠、传输可靠、消费可靠和结果可追踪。生产端可使用本地消息表或事务消息，消费者要记录消费状态并实现幂等；积压达到阈值时扩容或降级，无法处理的消息进入死信队列。消息的业务键、事件版本和时间戳便于追踪、去重和回放。

八、治理平台与组织协作

微服务治理不能只依赖一个注册中心。还需要服务目录、接口契约、版本规则、依赖拓扑、配置审计、发布审批、运行指标和责任人。平台应支持按服务查看调用量、错误率、P99、实例健康和版本分布。团队应约定API兼容规则、事件命名、错误码、日志字段和告警等级。

九、案例推演

某订单系统拆出订单、库存和支付服务后，出现重复扣库存、支付成功但订单未更新、服务调用雪崩三个问题。改进方案包括：订单号作为全链路幂等键，库存扣减采用条件更新和补偿；支付结果通过事件通知，订单服务以状态机处理重复通知并定期主动查询；调用链设置超时预算、舱壁隔离和熔断，支付故障时订单进入待支付状态而不是无限等待。

十、练习与答案

为什么“每个服务一个数据库”不是绝对规则？答：它强调数据所有权和松耦合，但小型系统可先采用模块化单体；若强行拆库而团队不具备治理能力，可能增加复杂度。
如何判断重试是否安全？答：看操作是否幂等、错误是否明确属于暂时性、是否会造成重复副作用，并设置次数和退避。
写出微服务上线前的五项检查：接口兼容、配置与密钥、依赖健康、监控告警、回滚和数据变更。

十一、论文落点

写微服务时，至少覆盖边界、通信、数据、一致性、治理、可观测、发布和故障恢复。文章最终要回答：拆分解决了什么问题，拆分后增加了什么问题，又如何用治理机制控制这些问题。

十二、服务化迁移路线

遗留系统不宜一次性拆完。可以先在外围增加网关和统一鉴权，再识别变化频繁、边界较清晰的能力进行绞杀式迁移；通过防腐层隔离旧模型，逐步把新服务的数据写入和查询接管。迁移期间要处理双写、数据校验、回放、灰度和回滚，不能只关注代码拆分。

迁移完成后还要删除无效链路和旧接口，否则系统会形成新旧两套架构长期并存。应设置迁移完成标准，例如流量切换比例、数据校验通过率、错误率、回滚窗口和旧模块下线时间。

十三、服务治理练习

某服务平均响应100毫秒，偶发依赖超时10秒。请说明如何治理。参考答案：设置连接和请求超时，传递调用预算；对暂时性错误有限重试并退避；配置熔断和舱壁隔离，避免线程池耗尽；通过TraceId定位慢调用；非核心能力采用异步或降级；上线前用故障注入验证。

十四、服务化的可观测性

服务治理必须同时观察技术指标和业务指标。技术指标包括实例健康、CPU、内存、连接池、线程池、请求量、错误率、延迟和消息积压；业务指标包括订单创建成功率、支付状态转换、库存扣减失败和补偿任务数量。仅监控CPU可能看不到业务已经失败，只有将两类指标关联，才能判断故障影响。

十五、综合回答模板

当题目问“如何保证微服务可靠性”时，可按以下顺序作答：服务边界降低故障传播；网关和注册发现保障入口与实例选择；超时、重试、熔断、舱壁和限流控制调用风险；消息可靠投递、幂等和补偿保证异步一致性；日志、指标和追踪支持定位；灰度发布和自动回滚控制变更风险；故障演练验证方案。最后写出拆分带来的成本。

还应说明治理责任。平台团队提供通用注册、配置、观测、发布和策略能力，业务团队负责服务边界、接口契约、数据一致性和业务降级，测试团队负责契约、故障和性能验证，运维团队负责容量、告警、演练和应急。职责清楚后，微服务不会因为“大家都能改”而失去控制。

服务治理最终要用发布失败率、调用错误率、P99、消息积压、补偿成功率和故障恢复时间验证，而不是以服务数量作为成果；这些指标还应按服务和业务链路分层统计，避免平均值掩盖局部故障。

服务治理还要建立变更兼容策略。接口新增字段应保持旧客户端可用，事件版本应允许消费者逐步升级，数据库迁移应遵循先扩展、再切换、后收缩；删除接口前要统计调用方并提供迁移窗口。服务治理最终要用发布失败率、调用错误率、P99、消息积压、补偿成功率和故障恢复时间验证，而不是以服务数量作为成果。

服务治理还要建立变更兼容策略。接口新增字段应保持旧客户端可用，事件版本应允许消费者逐步升级，数据库迁移应遵循先扩展、再切换、后收缩；删除接口前要统计调用方并提供迁移窗口。案例题若问“服务拆分后如何保证事务”，应写本地事务、事件、幂等、补偿、状态机和对账，而不是简单恢复共享数据库事务。

服务治理还要建立变更兼容策略。接口新增字段应保持旧客户端可用，事件版本应允许消费者逐步升级，数据库迁移应遵循先扩展、再切换、后收缩；删除接口前要统计调用方并提供迁移窗口。若题目问“微服务是否一定优于单体”，应明确回答否定，并结合团队规模、边界清晰度和治理能力说明选择条件。