雲數據庫架構演進與實踐
微服務，也就是一種面向服務的，有特定邊界的松散耦合的架構。
主要特點包括，每一個微服務是一個獨立的自治系統，可以不依賴外部組件獨立運行；對應用只暴露接口，用戶可以靈活的調整過每個微服務的使用；業務粒度足夠小。
在企業架構“雲化”的過程中，數據庫的雲化是最為重要也是難度較大的一個部分。數據庫雲平臺（dbPaaS）是一類支持彈性擴張、多租戶、自我管理、並能夠運行在雲服務提供商的基礎設施（IaaS）之上的數據庫管理系統（DBMS）或存儲管理系統。
根據Gartner報告預測，數據庫雲平臺市場份額將會在下一個五年中翻倍，而70%的用戶將開始使用dbPaaS數據庫雲平臺。因此，為了滿足各類應用程序對數據庫雲平臺的需求，同時為了減少私有雲部署中對大量不同類型數據存儲產品的運維復雜性，數據庫的架構演進將是未來十年數據庫轉型的主要方向之一。
雲數據庫的技術需求
在業務和應用進行“雲化”的過程中，雲數據庫因為在整體架構中的重要地位，在雲化改造中的重要性不言而喻。雲數據庫的核心需求有一下幾點，主要有：
?彈性擴張能力：數據庫容量需要根據業務彈性擴展，滿足不同業務的容量需求；
?彈性部署與隨需應變能力：除了數據庫的存儲，其他數據庫功能也需要根據應用的需求，進行彈性的部署調整；
?數據可靠性與服務持續能力：數據的可靠安全，全時在線是所有業務的必須要求；
?計算存儲分離：將計算和存儲資源靈活配置，既可以選擇多種計算方式也可以同時對應多種存儲方式，滿足更多業務需求；
?多模式存儲能力：結構化、非結構化、半結構化和圖等多類型數據的存儲；
?自我管理能力：提供零停機維護、持續集成、以及滾動升級能力，提升開發人員效率；
?是否滿足特定應用場景：針對特定場景的可插拔組件或工具；
?監管與安全：滿足監管的要求，保證數據的安全。
雲數據庫需要滿足這些技術要求，除了在功能上的具體提升，在整體架構上更需要進行升級和“進化”。
雲數據庫架構方向
雲數據庫架構是其能否承載應用架構“雲化”的關鍵點，隨著技術和業務的發展，雲數據庫的架構出現了幾個主要的發展方向：
?在dbPaaS平臺中，計算-存儲層分離將會成為主流技術方向。通過將協議解析、計算等模塊與底層存儲解耦，數據庫雲平臺將存儲層進行分片以實現存儲的彈性水平擴張，同時通過計算層的無狀態設計允許計算層通過增加節點數量線性提升計算能力，已達到整個數據庫雲平臺的彈性水平擴張。
?雲數據庫平臺將會提供多種混合模式的數據服務 – 關系型與非關系型。該模式使用戶能夠在同一平臺中結合不同數據存儲類型的特點，為新一代IT應用系統提供混合數據存儲解決方案。
?更符合微服務業務架構的要求，微服務要求各個服務模塊之間盡量松耦合和可獨立擴展。因此對於數據庫，也同樣會針對不同的業務，進行不同側重的配置，無論是傳統的“讀寫分離”或者現在流行的HTAP都是圍繞這個要求展開的。
針對這幾個主要的發展方向，我們就將詳細來探討雲數據庫的幾個重要技術特點。
1）存儲-SQL 分離
針對雲數據庫的需求和架構方向，一種新的數據庫架構也在漸漸成為主流，也就是數據庫的 “存儲-SQL分離”架構。
存儲-SQL分離架構，即指數據庫的存儲引擎和SQL引擎兩部分互相松耦合獨立工作的架構。通常這一架構，分為存儲、SQL和元數據 三個部分。
?存儲層：即數據庫的存儲引擎，存儲引擎負責處理數據的存儲管理。同時包含路由及事務控制，保障數據的ACID特性。此外，存儲層還應還具備索引、查詢條件過濾、排序等一系列功能。
?SQL層：SQL層主要負責處理SQL請求，上層直接面對應用程序，將應用程序的訪問請求分發給存儲層，並且接受存儲層返回的數據結果。
?元數據區：元數據區負責存儲整個數據庫的所有元數據信息。
典型的雲數據庫架構示意
對於這一架構，其實MySQL數據庫當前的架構是有一些類似的。
MySQL數據庫的SQL、存儲分離的架構，在架構較為靈活，而其開源的生態也支持將不同的產品、引擎和工具進行充分的對接。在存儲引擎的架構上，插件式的存儲引擎架構將查詢處理和其它的系統任務以及數據的存儲提取相分離。這種架構可以根據業務的需求和實際需要選擇合適的存儲引擎。
MySQL數據庫整體技術模塊架構
如上圖所示，MySQL 的存儲引擎可以掛載多種不同的產品，每個引擎都能提供不同的技術特性。其中包括InnoDB、MyISAM等架構。
存儲與SQL分離的架構，目前在數據庫業界十分流行，AWS的Aurora數據庫在SQL訪問上也采用了類似的架構。SequoiaDB 3.0 目前在MySQL兼容上，主要也是采取“SQL-存儲分離“的架構。
SequoiaDB 3.0 MySQL 兼容邏輯架構
SequoiaDB 3.0使用了MySQL數據庫原生的SQL解析器，天然支持MySQL協議並可以做到100%語法兼容。在該架構中，MySQL協議解析層作為SQL解析和分發的角色，直接面對應用程序，每一個MySQL服務的接入節點都是一個獨立支持讀寫操作的MySQL進程。而數據存儲和管理層，則完全由巨杉數據庫的分布式數據庫引擎實現。簡單來說，SequoiaDB 3.0作為MySQL的InnoDB替換引擎，在天然支持MySQL的全部語法和功能的同時，提供了數據庫存儲層彈性擴張的能力。
2）多模Multi-Model
企業使用雲數據庫對接的應用越來越多，需求多種多樣，傳統的做法是在dbPaaS裏面提供十幾個不同的數據庫產品分別應對各種需求，這樣的方法在系統增加後，整體維護性和數據一致性管理成本很高，會影響到整個系統的使用。
雲數據庫的“多模”示意圖
為了實現業務數據的統一管理和數據融合，新型數據庫需要具備多模式（Multi-Model）數據管理和存儲的能力。數據庫多模Multi-Model是指同一個數據庫支持多個存儲引擎，可以同時滿足應用程序對於結構化、半結構化、非結構化數據的統一管理需求。
通常來說，結構化數據特指表單類型的數據存儲結構，典型應用包括銀行核心交易等傳統業務；而半結構化數據則在用戶畫像、物聯網設備日誌采集、應用點擊流分析等場景中得到大規模使用；非結構化數據則對應著海量的的圖片、視頻、和文檔處理等業務，在金融科技的發展下增長迅速。
多模式數據管理能力，使得金融級數據庫能夠進行跨部門、跨業務的數據統一存儲與管理，實現多業務數據融合，支撐多樣化的金融服務。
在架構上，剛剛提到的多模Multi-model也是針對雲數據庫需求的，則使得數據庫使用一套數據管理體系可以支撐多種數據類型，因此支持多種業務模式，大大降低使用和運維的成本。
3）災備和多活
對於應用程序來說，開發人員並不希望在設計應用的過程當中花費大量的精力來考慮底層數據高可用、災備與多活時應用的切換邏輯。一般來說，一個成熟的dbPaaS層應當盡可能將底層的數據多副本同步、災難切換、高可用接管等一系列操作進行封裝，對於應用程序做到完全透明。
在傳統的應用程序開發中，開發者使用中間件容器對數據源進行配置，底層使用F5或其他虛擬IP地址對多個數據源進行封裝。但是，在雲化的演變過程中，底層的數據庫從單一節點向分布式節點過渡，對於上層的應用程序一方面希望盡可能減少應用程序設計時對分庫分表的依賴，另一方面更希望在數據節點切換，甚至數據中心災難接管的過程當中做到應用透明無感知。
SequoiaDB 3.0則引入了異地多活的架構，應用程序可以從任意接入節點以讀寫的方式訪問本地數據庫。在數據讀寫的過程當中，巨杉數據庫能夠從底層有效地進行數據一致性控制，對多個地區本地寫入的數據進行遠程復制，確保多個站點所讀寫的數據完全一致。
另外，災難發生時巨杉數據庫提供對應用程序透明的數據切換與接管機制，動態調整底層數據分布拓撲邏輯，能夠動態有效地排除故障數據中心內的節點，做到其他站點無感知地繼續提供數據服務。
多活相比於傳統的高可用來說，不僅在性能和安全性上實現了更大的提升，而這一架構也能在多活數據中心中充分的應用軟硬件設備，減少冗余。
雲數據庫架構優勢
在技術驅動的需求下，雲數據庫架構具備了幾項主要的業務價值：
?無需分庫分表：此前，一種數據庫分布式改造的方向是關系型數據庫往分布式架構改造，MySQL分庫分表就是其中一種方案。如今，存儲-SQL分離的架構，在數據存儲層已經實現原生分步實施，就避免了復雜冗長的“分庫分表”方案。
?靈活支撐業務需求：存儲和SQL層都可以實現服務、存儲的彈性調整，靈活地支撐業務的需求。
?多存儲引擎兼容：由於SQL和存儲層的分離，在保持SQL接口不變的情況下，底層存儲引擎可以支撐多個不同引擎，實現多種數據引擎的同時兼容。
?完全兼容已有應用：由於SQL層更多使用已有的標準SQL解析器，因此對於原有應用在SQL上可以實現完全的兼容，沒有任何應用改造的投入。
?數據安全可用：分布式的存儲和松耦合的架構，數據擁有安全的多副本，松耦合則大大增強了整個系統的容錯性。相比傳統單點架構，可以很好的實現數據雙活甚至多活的架構，滿足“兩地三中心”“三地五中心”的合規監管安全要求。
雲數據庫應用場景
在新架構驅動下，雲數據庫目前在多個場景下已經開始實現落地應用。
傳統交易服務
在傳統中心化交易型業務中，高性能、高吞吐量的數據存儲與處理能力，ACID以及安全都是非常重要的特性。例如，在一個典型的銀行業務中，為了滿足高峰時期的在線交易量，交易型數據庫需要在億級記錄條數的數據庫中每秒處理上千比交易。同時，為了滿足生產系統的健壯性與可靠性，傳統交易服務對於底層數據存儲的安全性、高可用性、兩地三中心部署能力都有著非常明確的要求。
因此雲數據庫既需要將傳統交易型業務逐漸轉移至雲平臺，同時也需要在滿足安全性和合規監管方面，為用戶提供更好的支持。
歷史數據服務
近年來，隨著IT技術與大數據的不斷發展，越來越多的企業將數據作為自身寶貴的資產進行長期保留。這使得一些傳統應用程序的歷史數據包袱越來越重，最終數據庫不堪重負導致應用整體性能低下。另一方面，隨著大數據需求的不斷增加，曾經已經歸檔的數據需要重新在線以滿足在線化、實時化使用、查詢和分析等等要求，這就要求將原有龐大的離線數據進行“在線化”。這些需求使得歷史數據管理成為必須。
對於歷史數據服務來說，由於對外提供應用程序的直接訪問，其健壯性、可靠性、可配置一致性策略、性能與並發能力都是極為值得關註的。同時，相對傳統交易服務來說，強一致和ACID反倒並不是最關註的點。鑒於一些企業直接將部分報表和自助查詢運行在歷史服務平臺上，HTAP的能力也是值得關註的特性。
雲數據庫在擴展性和性能上通過分布式的架構滿足了這些需求，將歷史數據很好的管理起來。
實時在線服務
當前大部分企業的生產業務系統與後臺的數據加工、分析與查詢系統都是通過T+1的方式進行數據ETL。而最近隨著流處理技術的興起，越來越多的企業開始基於流處理技術構建T+0的數據總線，以實現不同業務流程之間實時數據對接。譬如說，用戶資產視圖就可以利用流處理技術，在提供用戶全資產視圖查詢的優秀用戶體驗的同時，大幅度減輕其對後臺生產系統造成的查詢壓力。
對於實時在線服務來說，數據庫的層面最為關註性能、吞吐量、可靠性、與可用性。而對於強一致、ACID、與HTAP來說並不構成其最重要的特性。
在線業務的數據多樣化和性能都需要雲架構的數據庫提供更靈活高效的支持。
影像存儲服務
很多行業在業務運營中會產生大量紙質憑證，在信息化處理和監管要求下，這些紙質的憑證都需要掃描成影像文件並長期保存。隨著互聯網技術以及集中作業中心等理念的深入推廣，大量行業普遍需要建設統一的影像管理平臺。
對於典型的影像平臺來說，其存儲的數據總體量極大，使用傳統存儲的單位成本很高，需要進行生命周期管理時對運維又非常復雜。因此，對於逐年遞增的海量影像數據來說，大部分企業都存在查詢難、管理難、擴容難的幾大痛點。
同時，由於影像存儲服務已經成為很多流程的一部分，其穩定性、可靠性與健壯性與核心交易系統處於同一級別。因此，影像存儲服務最關註的層面在於可靠性、一致性、可擴展性、吞吐量、以及非結構化存儲的多模特性。而其對於交易的ACID、HTAP等特性並不重點關註。
小結
雲數據庫是未來數據庫發展的一個重要方向，雲數據庫架構隨著雲化要求也需要進行相應的叠代，未來在雲數據庫架構的演進還會隨著需求的變化而持續發展。
其中對於多模數據引擎、計算存儲分離等將是雲數據庫技術演進的重點方向。
巨杉也會持續關註架構的叠代演進，同時也在技術和架構上針對雲架構進行更多的創新。
雲數據庫架構演進與實踐