背景
一直以來，大一統還是碎片化，是數據庫發(fā)展趨勢的兩種最主流預測。隨著數字化進程的推進，單一場景無法滿足應用多樣化的需求，數據庫碎片化已呈不可逆的趨勢。在當前，市場占有率最高的商用數據庫—— Oracle 并沒有明顯短板的情況下，各種全新的數據庫依舊如雨后春筍般層出不窮。如今，DB-Engines 上已有超過 300 余種數據庫參與排名。
應用場景的不斷擴張，加速了數據庫碎片化的進程，數據庫的架構、協議、功能、適用場景也愈加多樣化。在數據庫架構方面，基于單機系統演進而來的集中式數據庫與原生面向分布式的新一代數據庫并存;在數據庫協議方面，MySQL 和 PosrtgreSQL 這兩大主要開源生態(tài)以及周邊廠商所提供的服務生態(tài)也在全球數據庫體系中各自占有一席之地;每種數據庫的獨特功能和適用場景，也在相關的領域大放異彩。
在企業(yè)的應用現狀中，數據庫的多元并存已是常態(tài)。在互聯網行業(yè)中，以 MySQL + 數據分片中間件作為核心業(yè)務存儲的架構模式為主，以 GreenPlum、HBase、Elasticsearch、Clickhouse 等其他大數據生態(tài)作為分析型數據的計算引擎為輔助。與此同時，一些遺留系統(如：通過 .NET 轉型時遺留的 SQLServer、或通過外采而遺留的 Oracle)的數據庫仍在運行;在金融行業(yè)中，核心交易系統仍然大量使用 Oracle 或 DB2，新業(yè)務向 MySQL 或 PostgreSQL 遷移，部分業(yè)務則逐漸嘗試使用自主研發(fā)的數據庫。除了交易型數據庫，分析型數據庫的種類則更加繁多。
因此，碎片化是數據庫領域的大勢所趨，單一品類的數據庫無法適用于所有場景，只能適用于某一種或某幾種擅長的場景。
數據庫碎片化帶來的問題
隨著企業(yè)采用的數據庫種類不斷增加，各種問題和痛點也隨之出現。
1.架構選型困難
當應用架構為了適應更加靈活多變的業(yè)務需求，將架構設計從單體式向服務化再到微服務進行轉化之后，用于存儲業(yè)務核心數據的數據庫則成為分布式系統的下一個焦點。
相對比無狀態(tài)的應用，具有狀態(tài)的數據庫的設計難度則有過之而無不及。分而治之是分布式系統的最佳實踐，顯然，數據庫體系也不能簡單的用單一產品以及一體化集群來響應所有的服務請求。
首先，單一品類的數據庫無法滿足業(yè)務應用的全部需求，在高吞吐量、低延時、分布式無感知、強一致性、運維友好度甚至穩(wěn)定性等方面難以做到面面俱到。一個應用需要多種數據庫共存的可能性尚且不高，但多個應用混用多種數據庫的可能性則大大提升。
其次，無論是單機數據庫，還是 All in One 的分布式數據庫集群，都難以成為眾多微服務應用后端的唯一存儲支撐。單機數據庫無法承載越來越大的數據量和訪問量，所以越來越多的應用選擇采用分布式解決方案。然而，多應用使用統一的數據庫集群，在 CPU、內存、磁盤、網絡等方面的負載無法做到完全隔離。一個應用的超額資源使用，可能會導致眾多毫不相干的應用服務質量下降。
如今，大部分分布式數據庫的搭建成本相當高，在計算節(jié)點、存儲節(jié)點和治理節(jié)點都需要備份和冗余的獨立服務器。如果要為每一個微服務都搭建一套獨立的分布式數據庫，一定會造成非必要的資源消耗，最終導致企業(yè)無法承受。
最后，大量企業(yè)采用單元化架構?；跀祿制慕鉀Q方案，將數據庫的拆分和單元化一并放到應用端解決。隨著數據庫數量的增多，架構設計的復雜度會呈指數級增長。長此以往，業(yè)務開發(fā)團隊將無法把精力集中在最擅長的業(yè)務研發(fā)層面，反而需要花費大量精力投入到基礎組件的維護。盡管 Apache ShardingSphere 的數據分片功能可以較好解決相關問題，但面對更多元的數據庫，僅支持單一品類數據庫的水平分片能力是遠遠不夠的。
2.技術挑戰(zhàn)眾多
當碎片化數據庫共存成為常態(tài)時，研發(fā)人員的學習與開發(fā)成本將不可避免的持續(xù)增長。盡管數據庫大多支持 SQL 的操作方式，但各數據庫間仍有大量 SQL 方言的差異。除此之外，各數據庫間驅動程序的使用方式也或多或少存在不同。
因此如需精細化使用每一種數據庫，必定會占用研發(fā)工程師大量的精力，且沉淀下來的知識和經驗不易傳承;如果采用粗粒度的標準模式統一使用異構數據庫，將會湮沒數據庫自身的特點，而無法發(fā)揮其應有的作用。
3.運維復雜度高
掌握各種數據庫特征，并結合實際場景制定行之有效的運維規(guī)范，需要大量時間和實踐經驗的積累。除了最基本的運維工作，數據庫周邊配套工具的差異性也非常大。通過周邊配套工具所組成的監(jiān)控、備份及其他自動化運維等工作，隨著數據庫種類的增加將會產生巨大的運維成本。
4.數據庫間缺乏協作和統管能力
站在數據庫的角度，其首要目標是完善自身的能力，而非面向其他數據庫的在線協作能力。跨越異構數據庫的關聯查詢、分布式事務等功能，是無法在數據庫本身實現的。
與相對標準的 SQL 不同，數據庫自身的協議和周邊生態(tài)工具缺乏統一的標準。對異構數據庫的統一管控能力也受到越來越多的關注。但遺憾的是，數據庫上層標準的缺失，使得數據庫間的協作和統管能力難以取得有效的推進。
Database Plus 是什么?
Database Plus 是一種分布式數據庫系統的設計理念。旨在碎片化的異構數據庫上層構建生態(tài)，在最大限度復用數據庫原生存算能力的前提下，進一步提供面向全局的擴展和疊加計算能力。使應用與數據庫間的交互面向 Database Plus 構建的標準，從而屏蔽數據庫碎片化對上層業(yè)務帶來的差異化影響。
『連接、增強、可插拔』是定義 Database Plus 核心價值的三個關鍵詞。
1.連接：打造數據庫上層標準
相對于提供一個全新的標準，Database Plus 更傾向于提供一個可以適配于各種數據庫 SQL 方言和訪問協議的中間層，提供開放的接口用于對接各種數據庫。
由于數據庫訪問協議的實現，Database Plus 和數據庫在使用體驗上并無二致，可以支持任意的開發(fā)語言和數據庫訪問客戶端。
除此之外，Database Plus 能夠最大限度支持 SQL 方言間的相互轉換?？梢詫?SQL 解析而成的 AST(抽象語法樹)根據其他數據庫方言的規(guī)則重新生成 SQL。SQL 方言轉換的能力，打通了連接異構數據庫之間相互訪問的通道，用戶可以使用任意一種 SQL 方言訪問異構的底層數據庫。
『數據庫網關』是對連接的最佳詮釋。在數據庫上層打造開放對接的通用層，將碎片化數據庫的全部訪問流量匯集于此，是 Database Plus 為數據庫碎片化提供解決方案的前提條件。
2.增強：數據庫計算增強引擎
數據庫經歷了數十年的發(fā)展，其自身具備了查詢優(yōu)化器、事務引擎、存儲引擎等久經考驗的存算能力和設計模型。在 IT 領域，數據庫的設計和使用方式已深入人心，不可動搖。隨著分布式和云原生時代的到來，將數據庫原有的計算和存儲能力全部打散，并織入分布式和云原生級別的全新能力，會不可避免的重復造輪子。
因此，Database Plus 采用了既重視傳統數據庫的實踐經驗，又適配于新一代分布式數據庫的設計理念。無論是集中式還是分布式的數據庫，Database Plus 都能復用數據庫的存儲和原生計算能力，并在其基礎之上提供全局化的能力增強。
全局化的能力增強主要在分布式、數據控制和流量控制三個方面。
無論是原生面向分布式的數據庫，還是基于集中式數據庫作為基石的分布式擴展方案，都離不開分而治之這個分布式系統永恒不變的設計原理。數據分片、彈性伸縮、高可用、讀寫分離、分布式事務、以及基于垂直拆分的異構數據庫聯邦查詢等功能，都是 Database Plus 在分布式的異構數據庫全局層面下所能夠提供的能力。它的關注點不在于數據庫自身，而是站在碎片化的數據庫上層，關注于多個數據庫之間的全局協作能力。
除了分布式增強之外，數據控制和流量控制的增強能力均處于豎井化范疇。面向數據控制的增量能力包括：數據加密、數據脫敏、數據水印、數據溯源、SQL 審計等;面向流量控制的增量能力包括：影子庫、灰度發(fā)布、SQL 防火墻、黑白名單、熔斷限流等。這些均屬于數據庫生態(tài)層所提供的能力，然而在數據庫碎片化的態(tài)勢下，為每一種數據庫提供全量的增強能力的工作量十分巨大，且缺失統一的實現標準。Database Plus 通過提供支點，將支持的數據庫種類和增強功能相疊加，以排列組合的方式提供給用戶使用。
3.可插拔：構建數據庫功能生態(tài)
不斷增加的數據庫類型對接和增強功能織入，會使 Database Plus 通用層逐漸趨于臃腫。連接和增強的可插拔化，既是 Database Plus 通用層維持小而美的基石，也是擴展生態(tài)無限化的有效保障?？刹灏蔚捏w系，為 Database Plus 通用層提供了插件生態(tài)無限擴張的可能，使用者只需根據自身需求裁減插件即可。
通過可插拔體系，Database Plus 將能夠真正的構建面向數據庫的功能生態(tài)，將異構數據庫的全局能力統一納管。它不僅面向集中式數據庫的分布式化，也同時面向分布式數據庫的豎井功能一體化。
微內核設計和可插拔架構是 Database Plus 理念的核心價值，它面向通用的平臺層，而非某項具體功能。
ShardingSphere 在 Database Plus 方向的探索
Apache ShardingSphere 項目歷史悠久，從開源伊始的數據庫分片中間件，到如今 Database Plus 理念的奠基者和實踐者，它的前進步伐從未放緩。目前，Apache ShardingSphere 遵循 Database Plus 理念，已完成了 Database Plus 三大核心價值下的大部分基礎設施建設。
1.連接層
ShardingSphere 已支持 MySQL、PostgreSQL、openGauss 等數據庫協議，以及 MySQL、PostgreSQL、openGauss、SQL Server、Oracle 和所有支持 SQL92 標準的 SQL 方言。
連接層抽象的頂層接口可供其他數據庫開放對接，包括：數據庫協議、SQL 解析和數據庫訪問等。
2.增強層
ShardingSphere 的功能增強劃分為內核層和可選功能層。
內核層包含查詢優(yōu)化器、分布式事務、執(zhí)行引擎、權限引擎等與數據庫內核強相關的功能，以及調度引擎、分布式治理等與分布式強相關的功能。內核功能的每個模塊都必須存在，但可以切換至不同的實現類型。以查詢優(yōu)化器為例，如果待執(zhí)行 SQL 可以完美下推至后端數據庫，則采用基于原始 SQL 與數據庫交互的計算下推引擎;如果待執(zhí)行 SQL 需要跨越多數據源進行關聯查詢，則采用基于查詢計劃樹與數據庫交互的聯邦查詢引擎。
可選功能層的功能模塊由開源社區(qū)沉淀而形成。除了最具代表性的數據分片和讀寫分離之外，高可用、彈性伸縮、數據加密、影子庫等功能模塊，都在逐步的完善之中。
3.可插拔層
從最初的 MySQL + 數據分片為核心的架構模型，到如今的微內核 + 可插拔架構，項目進行了徹底的改造。從提供連接的數據庫種類和增強功能到內核能力，ShardingSphere 全部面向可插拔。
ShardingSphere 的架構核心外圍，由微內核、可插拔接口、插件實現這三層模型組成，層次之間單項依賴，微內核對插件功能完全無需感知，插件之間也無需相互依賴。對于一個擁有 200+ 模塊的大型項目來說，架構的解耦和隔離，是社區(qū)開放協作、將錯誤影響范圍降低至最小的有效保障。
小結
Database Plus 是 ShardingSphere 的理論支撐，ShardingSphere 是 Database Plus 理念的最佳實踐。隨著 ShardingSphere 的越來越成熟，Database Plus 的拼圖也會越來越豐滿。
Database Plus 帶來的優(yōu)勢
Database Plus 帶來眾多的優(yōu)勢，受限于篇幅，無法在文中一一列舉。下面僅從影響系統架構設計和技術選型方面進行闡述。
1. 精細化適配靈活多變的應用場景
用戶可以根據自身需求定制化使用相應功能，數據分片不再是使用 ShardingSphere 的必要條件，獨立使用數據加密功能的用戶已不在少數。ShardingSphere 的可插拔能力不僅限于數據庫接入層和功能增強模塊本身，每個功能模塊的內部也能夠基于可插拔架構靈活配置。
以數據分片為例，作為數據分片模塊的可插拔部分，分片算法可以由用戶自定義配置，無論是標準的哈希、范圍、時間等分片算法，還是自定義分片算法，使用者都可以根據業(yè)務場景需要自由靈活配置，最大限度切合業(yè)務場景。
2.面向架構師的微服務后端支撐能力
Apache ShardingSphere 是微服務后端的數據庫單元化最佳方案。正如前文所述，不同的微服務共享一套分布式數據庫集群，無論從架構設計的不對稱性，還是資源隔離的不可控性，都不能稱之為完善和優(yōu)雅的解決方案。為每一組微服務搭建一套分布式數據庫集群，則又會造成非必要的資源浪費。
相對于重量級的分布式數據庫集群，ShardingSphere-Proxy 所占用的資源節(jié)省很多，為每個微服務集群獨享一套數據庫集群奠定良好基礎。但如果微服務拆分足夠精細，為每一組微服務搭建一套 ShardingSphere-Proxy 的額外資源占用依舊不可小覷。在這種情況下，可以考慮使用占用資源更少的 ShardingSphere-JDBC，它作為類庫與應用代碼部署在一起，無需額外占用資源。
ShardingSphere-Proxy 和 ShardingSphere-JDBC 不僅可以通過混合使用的方式，來滿足用戶的使用友好度、跨語言適配、高性能、資源節(jié)省等各方面需求;還可以通過 Traffic Rule 讓 ShardingSphere-Proxy 和 ShardingSphere-JDBC 在不同特征的 SQL 請求中相互路由，以最小化應用資源占用所帶來的影響。
Traffic Rule 可以根據用戶自定義的 SQL 特征(如：聚合計算、無分片鍵的全路由查詢等)，將占用更多計算資源的請求發(fā)送至獨占資源的 ShardingSphere-Proxy，而將交易型的輕量級操作保留在微服務應用端。這與邊緣計算的理念不謀而合，ShardingSphere-JDBC 在微服務應用端的算力和邊緣計算節(jié)點有異曲同工之妙。用于中心計算的 ShardingSphere-Proxy 可以根據業(yè)務自身需要，部署獨立的集群服務于多組微服務。
通過靈活使用 ShardingSphere-Proxy、ShardingSphere-JDBC 和 Traffic Rule，這套組合將能夠不斷激發(fā)著架構師的設計靈感和創(chuàng)造力。開句玩笑，正確使用 ShardingSphere 進行優(yōu)雅的系統設計，可以被當作優(yōu)秀架構師的準入線。
3.DistSQL 為 DBA 帶來數據庫原生操作體驗
面對數據分片、數據加密等增強功能，Apache ShardingSphere 之前版本主要采用 YAML 的方式進行配置。對于開發(fā)工程師來說，靈活的 YAML 配置使用起來得心應手，但對于 DBA 而言，YAML 的配置方式確存在諸多不便。除了改變了 DBA 的日常 SQL 操作習慣之外，無法對接諸如權限、安全、工單、監(jiān)控、審計等第三方系統，也讓此前的 ShardingSphere 難以適用于生產環(huán)境的運維管控。
全新版本的 Apache ShardingSphere 增加了 DistSQL 的操作方式。使用者可以完全通過 SQL 在任意的數據庫終端(如：MySQL Cli、Navicat 等)操作增強功能。數據分片、數據加密、讀寫分離等所有的強功能都擁有與之相匹配的 DistSQL，使用 DBA 所熟悉的 CREATE/ALTER/DROP/SHOW 等 SQL 語法即可完成全部功能的配置。DistSQL 同樣支持授權語句的管控，也可以通過對接 SQL 審計平臺記錄所有使用者的操作記錄。
數據庫表結構是 Database 的元數據，增強功能配置是 Database Plus 的元數據。DistSQL 的出現，不僅提升了用戶友好度，也補全了 Apache ShardingSphere 上線和運維的最終拼圖。
4.Proxyless 模式提升性能至極致
在 Service Mesh 領域，最為經典就是 Istio + Envoy 架構搭配模式。它通過 Sidecar 的部署方式管理 Envoy，做到對應用的無侵入，稱之為 Proxy Service Mesh，降低了開發(fā)、使用和升級的成本，但由于在訪問鏈路中增加了 Proxy/Sidecar 這一層，使得性能有所下降。
而 Proxyless Service Mesh 則采用另一種設計模式，它始于 gRPC 對 xDS 協議的實現，Istio 新版本通過 gRPC + xDS 的方式，允許應用代碼直接通過 Istio Agent 提供的 SDK 編程，有效提升了通信性能。
在分布式數據庫領域，存算分離的架構設計模式已經深入人心。計算節(jié)點和存儲節(jié)點分離的設計，與 Proxy Service Mesh 的架構模型有些類似。ShardingSphere-Proxy 的設計完全契合了存算分離的架構模型，它有效降低了用戶的開發(fā)、使用和升級成本，卻不可避免帶來了一定的性能損耗。
對于性能延時敏感的應用而言，與 Proxyless Service Mesh 設計理念不謀而合的ShardingSphere-JDBC 無疑更加合適，其能夠將系統的性能發(fā)揮至極致。在近期使用 ShardingSphere + openGauss 測試 TPC-C 模型的結果中，得到了驚人的 16 臺服務器超過 1000w tpmC 的測試結果，行業(yè)同等規(guī)模下性能最佳。
小結
一直以來，先進的設計理念和創(chuàng)新均源于西方。但 gRPC 的 Proxyless 設計理念是近期才出現的，而 ShardingSphere-JDBC 則是項目在 2016 年開源伊始時就已經存在。因此，ShardingSphere-JDBC 并未參考 Proxyless 的設計理念，它是基于當時國內互聯網業(yè)務對高并發(fā)和低延時的極致性能要求而誕生的。
至于 Database Plus 理念的設計，又何嘗不是如此。伴隨著互聯網的長期快速發(fā)展，業(yè)務的變化直接推動了技術的積累和成長，ShardingSphere 就是這一過程的最好例證，它的設計方案全部源自于真實業(yè)務場景。中國互聯網無疑是全球最全面的場景之一，在此類場景下誕生的設計理念，在全球范圍內也一定擁有十分廣闊的生長空間。
未來規(guī)劃
盡管在 Database Plus 理念的實踐道路上越走越遠，但 Apache ShardingSphere 仍然有大量的工作等待完成。數據庫網關和異構聯邦查詢，是完善 Database Plus 理念的重要功能拼圖。
1.數據庫網關
Apache ShardingSphere 雖然支持異構數據庫的對接，但無法做到數據庫之間方言的相互轉換。在 ShardingSphere 的線路規(guī)劃中，SQL 方言轉換是實現數據庫網關的重要功能，用戶通過 PostgreSQL 的數據庫協議用 MySQL 方言訪問 MongoDB 將不再是難以實現的任務。
2.異構聯邦查詢
Apache ShardingSphere 目前僅支持同構數據庫間的聯邦查詢。在 ShardingSphere 的線路規(guī)劃中，異構數據庫間的聯邦查詢也將被提上日程。用戶通過一條 SQL 關聯查詢 MySQL 和 HBase 的場景將不再遙遠。
寫在最后
Apache ShardingSphere 社區(qū)已在開源領域耕耘了 7 年的時間。長久的堅持，使社區(qū)愈加成熟，已呈開放和多元化的勢態(tài)。我們誠心誠意地歡迎有開源情懷和編碼熱情的朋友一起參與社區(qū)共建。
Apache ShardingSphere 的可插拔架構和數據分片哲學已在學術界獲得廣泛認可。在今年的數據庫領域頂級的會議 ICDE 中，已成功發(fā)表論文《Apache ShardingSphere：A Holistic and Pluggable Platform for Data Sharding》。
關于作者
張亮，SphereEx 公司創(chuàng)始人 & CEO，歷任多家大型知名互聯網企業(yè)的架構、數據庫團隊負責人。熱愛開源，是 Apache ShardingSphere、ElasticJob 等知名開源項目創(chuàng)始人 & 項目管理委員會主席、現任 Apache 軟件基金會會員、微軟 MVP、騰訊云 TVP、華為云 MVP。擁有超過 10 年的架構和數據庫領域探索、實踐經驗。擅長分布式架構，推崇優(yōu)雅代碼，在分布式數據庫技術和學術等方面均取得重大成果。曾在 ApacheCon、QCon、AWS 峰會、DTCC、SACC、DTC等數十個國內和國際重大行業(yè)和技術峰會中擔任出品人和分享嘉賓。曾出版書籍《未來架構——從服務化到云原生》，并在數據庫行業(yè)頂級會議 ICDE 發(fā)表論文《Apache ShardingSphere：A Holistic and Pluggable Platform for Data Sharding》。
（免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。 ）
