業務系統設計要考慮的問題(一)分散式資料存放區設計

近一段時間，公司上線了一個全國性的業務系統，這個系統功能覆蓋了全部商務程序，使用者包括全國32個分公司，可謂是一個把所有雞蛋放在同一個藍子裡的巨大系統，上線過程多麼辛苦不說了，只說上線後的一些問題所帶給我的一些關於業務系統設計啟發。

 

一、應該考慮分散式資料存放區設計

企業內的生產線類系統，一開始都對效能考慮不足，在設計中基本上都採用單一資料庫來支援業務，隨著業務規模的擴大，對資料庫效能要求提升時，企業會採購更昂貴的軟硬體產品來支援更大的訪問壓力，當實在無法緩解時，會考慮在資料庫端採用分區等方法來分散硬體壓力，但是資料庫本身從邏輯上還是單一的執行個體。

由於所有資料服務都在集中在少數的關鍵硬體上，就會造成幾方面的問題，一是極高效能的硬體成本太高，二是所有的雞蛋放在了同一個籃子裡，服務故障造成的災難影響面太大，三是硬體的升級總是跟不上資料量、訪問量的提升速度，整個系統總是慢吞吞的。

 

要解決這個問題，可以採用的第一個設計思路，是按業務領域劃分為若干個系統，每個系統之間再做服務、資料、流程的整合。這種思路已經廣為採用，優劣各人自知，不再多說，本文想討論的是另一個更為大膽激進的想法：分散式客戶資料。

Facebook、twitter、微博這種社交網站面對的訪問量遠遠大於公司專屬應用程式，與公司專屬應用程式相比而言，社交網站還要考慮如“突然大批的使用者湧來怎麼辦？”、“某個普通使用者突然火了怎麼辦？”這種突發效能要求的處理。

他們解決方案是在軟體邏輯上就支援分散儲存，即建立數量不限的資料庫，資料被按一定的策略分散儲存在不同的資料庫硬體裡，這樣在訪問不同的資料時，可以按策略來判斷應該去哪個資料庫裡去尋找資料。由於資料庫是獨立的，只需要增加一些低端的硬體，就可以達到平滑升級效能的目的。

為了與邏輯上集中物理上分布的表分區等技術相區別，我以“分散”一詞來表示這種在邏輯上的多數儲存方案。

資料分散的策略有哪些？主要是三種：

一是按業務（產品）領域劃分。這種方式其實與分為多個子系統沒有區別，但主要業務一般也是資料量最大、訪問量最大的，按這種劃分的話，可能還是無法解決最主要的問題。

二是按業務時間劃分。這種方法對於一些偏重近期的業務會有作用，如股票交易，但是對於依靠長期資訊的業務則不實用，比如長期保險業務中，保單生效越長，反而越有可能發生理賠、給付等，而且在這些業務處理過程中，要依據業務對象的所有資訊進行處理，如果資料是按時間分散儲存的，軟體系統邏輯上則有較大幅度的複雜度增加。

三是按主業務對象的“群落”來劃分。比如把客戶分群，某一個客戶的所有相關商務資訊（比如他的博文、有關評論等）不可分散，按群放在不同的物理資料來源中。這樣，當系統存取某個客戶的資訊時，可以按群落找到客戶所在的物理資料庫，之後的邏輯則與集中式資料庫的處理大體類似。

如何得知客戶所在群落呢？對於不存在個別突發的訪問增長的系統，可以暫時採用平均式的分群方案，用某種約定演算法求得客戶群號，比如說按客戶證件號的前幾位。但是這種分類一但固定了就不容易更改，例如，一開始用證件號第一位平均分為10個資料庫，但如果業務增加到10個資料庫也頂不住時，要修改這個分群就很困難了。

另一個辦法就是採用一個中樞資料庫來記錄使用者所在群落，這個中樞資料庫裡只需要一張表、最少三個欄位就夠了——使用者標識、群落號或物理資料來源地址、可訪問狀態。當系統要開始處理一個使用者的業務時，需要向這個資料庫進行詢問，得到群號後就可以轉向所在資料來源進行業務處理。

這種辦法的好處很大，比如微博這種社會網路上，常常會有人突然火了，前一天還是無名小卒，一百多個粉絲，每天兩篇微博，被與其他五十萬同樣的屁民放在某個刀片機上的mysql裡默默無聞著，誰知道第二天他可能運氣太好（或是運氣太壞）趕上了個什麼熱點時件，突然有幾十萬人來關注他，那個機器立即就頂不住了。在這種情況下，就用資料移轉程式把這個人的有關資訊全部移到另一台小型機上去跑，遷移完成之後修改中樞資料庫，壓力立即就調整了。

這種遷移甚至可以做成自動的，發現哪個使用者火了就自動啟動，按策略移到預備的空閑計算資源上去。

這樣的系統架構下，壓力最大的地方就成了中樞資料庫，但是第一，這個資料庫中裡沒有業務資料，資料結構很簡單，極容易最佳化索引與效能，就是買好硬體，所需的投資也有限。其次，使用者分群策略可以結合關聯規則與特殊指定分群，中樞資料庫可以只儲存特殊指定分群的記錄，如果沒有記錄則是按關聯規則（證件號第一位？）來分。再次，應用伺服器也可以按緩衝訪問過的使用者分群資訊，只在按關聯規則斷言資料來源後訪問失敗、而且沒有緩衝過或按緩衝訪問失敗的情況下才訪問中樞資料庫，得到使用者的最新群落位置。

不可否認，這種模式會對全域性資料訪問需求造成技術困難，例如需要統計全系統的一些資料時，就需要協調所有的資料庫進行分別運算，最後再把結果匯總，這肯定需要一些全新的開發與營運架構來支援，但對於巨量資料的系統來說，統計結果的絕對精確性已經讓位於系統可以正常啟動並執行要求。