系统"向后兼容"的重要性

最近有个接口系统升级，应业务的需求，他们要改动接口参数，增加几个字段，但是要求用到这个接口的其它系统都改造，以适配升级。这其实是有些问题的，尤其从架构层面，接口层的改造影响了关联系统。

其实对接口系统来说，他需要做的就是能够"向后兼容（Backward Compatibility）"，或者叫"向下兼容"。

向后兼容指的是：接口（或系统）的新版本，能够继续支持旧版本的客户端，旧应用无需做任何修改就能正常工作。

改动接口参数，但不让关联应用进行改造，意味着改动不能破坏旧调用方式，这正是向后兼容的核心要求。原则上，这应该是对接口系统的最基本要求，不能因为自己的变更影响关联系统。

改动接口参数，这个行为本身有多种做法，只有兼容性的修改才能实现不让旧应用改造，

• ✅ 兼容：新增可选参数（带默认值）、增加新接口但保留旧接口、放宽参数约束（如将必填改为可选）。
• ❌ 不兼容：删除原有参数、修改参数类型、将可选改为必填、改变参数语义等。

如果改动属于前者就可以称为向后兼容的接口变更，如果属于后者，则旧应用必然出错，就不能说不让改造了。

因此，尤其针对向外提供接口服务的公共系统来讲，一旦要改造，"向后兼容"，这是必须考虑的，否则就会牵一发动全身，对关联系统不够友好，可能对相关系统的稳定运行产生一定影响。

再进一步理解，既然有"向后兼容"，有没有"向前兼容"？

答案是存在"向前兼容"，它的方向和"向后兼容"正好相反。"向前兼容"可以理解成站在旧版本的角度，旧版本能接受新版本产生的东西，例如，

• 消息协议：旧版解析器遇到新增的字段，忽略不认识的字段（如 Protobuf、JSON的"忽略未知属性"）。
• 数据库：旧版表结构增加新列后，旧版插入语句仍然有效（新列有默认值或允许NULL）。
• 文件格式：新版Word保存的.docx，旧版Word能打开并显示可读内容（忽略不支持的新特性）。
• HTTP API：服务端给响应增加新字段，旧客户端不读该字段仍能正常工作。

"向后兼容"和"向前兼容"比对，

概括讲，"向后兼容"和"向前兼容"是互补的两个方向，都是衡量系统演化能力的重要指标。

实践操作中，向后兼容比较常见的，因为设计时只需保证新代码不破坏旧调用。向前兼容更难，因为旧版本无法预知未来的变化，通常需要约定"可扩展的格式"。