Day31-21｜10.6.10 大型网站系统架构演化实例（十）：分布式服务阶段的治理与收口

一、教材定位

大型网站经过单体、垂直架构、缓存、集群、数据库扩展、边缘加速、分布式存储和业务拆分后，最终可能进入分布式服务阶段。此时系统由多个独立部署、通过网络协作的服务组成，能够按业务和资源独立扩展，但也带来了服务发现、配置、调用、容错、数据一致性、版本、监控和运维治理等新问题。

“分布式服务”不是把单体简单拆成许多进程，而是一整套架构能力。服务必须有清晰的业务边界、契约、所有权和生命周期；平台必须能够管理注册发现、配置、流量、发布、故障和观测；业务必须能够处理部分失败、重复、延迟和最终一致。考试中要同时写出收益和代价，避免把分布式服务等同于微服务数量。

二、分布式服务的基本特征

1. 独立部署

服务有独立构建、测试、发布和回滚单元，可以按业务变化和资源需求扩展。但独立部署要求接口、消息、数据和配置兼容，否则仍会形成隐形的整体发布。

2. 网络协作

进程内调用变成网络调用，网络延迟、丢包、超时、重试、连接耗尽和服务不可达都成为正常设计的一部分。调用方不能假设对方一定快速成功。

3. 数据自治

服务通常拥有自己的数据和写入权，其他服务通过接口、事件或读模型访问。数据自治减少直接耦合，但需要事件一致性、幂等、补偿和对账。

4. 团队和责任自治

服务应有明确的业务和技术负责人，负责代码、发布、监控、值班、漏洞和恢复。没有责任自治的服务，只会增加系统数量和协调成本。

三、服务注册与发现

服务实例动态启动、扩容和故障，因此调用方不能依赖固定地址。注册中心记录服务名称、实例地址、版本、区域、权重、健康状态和元数据。客户端或代理根据服务发现结果选择实例。

注册中心需要高可用、一致性和权限控制。实例注册要有租约和心跳，过期实例应被摘除；网络分区时要防止错误摘除健康实例或同时出现多个控制者。服务发现结果需要缓存和过期策略，注册中心暂时不可用时，调用方可以使用最后已知的安全列表，但要防止长期使用失效地址。

健康检查分为进程存活、服务就绪和业务可用。实例能响应端口不代表依赖和核心业务正常，过于严格的检查又可能导致整个集群被同时摘除。健康状态要与流量接收、预热和优雅下线配合。

四、服务调用治理

1. 接口契约

接口要定义请求、响应、错误、超时、幂等、权限、版本和容量。契约测试保证生产者和消费者兼容，接口目录和依赖关系要可查询。

2. 超时和重试

每一跳都应有超时，整体链路还要有预算。重试只适合临时错误和幂等操作，应使用退避、抖动和最大次数。层层重试会放大流量，造成级联故障；对非幂等操作必须有业务键和状态保护。

3. 熔断和降级

依赖持续失败或变慢时，熔断可以快速失败，保护调用方和依赖。降级可以使用缓存、默认结果、异步受理或关闭非核心功能。恢复时要经过半开和观察，不能一恢复就释放全部流量。

4. 限流和舱壁

按租户、用户、接口、实例和依赖设置限流，防止一个调用方耗尽资源。线程池、连接池和队列隔离不同业务，核心服务和非核心服务互不拖累。

5. 路由和流量控制

支持按版本、区域、租户、标签和权重灰度。路由必须可审计、可回滚，兼顾会话、数据位置和合规要求。

五、配置与服务治理

配置中心管理服务地址、超时、限流、特性开关、证书和业务参数。配置应版本化、校验、审批、灰度和回滚，敏感数据通过安全存储引用，不进入普通日志。

配置发布要区分静态配置和动态配置。动态调整可以减少发布，但也可能快速扩散错误。高风险参数要设置范围、审批、观察窗口和自动停止。所有实例的最终生效配置应可查询，避免“配置中心显示一个值、实例实际使用另一个值”。

六、分布式数据与服务一致性

服务自治后，跨服务事务不能默认依靠单一数据库。设计时先明确业务不变量和一致性目标，能放在一个服务内的原子操作不要强行跨服务。

跨服务流程可采用可靠消息、Outbox、Saga、TCC、状态机和补偿。每个步骤要有业务标识、幂等状态、超时、重试、死信和人工接管。最终一致必须有收敛时间和对账机制，不能只依赖“消息最终会到”。

读模型、缓存和搜索索引通常是派生数据，允许延迟但必须可重建。服务下线和数据迁移时，要处理仍在运行的消息、历史状态和旧消费者。

七、服务版本与发布

分布式服务通常长期存在多个版本。接口新增字段应可选，删除和语义变化要经历弃用窗口；消息要支持新旧消费者；数据库采用先扩展、后迁移、再收缩。

发布策略包括滚动、蓝绿、金丝雀和按租户灰度。选择时考虑状态、数据、容量、回滚和副作用。回滚不只是切回旧镜像，还要处理已发送消息、已写数据和配置变化。发布前后应通过契约、场景、故障和业务对账验证。

八、可观测性和故障定位

服务数量增加后，单个日志文件无法说明端到端结果。需要统一日志、指标、分布式追踪、事件和业务关联号，能够从用户请求定位到服务、数据库、消息和版本。

核心指标包括请求量、成功率、错误率、P95/P99、超时、重试、熔断、队列、依赖、资源、数据差异和补偿。要区分服务健康、依赖健康和业务健康。告警应有责任人、分级和抑制，避免服务越多告警越多而没有行动。

故障排查按时间线和影响范围展开：先判断用户和业务影响，再定位入口、调用链和依赖，最后确认数据和恢复。复盘要修复系统性原因，如重试放大、缺少限流、监控缺失和契约不兼容。

九、服务治理平台与组织能力

分布式服务需要平台提供注册发现、配置、网关、发布、监控、日志、追踪、权限和应急能力。平台应降低重复建设，但不能成为所有业务逻辑的强耦合中心。

组织上要建立服务目录、所有者、值班、SLA、依赖、版本和数据责任。服务团队要能够独立交付和恢复；平台团队提供标准和工具；架构团队负责跨服务原则、关键质量和演化治理。

十、案例分析：大型网站进入分布式服务阶段

某网站完成业务拆分后拥有用户、商品、订单、支付、库存、营销、搜索和通知等服务。上线初期出现订单超时、重试风暴、消息积压和故障定位困难。原因包括调用没有统一超时，多个层级重复重试；服务发现缓存过期，流量打到下线实例；消息没有幂等，补偿造成重复操作；各团队监控和错误码不一致。

治理方案首先建立服务目录和契约，统一请求ID、错误码、超时预算和幂等键；服务发现加入租约、健康、预热和摘除；调用侧设置超时、退避、熔断、限流和舱壁，禁止无上限重试；订单、支付和库存使用状态机、可靠事件和业务对账；消息进入死信并支持安全重放；发布采用契约测试、灰度和自动回滚。

平台统一日志、指标和追踪，业务团队负责领域指标和恢复；所有动态配置版本化并可审计。通过核心订单成功率、P99、重试量、消息积压、数据差异、恢复时间和发布失败率观察治理效果。分布式服务最终是否成功，取决于治理和组织，而不仅是服务数量。

十一、综合知识练习

题1

分布式服务相比单体架构新增了哪些主要风险？

参考答案：网络延迟和失败、超时与重试放大、服务发现、版本兼容、分布式事务、消息重复和乱序、数据最终一致性、故障定位、发布协调和运维成本增加。

题2

为什么分布式服务必须建立服务目录和责任人？

参考答案：服务数量多且依赖复杂，需要知道接口、版本、数据、负责人、值班和恢复方式。没有目录和责任，故障无法快速定位，服务也容易成为无人维护的孤岛。

题3

如何防止服务调用中的重试风暴？

参考答案：设置端到端超时预算，限制重试次数，使用指数退避和抖动，只对临时错误和幂等操作重试；配合熔断、限流、舱壁、队列和降级，并监控重试量和下游压力。

十二、论文写作素材

论文中可以这样描述分布式服务演化：

“在业务拆分后，我围绕服务注册发现、配置、调用、容错、消息、数据和观测建立统一治理。服务通过契约和版本管理保持兼容，注册中心使用租约、健康检查和预热控制实例；调用侧设置超时预算、退避重试、熔断、限流和舱壁，避免局部故障扩散。跨服务流程使用可靠事件、状态机、幂等、补偿和对账，发布采用契约测试、灰度和自动回滚；平台统一日志、指标和追踪，业务团队负责领域指标和恢复。最终通过成功率、P99、重试、积压、数据差异、恢复时间和发布失败率验证分布式服务治理效果。”

十三、今日复盘

分布式服务的核心不是数量，而是独立边界、网络协作和治理能力。
注册发现、配置、调用容错、版本、数据一致性和可观测性必须成体系。
超时、重试、熔断、限流和舱壁用于防止故障级联。
服务自治需要明确数据所有权、业务不变量、幂等、补偿和对账。
独立部署必须配合契约、灰度、回滚和组织责任。
案例答题要写清平台治理、业务治理、故障闭环和度量证据。