微服务API兼容性怎么维护？

维护API兼容性的关键是保持向后兼容，使用语义化版本控制（主版本号表示不兼容变更，次版本号新增功能，修订号修复bug），在URL或请求头中携带版本信息；避免删除或修改已有字段，新增字段设为可选，通过OpenAPI定义接口，在CI中引入契约测试验证兼容性，提供清晰的变更日志与通知机制，保留旧版本供迁移，结合渐进演进、自动化校验与透明沟通，确保服务升级不影响调用方。

维护微服务中的 API 兼容性，关键在于控制变更对调用方的影响，确保服务升级不会导致依赖它的其他服务出错。核心思路是保持向后兼容，同时建立良好的版本管理和沟通机制。

使用语义化版本控制

通过版本号明确标识变更类型，帮助调用方判断是否需要调整代码：

• 主版本号（如 v1 → v2）：表示不兼容的变更，例如删除字段、修改接口行为
• 次版本号（如 v1.0 → v1.1）：新增功能但保持兼容，调用方可安全升级
• 修订号（如 v1.1.0 → v1.1.1）：修复 bug，不影响接口结构

避免破坏性变更

尽量不删除或重命名已有字段，不改变字段类型或含义：

• 需要移除字段时，先标记为 deprecated，在文档中说明停用计划
• 新增字段默认设为可选，不影响旧客户端解析
• 修改接口逻辑时，确保原有输入输出行为不变

引入契约测试和自动化验证

通过工具确保服务提供方变更不会违反与消费方约定的接口格式：

• 使用 OpenAPI/Swagger 定义接口规范，并作为团队协作依据
• 在 CI 流程中加入契约测试（如 Pact），验证新版本是否满足所有消费者期望
• 部署前自动检查变更是否属于兼容范围

提供清晰的变更文档和通知机制

让调用方了解接口变化并有足够时间应对：

• 维护更新日志（CHANGELOG），记录每次变更内容和影响
• 对即将废弃的接口发送邮件或通过内部平台提醒相关团队
• 保留旧版本一段时间，给予迁移窗口期

基本上就这些。只要坚持渐进式演进、加强自动化校验、保持透明沟通，就能有效维护微服务间的 API 兼容性。