程序員必備，《新老系統(tǒng)切換寶典》

這里是Z哥的個人公眾號

每周五11：45 按時送達

當然了，也會時不時加個餐～

我的第「216」篇原創(chuàng)敬上

大家好，我是Z哥。

有三周沒有發(fā)文了，有點過意不去～

不過最近的辛苦也沒有白費，總算完成了一個小里程碑，目前負責的項目中難啃的兩塊骨頭總算啃掉了一塊，松了半口氣。

也順帶松口氣騰出時間來寫點東西。

最近正在做新老系統(tǒng)切換的準備工作，對于新老系統(tǒng)的切換方案，正好最近有做一些了解和思考，在這里和大家分享一下，可能你以后也會用得到。

除非你所在的企業(yè)是一個發(fā)展沒多久的企業(yè)，否則新老系統(tǒng)的切換其實是個很常見的問題。我認為大家都有必要掌握這方面的知識。

可能有些人會覺得，這不是很簡單么。找個半夜的時間，關(guān)閉系統(tǒng)的對外訪問，然后一頓發(fā)布，不就完成切換了么。

這個方案也不是不可行，只是對外部條件的要求比較高。比如，整個發(fā)布的耗時不能太長，畢竟半夜就那點時間。另外，需要停機才能發(fā)布，這個對于業(yè)務(wù)來說是個硬傷，不但失去了靈活性，而且一旦切換期間出現(xiàn)問題，想要回滾的難度也很大。

當然，停機切換的方案，對于需要做的準備工作是最少的，投入的顯性成本最低，在一些場景下還是值得選擇的。

其實遷移方式主要是兩個維度上的考量。

• 應(yīng)用程序是否停機

• 數(shù)據(jù)的同步是離線進行還是實時進行

根據(jù)這兩個維度的組合就可以得到四個不同的方案：

1. 停機+離線

2. 停機+實時

3. 不停機+離線

4. 不停機+實時

我們來一個個聊一下。

01? 停機 + 離線

正如前面所說，這個方案是準備工作最少的方案，也俗稱一刀切方案。整個過程大概是這樣：

1. 對外宣告維護中。

2. 將舊格式的數(shù)據(jù)批量轉(zhuǎn)換為新格式的數(shù)據(jù)。

3. 發(fā)布新版本的系統(tǒng)。

4. 檢查系統(tǒng)功能正常后，宣告維護結(jié)束。

核心步驟就兩步，但是每一步都是非生即死的操作……，一般適用于小范圍內(nèi)操作，比如非核心的子系統(tǒng)。

02? 停機 + 實時

這種方式意味著需要停機的終端系統(tǒng)在更新后的新版本中同時兼容新舊兩套服務(wù)端系統(tǒng)，通過流量控制進行轉(zhuǎn)發(fā)到新 or 舊服務(wù)端。新舊兩套服務(wù)端之間進行數(shù)據(jù)的實時雙向同步。

整個過程是這樣的：

1. 部署新服務(wù)端系統(tǒng)。

2. 建立新老服務(wù)端系統(tǒng)之間的雙向同步。

3. 檢查同步機制 OK 后，對外宣告維護中。

4. 發(fā)布新版本的終端系統(tǒng)。

5. 檢查系統(tǒng)功能正常后，宣告維護結(jié)束。

這種方案很少用到，因為實現(xiàn)終端系統(tǒng)的不停機比服務(wù)端數(shù)據(jù)的實時同步容易得多，一般決定了在服務(wù)端層面做實時雙向同步，往往也會讓終端系統(tǒng)配合著做不停機。

03? 不停機 + 離線

這種方案不存在，因為數(shù)據(jù)既然選擇離線遷移，就必然意味著相關(guān)的系統(tǒng)必須停機，否則在離線遷移過程中產(chǎn)生的新數(shù)據(jù)需要反復(fù)進行離線遷移，陷入無限循環(huán)。

04? 不停機 + 實時

這種方式是對業(yè)務(wù)影響降到最低的方式，但是涉及到的工作也最多。

1. 部署一套完整的新系統(tǒng)（終端+服務(wù)端）。

2. 檢查整套新系統(tǒng)功能正常后，對新訪問的用戶進行流量切換（ APP 的話就是灰度下發(fā)升級），將部分流量導(dǎo)到新的終端系統(tǒng)。

3. 驗證新系統(tǒng)的穩(wěn)定性。如果穩(wěn)定性出現(xiàn)問題，流量完全切換回舊系統(tǒng)，否則繼續(xù)提高新系統(tǒng)的流量占比。

4. 等到流量 100% 切換到新系統(tǒng)之后，完全下線老系統(tǒng)，完成切換。

一般核心的、面向 C 端用戶的系統(tǒng)大多會選擇這種方式。

我們今天主要對「不停機 + 實時」這個方案的實施細節(jié)展開聊一下。

實施中的關(guān)鍵點主要都是圍繞數(shù)據(jù)進行，因為數(shù)據(jù)同步天然存在延遲，而延遲一旦處理不善不僅僅是系統(tǒng)出現(xiàn)問題，數(shù)據(jù)的準確性、有效性都會遭到破壞。我們主要的關(guān)注點是以下三個：

1. 數(shù)據(jù)遷移的方案

2. 異常數(shù)據(jù)的識別工具

3. 異常數(shù)據(jù)的自動處理機制

/01? 數(shù)據(jù)遷移方案/

數(shù)據(jù)的遷移主要分為兩部分數(shù)據(jù)。存量數(shù)據(jù)（已發(fā)生的）和增量數(shù)據(jù)（當前新發(fā)生的）。

對新系統(tǒng)來說，只有將老系統(tǒng)的存量數(shù)據(jù)+增量數(shù)據(jù)都同步過來，才算真正建立了雙向同步通道。

這里延伸出了兩個問題：

• 需要同步的存量數(shù)據(jù)范圍（主要是時間跨度）

• 臨界點的處理方案

遷移的存量數(shù)據(jù)范圍一般要配合相應(yīng)的功能進行，如果終端系統(tǒng)只對外提供 2 年內(nèi)的數(shù)據(jù)，那么只要遷移 2 年內(nèi)的數(shù)據(jù)就好了。

這里還可以根據(jù)存量數(shù)據(jù)是否在當前是否繼續(xù)發(fā)生變化，再分為兩部分。不發(fā)生變化的部分遷移很容易進行，因為不會受到實時數(shù)據(jù)的干擾，我們可以在實施遷移之前就把數(shù)據(jù)遷移好。而會發(fā)生變化的部分，就是我們需要考慮的「臨界點的處理方案」。

針對臨界點的處理，也有兩種方案。使用哪一種方案取決于系統(tǒng)的數(shù)據(jù)變更是否依賴同一條數(shù)據(jù)的上一次變更。有點繞口，簡單來說就是系統(tǒng)的數(shù)據(jù)變動是增量模型還是全量模型。舉個例子：

• 訂單管理系統(tǒng)就是全量模型的系統(tǒng)，因為單據(jù)的變化依賴于上一次的變化，無法跳過中間的任意一次變化。

• 庫存管理系統(tǒng)就可以設(shè)計成增量模型的系統(tǒng)，因為每一次對庫存的增加和減少都是獨立進行的，不依賴于上一次的變化。

針對全量模型的系統(tǒng)處理數(shù)據(jù)同步是最難的，因為需要保證數(shù)據(jù)變更的順序性。而針對增量模型的系統(tǒng)就會相對簡單一些，可以不用保證順序。

至于進行數(shù)據(jù)遷移的技術(shù)實現(xiàn)，可以選擇通過中間件進行，如 DB、MQ等等，也可以選擇通過 RPC 調(diào)用進行。

但是不管選擇什么方式進行數(shù)據(jù)遷移，有幾個原則需要盡可能地遵守。

資源保護原則

數(shù)據(jù)過濾原則

數(shù)據(jù)照搬原則

http://chisc.net/doc/view/3373.html

/02? 異常數(shù)據(jù)的識別工具/

數(shù)據(jù)同步至新系統(tǒng)的過程中可能會出現(xiàn)數(shù)據(jù)重復(fù)、數(shù)據(jù)缺失、同步延遲等問題。為了保證遷移過程的可觀測性，還需要針對性的開發(fā)一個異常數(shù)據(jù)的識別工具。

這個工具本質(zhì)上就是做兩件事。

1. 分別采樣新舊系統(tǒng)在某些時刻的數(shù)據(jù)。

2. 統(tǒng)計出這些時刻新舊系統(tǒng)之間差異情況。（差異數(shù)量、差異的同比、環(huán)比變化）

如果做得再好一些，可以考慮將數(shù)據(jù)同步的延遲情況也包含進去。

/03 異常數(shù)據(jù)的處理/

利用第二步中的工具，我們可以識別出一些異常數(shù)據(jù)，主要分為三種情況：

• 數(shù)據(jù)重復(fù)：應(yīng)對重復(fù)數(shù)據(jù)，主要的思路就是冪等處理。其實這也是應(yīng)該在制定同步方案的時候就要考慮好的問題。

  
  

• 數(shù)據(jù)缺失：如果不是 DB 層面的數(shù)據(jù)同步，數(shù)據(jù)缺失的情況還是有概率出現(xiàn)的。要么是舊系統(tǒng)發(fā)起同步的時候丟了，要么是新系統(tǒng)接收到數(shù)據(jù)并寫入到磁盤的時候出現(xiàn)了異常。解決起來倒也簡單，重新同步一下就好了。

• 數(shù)據(jù)同步時間差：像訂單系統(tǒng)這種全量模型的系統(tǒng)，對于數(shù)據(jù)同步的延遲容忍度比較低，比如用戶來查看自己的訂單，發(fā)現(xiàn)還是修改之前的信息，就很尷尬。此時，我們可以做一個主動查詢舊系統(tǒng)的機制：

1. 當用戶在新系統(tǒng)發(fā)起查詢某個數(shù)據(jù)時，我們主動查詢一下舊系統(tǒng)。

2. 如果發(fā)現(xiàn)新系統(tǒng)的數(shù)據(jù)是舊的，則強制同步一次。

3. 同步完成后，返回給終端展示給用戶。（因為是單條數(shù)據(jù)同步，一般1秒內(nèi)都能搞定，用戶無感）

其實整個實時雙向同步方案中，需要考慮的細節(jié)還有不少，限于篇幅原因今天就不繼續(xù)展開了。

比如，可能有必要引入版本號的概念，兩邊系統(tǒng)共用一個版本號生成器。當發(fā)現(xiàn)本地修改時，版本號不是連續(xù)的，說明存在兩邊同時修改的情況，需要做針對性的處理。

思路比具體的方案細節(jié)更重要，今天我們就交流一下核心思路。

好了，總結(jié)一下。

這篇呢，Z哥和你分享了我最近在做的新老系統(tǒng)切換方案的思路。

切換方案主要從兩個維度來考量，停機 or 不停機，數(shù)據(jù)同步實時 or 離線。常見的方案是「停機+離線」，「不停機+實時」。我們這次主要針對后者展開聊了下。

在實施「不停機+實時」方案的時候，有三個重要的點需要考慮。

1. 數(shù)據(jù)遷移的方案

2. 異常數(shù)據(jù)的識別工具

3. 異常數(shù)據(jù)的自動處理機制

對這三個要點做好考慮，基本上就比較穩(wěn)了。希望對你有所啟發(fā)。

不知道你對新老系統(tǒng)的切換，有什么好想法嗎？歡迎在留言區(qū)分享給大家，相互學(xué)習～

推薦閱讀：

• golang使用3周總結(jié)
  

• 高強度工作后的思考
  

原創(chuàng)不易，如果你覺得這篇文章還不錯，就「點贊」或者「在看」一下吧，鼓勵我的創(chuàng)作 ：）

也可以分享我的公眾號名片給有需要的朋友們。

如果你有關(guān)于軟件架構(gòu)、分布式系統(tǒng)、產(chǎn)品、運營的困惑

可以試試點擊「閱讀原文」