微服務架構下需要什么樣的數據庫
“微服務架構下需要什么樣的數據庫?”作為一個數據庫開發人員，深知應用技術和數據庫技術的緊密關系，自從知道微服務這個概念以來，這個問題就一直縈繞在我的腦海中。后來參與一個大型的金融企業業務上云微服務改造項目，并親自完成了數據層的改造，這才對微服務對數據庫技術的影響有了直觀的認識。
因為涉及到企業隱私，就以網上比較通用的一個業務模型舉例。傳統企業應用服務架構采用的是“巨石”架構，也就是將所有“大腦”集中在一起，以 CS 架構為代表，將所有的邏輯放在一個應用中。在這種架構下，所有業務模塊的數據都集中到一個數據庫中，即使在最開始的業務設計時進行了比較清晰的表結構劃分，但獲取數據最方便的方式就是直接關聯表數據。一般的開發團隊也不會對跨模塊的信息傳遞做硬性規定，只要性能能抗的住，SQL語句就沒問題，一旦有問題DBA給抓出來再打回去重改。
傳統應用的巨石架構
久而久之，數據庫的表越來越多，越來越復雜，最后可能沒有一個人能說清楚每個表都是干什么的;SQL語句可能也越寫越復雜，兩個表關聯、三個表關聯，套上幾層子查詢... 不久數據規模進一步增大，SQL已經不能通過調優解決了。這時一般的做法是，再換上一套更新的小機，再加上最新的高端陣列，好像又可以運轉飛快了。
如果世界沒有什么變化，這一切看起來也不錯，傳統三件套價格雖高，但還算非常穩定。可是傳統業務也都逐漸由各地分布走向集中管理和運維，而且面向互聯網的業務也逐漸增多，這樣對系統提出了新的要求，總結起來就是4S [1]，
微服務
4S本身有很廣的內涵，具體到數據庫技術層面可以總結為：
“Scale”系統可以隨數據量的急劇增加要能夠隨需伸縮;
“Speed”服務請求響應時延要低;
“Safety”服務質量和穩定性要求高;
“Sharing”系統資源可以共享;
微服務架構
雖然應用做了微服務拆分，但并不代表數據規模一定會小，某些服務(如訂單服務)的數據庫由于數據逐漸累積，會逐漸膨脹，超出單個數據庫實例的管理能力;其次互聯網類應用訪問量會隨著某些活動而發生劇烈波動，比如在雙11、618促銷中訪問量通常是平時的2倍以上，需要提前對后臺處理能力進行擴容，所以微服務會部署到企業私有云或者公有云平臺上，數據庫自然也需要支持云平臺管控。然后各種微服務的數據類型，業務模型都有差異，以前在一個庫里都只能遵守同樣的數據分片方案，現在拆分后，完全可以根據業務特點采用不同的數據分片方案。另外一個具備企業級性能、可靠性數據庫引擎也是必不可少的。最后，如果要支持更高的可用性，需要采用多中心部署，為了在不降低性能的情況下保證RPO=0，支持分布式一致性協議必要的。
可見微服務時代，業務對數據庫的要求不是更低了而是更高了，需要這樣的一個數據庫：
1、支持云化部署或者多租戶管理能力;(“Sharing”)
2、支持在線水平擴容和水平縮容;(“Scale”)
3、支持多種數據分片方案(哈希、列表、范圍)，這樣可以根據業務特點靈活選擇，保障性能最優;(“Speed”)
4、支持完美分片和兩階段事務自適應，保障性最優;(“Speed”)
5、企業級穩定及高性能的數據庫引擎;(“Safety”\“Speed”)
6、通過分布一致性協議支持多副本在多地多中心靈活部署;(“Safety”)
