背景 前段時間，以 Apache ShardingSphere 核心團隊組建的創業公司 SphereEx，正式對外推出了 Database Mesh 2.0 概念以及與之相配套的開源產品 Pisanix，這引發了社區間對於 ShardingSphere 和 Database Mesh 的不少爭論與思 ...
背景
前段時間，以 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
Database Mesh：https://www.database-mesh.io/
SphereEx 官網：https://www.sphere-ex.com
