作者 |  何蔚

一、背景

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

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

二、技術挑戰

在過去十幾年中，該客戶在SQL Server積累了大量的用戶數據、系統數據，業務代碼和測試代碼也是面向SQL Server和SQL Server Compact（SQL CE）編寫的。我們為客戶梳理出如下的技術挑戰：

• T-SQL轉換
• 自動化測試數據的遷移
• 高效加載測試數據

三、T-SQL轉換

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

• 交付計劃
• T-SQL的形態
• T-SQL的數量

1.交付計劃

業務側的用戶數據是否迭代遷移、開發側的代碼能否迭代修改，將會直接決定T-SQL轉換的交付計劃，也會決定有幾種方言的SQL會同時存在。

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

2.T-SQL的形態

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

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

為了實現多方言SQL的切換并根據用戶數據動態訪問不同的數據庫系統，我們基于.Net的XML資源文件設計了以下流程。

在客戶已有上下文和開發流程下，這個T-SQL改寫流程具有以下優點：

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

3.T-SQL的數量

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

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

特別強調，在企業中使用第三方開源庫和框架，必須根據開源許可證確認其允許商業使用。否則，將會給企業帶來法律風險。

四、自動化測試數據的遷移

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

想要將同一套測試運行在兩種不同的數據庫系統上面，并且只維護一套測試數據，可以嘗試下面的方法：

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

五、高效加載測試數據

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

1.使用模板數據庫

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

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

2.回收存儲空間

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

針對統一維護的測試數據庫系統，可以創建一條夜間運行流水線去清除特定名稱的數據庫。也可以讓每個測試集在測試完成時刪除各自用過的數據庫。

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

六、寫在最后

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