走好信創(chuàng)落地“最后一公里”
原創(chuàng)?隨著近些年來內(nèi)外部形勢的劇烈變化及企業(yè)自身發(fā)展訴求,國內(nèi)企業(yè)愈發(fā)重視基礎(chǔ)軟件的自主可控。特別是對于某些涉及國計民生的重點行業(yè),監(jiān)管層面也提出了非常明確的指導意見,在指定時間內(nèi)完成技術(shù)改造。
作為核心技術(shù)軟件之一,數(shù)據(jù)庫在其中無疑扮演著重要的角色,且具有非常高的復雜性。一方面是作為基礎(chǔ)軟件之一,數(shù)據(jù)庫自身復雜度就比較高;另一方面近些年數(shù)據(jù)庫技術(shù)發(fā)展迅猛,以分布式、多模、HTAP為代表新型數(shù)據(jù)庫架構(gòu)不斷涌現(xiàn)。這些都會帶來較高的復雜度,同時我們也看到國內(nèi)數(shù)據(jù)庫發(fā)展活躍、廠商產(chǎn)品能力參差不齊,用戶在選型、研發(fā)、遷移、使用上面臨諸多痛點。特別是在整體改造的最后階段,涉及將系統(tǒng)從原有技術(shù)棧遷移到新技術(shù)棧,這其中蘊含了較多工作及風險。本文嘗試從信創(chuàng)改造角度出發(fā),重點談在改造中往往處于最后改造的數(shù)據(jù)庫部分,即所謂信創(chuàng)改造“最后一公里”所面臨的痛點問題及可能解決思路。
1. 信創(chuàng)改造階段劃分
在企業(yè)的信創(chuàng)改造過程,我大致將其劃分為四個階段。
架構(gòu)選型階段
這一階段完成信創(chuàng)技術(shù)棧的選型問題。當然這部分需要考慮的因素是比較多的,我在之前的文章中也提到過關(guān)于選型的諸多難點。
研發(fā)測試階段
這一階段完成業(yè)務系統(tǒng)針對信創(chuàng)技術(shù)棧的改造及測試。這其中涉及到較大的成本(人力、時間)的投入。
系統(tǒng)驗證階段
這一階段完成業(yè)務系統(tǒng)改造后,需針對新平臺的功能、穩(wěn)定性、可用性等方面進行驗證。一般為保證真實性,可通過業(yè)務并行方式進行。
系統(tǒng)上線階段
這一階段是在系統(tǒng)已經(jīng)得到充分驗證后,將業(yè)務系統(tǒng)從原技術(shù)棧完全遷移到新技術(shù)棧。此階段需重點解決遷移及出現(xiàn)問題的保障維護方面。
2. 階段:架構(gòu)選型
信創(chuàng)技術(shù)棧分散
信創(chuàng)技術(shù)棧分散,尚未形成選型標準,用戶選型困難。在生態(tài)兼容性上,有兼容MySQL、PG、Oracle、自有標準等多種形式。架構(gòu)上包括單機、集中式、分布式等多種,包括以NewSQL為代表的產(chǎn)品受到關(guān)注。在部署平臺上,包括私有部署及云端部署(含私有云帶底座、公有云)等多種形式。
解決思路
解決上述問題的思路是用戶在選型時,盡量采用“生態(tài)兼容”而非簡單的選擇產(chǎn)品,同時針對選擇多產(chǎn)品問題,需形成標準統(tǒng)一的數(shù)據(jù)管理能力。針對前者,推薦的方式是形成企業(yè)內(nèi)部數(shù)據(jù)庫標準訪問層;針對后者,則需形成數(shù)據(jù)標準管理層。
- 數(shù)據(jù)庫訪問標準層
首先需統(tǒng)一企業(yè)內(nèi)部的數(shù)據(jù)庫生態(tài),明確采用如MySQL、PG等為代表的事實標準生態(tài)。針對同生態(tài)產(chǎn)品間(如MySQL生態(tài)的TDSQL、GoldenDB、TiDB等),提供標準能力兼容支持;針對異構(gòu)生態(tài)產(chǎn)品間(如Oracle、DB2)到MySQL或PG生態(tài),提供等價改寫、異常處理(當然前提是收斂異構(gòu)間數(shù)據(jù)庫差異,規(guī)范標準寫法)。
其次需統(tǒng)一企業(yè)內(nèi)部的數(shù)據(jù)庫協(xié)議,可通過標準的MySQL或PG協(xié)議,訪問多種異構(gòu)數(shù)據(jù)庫。例如通過標準MySQL協(xié)議接入,底層可對接不同數(shù)據(jù)源(如Oracle、DB2)。當前執(zhí)行的語法為目標數(shù)據(jù)源。這種統(tǒng)一接入管理方式,對企業(yè)內(nèi)部數(shù)據(jù)庫管理帶來極大便利。
- 數(shù)據(jù)標準管理層
面對企業(yè)內(nèi)部多數(shù)據(jù)庫產(chǎn)品并存的情況,需從全局視角出發(fā)擬定數(shù)據(jù)管理策略。之前豎井式的管理方式,在現(xiàn)有碎片化現(xiàn)狀下將更加困難。可考慮建立數(shù)據(jù)標準管理層,將常用的數(shù)據(jù)管理職能(如訪問安全、數(shù)據(jù)加密)等統(tǒng)一處理。
產(chǎn)品能力層次不齊
如之前所談,信創(chuàng)數(shù)據(jù)庫產(chǎn)品能力層次不齊,不同產(chǎn)品間功能差異明顯,包括內(nèi)核層面、周邊生態(tài)層面及管理維護層面等多方面。這對于用戶來說,無法面對統(tǒng)一的服務界面會很困難。此外,在產(chǎn)品部署形態(tài)上,云數(shù)據(jù)庫產(chǎn)品成為很多企業(yè)的選擇。但在云產(chǎn)品選擇上,用戶的自主權(quán)較差,存在與原有方式的管理差異。
解決思路
數(shù)據(jù)庫增強能力
增強數(shù)據(jù)庫及周邊生態(tài)的能力,例如針對單機數(shù)據(jù)庫短板,通過引入中間層解決分布式能力,在不改變底層技術(shù)棧的情況下,提升數(shù)據(jù)庫的上限能力。
云適配能力
云,為用戶帶來資源供給方式的變化,這會帶來收益;但同時也存在一些問題。一方面來自于基礎(chǔ)底座變化帶來的管理體驗的變化,一方面來自于云廠商綁定的問題。用戶希望可通過一層能力屏蔽底層變化和管理方式的差異。
3. 階段:研發(fā)測試
原系統(tǒng)遷移評估難
在實際工作中,經(jīng)常會面臨一類問題就是舊有系統(tǒng)已無人了解或干脆是由第三方開發(fā)的。如在存量業(yè)務的改造中,缺乏有效的手段去收集、進而很難評估改造任務工作量。
解決思路
- 源系統(tǒng)評估工具
提供對數(shù)據(jù)庫的評估工具,實現(xiàn)抓取數(shù)據(jù)庫的語句、負載,支持回放能力。針對數(shù)據(jù)庫特有的方言、函數(shù)等個性化需改造內(nèi)容,可生成報告方便工作量評估及改造工作。當然如果沒有工具,通過調(diào)研表的方式也可以完善對之前情況的評估,公眾號之前寫過類似主題,可參考。
遷移過程成本高
很多應用系統(tǒng),對原有技術(shù)棧依賴嚴重,之前大多采用Oracle、DB2為代表大型商業(yè)數(shù)據(jù)庫,應用端對商業(yè)數(shù)據(jù)庫方言、庫內(nèi)計算(存儲過程、觸發(fā)器、函數(shù)等)、生態(tài)工具(SQL優(yōu)化、數(shù)據(jù)集成、管控維護)等,都存在較重依賴。而新技術(shù)棧產(chǎn)品差異明顯,通過應用研發(fā)改造也存在工作量極大的情況。大量基于商業(yè)數(shù)據(jù)庫的開發(fā)邏輯,需改造遷移。一部分需改造適應新架構(gòu)數(shù)據(jù)庫,一部分需考慮在異構(gòu)平臺(如大數(shù)據(jù)平臺、緩存平臺)或應用層解決。部分改造內(nèi)容,不等價實現(xiàn),提高了改造難度。
解決思路
- 輔助開發(fā)平臺
為滿足在新技術(shù)棧下的開發(fā),需秉承在架構(gòu)選型階段談到的數(shù)據(jù)庫訪問標準層的理念,簡化對數(shù)據(jù)庫的使用。但對于重度依賴的原有系統(tǒng),需提供一種方式可完成將舊邏輯向新邏輯的轉(zhuǎn)換,這點是比較難的,通常很難做到完全的等價轉(zhuǎn)換。目前有些工具已經(jīng)能夠?qū)崿F(xiàn)將復雜的庫內(nèi)計算(如存儲過程、觸發(fā)器等)轉(zhuǎn)化為業(yè)務語言實現(xiàn)(如Java),這一方式可大大加速這一過程。當然,更為重要的還是將兩者的差異充分暴露給開發(fā)者,讓大家有的放矢地去改造,明確知道潛在的工作量。更進一步的,可提供一些諸如數(shù)據(jù)集成、數(shù)據(jù)管理、SQL診斷優(yōu)化等工具,方便在改造過程中提高開發(fā)效率。
- 提升兼容性的平臺
可通過兩種手段進一步減少改造工作量,一方面是提升目標平臺對源平臺的兼容性能力,一方面是通過中間層實現(xiàn)必要的改寫,自動完成不兼容改造。針對第二方面的訴求,可以通過第三方平臺實現(xiàn),它可兼容新舊平臺的語法,同時完成等價轉(zhuǎn)化。針對不能轉(zhuǎn)化的部分,給出異常提示。配合前面的改造改寫工具,完成內(nèi)容的修改,不斷收斂兩者的差異。
遷移結(jié)果評估難
對很多新架構(gòu)產(chǎn)品提供的兼容性能力存疑,僅通過語法層面的兼容或少量改造,很難保證語義上的一致性,這會造成未來上線的風險。缺乏有效的評測手段,針對應用遷移前后的語義等價(數(shù)據(jù)一致性)及性能等能做到評估。
?解決思路
- 遷移結(jié)果評估工具
針對遷移后的運行狀態(tài),可提供一種機制能驗證運行結(jié)果,包括但不限于對執(zhí)行結(jié)果一致性的檢查、運行效率的檢查等等。通過這一能力,可有效降低系統(tǒng)上線后的風險。
4. 階段:系統(tǒng)驗證
系統(tǒng)驗證階段,是很多重要系統(tǒng)正式上線前必須經(jīng)歷的階段。通過這一方式,可以大幅降低可能的技術(shù)風險,提高系統(tǒng)上線成功率。
遷移風險高,無法回退
為了在驗證階段,驗證系統(tǒng)是否工作正常,一般需要開發(fā)大量驗證類的代碼。這部分工作主要是為了滿足系統(tǒng)支持新舊技術(shù)棧及必要的對比等工作,但這部分往往工作量巨大。如很多應用常見的數(shù)據(jù)雙發(fā)邏輯,就是通過數(shù)據(jù)雙寫,同步驗證兩邊執(zhí)行結(jié)果。為達到這一訴求,不得不在原有業(yè)務邏輯上開發(fā)兩套適應不同技術(shù)棧的代碼。
解決思路
- 數(shù)據(jù)雙寫平臺
提供基于中間層的輕量級實現(xiàn),在應用側(cè)無需改動或少量改動代碼,即可完成數(shù)據(jù)的雙發(fā)寫入,滿足數(shù)據(jù)同步寫入到異構(gòu)平臺中。為保證數(shù)據(jù)的一致性,還需提供必要的事務性保證,保證異構(gòu)數(shù)據(jù)庫間數(shù)據(jù)的一致性。但當一方平臺出現(xiàn)異常時,應可自動退化,不影響另一套平臺正常使用。從前端業(yè)務可自動感知這一變化,可自動適應這一過程,業(yè)務無感。但系統(tǒng)修復后,又可以手工添加回雙發(fā)狀態(tài)(需提供異常期間的數(shù)據(jù)補償能力)。這一思路的難點在于如何實現(xiàn)應用代碼邏輯不變的情況下,支持寫入異構(gòu)庫。常見的思路是通過將于數(shù)據(jù)庫的交互語言-SQL,從一種方言翻譯到另一種方言,當然前提是語義等價。此時,就可以參考之前在架構(gòu)選型階段談到的-數(shù)據(jù)庫訪問標準層,收斂企業(yè)內(nèi)數(shù)據(jù)庫的訪問,盡量簡化、標準化對數(shù)據(jù)庫的使用,這也是對雙發(fā)驗證階段可執(zhí)行對比的前提。
遷移驗證,無從下手
在驗證階段還有一個比較難的地方在于如何驗證,最好的驗證方式是帶著真實流量的驗證,但同時還需考慮風險問題。如果對業(yè)務訪問做好精準的控制,按需求進行業(yè)務驗證,且還需提供必要的退化能力保證安全。如常用的基于讀寫的分配、基于流量的分發(fā)(甚至基于業(yè)務特征的分發(fā)能力)。
解決思路
- 流量分發(fā)平臺
提供流量分發(fā)平臺,滿足在多平臺在線情況下,根據(jù)策略分配業(yè)務訪問??删珳实乜刂破淞飨?,如痛點中提到的讀寫流量、比例流量亦或是帶有業(yè)務特征的流量。可感知下方物理拓撲變化(甚至是異構(gòu)平臺間的變化),可對應做流量重分發(fā),不影響業(yè)務正常運行。這樣對上層來說,會帶來很大的靈活度,可根據(jù)需要隨時調(diào)整驗證策略,降低驗證期間的風險。
5. 階段:系統(tǒng)上線
遷移窗口短,遷移困難
在系統(tǒng)上線階段,一個突出問題是遷移窗口期的問題,其普遍的上線窗口期很短。這就需要在較短的時間內(nèi)能夠完成數(shù)據(jù)庫間(一般是異構(gòu))的數(shù)據(jù)的遷移工作,同時還需針對遷移后的數(shù)據(jù)提供質(zhì)量對比,能夠保證遷移數(shù)據(jù)是正確的。
解決思路
- 離在線遷移工具
解決這一問題通常采用離在線遷移工具,可提供異構(gòu)數(shù)據(jù)源間的數(shù)據(jù)離在線的遷移能力??沙浞掷梦锢碣Y源,采用并行處理技術(shù)提升遷移效率,滿足時間窗口。對于海量數(shù)據(jù)遷移,通常是離線與在線相結(jié)合,即將靜態(tài)數(shù)據(jù)通過離線方式遷移,針對動態(tài)(活躍)數(shù)據(jù)采取在線遷移方式,通過這一方法盡量壓縮遷移窗口。此外,還需提供數(shù)據(jù)對比能力,可根據(jù)用戶需要進行比對。這里面臨兩個難點,一是如何提升對比效率滿足海量數(shù)據(jù)對比;二是如何實現(xiàn)動態(tài)變化的數(shù)據(jù)對比。針對前者,通常的解決思路是可以讓用戶選擇對比方法(算法),從簡單計數(shù)、部分采樣、統(tǒng)計報表或復雜算法。針對后者,可通過流式窗口比較的方法,不斷擬合趨近于實時結(jié)果。
- 新上系統(tǒng)不穩(wěn)定
系統(tǒng)上線后的穩(wěn)定性問題,也是用戶最為關(guān)心的。作為新產(chǎn)品、新架構(gòu),很難保證上線后一定不出問題。雖然可通過充分的測試、并行驗證等多種手段盡量減少這個出現(xiàn)問題的風險,但顯然無法完全避免。比較好的方式是提供一種能力,根據(jù)可能出現(xiàn)的運行問題,通過一些手段可以盡量減少問題影響范圍,恢復業(yè)務。
解決思路
- 流量治理平臺
提供數(shù)據(jù)庫流量的統(tǒng)一接入,并實現(xiàn)治理能力。通過多種手段(基于標簽、SQL文本、用戶名、來源IP等)實現(xiàn)對SQL流量的精準控制。例如針對低效SQL,可實現(xiàn)熔斷、限流;針對特定SQL,提供黑白名單;為滿足問題排查提供全量SQL的審計能力,可做到事后追蹤等。
- 系統(tǒng)逃生平臺(方案)
為防止出現(xiàn)系統(tǒng)性風險或全局邏輯性錯誤,需提供一種異構(gòu)“逃生”方案。所謂異構(gòu),一定是一種有別于現(xiàn)有技術(shù)棧的平臺或方案。兩套平臺間的數(shù)據(jù)是需要做到可控同步的,即可根據(jù)需要選擇實時同步、延遲同步和人工同步。同時在數(shù)據(jù)之上,還需提供切換的能力,可滿足在異常情況下短時可切換。