前言

繼上篇文章, 有些小夥伴有些疑問, 比如 A 系統以來 B 系統的介面, 兩個系統同時釋出最新的程式碼版本不就不用考慮相容性了, 但是這個受限於幾個情況, 比如需要分組釋出, 總共 30 臺機器, 需要 10 個一組慢慢釋出, 不然流量都打不過來了, 造成系統問題, 或者 A 系統是開放平臺外面的系統或者是前端, 也需要給一定的時間來迭代或者灰度釋出甚至要永久支援, 這樣 B 系統是不得不考慮相容性的. 不然就像下圖這樣, 神奇的默契,,,

相容性場景

介面相容性解決方案:修改/刪除現有出入參欄位需要和呼叫方通知到位, 統一評估如果沒有影響, 可以刪除或者修改現有欄位如果依賴這個欄位的系統很多不容易拉齊或者需要儘快上線, 不方便修改/刪除欄位, 可以透過新增新的相似的欄位來完成新的功能也可以加新版本的相似介面來解決問題, 呼叫方逐步切換到新的介面如果一開始考慮到後續版本有可能會變更這個欄位, 可以給這個欄位加上版本說明, 需要呼叫方判斷版本正確的時候再使用這個欄位, 當然要 A 系統考慮不用這個欄位引發的問題, 而且一開始設計的時候就考慮到後續版本會變更的情況比較少修改/刪除老的介面方法需要和呼叫方通知到位, 統一評估如果沒有影響, 可以刪除或者修改現有介面如果依賴這個介面的系統很多不容易拉齊或者需要儘快上線, 不方便修改/刪除即可, 可以透過新增新的相似的介面來完成新的功能, 並通知呼叫方儘快逐步切換到新的介面如果一開始考慮到後續版本有可能會變更這個介面, 可以給這個介面加上版本字首, 這樣可以不同版本的同一個相似的介面共同存在, 這個要注意不要在介面實現層寫更多的邏輯, 不然會造成更多的一些重複的程式碼儲存相容性:快取相容性

序列化方式: 這種改變是需要先關閉快取開關, 讓這個快取 key 讀和寫的程式碼都關掉, 清空快取, 釋出最新的程式碼再開啟開關, 讓最新的程式碼寫入快取並消費, 清掉這個相關 key 所有的快取要注意快取沒有了全部打到了資料庫上的流量, 資料庫能夠撐住, 否則就弄巧成拙了

資料格式: 上面的方式同樣可以適合這種場景, 但是這種場景對開發者要求比較高, 需要在用快取的地方都留有開關, 如果沒有這種前置條件, 對資料格式這種變化, 可以採取之前的灰度和弱依賴的方式來比較讀取和寫入的報錯而影響了主要流程, 最好是根據快取的格式/內容能判斷出是否是新的快取物件來序列化成不同的物件

資料庫相容性

新增欄位歷史資料問題: 新增的欄位一般要設定預設值, 如果沒有可能需要人工重新整理, 或者應用程式考慮讀取資料庫的時候如果是空如何處理

非同步訊息的相容性:

訊息和介面也比較像, 要更換格式的時候可以生產者透過新增新的欄位(新的消費者程式碼要注意消費的時候如果沒有新的欄位, 還要按照舊的欄位來消費, 以免有訊息的積壓, 舊的訊息一直無法消費或者消費不正常)

另一個方案是更換成新的 topic + 版本作為新的 topic 來實現程式碼的相容(但是要注意舊的訊息要留有機器消費完成之後再完全下掉舊的消費者程式碼)

註冊中心的相容性:

換註冊中心相當於開著汽車換髮送機, 開著飛機換引擎, 最好是少做, 如果不得不做的時候需要停機, 驗證好了再全量切換成最新的註冊中心, 以免 rpc 大量報錯或者分散式鎖/事務失效等情況

日誌的相容性:

更改列印日誌的格式的時候最好是在後面新增入參, 別在中間新增入參, 可能會影響報警/統計報表, 最好在修改的時候參考系列第一篇文章, 效能/穩定性上的問題也最好是灰度加弱依賴來保證安全

當然啦, 上面的也不是銀彈, 不同的場景需要不同的思考方式, 相容性只是一種思考的方式, 幫助我們提高系統的穩定性, 需要在實踐中不斷的踩坑填坑, 心中無相容性, 手中有相容性就成為大佬啦, 我們一起努力...

當然啦, 最穩定的做法就是不寫程式碼不變更, 不用考慮相容了, 這出事機率最低了, 這一秘訣分享給大家~