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

這里是Z哥的個(gè)人公眾號

每周五11：45 按時(shí)送達(dá)

當(dāng)然了，也會時(shí)不時(shí)加個(gè)餐～

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

大家好，我是Z哥。

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

不過最近的辛苦也沒有白費(fèi)，總算完成了一個(gè)小里程碑，目前負(fù)責(zé)的項(xiàng)目中難啃的兩塊骨頭總算啃掉了一塊，松了半口氣。

也順帶松口氣騰出時(shí)間來寫點(diǎn)東西。

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

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

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

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

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

其實(shí)遷移方式主要是兩個(gè)維度上的考量。

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

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

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

1. 停機(jī)+離線

2. 停機(jī)+實(shí)時(shí)

3. 不停機(jī)+離線

4. 不停機(jī)+實(shí)時(shí)

我們來一個(gè)個(gè)聊一下。

01? 停機(jī) + 離線

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

1. 對外宣告維護(hù)中。

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

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

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

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

02? 停機(jī) + 實(shí)時(shí)

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

整個(gè)過程是這樣的：

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

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

3. 檢查同步機(jī)制 OK 后，對外宣告維護(hù)中。

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

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

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

03? 不停機(jī) + 離線

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

04? 不停機(jī) + 實(shí)時(shí)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這里延伸出了兩個(gè)問題：

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

• 臨界點(diǎn)的處理方案

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

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

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

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

• 庫存管理系統(tǒng)就可以設(shè)計(jì)成增量模型的系統(tǒng)，因?yàn)槊恳淮螌齑娴脑黾雍蜏p少都是獨(dú)立進(jìn)行的，不依賴于上一次的變化。

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

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

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

資源保護(hù)原則

數(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ā)一個(gè)異常數(shù)據(jù)的識別工具。

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

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

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

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

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

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

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

  
  

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

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

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

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

3. 同步完成后，返回給終端展示給用戶。（因?yàn)槭菃螚l數(shù)據(jù)同步，一般1秒內(nèi)都能搞定，用戶無感）

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

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

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

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

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

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

在實(shí)施「不停機(jī)+實(shí)時(shí)」方案的時(shí)候，有三個(gè)重要的點(diǎn)需要考慮。

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

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

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

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

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

推薦閱讀：

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

• 高強(qiáng)度工作后的思考
  

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

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

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

可以試試點(diǎn)擊「閱讀原文」