背景
前段時間，以 Apache ShardingSphere 核心團隊組建的創業公司 SphereEx，正式對外推出了 Database Mesh 2.0 概念以及與之相配套的開源產品 Pisanix，這引發了社區間對于 ShardingSphere 和 Database Mesh 的不少爭論與思考，許多用戶都很清楚，SphereEx 是由 Apache ShardingSphere 核心團隊創立的，
那么有部分用戶就提出了疑問，既然已經有了 Apache ShardingSphere 這樣一個如此成功的開源專案，為何還要大費周章選擇在一個全新的領域從頭開始？在云原生趨勢的影響下，未來 ShardingSphere 會不會逐漸被并入到 Database Mesh 的理念體系中？
隨著 SphereEx 推出 Database Mesh 2.0 概念，并開辟了另一條開源發展路線，看似與此前已經大獲成功的 ShardingSphere 產生了沖突，但實際上，兩者是“同氣連枝、相輔相成”的關系，本篇將主要針對 ShardingSphere 社區用戶對于 Database Mesh 概念以及未來發展方向做出整體闡述，帶領大家從頭梳理 Apache ShardingSphere 的指導理念 Database Plus，以及與 Database Mesh 理念之間的脈絡聯系，
一、從微服務治理到云原生資料庫服務治理，變在了哪？
相比于微服務，云原生下的資料庫治理在功能選擇上會有不同的側重，
首先，資料庫是有狀態的，請求無法像服務一樣被隨意路由到對等節點，因此對于資料庫而言，資料分片是一個重要的能力；另外，由于資料庫連接本身具有狀態性，啟動或停止一個新的資料庫實體，往往意味著資料同步和復制，因此相較于微服務，實體自動發現能力的重要性就會降低，
如果將資料庫看作為一個微服務，雖然可以通過 Service Mesh 對資料庫訪問進行治理，但卻會受到許多限制，同時，資料庫擁有一些特殊治理屬性，比如通信協議、資源管理、基于資料請求的負載均衡、分庫分表、還有可觀測性、訪問控制等，這些都不能簡單地以服務的概念來理解和解決，而是屬于資料庫可靠性工程領域的問題，
這就為 Database Mesh 的發展提供了空間，SphereEx 提出的 Database Mesh 2.0 概念更關注在云原生環境下，如何實作以下幾個目標：
-
進一步減輕開發人員的心智負擔，提高開發效率，提供透明和無感的資料庫基礎設施使用體驗；
-
以可配置、可插拔、可編程的方式，實作一個覆寫資料庫流量、運行時資源和穩定性保障等方面的治理框架；
-
為異構資料源、云原生資料庫、分布式資料庫等多個資料庫領域的典型場景提供標準的使用界面，
提供資料分片、負載均衡、可觀測性、審計等能力，這些能力已經解決了資料庫治理中屬于流量治理的部分問題，更近一步地，當業務應用開始以容器的方式進行打包交付、利用 CI/CD 流水線每天發布成百上千次到各個資料中心的 Kubernetes 基礎設施的時候，引發了對云環境下如何實作資料庫可靠性工程的思考，Database Mesh 2.0 就是在這種思考之下的產物，
二、ShardingSphere 的指導理念 Database Plus，與 Database Mesh 之間的不同
首先，理念不同
其實，只看理論和概念，Database Mesh 與 Database Plus 之間還是有相當大差異的，
-
關于 Database Mesh，SphereEx 認為云上資料庫治理有共性也有其獨特性，對于共性問題可以通過標準化和自動化的方式加以解決，獨特性的可以通過提供一種靈活的擴展機制，讓工程師可以按需配置和實作因此需要通過可編程實作高性能擴展，應對云上資料庫治理挑戰；
-
而關于 Database Plus，Apache ShardingSphere 社區則認為這是一種分布式資料庫系統的設計理念，旨在碎片化的異構資料庫上層構建生態，在最大限度地復用資料庫原生存算能力的前提下，進一步提供面向全域的擴展和疊加計算能力，使應用和資料庫間的互動面向 Database Plus 構建的標準，從而屏蔽資料庫碎片化對上層業務帶來的差異化影響，
不過隨著資料庫上云的趨勢不可避免，Database Mesh 與 Database Plus 這兩者之間難免會產生交集，在云原生以及分布式資料庫的場景下，ShardingSphere 與 Database Mesh 之間將會產生更多的火花，
其次，應用場景不同
在 Database Plus 理念指導下的 ShardingSphere，主要被應用于分布式資料庫場景之中，Database Mesh 主要被用來指導云原生場景下資料庫可靠性的具體實踐，作為兩個不同領域的不同設計哲學，Database Plus 和 Database Mesh 均代表了在各自資料治理場景中的科學理念，并且在科學理念的指導下，誕生了 ShardingSphere 和 Pisanix 這兩款開源實踐產品，
Database Mesh 2.0 希望提供一種以資料庫為中心的治理框架：
-
資料庫是一等公民：一切抽象圍繞資料庫治理行為進行，比如訪問控制、流量治理、可觀測性等；
-
面向工程師體驗：對于開發人員，通過便捷易用的資料庫宣告和定義，即可進行開發，無需關心資料庫的位置；對于運維和 DBA，提供多種資料庫治理行為抽象，實作自動化的資料庫可靠性工程；
-
云原生：以開放的生態和實作機制適配不同的云環境，面向云原生構建和實作，而無需擔心廠商鎖定，
而 Database Plus 則希望以『連接、增強、可插拔』為核心，在碎片化的異構資料庫上層構建計算生態，以解決本地架構選型困難、技術及運維復雜度高、資料庫上層標準缺失、資料庫間缺乏協作和統管能力等問題，
總而言之，Database Plus 理念下的實踐 Apache ShardingSphere，是面向于分布式資料庫場景下的具體實踐，而 Database Mesh 則是在云原生場景下的，面向云原生場景下資料庫治理難點的解決方案，
最后，業務場景與訴求所引發的轉型貧訓不同
從關系型資料庫到分布式資料庫，應用場景的不斷擴張，資料庫在不同場景下的優劣表現，均決定了企業應用資料庫的多元并存常態，碎片化是資料庫領域的大勢所趨，單一品類的資料庫無法適用于所有場景，只能適用于某一種或某幾種擅長的場景，而在業務場景的驅動下，采用分布式資料庫解決方案，已經成為應對大流量、高并發、緩解資料庫壓力的行業共識，
同樣由于場景驅動，在分布式資料庫風靡全球的這幾年中，云計算也在充分發揮著自身的優勢與特性，雖然不能預測未來的發展和變化，但對于云計算來說，隨著云原生環境的成熟，天然產生于云環境下的資料庫（即云原生資料庫）越來越多，其不僅集中在各家云廠商手中，市面上更是有越來越多產品涌現出來，
加之使用場景以及在不同的用戶視角里，開發人員更關注運行效率、成本開銷，以及資料庫協議型別和訪問資訊，不關心資料存盤的位置，運維和 DBA 更關注資料庫服務的自動化、穩定性、安全性、監控報警等，此外 DBA 還會關心資料的變更、容量、安全訪問、備份、遷移等等，正是隨著對資料庫治理場景的深入理解和對用戶體驗的極致追求，共同催生了 Database Mesh 2.0 的核心思想：通過可編程實作高性能擴展，應對云上資料庫治理挑戰，
三、當分布式成為共識、云原生趨于繁榮：ShardingSphere 與云之間會沖突嗎？
早在 Service Mesh 大行其道的 2018 年，Apache ShardingSphere PMC Chair 張亮就曾借著 Service Mesh 的東風，創造性地提出了 Database Mesh 概念，設想是否有一種模式可以有效的結合 JDBC 代理端與 Proxy 客戶端的優點并屏蔽其缺點，借助“彈性伸縮 + 零侵入 + 去中心，實作了一個真正的云上基礎設施”，而當時設想中的 ShardingSphere Sidecar，正是 Database Mesh 1.0 階段的產物，
隨著迎來『分布式成為共識、云原生趨于繁榮』的階段，作為一款由社區主導的開源專案，自然需要跟著業務、場景的變化而變化，ShardingSphere 也在這一條件下經歷了從 Sharding-JDBC 到 ShardingSphere 的轉變，不只是名稱的變化，更是 ShardingSphere 產品本身定位和技術生態領域的變化，
Pisanix 是用 Rust 和 Go 重寫的上云版 ShardingSphere？
近期，SphereEx 對外開源了面向 Database Mesh 的解決方案 Pisanix，對于 Pisanix 面向資料庫流量的核心組件 Pisa-Proxy 而言，其與 ShardingSphere-Proxy 兩者的架構非常相似，粗略一看很容易將這兩者聯系為重構的關系，
當然也不只是 Pisanix 與 ShardingSphere-Proxy，所有面向 MySQL 資料庫的代理的架構設計都大同小異，尤其是資料庫領域，存在著一定的同質化問題，不過對于產品而言，關鍵就是在其間尋找差異，對于 Pisanix 與 ShardingSphere-Proxy 而言，這兩者的區別在于在拿到資料后要實作怎樣的效果，解決用戶怎樣的問題，
因此，Pisanix 不能簡單的被認為是用 Rust 重寫的 ShardingSphere，兩者完全不同，只是在入口處比較像，對于資料庫領域而言，總歸是有相似點的，
另一方面，許多用戶會非常自然地將 Database Mesh 與 ShardingSphere-Sidecar 劃作等號，但其實這兩者在內核層面有很大不同，這也是區別兩者的最關鍵因素，目前，作為 Database Mesh 理念的實踐，Pisanix 已能夠承擔一部分原有 ShardingSphere-Sidecar 在云原生環境下的資料治理能力，方便用戶在云上環境中使用 ShardingSphere，
Pisanix 專案地址：https://github.com/database-mesh/pisanix
對于 Database Mesh 而言，Sidecar 并不是它的內核，Database Mesh 的內核一定是面向某個具體的、工程化的問題，Sidecar 只是 Database Mesh 概念其中的一種部署形式，有可能未來有一天 Pisanix-Proxy 就不是 Sidecar 的形式了，也有可能會演化成一個很薄的中間層，總而言之，Sidecar 只是實作治理能力的一個手段，
Database Mesh 真正的內核在于對用戶體驗、資料庫服務治理等層面的拓展，如果未來有更多資料庫型別的出現，有更多云上云下的場景出現，Database Mesh 的概念也會進一步實作擴展，這才是 Database Mesh 正在追求的方向，
Database Mesh 想做的是把各種云上的因素屏蔽掉，統一將上層資料庫的各類行為治理起來，但不同資料庫的協議和運維特性是千差萬別的，困難就在于能否抽象出標準的治理行為，技術方案本身是多種選擇中的一種，最核心的部分是用戶體驗，至于選擇 Java 還是 Rust 或是 Python，都只是技術方案中的一部分，通過選擇合適的語言的來保持專案的生命力以及生態，這些都是必須要考慮的部分，
四、資料庫未來全景圖：ShardingSphere + Database Mesh +....
Database Mesh 可以治理 ShardingSphere 嗎？
如果把 ShardingSphere 看作為一個高性能的分布式資料庫，對于 Database Mesh 而言，治理 ShardingSphere 與治理 MySQL、TiDB 等資料庫都是一樣的，
因此盡管可以治理，但 ShardingSphere 本身并不額外需要其它理念的影響，因為對 ShardingSphere 的設計哲學 Database Plus 而言，是通過連接、增強、可插拔的特性將 MySQL 本身不具備的能力增強出來，這種增強是原生資料庫不具備的能力，而通過 ShardingSphere 則能夠與底層資料庫結合，將較強的計算能力以某種方式部署在應用端，變成一個高性能的分布式資料庫，避免資源浪費，提供相較于其它分布式資料庫更加高性價比的解決方案，
云原生的場景下的機遇
接下來，讓我們把眼光著眼于行業，眾所眾知，云是代表著未來，代表著不可逆的方向，因此，一個專案、一款產品、一個理念，能否服務于這個『不可逆』的未來，將直接影響到自己的生命周期與影響力，這也是 ShardingSphere 規劃上云、也一定會上云的根本原因，
在 Database Plus 理念的指導下，Apache ShardingSphere 可以在云資料庫現有基礎上拓展更多功能，為企業、云計算平臺提供更加強大的跨不同資料庫產品本身的能力，底層兼容多個資料庫，兼容云端各類資料庫產品，研發側無需感知；另外，以保持云中立的身份，確保云端體驗與本地體驗相同，支持多云架構，在不同云的基礎設施下提供同樣的體驗，這正是 ShardingSphere 在云原生場景下的機會與能力，
作為兩款完全獨立的設計哲學，Database Plus 與 Database Mesh 之間并不是競爭關系，相反，Database Mesh 與 Database Plus 之間可以產生很好的化學反應，這兩者都是基于資料庫現有的碎片化生態、用戶所面臨的痛點來提供解決方案，盡管方向不同，但均代表了時下對于解決不同場景下資料治理難題的最佳思路，
目前 Database Mesh 官網 已上線，相應的規范定義也開源在（ https://github.com/database-mesh/database-mesh ）倉庫里，同時 Database Mesh 的具體實踐 Pisanix 也已開源，歡迎大家的關注，
專案地址：https://github.com/database-mesh/pisanix
官網地址：https://www.pisanix.io/
Database Mesh：https://www.database-mesh.io/
SphereEx 官網：https://www.sphere-ex.com
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/499151.html
標籤：其它
下一篇：【時序資料庫InfluxDB】Windows環境下配置InfluxDB+資料可視化，以及使用 C#進行簡單操作的代碼實體