在計算機科學的世界里，操作系統(tǒng)和數(shù)據(jù)庫可謂是兩大最重要的基礎軟件。就拿 SQL 這門語言來說，它的半衰期之長令人記憶深刻。SQL 不僅在早期的 DBMS 系統(tǒng)中扮演了相當重要的角色，近些年在數(shù)據(jù)科學領域和 Python 一同成為從業(yè)人員的必備技能。SQL 的生命力真可謂是“歷久彌新”，以至于有論文直言希望“One SQL to rule all”。這也從側(cè)面反映了數(shù)據(jù)庫領域歷史之久，地位之重，具備濃重的領域特色。

如果將數(shù)據(jù)庫視為調(diào)用鏈上一個服務節(jié)點，那么可以考慮采用 Service Mesh 的框架進行治理。而如果將數(shù)據(jù)庫視作一個有狀態(tài)的業(yè)務應用，它獨特的領域性帶來了治理的特殊性：比如，數(shù)據(jù)庫請求無法像服務一樣可以被隨意路由到任何對等節(jié)點。而對數(shù)據(jù)庫協(xié)議的感知和理解、數(shù)據(jù)分片和路由、數(shù)據(jù)庫部署的多副本、讀寫分離、主庫多寫等模式，甚至數(shù)據(jù)庫上云，都是困難多多，挑戰(zhàn)多多。那么基礎架構該如何應對這樣的數(shù)據(jù)庫治理局面呢？

時間撥回到 2018 年 3 月，彼時的 ShardingSphere 剛從原來的 ShardingSphere-JDBC 演化出來了可以獨立部署的 ShardingSphere-Proxy。它們都采用 Java 構建實現(xiàn)，分別代表了 SDK 模式和 Proxy 模式，提供了相同的標準化數(shù)據(jù)分片、分布式事務等功能。但無論使用哪種方式，都有其各自的優(yōu)缺點。項目創(chuàng)始人張亮就在設想是否有一種模式可以有效的結(jié)合 JDBC 代理端與 Proxy 客戶端的優(yōu)點并屏蔽其缺點，借助“彈性伸縮 + 零侵入 + 去中心，實現(xiàn)了一個真正的云上基礎設施”呢？于是就有了這篇文章：《Service Mesh 是大方向，那 Database Mesh 呢？》 。文中是這么描繪 Database Mesh 的：

“Database Mesh，一個搭乘 Service Mesh 浪潮衍生出來的新興詞匯。顧名思義，Database Mesh 使用一個嚙合層，將散落在系統(tǒng)各個角落中的數(shù)據(jù)庫統(tǒng)一治理起來。通過嚙合層集中在一起的應用與數(shù)據(jù)庫之間的交互網(wǎng)絡，就像蜘蛛網(wǎng)一樣復雜而有序?！?/span>

說到 Database Mesh 就不得不從 Service Mesh 開始。2016 年，第一代 Service Mesh 由 Linkerd 帶入大眾視野，緊接著 2017 年就誕生了以 Istio 為代表的第二代 Service Mesh，采用了控制面和數(shù)據(jù)面分離的設計模式，將服務治理中如流量治理、訪問控制、可觀測性等關鍵行為要素進行了抽象和標準化，然后借助 Kubernetes 的 Sidecar 模式解耦了應用容器和治理容器。至此，Service Mesh 的形態(tài)已經(jīng)基本確定。

如此一來 Service Mesh 在 Kubernetes 上的 Sidecar 模型實現(xiàn)就變得非常有啟發(fā)性：如果設計一種 ShardingSphere-Sidecar 模式，將 ShardingSphere 的核心分片能力等遷移到其中，就可以有效的結(jié)合 JDBC 代理端與 Proxy 客戶端的優(yōu)點并屏蔽其缺點，實現(xiàn)那個“彈性伸縮 + 零侵入 + 去中心，實現(xiàn)了一個真正的云上基礎設施”。這個階段的 Database Mesh 為 1.0 階段。

任何一個新技術概念在它落地的時候，都會因為不同的業(yè)務場景和模式、不同的架構設計模式、不同的基礎設施成熟度、乃至差異的工程師文化而打上自己獨特的烙印。這一點在 Kubernetes 落地歷程中已經(jīng)得到了充分驗證， 而 Service Mesh 落地又再次加深了這個觀點。那么對于 Database Mesh 呢？

在 Database Mesh 1.0 誕生的這些年里，一些公司在原有基礎上豐富了更多觀點，比如在 Service Mesh 的框架中，通過二次開發(fā)的方式增加了對 SQL 協(xié)議的解析和支持，增強了數(shù)據(jù)庫流量治理能力，兼容了統(tǒng)一的服務治理配置；比如將 Database Mesh 的理念集成到一套完整的中間件服務框架中，以 SDK 或者 Sidecar 的方式給業(yè)務應用暴露統(tǒng)一的訪問方式，簡化開發(fā)者的使用；還比如將分布式事務能力集成到 Database Mesh Sidecar 中的項目，以云原生分布式數(shù)據(jù)庫的方式為業(yè)務應用進行呈現(xiàn)。不管是哪種方式，都可以看出來 Database Mesh 理念正在不斷深入人心，逐步成長為一個繁榮的生態(tài)。

注：從左往右分別為“ShardingSphere-Sidecar、統(tǒng)一 Mesh 管控、分布式數(shù)據(jù)庫”三種 Database Mesh 1.0 的實現(xiàn)。

更近一步地，當業(yè)務應用開始以容器的方式進行打包交付、利用 CICD 流水線每天發(fā)布成百上千次到各個數(shù)據(jù)中心的 Kubernetes 基礎設施的時候，必然會引發(fā)對應用上層服務治理和對數(shù)據(jù)庫治理的思考，Database Mesh 就是這種思考之下的產(chǎn)物。如果沒有 Database Mesh，不管是 SDK 還是 Proxy，同樣可以支持對數(shù)據(jù)庫的訪問治理，Sidecar 本身并非 Database Mesh 的內(nèi)核，實際上是基礎架構全面云原生化的浪潮，在不斷推著 Database Mesh 前進。

Database Mesh 不是靜態(tài)的定義，而是一個在不斷進化的動態(tài)概念。

Database Mesh 從 1.0 開始，始終關注對數(shù)據(jù)庫流量的治理，基于數(shù)據(jù)庫協(xié)議感知能力，提供數(shù)據(jù)分片、負載均衡、可觀測性、審計等能力。這些能力已經(jīng)解決了數(shù)據(jù)庫治理中的屬于流量治理的部分問題。但對運維人員和數(shù)據(jù)庫管理人員來說，還有很多可以持續(xù)建設的方面。比如是否可以通過統(tǒng)一的配置聲明數(shù)據(jù)庫接入？是否可以通過可編程的方式，實現(xiàn)對數(shù)據(jù)庫訪問的資源限制？是否可以通過標準的界面自動化數(shù)據(jù)庫維護體驗？

在不同的用戶視角里，開發(fā)人員更關注運行效率、成本開銷，以及數(shù)據(jù)庫協(xié)議類型和訪問信息，不關心數(shù)據(jù)存儲的位置。運維和 DBA 更關注數(shù)據(jù)庫服務的自動化、穩(wěn)定性、安全性、監(jiān)控報警等，此外 DBA 還會關心數(shù)據(jù)的變更、容量、安全訪問、備份、遷移等等。這些問題都屬于數(shù)據(jù)庫可靠性工程的范疇。

正是隨著對數(shù)據(jù)庫治理場景的深入理解和對用戶體驗的極致追求，共同催生了 Database Mesh 2.0：通過可編程實現(xiàn)高性能擴展，應對云上數(shù)據(jù)庫治理挑戰(zhàn)。

Database Mesh 2.0 關注在云原生環(huán)境下，如何實現(xiàn)以下幾個目標：

• 進一步減輕開發(fā)人員的心智負擔，提高開發(fā)效率，提供透明和無感的數(shù)據(jù)庫基礎設施使用體驗；

• 以可配置、可插拔、可編程的方式，實現(xiàn)一個覆蓋數(shù)據(jù)庫流量、運行時資源和穩(wěn)定性保障等方面的治理框架；

• 為異構數(shù)據(jù)源、云原生數(shù)據(jù)庫、分布式數(shù)據(jù)庫等多個數(shù)據(jù)庫領域的典型場景提供標準的使用界面。

如前所述，業(yè)務開發(fā)人員主要關注業(yè)務邏輯和實現(xiàn)，無需關心基礎設施和其運維特征，而開發(fā)的體驗會逐步向 Serverless 的方向前進，對數(shù)據(jù)庫的訪問也就必然會變得越來越透明和無感。開發(fā)人員只需要了解自己業(yè)務所需要的數(shù)據(jù)存儲類型，然后使用預置的或者動態(tài)的身份機密信息，即可訪問相應的數(shù)據(jù)庫服務。

對于數(shù)據(jù)庫流量來說，不同的場景會有不同的負載均衡策略和防火墻規(guī)則，這些都可以以配置的形式提供給用戶。更進一步地，對于流量帶寬等運行時資源，可以通過加載可編程插件的方式對其進行限制。無論是配置還是插件，都希望給用戶提供框架之內(nèi)最大的靈活度，踐行 Unix “機制和策略分離”的設計哲學。

在數(shù)據(jù)庫上云的過程中，因為部署模式、數(shù)據(jù)遷移、數(shù)據(jù)容量等諸多問題，增加了上云的復雜度。而標準化的操作可以極大地幫助上云過程。如果可以有一套完整的操作界面，就可以在不同的數(shù)據(jù)庫環(huán)境里實現(xiàn)統(tǒng)一的治理行為，從而讓未來上云的過程變得更加順滑。

為實現(xiàn)上面的三個目標，Database Mesh 2.0 提供了一種以數(shù)據(jù)庫為中心的治理框架：

• 數(shù)據(jù)庫是一等公民：一切抽象都圍繞數(shù)據(jù)庫治理行為進行，比如訪問控制、流量治理、可觀測性等；

• 面向工程師體驗：對于開發(fā)人員，通過便捷易用的數(shù)據(jù)庫聲明和定義，即可繼續(xù)進行開發(fā)，無需關心數(shù)據(jù)庫的位置。對于運維和 DBA，提供多種數(shù)據(jù)庫治理行為抽象，實現(xiàn)自動化的數(shù)據(jù)庫可靠性工程；

• 云原生：以開放的生態(tài)和實現(xiàn)機制適配不同的云環(huán)境，面向云原生構建和實現(xiàn)，而無需擔心廠商鎖定。

這套治理框架依賴于如下工作負載：

• 虛擬數(shù)據(jù)庫：開發(fā)人員視角里一個可以被訪問的數(shù)據(jù)庫端點

• 流量策略：對數(shù)據(jù)庫訪問流量的治理策略，如分庫分表、負載均衡、限流、斷路

• 訪問控制：根據(jù)指定規(guī)則提供細粒度的訪問控制，如表級別

• 安全聲明：數(shù)據(jù)安全性聲明，如數(shù)據(jù)加密等

• 審計申請：記錄應用對數(shù)據(jù)庫的操作行為，如接入風控系統(tǒng)

• 可觀測性：數(shù)據(jù)庫的訪問流量、運行狀態(tài)、性能指標等可觀測性的配置

• 事件總線：接受數(shù)據(jù)變更的事件總線

• QoS 聲明：提高數(shù)據(jù)庫整體 SLO 指標而設定的資源 QoS 指標

• 備份計劃：按計劃任務的方式執(zhí)行數(shù)據(jù)庫備份

• Schema 流水線：以代碼方式管理數(shù)據(jù)庫 schema 變更，提高數(shù)據(jù)庫 DDL 和 DML 變更的成功率

基于這樣的設計，可以讓開發(fā)更集中更高效，讓云計算更親和。換句話說，Database Mesh 正在向著擴展性、易用性和標準化的方向大踏步地前進。

這個階段的 Database Mesh 為 2.0 階段。

目前 Database Mesh 官網(wǎng)（ https://www. ）已上線，相應的規(guī)范定義也開源在在 https://github.com/database-mesh/database-mesh 倉庫里。社區(qū)每兩周都會進行線上討論，信息如下：

歡迎各位讀者加入官方社區(qū)進行討論，Database Mesh 社區(qū)歡迎來自不同背景的愛好者們一起建設生態(tài)。

此外，Database Mesh 發(fā)起人張亮所在的 SphereEx 公司將于下月推出面向數(shù)據(jù)庫網(wǎng)格的開源解決方案 Pisanix（ https://www. ），歡迎各位關注。

作者介紹：

苗立堯，現(xiàn)任 SphereEx 云研發(fā)負責人，開源布道師，專注于 SaaS 和 Database Mesh。從 2015 年起開始接觸 Kubernetes，是國內(nèi)最早一批云原生實踐者，2016 年創(chuàng)辦“容器時代”公眾號，原創(chuàng)和翻譯引進了 600 余篇技術文章。曾在株式會社ネットスターズ、北京穿楊科技、螞蟻金服、易寶支付等擔任基礎設施架構師、云產(chǎn)品負責人、云原生研發(fā)工程師等相關職位。

Github: https://github.com/mlycore

張亮，SphereEx 公司創(chuàng)始人 & CEO，歷任多家大型知名互聯(lián)網(wǎng)企業(yè)的架構、數(shù)據(jù)庫團隊負責人。熱愛開源，是 Apache ShardingSphere、ElasticJob 等知名開源項目創(chuàng)始人 & 項目管理委員會主席、現(xiàn)任 Apache 軟件基金會會員、微軟 MVP、騰訊云 TVP。擁有超過 10 年的架構和數(shù)據(jù)庫領域探索、實踐經(jīng)驗。擅長分布式架構，推崇優(yōu)雅代碼，在分布式數(shù)據(jù)庫技術和學術等方面均取得重大成果。曾在 ApacheCon、QCon、AWS 峰會、DTCC、SACC、DTC 等數(shù)十個國內(nèi)和國際重大行業(yè)和技術峰會中擔任出品人和分享嘉賓。曾出版書籍《未來架構——從服務化到云原生》，并在數(shù)據(jù)庫行業(yè)頂級會議 ICDE 發(fā)表論文《Apache ShardingSphere：A Holistic and Pluggable Platform for Data Sharding》。

GitHub: https://github.com/terrymanu