隨著近些年來內外部形勢的劇烈變化及企業自身發展訴求，國內企業愈發重視基礎軟件的自主可控。特別是對於某些涉及國計民生的重點行業，監管層面也提出了非常明確的指導意見，在指定時間內完成技術改造。作為核心技術軟件之一，數據庫在其中無疑扮演著重要的角色，且具有非常高的複雜性。一方面是作為基礎軟件之一，數據庫自身複雜度就比較高；另一方面近些年數據庫技術發展迅猛，以分佈式、多模、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的審計能力，可做到事後追蹤等。

系統逃生平臺（方案）

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