互联网服务接口兼容问题
2024-10-14 14:30:12 0 举报AI智能生成
APP已经发布的接口，由于业务或技术问题需要升级。修改数据库字段、接口字段等，可使用此脑图作为检查列表，做到无感升级
作者其他创作
大纲/内容
报服务不存在
存在问题
在接口上标识：废弃【版本】
接口逻辑兼容
标识：强更【版本】
强更版本后删除
兼容方式
删除
新增接口
旧接口按删除接口的流程处理
改路径
假设Eshop服务A接口新增了调用Base服务B接口，B接口为新增接口。因为生产环境有两套服务，假设这时直接发布了第一组Eshop和Base服务，第二组未发布。则这时第一组的Eshop服务A接口可能到第二组Base服务调用B接口，这时第二组的服务还没发布新版，就会报服务不存在
发版时备注先将B接口的两套服务发布后，再发布A接口的服务
接口内部新增调用外部接口
接口
旧版本APP未传此参数，但由于新需求需要此参数，直接新增会导致旧APP报参数必填
要求产品确定旧数据及旧APP的默认值
新增接口，新旧两个接口使用相同的业务逻辑代码
旧接口在controller层设置改参数的默认值
新增必填参数
修改前参数在旧版APP传递过来后丢失
旧版APP未传递修改后参数
采用新增参数的方式，保留旧参数
在controller层进行参数的转换，将旧参数的值按业务逻辑转到新参数上
修改
参数
新旧程序不同类型的Value写入同一个key
新程序读取后反序列化失败，报错
直接改掉key，既认为是一个新的KV对。使新旧程序分别维护各自的数据
但如果数据较为重要，无法通过MySQL等恢复，需要考虑数据迁移
修改Value的类型或结构
redis
报错
先升级程序，保证代码中不再使用该表
保证表数据被迁移到新表中（可选）
在《数据库表废弃记录》登记
版本发布后下个版本，建立独立的SQL包，将表删除至高保真环境
下下版本在生产执行该SQL包，最终删除表
删除表
改表到两组服务发布完成时间差过程中，服务报错
采用新增表迁移数据的方式，程序使用新表
如果数据写入不频繁，发版前直接迁移数据到新表
建议不修改，将错就错
如果写入频繁
改表名
旧代码写入时字段为空
字段必须有默认值
如果不能指定默认值，必须先设置为非必填，待程序发布后再处理
新增必填字段
旧程序调用时报错
采用新增字段再迁移数据的方式
修改字段名
旧程序报错
如果对应的java字段类型不改变，可直接改
如果对应java字段类型改变则不能直接改，需要新增字段再迁移数据
兼容方法
改字段类型
非必填改必填，必须有默认值。如果不能指定默认值，需要先升级程序后再修改数据库
改字段约束
采用先升级程序，在《数据库表废弃记录》登记后，再下个版本删除
先升级程序，保证代码中不再使用该字段
保证数据被迁移到新字段中（可选）
下下版本在生产执行该SQL包，最终删除字段
删除字段
数据库
直接修改会到值已经发送到MQ的消息体无法反序列化（类似于redis的问题）
在消费者代码中，兼容新旧消息体的处理
在下一版本才能去掉旧消息体的处理逻辑
消息体修改
MQ
代码兼容问题
0 条评论
回复 删除
下一页
