前言
兼容性一直是个很隐秘的问题, 在配备良好的研发流程和人员的情况下, 在大流量系统中兼容性问题仍然会偶尔出现, 直接原因在于兼容性的测试复杂性, 隐蔽性, 需要考虑新旧代码共存的兼容性关系, 所以这里梳理了一些情况, 下一篇会整理一些常用的解决问题的方法, 大家还有要分享的情况可以私聊指导我一下
兼容性场景
接口兼容性:
修改/删除现有出入参字段
字段类型: 比如原来的字段是 String 类型, 代表着支付金额, 结果我们把这个字段的类型变成了 BigDecimal, 结果因序列化框架的配置原因, 把 23.001 序列化成了 23.00, 导致支付金额不正确
字段格式: 比如可还款金额原来是 1000.00 这种, 后来我们将字段格式变为了 1,000.00, 调用我们系统使用 new BigDecimal() 时候就会疯狂报错
字段含义: 这个就是原来这个字段代表利息, 后来将这个字段代表罚息, 会造成系统的混乱
验证要求: 比如使用了 @Length(min=10,max=100) 注解到了 userName 字段, 后面感觉长度 100 太长啦, 改为了 50, 结果出现了一个 50+ 的人名, 就会造成调用方系统报错
修改/删除老的接口方法
修改 http 方式: 本来是 put, 改为了 post 方式, 这样一来这个接口的调用方就会因为找不到这个接口而报错
修改出入参: 效果同修改字段的相关, 在加上比如有个入参 aaa, 感觉没人用的就删除了, 调用方用到这个字段也会报错或者效果不一致
修改接口名称: 这样一来这个接口的调用方就会因为找不到这个接口而报错
存储兼容性:
缓存兼容性
序列化方式: 一般使用缓存框架都有一种序列化方式, json 或者 string 这种, 如果改了序列化方式为 json, 而生产上的数据目前是 string 类型的, 就会导致报错, 如果此时没做缓存报错的弱依赖, 就会导致大的问题
数据格式: 原来缓存进去的是 Order, 后来这个程序作了扩展, 缓存进去是是 List
数据库兼容性
字段的修改/删除也参考第一段的影响, 比如用枚举接收数据库字段, 结果新的数据增加了枚举 A, 这个时候应用代码还没有部署最新的版本, 就会造成程序报错
新增字段历史数据问题: 新增的字段如果有默认值一般可以没问题, 要是没有默认值应用程序层面可能会报空指针等问题
异步消息的兼容性:
生产者修改删除字段, 可能有旧的消费者代码依赖相应字段, 所以删除了会导致消费异常
注册中心的兼容性:
当使用分布式中间件等切换注册中心需要考虑发布过程中一组机器用旧的注册中心, 一组用新的, 可能导致分布式锁失效, 服务找不到等异常
日志的兼容性:
可能有些字段用来生成监控指标和报警, 可能由于日志框架或者日志格式的变化导致报警失效或者指标计算错误等, 需要考虑日志的兼容性