📫作者簡介：小明java問道之路，專注于研究 Java/ Liunx內核/ C++及匯編/計算機底層原理/源碼，就職于大型金融公司后端高級工程師，擅長交易領域的高安全/可用/并發/性能的架構設計與演進、系統優化與穩定性建設。

📫 熱衷分享，喜歡原創~ 關注我會給你帶來一些不一樣的認知和成長。

🏆 InfoQ簽約作者、CSDN專家博主/后端領域優質創作者/內容合伙人、阿里云專家/簽約博主、51CTO專家 🏆

🔥如果此文還不錯的話，還請👍關注、點贊、收藏三連支持👍一下博主~?

本文目錄

本文導讀

一、 資損防控系統設計資損防控規范

二、兼容性設計隨業務的不斷變更和發展

1、數據庫、接口服務新增的向前兼容性原則

2、數據庫、接口服務變更的向后兼容性原則

2.1 刪除字段

2.2 新增字段

2.3 變更字段約束

2.4 變更字段名稱

2.5 變更字段類型

2.6 數據庫索引變更的時候要考慮對產線執行計劃的影響

三、數據庫、接口服務刪除原則

四、注意文件字段、緩存對象，消息對象

五、生產系統發布過程中兼容性考量

1、系統和數據之間的兼容性

2、系統和業務處理之間的兼容性

3、新老系統間的兼容性

4、兼容性分析

4.1 組合考量業務的處理

4.2 組合考量新舊系統兼容性的處理

4.3 組合考量新舊系統與新舊數據的兼容性處理

六、生產系統發布過程中，要考慮消息調度的兼容性

七、業務遷移過程的兼容處理

八、數據和數據存儲的遷移

九、采用開關的方式規避風險

總結

---

本文導讀

系統兼容性設計隨業務的不斷變更和發展、系統和架構也在不斷的調整和優化這其中既有新業務、新系統的上線，也有老業務、老系統、老數據的遷移。在這些新老的變化過程中，我們既不能導致業務的間斷影響可用率，更不能產生資損造成公司損失。

為了防范這些新舊間處理的風險，我們需要從數據、系統、發布、業務等各個環節做好兼容性設計。

一、 資損防控系統設計資損防控規范

從系統架構層面整體來看，支付公司的系統可以抽象為如下結構:

一、對外部商戶提供收單服務類的系統

二、連通支付公司與各金融渠道的網關類系統

三、支付公司的內部業務處理系統

四、消息、調度等中間件系統

五、數據庫、緩存等存儲平臺

?

從系統架構與業務架構上來講，各個結構連接的地方最容易出現資損。因此我們將從接口服務層面與系統設計層面對資損進行分析并總結相關規范。

二、兼容性設計隨業務的不斷變更和發展

系統兼容性設計隨業務的不斷變更和發展、系統和架構也在不斷的調整和優化這其中既有新業務、新系統的上線，也有老業務、老系統、老數據的遷移。在這些新老的變化過程中，我們既不能導致業務的間斷影響可用率，更不能產生資損造成公司損失。

為了防范這些新舊間處理的風險，我們需要從數據、系統、發布、業務等各個環節做好兼容性設計。

1、數據庫、接口服務新增的向前兼容性原則

數據庫、接口服務新增的向前兼容性原則，向前兼容設計更多的體現在數據庫、接口的初始化設計階段（新增數據庫結構、新增接口）。

數據庫結構與服務接口在設計過程中，在數據庫、接口復雜度與字段（個數、長度等）允許的范圍內，盡可能的考慮到未來可以預見的情況，支持未來的業務拓展。

新增設計時，需要考慮到：

1、數據庫字段、接口字段的合理冗余。比如在設計交易接口的時候，除了考慮交易金額字段，考慮未來有收費的場景，可以增加手續費金額字段。此時，也要注意避免過度設計。

2、數據庫字段，接口字段長度的適度放大與類型的泛化。比如在允許的范圍內，可以將交易金額字段設計的范圍長度大一些某些類型字段定義為字符串類型而非整數類型；時間參數精度設計到毫秒等。

3、數據庫字段、接口字段或接口處理邏輯的約束。考慮到未來有可能擴展或放松現有約束（如非空判斷等），在接口中考虛默認、異常等多種處理情況。

2、數據庫、接口服務變更的向后兼容性原則

數據庫、接口服務變更的向后兼容性原則，向后兼容設計是最常見的應用場景，更多的提現在數據庫，接口的變更階段（變更數據庫結構、接口）。

服務提供方在做接口非破壞性的變更時，需要確保服務以向后兼容的模式演變：

在無需變更現有消費者的實現或配置的條件下被更多的消費者重用。由于我們發布過程是DB先發布，所以新老系統是會同時使用一個數據庫結構的。因此必須保證數據庫結構發生變化的時候，新舊系統可以同時使用變更后的數據庫結構。

一般數據庫、接口變更，分為如下場景：

2.1 刪除字段

1、禁止直接刪除正在使用的字段。

2、對于接口字段，如果確認該字段所有的請求方和服務方都不再使用。分多個版本，按照請求方先去掉該字段，確認所有請求方完成后，服務方方可以進行字段的刪除。

3、對于數據庫字段，老系統要先解除和數據庫結構間的字段依賴（包括語法依賴和業務依賴）再進行刪除。對于已經產生的數據，要考慮保存機制。

2.2 新增字段

1、服務提供方需要考慮各服務請求方的兼容性。服務提供方對該字段的約束允許為空，接口處理可以以提供默認值等方法保證邏輯處理兼容性。

2、數據庫結構新增字段的時候，需要保證系統與數據庫結構的語法與業務兼容。數據庫字段可空。

3、服務請求方在升級新增字段的時候，根據服務提供方該新增字段是否已經上線、制定兼容性方案。

2.3 變更字段約束

1、禁止直接進行字段約束從嚴的變更。接口進行從嚴變更（如長度收縮）的時候，需要各服務請求方先檢視請求方約束是否符合條件；

不符合條件的。先完成請求方的變更后續進行服務方的升級。數據庫進行從嚴變更的時候，要保證老數據符合規范系統先完成約束控制后進行變更。

2、字段約束放松的變更。接口按照服務提供方先進行約束放松，后續版本各請求方進行變更；請求方不能早于服務方進行變更。

2.4 變更字段名稱

1、禁止直接變更正在使用的字段名稱。尤其是對于為多個服務請求方提供服務的接口的字段。

2、當需要變更接口字段名稱的時候，按照新增字段、刪除字段的流程來處理變更。

2.5 變更字段類型

1、禁止直接變更正在使用的字段類型。

2、如果需要變更類型的時候，建議新增字段來解決。

2.6 數據庫索引變更的時候要考慮對產線執行計劃的影響

數據庫索引變更的時候要考慮對產線執行計劃的影響

三、數據庫、接口服務刪除原則

1、禁止直接刪除正在被使用的數據庫結構和接口服務

2、如果需要進行刪除。接口按照服務請求方先變更，在確認已無服務請求方請求接口的前提下服務提供方才可以進行接口刪除。數據庫結構需要保證系統不會再放我的情況下，并做好數據的保存。

四、注意文件字段、緩存對象，消息對象

對于文件字段、緩存對象，消息對象的使用和設計，也需要遵從數據庫與接口服務相關的兼容性設計原則，保證向前向后的兼容設計。

五、生產系統發布過程中兼容性考量

生產系統發布過程中兼容性考量，發布過程中，要從系統、數據、業務組合考慮兼容性

1、系統和數據之間的兼容性

需要考慮系統和數據之間的兼容性，設計過程中要保證新老系統產生的過程數據可以相互處理，即老系統產生的中間數據，系統發布后，新系統可以出來；

新系統產生的數據，系統一旦出問題回滾后，老系統也可以處理。如果不能處理的時候，不能選用直接的war包回滾方案。可以通過中間兼容版本保證回滾的兼容性、也可以通過數據訂正，保證新系統產生的數據部會被老系統處理（數據訂正方案是緊急情況下的處理方案，不建議采用）；

另外也可以通過引流等方式解決這部分數據問題，以保證其兼容性。

2、系統和業務處理之間的兼容性

需要考慮系統和業務處理之間的兼容性生產系統發布過程中，在老系統受理的業務，新系統可以繼續處理（如老系統落單、新系統繼續支付、老系統正交易邏輯、新系統反交易邏輯），并且要保證業務規則業務流程的兼容處理。

3、新老系統間的兼容性

新老系統間的兼容性，避免冪等擊穿、并發失效等問題對于新系統的功能變更、幕等機制、并發控制機制等只可以增加，不可以減少，避免老系統未能控制的冪等、并發，新系統也可以控制住。

如果是相關機制變更的話要重，控制只可以從嚴不可以從松、控制字段、控制場景、控制業務要考慮新舊系統兼容的情況。

4、兼容性分析

兼容性分析過程中，不可以孤立看新舊業務、新舊系統、新舊數據的處理，需要組合考量。

4.1 組合考量業務的處理

業務處理的各個場景和過程中都會有被新war包老war包處理的兩種情況。要通過分析業務各個場景和過程中在新舊war包中的處理步驟和流程，判新他們之間在業務上是否有依賴關系，并分析在組合的業務場景下是否可以被正確處理。

比如，訂單交易平臺修改了支付的沖銷邏輯、業務兼容性需要做如下分析：

對于一筆支付業務，有支付和沖銷兩種場景、支付場景、沖銷場景被老系統如何處理、被新系統如何處理？支付和沖銷有沒有依存關系？老系統的支付是不是必須被老系統沖銷？老系統支付新系統沖銷可以不可以被支持？新系統支付老系統沖銷可不可以被支持？

如果沖銷服務有查詢狀態沖銷發起兩個過程，還需要考慮著兩個過程和各個業務場景組合的情況。

4.2 組合考量新舊系統兼容性的處理

系統的多種處理和控制機制是分多個階段的，每個階段也都會有被新war包老war包處理的兩種情況。通過分析者每個階段在新war包和老war包中不同處理以及控制的目的、邏輯、方式直至字段代碼，判斷其相互之間有無依賴，每個階段在什么場號下可以成為下個階段的前置，并分析其在組合場景下可否互相處理完成功能。

比如，某個系統對幕等控制進行優化。需要分析該系統處理的任務有任務抓取、處理等階段，老war包怎么進行任務抓取？怎么進行任務處理，冪等控制的？新war包是怎么處理的？抓取的任務是做完冪等控制才能被處理？還是抓取后流入到處理進行冪等控制？新war包抓取的任務老war包能不能處理？

如果除了處理階段流程變化，還有處理邏輯變化，還需要進一步考慮并發、幕等控制的字段及實現代碼在各個組合場景下的兼容性。

4.3 組合考量新舊系統與新舊數據的兼容性處理

發布過程中存在新系統寫數據、老系統寫數據、新系統讀老系統寫的數據、新系統讀新系統寫的數據、老系統讀老系統寫的數據，老系統讀新系統寫的數據供六種場景。

要分析以上各個場景的讀寫是否正確，讀寫之后的業務處理方式是否正確，是否會對小一步業務處理產生不兼容的影響？

比如一個業務改造走掛內部帳邏輯的改造。要考慮新系統的時候寫數據會記錄掛賬單編號，老系統寫數據沒有掛賬單編號，新系統讀老系統沒有掛賬單編號的業務數據怎么處理？

六、生產系統發布過程中，要考慮消息調度的兼容性

生產系統發布過程中，要考慮消息調度的兼容性，按照前述的處理原則，發布的時候還需要避免消息處理、調度的不兼容處理。

其他處理方案（不建議）：當有消息不兼容的時候，需要告知部署同學按分組下線消息源頭生產者，當有調度不兼容的時候，部署的時候可以暫信調度。

七、業務遷移過程的兼容處理

業務遷移過程中、涉及到新舊業務流程、新舊業務規則、新舊業務數據等的兼容處理，需要從分析、設計、上線、驗證等各個環節把控。

1、對于業務移，必須詳細分析所遷移業務的新舊規則、流程、參數并和上下游系統確認。

2、新老業務與新老系統之間必須能夠業務處理流程和規則上保證平滑處理、無縫切換。

3、盡可能保證新老業務、系統、數據直接的交叉處理。不能保證的時候，要通過相關表示避免交叉。

4、業務移的風險較大，需要通過開關、引流等進行產線驗證。

5、遷移過程中，要有完整的報警、核對等跟蹤機制，保證及時發現問題；有完整的開關等流控機制，保證有問題的時候可以及時斷流。

八、數據和數據存儲的遷移

數據和數據存儲的遷移。涉及到系統的底層環節（數據），要分析不同數據結構、不同數據存儲之間的差異，保證這些差異口以被系統正常接受處理。

1、數據遷移（如CCDC數據遷移、會員數據遷移）前后，要保證業務系統能正常識別和處理。不能保證的話，要考慮停機遷移。

2、數據存儲遷移，尤其是不同存儲之間的遷移，要考慮其之間的差異（如oracle和pg的差異、redis和hippo的差異，尤美是者seauence相關的差異更應該注意，這些都和資損率切相關。

3、遷移過程中，要有完整的報警、核對等跟蹤機制，保證及時發現問題。

4、數據是系統的底層環節，遷移的時候一定要有完備的回退機制。

九、采用開關的方式規避風險

風險較大的系統發布與業務遷移，采用開關的方式規避風險，保證業務的兼容運行。

總結

我們的系統和數據一定是不斷迭代和更新的，變更往往存在諸多風險，bug/資損也往往在系統迭代過程中產生，做好兼容性控制至關重要！

總結

以上是生活随笔為你收集整理的【资损】系统迭代过程中的兼容性设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。