“微服務架構下需要什么樣的數(shù)據(jù)庫?”作為一個數(shù)據(jù)庫開發(fā)人員，深知應用技術和數(shù)據(jù)庫技術的緊密關系，自從知道微服務這個概念以來，這個問題就一直縈繞在我的腦海中。后來參與一個大型的金融企業(yè)業(yè)務上云微服務改造項目，并親自完成了數(shù)據(jù)層的改造，這才對微服務對數(shù)據(jù)庫技術的影響有了直觀的認識。

[[272285]]

因為涉及到企業(yè)隱私，就以網(wǎng)上比較通用的一個業(yè)務模型舉例。傳統(tǒng)企業(yè)應用服務架構采用的是“巨石”架構，也就是將所有“大腦”集中在一起，以 CS 架構為代表，將所有的邏輯放在一個應用中。在這種架構下，所有業(yè)務模塊的數(shù)據(jù)都集中到一個數(shù)據(jù)庫中，即使在最開始的業(yè)務設計時進行了比較清晰的表結(jié)構劃分，但獲取數(shù)據(jù)最方便的方式就是直接關聯(lián)表數(shù)據(jù)。一般的開發(fā)團隊也不會對跨模塊的信息傳遞做硬性規(guī)定，只要性能能抗的住，SQL語句就沒問題，一旦有問題DBA給抓出來再打回去重改。

傳統(tǒng)應用的巨石架構

久而久之，數(shù)據(jù)庫的表越來越多，越來越復雜，最后可能沒有一個人能說清楚每個表都是干什么的;SQL語句可能也越寫越復雜，兩個表關聯(lián)、三個表關聯(lián)，套上幾層子查詢... 不久數(shù)據(jù)規(guī)模進一步增大，SQL已經(jīng)不能通過調(diào)優(yōu)解決了。這時一般的做法是，再換上一套更新的小機，再加上最新的高端陣列，好像又可以運轉(zhuǎn)飛快了。

如果世界沒有什么變化，這一切看起來也不錯，傳統(tǒng)三件套價格雖高，但還算非常穩(wěn)定。可是傳統(tǒng)業(yè)務也都逐漸由各地分布走向集中管理和運維，而且面向互聯(lián)網(wǎng)的業(yè)務也逐漸增多，這樣對系統(tǒng)提出了新的要求，總結(jié)起來就是4S [1]，

微服務

4S本身有很廣的內(nèi)涵，具體到數(shù)據(jù)庫技術層面可以總結(jié)為：

“Scale”系統(tǒng)可以隨數(shù)據(jù)量的急劇增加要能夠隨需伸縮;

“Speed”服務請求響應時延要低;

“Safety”服務質(zhì)量和穩(wěn)定性要求高;

“Sharing”系統(tǒng)資源可以共享;

微服務架構

雖然應用做了微服務拆分，但并不代表數(shù)據(jù)規(guī)模一定會小，某些服務(如訂單服務)的數(shù)據(jù)庫由于數(shù)據(jù)逐漸累積，會逐漸膨脹，超出單個數(shù)據(jù)庫實例的管理能力;其次互聯(lián)網(wǎng)類應用訪問量會隨著某些活動而發(fā)生劇烈波動，比如在雙11、618促銷中訪問量通常是平時的2倍以上，需要提前對后臺處理能力進行擴容，所以微服務會部署到企業(yè)私有云或者公有云平臺上，數(shù)據(jù)庫自然也需要支持云平臺管控。然后各種微服務的數(shù)據(jù)類型，業(yè)務模型都有差異，以前在一個庫里都只能遵守同樣的數(shù)據(jù)分片方案，現(xiàn)在拆分后，完全可以根據(jù)業(yè)務特點采用不同的數(shù)據(jù)分片方案。另外一個具備企業(yè)級性能、可靠性數(shù)據(jù)庫引擎也是必不可少的。最后，如果要支持更高的可用性，需要采用多中心部署，為了在不降低性能的情況下保證RPO=0，支持分布式一致性協(xié)議必要的。

可見微服務時代，業(yè)務對數(shù)據(jù)庫的要求不是更低了而是更高了，需要這樣的一個數(shù)據(jù)庫：

1、支持云化部署或者多租戶管理能力;(“Sharing”)

2、支持在線水平擴容和水平縮容;(“Scale”)

3、支持多種數(shù)據(jù)分片方案(哈希、列表、范圍)，這樣可以根據(jù)業(yè)務特點靈活選擇，保障性能最優(yōu);(“Speed”)

4、支持完美分片和兩階段事務自適應，保障性最優(yōu);(“Speed”)

5、企業(yè)級穩(wěn)定及高性能的數(shù)據(jù)庫引擎;(“Safety”\“Speed”)

6、通過分布一致性協(xié)議支持多副本在多地多中心靈活部署;(“Safety”)