作者 | 李佳俊、程博

某天，正跟小張pair做卡呢。突然收到客戶通知：不用做了，這系統(tǒng)不要了。

啊? 都搞了好幾年，說不要就不要了，客戶這么財(cái)大氣粗？

細(xì)問之下，原來變化來源于最新的商業(yè)決策——客戶收購了一個(gè)市場占有率比較大的新公司，打算直接使用新公司已有的系統(tǒng)。那我們是不是可以下項(xiàng)目休息了？曹老大瞟了一眼我：你想得美?？蛻粝Ｍ熏F(xiàn)有的生產(chǎn)數(shù)據(jù)遷出到新系統(tǒng)去。不是吧，又遷，咱們不是剛把之前收購的老系統(tǒng)數(shù)據(jù)遷到新開發(fā)的系統(tǒng)嗎？

模型分析

前方目標(biāo)很明確：數(shù)據(jù)遷移，讓數(shù)據(jù)的價(jià)值在新系統(tǒng)中繼續(xù)發(fā)光發(fā)熱。

新老系統(tǒng)由于只是同一個(gè)領(lǐng)域的不同實(shí)現(xiàn)，所以模型上很相似。主要的源數(shù)據(jù)模型都能映射到目標(biāo)模型，模型上的部分字段甚至也是等價(jià)的概念。但是畢竟是兩波開發(fā)實(shí)現(xiàn)的兩個(gè)不同的系統(tǒng)，很多業(yè)務(wù)概念叫法完全不同，首先就需要坐下來跟客戶一起統(tǒng)一模型語言。另外，還有很多新系統(tǒng)的目標(biāo)字段不能由源數(shù)據(jù)直接獲得，有的字段甚至無法獲得。所以，我們根據(jù)不同類型的數(shù)據(jù)特征，將數(shù)據(jù)分成了4種類型：

• 直接映射，源數(shù)據(jù)模型的字段值直接映射為目標(biāo)數(shù)據(jù)模型的字段值。
• 間接映射，源數(shù)據(jù)模型的一個(gè)或多個(gè)字段值經(jīng)過一定的業(yè)務(wù)規(guī)則轉(zhuǎn)換為目標(biāo)數(shù)據(jù)模型的字段值。
• 默認(rèn)值，源數(shù)據(jù)模型沒有相關(guān)的字段，而目標(biāo)數(shù)據(jù)模型又是必填的字段值。
• 丟棄，源數(shù)據(jù)模型沒有相關(guān)的字段，而目標(biāo)數(shù)據(jù)模型也不是必填的字段值。

根據(jù)這四類規(guī)則，在和客戶友(lai)好(hui)討(la)論(che)了多輪之后，我們得到了一個(gè)數(shù)據(jù)映射表，將所有需要遷移的源數(shù)據(jù)模型映射為目標(biāo)數(shù)據(jù)模型。

遷移策略

數(shù)據(jù)清楚了就開搞吧！等等，客戶對(duì)遷移又提了幾個(gè)新需求：

• 新系統(tǒng)的數(shù)據(jù)加載部分想復(fù)用已經(jīng)寫好的腳本，腳本的輸入是json文件，所以希望使用json文件作為介質(zhì)將老系統(tǒng)的數(shù)據(jù)傳輸?shù)叫孪到y(tǒng)。
• 在數(shù)據(jù)還沒全部遷到新系統(tǒng)之前，兩個(gè)系統(tǒng)同時(shí)都要用，因?yàn)榭蛻粜枰谟脩袈煜ば孪到y(tǒng)的同時(shí)，使用老系統(tǒng)保證業(yè)務(wù)連貫性。

這意味著兩件事：老系統(tǒng)在幾個(gè)月內(nèi)還會(huì)源源不斷的產(chǎn)生新數(shù)據(jù)；新系統(tǒng)需要在一定的時(shí)間段內(nèi)看到老系統(tǒng)新產(chǎn)生的數(shù)據(jù)。這樣的狀況可能要持續(xù)很久，直到客戶喊停才能停。于是，遷移可能會(huì)變成這樣。

根據(jù)數(shù)據(jù)量的不同，我們把遷移又分成了全量遷移和增量遷移。

全量遷移關(guān)注的是如何把大批的數(shù)據(jù)一次性遷入到新系統(tǒng)，由于數(shù)據(jù)量較大，文件需要進(jìn)行分片處理。增量數(shù)據(jù)則關(guān)注的是如何保證數(shù)據(jù)實(shí)時(shí)性，在客戶能夠容忍的時(shí)間范圍內(nèi)，將增量數(shù)據(jù)同步到新系統(tǒng)?？蛻魧?duì)實(shí)時(shí)性要求并不高（一天之內(nèi))，而且也不希望在新系統(tǒng)上新增API去做實(shí)時(shí)同步，所以定時(shí)任務(wù)已經(jīng)能夠滿足增量數(shù)據(jù)同步的要求。

數(shù)據(jù)實(shí)體間存在單向依賴，希望按照依賴關(guān)系分批進(jìn)行遷移，簡化的說明圖如下：

對(duì)于增量數(shù)據(jù)，也需要考慮根據(jù)依賴關(guān)系，調(diào)整定時(shí)任務(wù)的實(shí)體同步順序。

實(shí)現(xiàn)

其實(shí)整個(gè)遷移過程看起來就是一個(gè)經(jīng)典的ETL過程，先將源數(shù)據(jù)從老系統(tǒng)提?。‥）出來，根據(jù)數(shù)據(jù)映射表進(jìn)行轉(zhuǎn)換（T），最后通過生成文件并加載（L）到新系統(tǒng)中。但在實(shí)現(xiàn)過程中還是遇到了不少麻煩。

1.AWS to GCP

這是我們?cè)谠O(shè)計(jì)階段遇到的第一個(gè)大麻煩，老系統(tǒng)運(yùn)行在AWS環(huán)境，而新系統(tǒng)運(yùn)行在GCP環(huán)境。云遷移的案例在網(wǎng)上搜集相關(guān)資料比較少。Spike了幾輪之后，處于安全性，效率等因素考慮，我們決定使用GCP的Workload identity federation（WIF）進(jìn)行云平臺(tái)間數(shù)據(jù)遷移。WIF是GCP提供的外部服務(wù)訪問GCP資源的服務(wù)，它旨在消除與服務(wù)帳號(hào)密鑰相關(guān)的維護(hù)和安全負(fù)擔(dān)。WIF遵循OAuth 2.0 令牌交換規(guī)范，令牌交換的主要過程大致為：

• 獲取AWS GetCallerIdentity token
• 使用AWS GetCallerIdentity token交換GCP federated access token
• 使用GCP federated access token交換GCP service account access token
• 使用GCP service account access token訪問GCP資源

在我們的項(xiàng)目場景中，由AWS lambda與GCP Security Token Service及Cloud IAM交互完成短期token的獲取，并持有短期token執(zhí)行將S3中的文件存入Cloud storage的過程。

2.數(shù)據(jù)安全

數(shù)據(jù)本身全是跟錢相關(guān)的東西，文件又需要走公網(wǎng)從AWS傳輸?shù)紾CP，所以數(shù)據(jù)安全也是需要重點(diǎn)考慮的環(huán)節(jié)。雖然GCP本身已經(jīng)提供了一定等級(jí)的數(shù)據(jù)加密，但是客戶還是不放心，希望我們?cè)趹?yīng)用程序本身再提供一層數(shù)據(jù)安全的保障。于是根據(jù)數(shù)據(jù)安全經(jīng)典過程，我們?cè)贏WS發(fā)送文件前對(duì)文件做了加密及簽名，并在GCP收到后文件完成解密及驗(yàn)證。加密為了保證數(shù)據(jù)不被中間人竊取，簽名為了防止惡意傳輸攻擊文件：

3.數(shù)據(jù)合并

前文提過，由于歷史原因，老系統(tǒng)當(dāng)前的數(shù)據(jù)其實(shí)也是從更老的系統(tǒng)中遷移過來了（更老的系統(tǒng)實(shí)際也還在使用中），老系統(tǒng)當(dāng)前對(duì)外提供的API存在著大量的數(shù)據(jù)合并邏輯。如果以數(shù)據(jù)庫為源頭對(duì)涉及數(shù)據(jù)合并的實(shí)體進(jìn)行遷移，那么就需要大量重寫這部分業(yè)務(wù)邏輯，而這將會(huì)是個(gè)漫長而又復(fù)雜的過程。如果直接使用當(dāng)前系統(tǒng)的API，由于遷移訪問的數(shù)據(jù)量很大，又會(huì)對(duì)線上業(yè)務(wù)造成影響。

于是我們采取了一個(gè)折中的辦法，在生產(chǎn)環(huán)境中復(fù)制了一個(gè)只讀實(shí)例來規(guī)避對(duì)數(shù)據(jù)合并邏輯的重復(fù)工作，并且不影響線上環(huán)境的實(shí)例性能。

4.增量數(shù)據(jù)統(tǒng)計(jì)

對(duì)于遷移期間的增量數(shù)據(jù)，我們采用事件驅(qū)動(dòng)的方式，通過監(jiān)聽源數(shù)據(jù)庫的新增或修改，并觸發(fā)lambda執(zhí)行轉(zhuǎn)換過程，將轉(zhuǎn)換后的數(shù)據(jù)存入中間表并記錄修改時(shí)間。在每天生成增量數(shù)據(jù)文件時(shí)，通過查詢所有比上次遷移時(shí)間晚的記錄，得到所有增量數(shù)據(jù)并最終生成本次文件。

5.數(shù)據(jù)校驗(yàn)

在生成文件的過程中，我們會(huì)對(duì)實(shí)體的各個(gè)字段根據(jù)業(yè)務(wù)規(guī)則進(jìn)行校驗(yàn)，對(duì)不符合校驗(yàn)規(guī)則的數(shù)據(jù)將其原始數(shù)據(jù)及錯(cuò)誤原因收集到錯(cuò)誤日志表中，方便我們后續(xù)修數(shù)據(jù)的環(huán)節(jié)。我們的測試環(huán)境雖然有一部分?jǐn)?shù)據(jù)也來自生產(chǎn)環(huán)境，但出于安全原因，大部分字段都做過混淆。所以在測試環(huán)境無法收集到所有真實(shí)數(shù)據(jù)的錯(cuò)誤，很難保證遷移的最終結(jié)果。

于是在上線前的一兩個(gè)迭代內(nèi)我們做的事情是，在生產(chǎn)環(huán)境中進(jìn)行若干輪預(yù)遷移（但不執(zhí)行加載）。這樣每一輪預(yù)遷移會(huì)收集到一部分?jǐn)?shù)據(jù)錯(cuò)誤。這些數(shù)據(jù)錯(cuò)誤大部分需要與客戶討論后進(jìn)行處理，主要處理方式有：

• 數(shù)據(jù)本身輸入不合法，需要客戶確定正確的值并修復(fù)
• 數(shù)據(jù)本身輸入合法，根據(jù)新系統(tǒng)的表現(xiàn)形式，重新確定轉(zhuǎn)換邏輯給予合法值
• 數(shù)據(jù)無法修復(fù)且不重要，丟棄

這樣在經(jīng)過多輪預(yù)遷移以后，我們修復(fù)了所有生產(chǎn)環(huán)境上的錯(cuò)誤，從而保證了最終遷移到新系統(tǒng)的數(shù)據(jù)質(zhì)量。

6.數(shù)據(jù)審計(jì)與錯(cuò)誤追溯

在做完數(shù)據(jù)遷移之后，我們需要進(jìn)行數(shù)據(jù)審計(jì)及錯(cuò)誤追溯，以保證遷移過程沒有丟失數(shù)據(jù)。在第一批數(shù)據(jù)遷移完成后，QA同學(xué)經(jīng)常抱怨說現(xiàn)在對(duì)數(shù)據(jù)審計(jì)及錯(cuò)誤追溯非常不友好。原因是我們對(duì)第一批數(shù)據(jù)遷移的設(shè)計(jì)是，源數(shù)據(jù)轉(zhuǎn)換后直接生成目標(biāo)文件。這導(dǎo)致進(jìn)行審計(jì)以及出錯(cuò)排查的時(shí)候，需要對(duì)文件直接進(jìn)行分析。而分析文件有兩個(gè)非常不方便的點(diǎn)：

• 生產(chǎn)環(huán)境不允許下載文件，只得在生產(chǎn)環(huán)境上搭建用于審計(jì)及錯(cuò)誤排查的腳本運(yùn)行環(huán)境
• 即使是測試環(huán)境允許下載文件，有些實(shí)體數(shù)據(jù)量非常大，文件無法直接打開，還是得寫腳本進(jìn)行分析

為了解決這個(gè)痛點(diǎn)，從第二批數(shù)據(jù)遷移開始，我們首先將轉(zhuǎn)換后的數(shù)據(jù)存入中間表，這樣也就對(duì)遷移過程做了一次解耦。事實(shí)證明解耦后我們對(duì)數(shù)據(jù)庫直接進(jìn)行計(jì)數(shù)對(duì)及查詢，對(duì)數(shù)據(jù)審計(jì)及錯(cuò)誤排查的效率有非常大的提升。

收獲

• 數(shù)據(jù)遷移過程涉及在三個(gè)系統(tǒng)之間傳輸數(shù)據(jù)。以及AWS到GCP的云平臺(tái)間的遷移，在這個(gè)復(fù)雜的過程遇到了大大小小數(shù)不盡的坑，也順勢學(xué)到了很多東西。
• 遷移并不是一錘子買賣，為了確保用戶的無縫過渡，在遷移過程中保證多個(gè)系統(tǒng)的可用性及系統(tǒng)間的數(shù)據(jù)一致性也非常重要。
• 實(shí)體間依賴對(duì)遷移計(jì)劃影響很大。在遷移過程中，需要建立了依賴映射并監(jiān)控了每個(gè)實(shí)體的遷移歷史，以檢查每個(gè)記錄的實(shí)體關(guān)系/依賴關(guān)系。每當(dāng)出現(xiàn)錯(cuò)誤時(shí)，無效數(shù)據(jù)和依賴于無效數(shù)據(jù)的數(shù)據(jù)將被過濾掉，以確保整個(gè)遷移過程能夠繼續(xù)進(jìn)行。
• 保持?jǐn)?shù)據(jù)可追溯性是遷移過程的關(guān)鍵方面。通過確保所有數(shù)據(jù)都可以追溯到其來源，可以幫助最大限度地減少數(shù)據(jù)丟失或損壞的風(fēng)險(xiǎn)，并確保在整個(gè)遷移過程中數(shù)據(jù)的準(zhǔn)確性和完整性
• 為確保成功的遷移，需要對(duì)復(fù)雜的業(yè)務(wù)邏輯進(jìn)行徹底分析，并確定在過程中可能出現(xiàn)的任何潛在問題。這包括將所有必要的字段映射到新系統(tǒng)，并解決源數(shù)據(jù)中可能存在的任何數(shù)據(jù)質(zhì)量問題。
• 為了確保遷移過程中數(shù)據(jù)的質(zhì)量，重要的是制定一個(gè)測試策略，并由團(tuán)隊(duì)中的每個(gè)人進(jìn)行審查和維護(hù)。遷移的驗(yàn)證過程需要充分考慮數(shù)據(jù)完整性和無數(shù)據(jù)丟失，并確保在遷移后滿足所有指定的功能和非功能方面的要求。