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

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

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

1. T-SQL轉(zhuǎn)換

2. 自動(dòng)化測(cè)試數(shù)據(jù)的遷移

3. 高效加載測(cè)試數(shù)據(jù)

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

1. 交付計(jì)劃

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

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

交付計(jì)劃

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

T-SQL的形態(tài)

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

1. XML資源文件(resx)中的完整T-SQL

2. 代碼邏輯中的T-SQL片段

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

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

1. 采用客戶開發(fā)人員熟悉的XML資源文件機(jī)制，降低理解和推廣的成本。

2. 不引入額外的工具庫即可達(dá)到切換SQL方言的功能，減少了改造的隱形成本，如升級(jí)老舊的庫、框架帶來的連鎖升級(jí)問題。

3. Resx文件之間的單向覆蓋，減少了需維護(hù)SQL的總數(shù)量，同時(shí)方便擴(kuò)展至其它方言SQL。

4. 對(duì)原始SQL文件不做改動(dòng)，從而避免對(duì)運(yùn)行中的業(yè)務(wù)造成影響。

5. 運(yùn)行時(shí)的SQL方言由用戶數(shù)據(jù)動(dòng)態(tài)決定，待用戶數(shù)據(jù)全部遷移后，原始T-SQL和原始Embeded T-SQL可以直接刪除，無須再修改代碼。

T-SQL的數(shù)量

如果SQL的總數(shù)量較少，可以考慮手動(dòng)改寫，因?yàn)殚_發(fā)自動(dòng)化工具不一定劃算。

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

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

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

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

• 定下測(cè)試數(shù)據(jù)的單一來源 (SSOT)。

• 開發(fā)或者使用一個(gè)命令行工具，配合流水線自動(dòng)轉(zhuǎn)換測(cè)試數(shù)據(jù)文件。

• 改造已有的自動(dòng)化測(cè)試，可以通過參數(shù)決定使用哪種數(shù)據(jù)庫文件運(yùn)行自動(dòng)化測(cè)試。

• 配合流水線在新數(shù)據(jù)庫系統(tǒng)上運(yùn)行已有全部測(cè)試用例。

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

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

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

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

回收存儲(chǔ)空間

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

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

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

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