作者 |  何蔚

一、背景

在這個數(shù)字化時代，企業(yè)的復(fù)雜業(yè)務(wù)邏輯運(yùn)轉(zhuǎn)需要依賴復(fù)雜的業(yè)務(wù)服務(wù)來完成。這些業(yè)務(wù)服務(wù)通常會經(jīng)歷變更、拆分、合并和上云等過程，最終與一些商業(yè)軟件和云平臺深度融合。

以之前服務(wù)過的客戶為例，他們的系統(tǒng)多年來一直在.Net生態(tài)和Azure云上運(yùn)行，并與微軟系數(shù)據(jù)庫系統(tǒng)進(jìn)行綁定。但是，隨著市場的變化，客戶想要擺脫對單一商業(yè)軟件和云平臺的依賴，以便在續(xù)約談判中爭取更多優(yōu)惠，而不是被廠商隨意操縱。他們面臨的其中一個挑戰(zhàn)是必須將數(shù)據(jù)庫系統(tǒng)遷移到PostgreSQL，以節(jié)省許可費(fèi)用并遷移到更優(yōu)惠的云平臺。

二、技術(shù)挑戰(zhàn)

在過去十幾年中，該客戶在SQL Server積累了大量的用戶數(shù)據(jù)、系統(tǒng)數(shù)據(jù)，業(yè)務(wù)代碼和測試代碼也是面向SQL Server和SQL Server Compact（SQL CE）編寫的。我們?yōu)榭蛻羰崂沓鋈缦碌募夹g(shù)挑戰(zhàn)：

• T-SQL轉(zhuǎn)換
• 自動化測試數(shù)據(jù)的遷移
• 高效加載測試數(shù)據(jù)

三、T-SQL轉(zhuǎn)換

T-SQL轉(zhuǎn)換的具體策略需要從以下幾個角度來綜合考量：

• 交付計劃
• T-SQL的形態(tài)
• T-SQL的數(shù)量

1.交付計劃

業(yè)務(wù)側(cè)的用戶數(shù)據(jù)是否迭代遷移、開發(fā)側(cè)的代碼能否迭代修改，將會直接決定T-SQL轉(zhuǎn)換的交付計劃，也會決定有幾種方言的SQL會同時存在。

以我們的客戶為例，各個產(chǎn)品線十多年的代碼混雜在一起，難以清晰拆分。此外，用戶數(shù)據(jù)量龐大，遷移至新數(shù)據(jù)庫系統(tǒng)需要耗費(fèi)數(shù)月時間。因此，我們采取了一次性交付代碼的策略，并同時支持對兩種數(shù)據(jù)庫系統(tǒng)（多方言SQL）的訪問。

2.T-SQL的形態(tài)

以我們的客戶為例，T-SQL以兩種形態(tài)存在于代碼庫中：

• XML資源文件(resx)中的完整T-SQL
• 代碼邏輯中的T-SQL片段

為了實現(xiàn)多方言SQL的切換并根據(jù)用戶數(shù)據(jù)動態(tài)訪問不同的數(shù)據(jù)庫系統(tǒng)，我們基于.Net的XML資源文件設(shè)計了以下流程。

在客戶已有上下文和開發(fā)流程下，這個T-SQL改寫流程具有以下優(yōu)點：

• 采用客戶開發(fā)人員熟悉的XML資源文件機(jī)制，降低理解和推廣的成本。
• 不引入額外的工具庫即可達(dá)到切換SQL方言的功能，減少了改造的隱形成本，如升級老舊的庫、框架帶來的連鎖升級問題。
• Resx文件之間的單向覆蓋，減少了需維護(hù)SQL的總數(shù)量，同時方便擴(kuò)展至其它方言SQL。
• 對原始SQL文件不做改動，從而避免對運(yùn)行中的業(yè)務(wù)造成影響。
• 運(yùn)行時的SQL方言由用戶數(shù)據(jù)動態(tài)決定，待用戶數(shù)據(jù)全部遷移后，原始T-SQL和原始Embeded T-SQL可以直接刪除，無須再修改代碼。

3.T-SQL的數(shù)量

如果SQL的總數(shù)量較少，可以考慮手動改寫，因為開發(fā)自動化工具不一定劃算。

在我們的案例中，需要在一個交付周期內(nèi)轉(zhuǎn)換超過600個SQL，長度甚至達(dá)到數(shù)十行，如果手動改寫不僅費(fèi)時，而且容易出錯。因此，我們團(tuán)隊為客戶量身定制了轉(zhuǎn)換工具，集成了第三方開源庫JOOQ。該工具可以直接讀取資源文件中的SQL語句，自動逐條轉(zhuǎn)換，并生成PostgreSQL版的資源文件。開發(fā)人員將代碼中的SQL整理到資源文件后，使用該工具轉(zhuǎn)換SQL的平均速度可以達(dá)到每條1-2秒。

特別強(qiáng)調(diào)，在企業(yè)中使用第三方開源庫和框架，必須根據(jù)開源許可證確認(rèn)其允許商業(yè)使用。否則，將會給企業(yè)帶來法律風(fēng)險。

四、自動化測試數(shù)據(jù)的遷移

完善的自動化測試是一張安全網(wǎng)，幫助企業(yè)第一時間發(fā)現(xiàn)破壞性修改。當(dāng)SQL從一種方言轉(zhuǎn)換到另一種方言之后，基于舊數(shù)據(jù)庫系統(tǒng)運(yùn)行的測試，對于新方言SQL就不再適用。為多種數(shù)據(jù)庫系統(tǒng)而維護(hù)幾套業(yè)務(wù)邏輯完全相同的測試，會極大增加測試的維護(hù)成本。而且隨著時間的推移，多套測試數(shù)據(jù)將會變得不再完全一致。

想要將同一套測試運(yùn)行在兩種不同的數(shù)據(jù)庫系統(tǒng)上面，并且只維護(hù)一套測試數(shù)據(jù)，可以嘗試下面的方法：

• 定下測試數(shù)據(jù)的單一來源 (SSOT)。
• 開發(fā)或者使用一個命令行工具，配合流水線自動轉(zhuǎn)換測試數(shù)據(jù)文件。
• 改造已有的自動化測試，可以通過參數(shù)決定使用哪種數(shù)據(jù)庫文件運(yùn)行自動化測試。
• 配合流水線在新數(shù)據(jù)庫系統(tǒng)上運(yùn)行已有全部測試用例。

五、高效加載測試數(shù)據(jù)

為了避免因數(shù)據(jù)更改導(dǎo)致的測試隨機(jī)失敗，集成測試和端到端測必須清理/恢復(fù)被修改的測試數(shù)據(jù)。對于像 SQL CE 這樣的文件型數(shù)據(jù)庫系統(tǒng)，每個測試套件復(fù)制數(shù)據(jù)文件的時間成本是可以接受的。但是，對于像 PostgreSQL 這樣的服務(wù)器數(shù)據(jù)庫系統(tǒng)，每個測試套件導(dǎo)入數(shù)據(jù)文件的時間成本比簡單復(fù)制文件更長，累積成本變得不可接受。

1.使用模板數(shù)據(jù)庫

為了加速測試，我們在PostgreSQL上采用模板數(shù)據(jù)庫(Template Database)。同時把數(shù)據(jù)文件的Hash片段作為Database的名字，測試框架代碼就能判斷這份數(shù)據(jù)文件是否已經(jīng)被導(dǎo)入過。倘若已導(dǎo)入，則跳過導(dǎo)入步驟，直接在PostgreSQL內(nèi)復(fù)制一份數(shù)據(jù)庫供測試使用。

更進(jìn)一步，對于只做查詢的測試用例，甚至可以跳過復(fù)制數(shù)據(jù)庫，在“模板數(shù)據(jù)庫”上直接運(yùn)行測試用例，這樣能進(jìn)一步減少準(zhǔn)備數(shù)據(jù)的時間開銷。缺點就是需要謹(jǐn)慎維護(hù)“只讀”測試用例，避免混入會修改數(shù)據(jù)的測試用例。

2.回收存儲空間

隨著測試的運(yùn)行，廢棄的測試數(shù)據(jù)會占用越來越多的存儲空間。采取什么樣的方法進(jìn)行清理，可以依據(jù)測試數(shù)據(jù)庫系統(tǒng)是統(tǒng)一維護(hù)，還是安裝在測試Agent上來決定。

針對統(tǒng)一維護(hù)的測試數(shù)據(jù)庫系統(tǒng)，可以創(chuàng)建一條夜間運(yùn)行流水線去清除特定名稱的數(shù)據(jù)庫。也可以讓每個測試集在測試完成時刪除各自用過的數(shù)據(jù)庫。

針對安裝在測試Agent上的測試數(shù)據(jù)庫系統(tǒng)，可以創(chuàng)建CronJob來清除數(shù)據(jù)庫。如果測試Agent是早上自動創(chuàng)建、晚上自動銷毀的虛擬機(jī)，則無須引入清理步驟。

六、寫在最后

更換大型系統(tǒng)所使用的數(shù)據(jù)庫系統(tǒng)，注定不是簡單的事情。不僅要考慮框架、代碼等具體的技術(shù)、基礎(chǔ)設(shè)施，還要考慮測試、甚至企業(yè)部門之間的配合等諸多方面。具體的策略、步驟、任務(wù)數(shù)量多少，都是由企業(yè)和系統(tǒng)所處情況來決定的。