前言
兼容性一直是個很隱秘的問題, 在配備良好的研發(fā)流程和人員的情況下, 在大流量系統(tǒng)中兼容性問題仍然會偶爾出現(xiàn), 直接原因在于兼容性的測試復(fù)雜性, 隱蔽性, 需要考慮新舊代碼共存的兼容性關(guān)系, 所以這里梳理了一些情況, 下一篇會整理一些常用的解決問題的方法, 大家還有要分享的情況可以私聊指導(dǎo)我一下
兼容性場景
接口兼容性:
修改/刪除現(xiàn)有出入?yún)⒆侄?/p>
字段類型: 比如原來的字段是 String 類型, 代表著支付金額, 結(jié)果我們把這個字段的類型變成了 BigDecimal, 結(jié)果因序列化框架的配置原因, 把 23.001 序列化成了 23.00, 導(dǎo)致支付金額不正確
字段格式: 比如可還款金額原來是 1000.00 這種, 后來我們將字段格式變?yōu)榱?1,000.00, 調(diào)用我們系統(tǒng)使用 new BigDecimal() 時候就會瘋狂報錯
字段含義: 這個就是原來這個字段代表利息, 后來將這個字段代表罰息, 會造成系統(tǒng)的混亂
驗證要求: 比如使用了 @Length(min=10,max=100) 注解到了 userName 字段, 后面感覺長度 100 太長啦, 改為了 50, 結(jié)果出現(xiàn)了一個 50+ 的人名, 就會造成調(diào)用方系統(tǒng)報錯
修改/刪除老的接口方法
修改 http 方式: 本來是 put, 改為了 post 方式, 這樣一來這個接口的調(diào)用方就會因為找不到這個接口而報錯
修改出入?yún)? 效果同修改字段的相關(guān), 在加上比如有個入?yún)?aaa, 感覺沒人用的就刪除了, 調(diào)用方用到這個字段也會報錯或者效果不一致
修改接口名稱: 這樣一來這個接口的調(diào)用方就會因為找不到這個接口而報錯
存儲兼容性:
緩存兼容性
序列化方式: 一般使用緩存框架都有一種序列化方式, json 或者 string 這種, 如果改了序列化方式為 json, 而生產(chǎn)上的數(shù)據(jù)目前是 string 類型的, 就會導(dǎo)致報錯, 如果此時沒做緩存報錯的弱依賴, 就會導(dǎo)致大的問題
數(shù)據(jù)格式: 原來緩存進去的是 Order, 后來這個程序作了擴展, 緩存進去是是 List<Order> 就會在發(fā)布的時候因為讀取之前的數(shù)據(jù)而引發(fā)報錯
數(shù)據(jù)庫兼容性
字段的修改/刪除也參考第一段的影響, 比如用枚舉接收數(shù)據(jù)庫字段, 結(jié)果新的數(shù)據(jù)增加了枚舉 A, 這個時候應(yīng)用代碼還沒有部署最新的版本, 就會造成程序報錯
新增字段歷史數(shù)據(jù)問題: 新增的字段如果有默認(rèn)值一般可以沒問題, 要是沒有默認(rèn)值應(yīng)用程序?qū)用婵赡軙罂罩羔樀葐栴}
異步消息的兼容性:
生產(chǎn)者修改刪除字段, 可能有舊的消費者代碼依賴相應(yīng)字段, 所以刪除了會導(dǎo)致消費異常
注冊中心的兼容性:
當(dāng)使用分布式中間件等切換注冊中心需要考慮發(fā)布過程中一組機器用舊的注冊中心, 一組用新的, 可能導(dǎo)致分布式鎖失效, 服務(wù)找不到等異常
日志的兼容性:
可能有些字段用來生成監(jiān)控指標(biāo)和報警, 可能由于日志框架或者日志格式的變化導(dǎo)致報警失效或者指標(biāo)計算錯誤等, 需要考慮日志的兼容性
