如何走好資料庫信創落地“最後一公里”？

【摘要】在基礎軟體自主可控改造過程中，資料庫因其較高的複雜度，以及國內資料庫廠商能力參差不齊等原因，在選型、研發、遷移、使用上面臨諸多難點。特別是在整體改造的最後階段，蘊含了較多工作及風險。本文重點談一談這所謂信創改造“最後一公里”所面臨的痛點問題及可能解決思路。

隨著近些年來內外部形勢的劇烈變化及企業自身發展訴求，國內企業愈發重視基礎軟體的自主可控。特別是對於某些涉及國計民生的重點行業，監管層面也提出了非常明確的指導意見，在指定時間內完成技術改造。

作為核心技術軟體之一，資料庫在其中無疑扮演著重要的角色，且具有非常高的複雜性。一方面是作為基礎軟體之一，資料庫自身複雜度就比較高;另一方面近些年資料庫技術發展迅猛，以分散式、多模、HTAP為代表新型資料庫架構不斷湧現。這些都會帶來較高的複雜度，同時我們也看到國內資料庫發展活躍、廠商產品能力參差不齊，使用者在選型、研發、遷移、使用上面臨諸多痛點。特別是在整體改造的最後階段，涉及將系統從原有技術棧遷移到新技術棧，這其中蘊含了較多工作及風險。本文嘗試從信創改造角度出發，重點談在改造中往往處於最後改造的資料庫部分，即所謂信創改造“最後一公里”所面臨的痛點問題及可能解決思路。

1. 信創改造階段劃分

在企業的信創改造過程，我大致將其劃分為四個階段。

架構選型階段

這一階段完成信創技術棧的選型問題。當然這部分需要考慮的因素是比較多的，我在之前的文章中也提到過關於選型的諸多難點。

研發測試階段

這一階段完成業務系統針對信創技術棧的改造及測試。這其中涉及到較大的成本(人力、時間)的投入。

系統驗證階段

這一階段完成業務系統改造後，需針對新平臺的功能、穩定性、可用性等方面進行驗證。一般為保證真實性，可透過業務並行方式進行。

系統上線階段

這一階段是在系統已經得到充分驗證後，將業務系統從原技術棧完全遷移到新技術棧。此階段需重點解決遷移及出現問題的保障維護方面。

2. 階段：架構選型

信創技術棧分散

信創技術棧分散，尚未形成選型標準，使用者選型困難。在生態相容性上，有相容MySQL、PG、Oracle、自有標準等多種形式。架構上包括單機、集中式、分散式等多種，包括以NewSQL為代表的產品受到關注。在部署平臺上，包括私有部署及雲端部署(含私有云帶底座、公有云)等多種形式。

解決思路：

解決上述問題的思路是使用者在選型時，儘量採用“生態相容”而非簡單的選擇產品，同時針對選擇多產品問題，需形成標準統一的資料管理能力。針對前者，推薦的方式是形成企業內部資料庫標準訪問層;針對後者，則需形成資料標準管理層。

資料庫訪問標準層

首先需統一企業內部的資料庫生態，明確採用如MySQL、PG等為代表的事實標準生態。針對同生態產品間(如MySQL生態的TDSQL、GoldenDB、TiDB等)，提供標準能力相容支援;針對異構生態產品間(如Oracle、DB2)到MySQL或PG生態，提供等價改寫、異常處理(當然前提是收斂異構間資料庫差異，規範標準寫法)。

其次需統一企業內部的資料庫協議，可透過標準的MySQL或PG協議，訪問多種異構資料庫。例如透過標準MySQL協議接入，底層可對接不同資料來源(如Oracle、DB2)。當前執行的語法為目標資料來源。這種統一接入管理方式，對企業內部資料庫管理帶來極大便利。

資料標準管理層

面對企業內部多資料庫產品並存的情況，需從全域性視角出發擬定資料管理策略。之前豎井式的管理方式，在現有碎片化現狀下將更加困難。可考慮建立資料標準管理層，將常用的資料管理職能(如訪問安全、資料加密)等統一處理。

產品能力層次不齊

如之前所談，信創資料庫產品能力層次不齊，不同產品間功能差異明顯，包括核心層面、周邊生態層面及管理維護層面等多方面。這對於使用者來說，無法面對統一的服務介面會很困難。此外，在產品部署形態上，雲資料庫產品成為很多企業的選擇。但在雲產品選擇上，使用者的自主權較差，存在與原有方式的管理差異。

解決思路：

資料庫增強能力

增強資料庫及周邊生態的能力，例如針對單機資料庫短板，透過引入中間層解決分散式能力，在不改變底層技術棧的情況下，提升資料庫的上限能力。

雲適配能力

雲，為使用者帶來資源供給方式的變化，這會帶來收益;但同時也存在一些問題。一方面來自於基礎底座變化帶來的管理體驗的變化，一方面來自於雲廠商繫結的問題。使用者希望可透過一層能力遮蔽底層變化和管理方式的差異。

3. 階段：研發測試

原系統遷移評估難

在實際工作中，經常會面臨一類問題就是舊有系統已無人瞭解或乾脆是由第三方開發的。如在存量業務的改造中，缺乏有效的手段去收集、進而很難評估改造任務工作量。

解決思路：

源系統評估工具

提供對資料庫的評估工具，實現抓取資料庫的語句、負載，支援回放能力。針對資料庫特有的方言、函式等個性化需改造內容，可生成報告方便工作量評估及改造工作。當然如果沒有工具，透過調研表的方式也可以完善對之前情況的評估，公眾號之前寫過類似主題，可參考。

遷移過程成本高

很多應用系統，對原有技術棧依賴嚴重，之前大多采用Oracle、DB2為代表大型商業資料庫，應用端對商業資料庫方言、庫內計算(儲存過程、觸發器、函式等)、生態工具(SQL最佳化、資料整合、管控維護)等，都存在較重依賴。而新技術棧產品差異明顯，透過應用研發改造也存在工作量極大的情況。大量基於商業資料庫的開發邏輯，需改造遷移。一部分需改造適應新架構資料庫，一部分需考慮在異構平臺(如大資料平臺、快取平臺)或應用層解決。部分改造內容，不等價實現，提高了改造難度。

解決思路：

輔助開發平臺

為滿足在新技術棧下的開發，需秉承在架構選型階段談到的資料庫訪問標準層的理念，簡化對資料庫的使用。但對於重度依賴的原有系統，需提供一種方式可完成將舊邏輯向新邏輯的轉換，這點是比較難的，通常很難做到完全的等價轉換。目前有些工具已經能夠實現將複雜的庫內計算(如儲存過程、觸發器等)轉化為業務語言實現(如Java)，這一方式可大大加速這一過程。當然，更為重要的還是將兩者的差異充分暴露給開發者，讓大家有的放矢地去改造，明確知道潛在的工作量。更進一步的，可提供一些諸如資料整合、資料管理、SQL診斷最佳化等工具，方便在改造過程中提高開發效率。

提升相容性的平臺

可透過兩種手段進一步減少改造工作量，一方面是提升目標平臺對源平臺的相容效能力，一方面是透過中間層實現必要的改寫，自動完成不相容改造。針對第二方面的訴求，可以透過第三方平臺實現，它可相容新舊平臺的語法，同時完成等價轉化。針對不能轉化的部分，給出異常提示。配合前面的改造改寫工具，完成內容的修改，不斷收斂兩者的差異。

遷移結果評估難

對很多新架構產品提供的相容效能力存疑，僅透過語法層面的相容或少量改造，很難保證語義上的一致性，這會造成未來上線的風險。缺乏有效的評測手段，針對應用遷移前後的語義等價(資料一致性)及效能等能做到評估。

解決思路：

遷移結果評估工具

針對遷移後的執行狀態，可提供一種機制能驗證執行結果，包括但不限於對執行結果一致性的檢查、執行效率的檢查等等。透過這一能力，可有效降低系統上線後的風險。

4. 階段：系統驗證

系統驗證階段，是很多重要系統正式上線前必須經歷的階段。透過這一方式，可以大幅降低可能的技術風險，提高系統上線成功率。

遷移風險高，無法回退

為了在驗證階段，驗證系統是否工作正常，一般需要開發大量驗證類的程式碼。這部分工作主要是為了滿足系統支援新舊技術棧及必要的對比等工作，但這部分往往工作量巨大。如很多應用常見的資料雙發邏輯，就是透過資料雙寫，同步驗證兩邊執行結果。為達到這一訴求，不得不在原有業務邏輯上開發兩套適應不同技術棧的程式碼。

解決思路：

資料雙寫平臺

提供基於中間層的輕量級實現，在應用側無需改動或少量改動程式碼，即可完成資料的雙發寫入，滿足資料同步寫入到異構平臺中。為保證資料的一致性，還需提供必要的事務性保證，保證異構資料庫間資料的一致性。但當一方平臺出現異常時，應可自動退化，不影響另一套平臺正常使用。從前端業務可自動感知這一變化，可自動適應這一過程，業務無感。但系統修復後，又可以手工新增回雙髮狀態(需提供異常期間的資料補償能力)。這一思路的難點在於如何實現應用程式碼邏輯不變的情況下，支援寫入異構庫。常見的思路是透過將於資料庫的互動語言-SQL，從一種方言翻譯到另一種方言，當然前提是語義等價。此時，就可以參考之前在架構選型階段談到的-資料庫訪問標準層，收斂企業內資料庫的訪問，儘量簡化、標準化對資料庫的使用，這也是對雙發驗證階段可執行對比的前提。

遷移驗證，無從下手

在驗證階段還有一個比較難的地方在於如何驗證，最好的驗證方式是帶著真實流量的驗證，但同時還需考慮風險問題。如果對業務訪問做好精準的控制，按需求進行業務驗證，且還需提供必要的退化能力保證安全。如常用的基於讀寫的分配、基於流量的分發(甚至基於業務特徵的分發能力)。

解決思路：

流量分發平臺

提供流量分發平臺，滿足在多平臺線上情況下，根據策略分配業務訪問。可精準地控制其流向，如痛點中提到的讀寫流量、比例流量亦或是帶有業務特徵的流量。可感知下方物理拓撲變化(甚至是異構平臺間的變化)，可對應做流量重分發，不影響業務正常執行。這樣對上層來說，會帶來很大的靈活度，可根據需要隨時調整驗證策略，降低驗證期間的風險。

5. 階段：系統上線

遷移視窗短，遷移困難

在系統上線階段，一個突出問題是遷移視窗期的問題，其普遍的上線視窗期很短。這就需要在較短的時間內能夠完成資料庫間(一般是異構)的資料的遷移工作，同時還需針對遷移後的資料提供質量對比，能夠保證遷移資料是正確的。

解決思路：

離線上遷移工具

解決這一問題通常採用離線上遷移工具，可提供異構資料來源間的資料離線上的遷移能力。可充分利用物理資源，採用並行處理技術提升遷移效率，滿足時間視窗。對於海量資料遷移，通常是離線與線上相結合，即將靜態資料透過離線方式遷移，針對動態(活躍)資料採取線上遷移方式，透過這一方法儘量壓縮遷移視窗。此外，還需提供資料對比能力，可根據使用者需要進行比對。這裡面臨兩個難點，一是如何提升對比效率滿足海量資料對比;二是如何實現動態變化的資料對比。針對前者，通常的解決思路是可以讓使用者選擇對比方法(演算法)，從簡單計數、部分取樣、統計報表或複雜演算法。針對後者，可透過流式視窗比較的方法，不斷擬合趨近於實時結果。

新上系統不穩定

系統上線後的穩定性問題，也是使用者最為關心的。作為新產品、新架構，很難保證上線後一定不出問題。雖然可透過充分的測試、並行驗證等多種手段儘量減少這個出現問題的風險，但顯然無法完全避免。比較好的方式是提供一種能力，根據可能出現的執行問題，透過一些手段可以儘量減少問題影響範圍，恢復業務。

解決思路：

流量治理平臺

提供資料庫流量的統一接入，並實現治理能力。透過多種手段(基於標籤、SQL文字、使用者名稱、來源IP等)實現對SQL流量的精準控制。例如針對低效SQL，可實現熔斷、限流;針對特定SQL，提供黑白名單;為滿足問題排查提供全量SQL的審計能力，可做到事後追蹤等。

系統逃生平臺(方案)

為 防止出現系統性風險或全域性邏輯性錯誤，需提供一種異構“逃生”方案。所謂異構，一定是一種有別於現有技術棧的平臺或方案。兩套平臺間的資料是需要做到可控同步的，即可根據需要選擇實時同步、延遲同步和人工同步。同時在資料之上，還需提供切換的能力，可滿足在異常情況下短時可切換。