问题描述

昨天发布系统时，某个 RPC 接口的入参方式从 request parameters 改造为 request body。这个改动方向是对的，但由于接口设计和发布流程未充分考虑兼容性问题，导致 customer 在调用时偶发 400 错误。

根本原因：滚动发布过程中，新旧版本的 customer 和 provider 会同时存在于系统中。如果版本组合处理不当，就会出现新版本 customer 调用旧版本 provider（或相反）的情况，因参数格式不一致而报错。

解决方案

核心思路是让 provider 具备向下兼容能力，保证新旧版本共存期间调用链路不受影响。具体分三步：

  1. Provider 新增新接口，保留旧接口 在 provider 侧新增支持 request body 的新接口，同时保留原有接口不变，两者业务逻辑保持一致，仅入参方式不同。

  2. Customer 切换调用新接口 Customer 代码统一改为调用新接口。

  3. 控制发布顺序：先升级 provider，再升级 customer 滚动发布时，先将 provider 全量部署完成，再升级 customer。

发布顺序

  • 先升级 provider：此时 provider 新旧接口同时在线，无论 customer 处于新版本还是旧版本，调用都能成功。
  • 先升级 customer：滚动发布过程中会出现"新版本 customer + 旧版本 provider"共存的情况，新 customer 调用新接口，但旧 provider 并不支持，从而返回 400。最后旧接口可以在 customer 全部升级完成、确认无流量调用后再下线。一般可以在下一个版本就删掉旧版本接口。