數(shù)據(jù)庫(kù)網(wǎng)格Database Mesh概要介紹

1、 數(shù)據(jù)庫(kù)網(wǎng)格Database Mesh概要介紹在微服務(wù)和云原生大潮的卷席之下，服務(wù)化一直以來(lái)是人們關(guān)注的重點(diǎn)。但服務(wù)化之后，真正繞不開(kāi)的數(shù)據(jù)訪問(wèn)卻鮮有論道。盡管目前的關(guān)系型數(shù)據(jù)庫(kù)遠(yuǎn)達(dá)不到云原生的要求，并且對(duì)分布式的不友好在長(zhǎng)期以來(lái)也飽受詬病，但不可否置的是，關(guān)系型數(shù)據(jù)庫(kù)至今依然扮演著極其重要的角色。從其本身以及周邊生態(tài)圈的成熟度、數(shù)據(jù)查詢(xún)的靈活度、開(kāi)發(fā)工程師以及 DBA 對(duì)其的掌控程度以及招聘到適合人員的難易度等方面來(lái)看，無(wú)論是 NoSQL 還是 NewSQL，實(shí)難于在近期完全取而代之。那么，對(duì)于微服務(wù)架構(gòu)中越來(lái)越多的數(shù)據(jù)庫(kù)垂直拆分，以及數(shù)據(jù)量急劇膨脹后的數(shù)據(jù)庫(kù)水平拆分，是否存在行之有效的方案

2、來(lái)管理呢？當(dāng)今大為流行的 Service Mesh 理念又能否對(duì)數(shù)據(jù)庫(kù)的治理帶來(lái)一些啟示呢？Database Mesh Database Mesh，一個(gè)搭乘 Service Mesh 浪潮衍生出來(lái)的新興詞匯。顧名思義，Database Mesh 使用一個(gè)嚙合層，將散落在系統(tǒng)各個(gè)角落中的數(shù)據(jù)庫(kù)統(tǒng)一治理起來(lái)。通過(guò)嚙合層集中在一起的應(yīng)用與數(shù)據(jù)庫(kù)之間的交互網(wǎng)絡(luò)，就像蜘蛛網(wǎng)一樣復(fù)雜而有序。從這一點(diǎn)來(lái)看，Database Mesh 的概念與 Service Mesh 如出一轍。之所以稱(chēng)其為 Database Mesh，而非 Data Mesh，是因?yàn)樗氖滓繕?biāo)并非嚙合存儲(chǔ)于數(shù)據(jù)庫(kù)中的數(shù)據(jù)，而是嚙合應(yīng)用與

3、數(shù)據(jù)庫(kù)間的交互。Database Mesh 的關(guān)注重點(diǎn)在于如何將分布式的數(shù)據(jù)訪問(wèn)應(yīng)用與數(shù)據(jù)庫(kù)有機(jī)串聯(lián)起來(lái)，它更加關(guān)注的是交互，是將雜亂無(wú)章的應(yīng)用與數(shù)據(jù)庫(kù)之間的交互有效的梳理。使用 Database Mesh，訪問(wèn)數(shù)據(jù)庫(kù)的應(yīng)用和數(shù)據(jù)庫(kù)終將形成一個(gè)巨大的網(wǎng)格體系，應(yīng)用和數(shù)據(jù)庫(kù)只需在網(wǎng)格體系中對(duì)號(hào)入座即可，它們都是被嚙合層所治理的對(duì)象。Service Mesh 回顧 服務(wù)治理主要關(guān)注服務(wù)發(fā)現(xiàn)、負(fù)載均衡、動(dòng)態(tài)路由、降級(jí)熔斷、調(diào)用鏈路以及 SLA 采集等非功能性需求。通常來(lái)說(shuō)，可以通過(guò)代理端和客戶(hù)端這兩種架構(gòu)方案實(shí)現(xiàn)。代理端的方案是基于網(wǎng)關(guān)的。提供服務(wù)的應(yīng)用服務(wù)器被隱藏在網(wǎng)關(guān)之后，訪問(wèn)請(qǐng)求必須經(jīng)由網(wǎng)關(guān)，

4、由網(wǎng)關(guān)進(jìn)行相應(yīng)的服務(wù)治理動(dòng)作后，再將流量路由至后端應(yīng)用。Nginx、Kong、Kubernetes Ingress 等采用此類(lèi)方案?？蛻?hù)端的方案則是由部署在應(yīng)用端的類(lèi)庫(kù)進(jìn)行相應(yīng)的服務(wù)治理動(dòng)作，并以點(diǎn)對(duì)點(diǎn)的方式訪問(wèn)服務(wù)提供者。Dubbo、Spring Cloud 等采用此種方案。無(wú)論使用代理端還是客戶(hù)端進(jìn)行服務(wù)治理，都有其各自的優(yōu)缺點(diǎn)。在代理端進(jìn)行服務(wù)治理的優(yōu)點(diǎn)是應(yīng)用只需獲取網(wǎng)關(guān)地址即可，后端的復(fù)雜部署結(jié)構(gòu)被完全屏蔽。缺點(diǎn)則是代理端自身的性能和可用性是整個(gè)系統(tǒng)的瓶頸，一旦宕機(jī)后果較為嚴(yán)重。其中心化架構(gòu)理念，與云原生背道而馳。在客戶(hù)端進(jìn)行服務(wù)治理的優(yōu)點(diǎn)是使用無(wú)中心化架構(gòu)，無(wú)需擔(dān)心某個(gè)節(jié)點(diǎn)成為系統(tǒng)瓶

5、頸。缺點(diǎn)則是服務(wù)治理對(duì)業(yè)務(wù)代碼的侵入。對(duì)于云原生所看重的零侵入來(lái)說(shuō)，使用客戶(hù)端進(jìn)行服務(wù)治理的方式顯然是不可行的?？蛻?hù)端治理的方案更無(wú)法做到對(duì)異構(gòu)語(yǔ)言的支持。在既希望零入侵、又需要無(wú)中心的云原生架構(gòu)下，第三種架構(gòu)模型Sidecar 則顯得更加契合。Sidecar 以一個(gè)獨(dú)立的進(jìn)程啟動(dòng)，可以每臺(tái)宿主機(jī)共用同一個(gè) Sidecar 進(jìn)程，也可以每個(gè)應(yīng)用獨(dú)占一個(gè) Sidecar 進(jìn)程。所有的服務(wù)治理功能，都由 Sidecar 接管，應(yīng)用的對(duì)外訪問(wèn)僅需要訪問(wèn) Sidecar 即可。顯而易見(jiàn)，基于 Sidecar 模式的 Service Mesh 才是云原生架構(gòu)的更好的實(shí)現(xiàn)方式，零侵入和無(wú)中心化使得 Ser

6、vice Mesh 倍受推崇。尤其是配合 Mesos 或 Kubernetes 一起使用時(shí)，通過(guò) Marathon 或 DeamonSet 確保 Sidecar 在每個(gè)宿主機(jī)都能夠啟動(dòng)，再配合其對(duì)容器的動(dòng)態(tài)調(diào)度能力，能發(fā)揮更大的威力。Kubernetes（Mesos） + Service Mesh = 彈性伸縮 + 零侵入 + 無(wú)中心，它們合力完成了一個(gè)云端所需的基礎(chǔ)設(shè)施。Database Mesh 與 Service Mesh 的異同 數(shù)據(jù)庫(kù)應(yīng)用治理與服務(wù)治理的目標(biāo)既有重疊，又有所不同。相比于服務(wù)，數(shù)據(jù)庫(kù)是有狀態(tài)的，無(wú)法像服務(wù)一樣隨意路由到對(duì)等節(jié)點(diǎn)，因此數(shù)據(jù)分片是一個(gè)重要的能力。相對(duì)來(lái)說(shuō)，數(shù)

7、據(jù)庫(kù)實(shí)例的自動(dòng)發(fā)現(xiàn)能力則不那么重要，原因也是數(shù)據(jù)庫(kù)的有狀態(tài)性，啟動(dòng)或停止一個(gè)新的數(shù)據(jù)庫(kù)實(shí)例，往往意味著數(shù)據(jù)遷移。當(dāng)然也可以采用多數(shù)據(jù)副本、讀寫(xiě)分離、主庫(kù)多寫(xiě)等方式進(jìn)行進(jìn)一步的處理。其他功能諸如對(duì)多從庫(kù)的負(fù)載均衡、熔斷、鏈路采集等，在數(shù)據(jù)庫(kù)治理中也同樣適用。與服務(wù)治理一樣，對(duì)數(shù)據(jù)庫(kù)應(yīng)用的治理同樣可以套用這三種架構(gòu)方案。基于代理端的解決方案是使用一個(gè)實(shí)現(xiàn)相應(yīng)數(shù)據(jù)庫(kù)通信協(xié)議（如 MySQL）的代理服務(wù)器。Cobar、MyCAT、kingshard 以及即將推出的 Sharding-JDBC-Server 等采用此種方案?；诳蛻?hù)端的解決方案則必須與開(kāi)發(fā)語(yǔ)言強(qiáng)綁定，例如 Java 語(yǔ)言一般可以通過(guò) J

8、DBC 或某個(gè) ORM 框架來(lái)實(shí)現(xiàn)。TDDL 和 Sharding-JDBC 等采用此種方案。同理，無(wú)論是代理端還是客戶(hù)端，都有各自的優(yōu)缺點(diǎn)。代理端的優(yōu)點(diǎn)是異構(gòu)語(yǔ)言的支持，缺點(diǎn)依然是中心化架構(gòu)。客戶(hù)端的優(yōu)點(diǎn)是無(wú)中心化架構(gòu)，缺點(diǎn)則是無(wú)法支持異構(gòu)語(yǔ)言，因此，對(duì)各種數(shù)據(jù)庫(kù)的命令行以及圖形界面的客戶(hù)端便無(wú)法有效支持。采用 Sidecar 模式，同樣可以有效的結(jié)合代理端與客戶(hù)端的優(yōu)點(diǎn)，并屏蔽其缺點(diǎn)。但是，基于服務(wù)治理的 Sidecar 和基于數(shù)據(jù)庫(kù)訪問(wèn)的 Sidecar 是一樣的么？當(dāng)然不是。最主要的不同在于數(shù)據(jù)分片。分片是一個(gè)復(fù)雜的過(guò)程，如果希望做到對(duì)應(yīng)用透明，業(yè)界常見(jiàn)的做法是針對(duì) SQL 進(jìn)行解析，

9、并將其精準(zhǔn)路由至相應(yīng)的數(shù)據(jù)庫(kù)中執(zhí)行，最終將執(zhí)行結(jié)果進(jìn)行歸并，以保證數(shù)據(jù)在分片的情況下邏輯仍然正確。一個(gè)數(shù)據(jù)分片的核心流程是 SQL 解析 SQL 路由 SQL 改寫(xiě) SQL 執(zhí)行 結(jié)果歸并。為了滿(mǎn)足對(duì)遺留代碼的零侵入，還需要對(duì) SQL 的執(zhí)行協(xié)議進(jìn)行封裝。比如，在代理端則需要模擬 MySQL 或其他相應(yīng)數(shù)據(jù)庫(kù)的通信協(xié)議；在 Java 客戶(hù)端實(shí)現(xiàn)，則需要覆蓋 JDBC 接口的相應(yīng)方法。說(shuō)了很多，那么當(dāng)前是否有 Database Mesh 的實(shí)現(xiàn)方案呢？遺憾的是，目前還沒(méi)有。即使是流行度很廣的 Service Mesh，它的各個(gè)產(chǎn)品也都還是在成熟的路上。出現(xiàn)稍早的 Linkerd 和 Envoy

10、雖然可以在生產(chǎn)環(huán)境使用，但新一代的 Istio 以更加宏偉的構(gòu)圖吸引著業(yè)界的眼球，只是目前還無(wú)法用于生產(chǎn)環(huán)境。Database Mesh 作為 Service Mesh 的延展，則更是處于發(fā)展的萌芽狀態(tài)。Sharding-JDBC Sharding-JDBC 于 2016 年由當(dāng)當(dāng)開(kāi)源。最初，它是一個(gè)在 Java 的 JDBC 層實(shí)現(xiàn)分庫(kù)分表的數(shù)據(jù)庫(kù)中間層。今年，京東金融云決定將 Sharding-JDBC 作為其核心的對(duì)外輸出。那么，Sharding-JDBC 勢(shì)必要進(jìn)行革新，面對(duì)云端，Database Mesh 無(wú)疑是正確的發(fā)展方向。Sharding-JDBC 決定實(shí)現(xiàn) Sidecar 版

11、本，期望可以成為一個(gè)純粹的云原生數(shù)據(jù)庫(kù)中間層產(chǎn)品。目標(biāo) Sharding-JDBC 的終極目標(biāo)是像使用一個(gè)數(shù)據(jù)庫(kù)一樣透明的使用散落在各個(gè)系統(tǒng)中的數(shù)據(jù)庫(kù)。讓?xiě)?yīng)用開(kāi)發(fā)者和 DBA 盡可能順暢地將其工作遷移至基于 Sharding-JDBC 的云原生環(huán)境中。Sharding-JDBC 希望提供一個(gè)無(wú)中心化、零侵入以及跨語(yǔ)言的云原生解決方案。演進(jìn)歷程 Sharding-JDBC 一直以來(lái)，以 JDBC 層分片作為其核心理念。它的架構(gòu)圖如下：它分為分片模塊、柔性事務(wù)模塊以及數(shù)據(jù)庫(kù)治理模塊。作為其核心的分片模塊完整的實(shí)現(xiàn)了 SQL 解析、路由、改寫(xiě)、執(zhí)行和歸并的過(guò)程。但是，作為一個(gè)立志服務(wù)于云原生架構(gòu)的產(chǎn)

12、品，僅在 JDBC 層提供服務(wù)是遠(yuǎn)遠(yuǎn)不夠的。Sharding-JDBC 將分別實(shí)現(xiàn) Driver、Server 以及 Sidecar 這三個(gè)不同的版本，一起組成 Sharding-JDBC 的生態(tài)圈，為不同的需求與環(huán)境提供更加具有針對(duì)性的差異化服務(wù)。近期，Sharding-JDBC 將發(fā)布其 Server 版本。在不久的將來(lái)，Sharding-JDBC 的 Sidecar 版本也將投入開(kāi)發(fā)。原有的 Sharding-JDBC 將重命名為 Sharding-JDBC-Driver。由于分片的核心功能已經(jīng)實(shí)現(xiàn)完畢，因此架構(gòu)模型的調(diào)整并不復(fù)雜，Sharding-JDBC-Server 的核心代碼仍然

13、使用 Sharding-JDBC 的原有分片邏輯，只是在外圍包裝了 MySQL 協(xié)議，未來(lái)也將提供其他數(shù)據(jù)庫(kù)的兼相關(guān)容協(xié)議。架構(gòu)圖如下：由于 Sharding-JDBC-Server 的出現(xiàn)，使得原來(lái) DBA 通過(guò) Sharding-JDBC-Driver 無(wú)法對(duì)數(shù)據(jù)進(jìn)行操作的缺憾得到了補(bǔ)償。由于 Sharding-JDBC-Driver 無(wú)需通過(guò)代理層進(jìn)行二次轉(zhuǎn)發(fā)，因此線上性能更佳，可以通過(guò)以下的混合部署方案使用 Sharding-JDBC:線上應(yīng)用使用 Sharding-JDBC-Driver 直連數(shù)據(jù)庫(kù)以獲取最優(yōu)性能，使用 MySQL 命令行或 UI 客戶(hù)端連接 Sharding-JDB

14、C-Server 方便的查詢(xún)數(shù)據(jù)和執(zhí)行各種 DDL 語(yǔ)句。它們使用同一個(gè)注冊(cè)中心集群，通過(guò)管理端配置注冊(cè)中心中的數(shù)據(jù)，即可由注冊(cè)中心自動(dòng)將配置變更推送至 Driver 和 Server 應(yīng)用。若數(shù)據(jù)庫(kù)拆分的過(guò)多而導(dǎo)致連接數(shù)會(huì)暴漲，則可以考慮直接在線上使用 Sharding-JDBC-Server，以達(dá)到有效控制連接數(shù)的目的。在不久的將來(lái)，Sharding-JDBC-Sidecar 也將問(wèn)世，它的部署架構(gòu)是這樣的：基于 Sharding-JDBC 的 Database Mesh 與 Service Mesh 互不干擾，相得益彰。服務(wù)之間的交互由 Service Mesh Sidecar 接管，基

15、于 SQL 的數(shù)據(jù)庫(kù)訪問(wèn)由 Sharding-JDBC-Sidecar 接管。對(duì)于業(yè)務(wù)應(yīng)用來(lái)說(shuō)，無(wú)論是 RPC 還是對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)，都無(wú)需關(guān)注其真實(shí)的物理部署結(jié)構(gòu)，做到真正的零侵入。由于 Sharding-JDBC-Sidecar 是隨著宿主機(jī)的生命周期創(chuàng)建和消亡的，因此，它并非靜態(tài) IP，而是完全動(dòng)態(tài)和彈性的存在，整個(gè)系統(tǒng)中并無(wú)任何中心節(jié)點(diǎn)的存在。對(duì)于數(shù)據(jù)運(yùn)維等操作，仍然可以通過(guò)啟動(dòng)一個(gè) Sharding-JDBC-Server 的進(jìn)程作為靜態(tài) IP 的入口，通過(guò)各種命令行或 UI 客戶(hù)端進(jìn)行操作。撥開(kāi) Sharding-JDBC 的迷霧 Sharding-JDBC 自誕生以來(lái)，使用手冊(cè)已經(jīng)

16、比較完善。但由于它一直處于高速發(fā)展的狀態(tài)中，因此很少對(duì)外披露其內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)。雖然代碼都是開(kāi)源的，但要求技術(shù)人員在選型時(shí)將第三方的代碼都通讀一遍，顯然是不現(xiàn)實(shí)的。篇幅有限，本文無(wú)法將 Sharding-JDBC 的所有源碼從頭到尾分析一遍，但可以對(duì)常見(jiàn)的疑問(wèn)給予解答。1. Sharding-JDBC 的 SQL 解析是如何做的，效率是否有問(wèn)題?回答：Sharding-JDBC 采用詞法 + 語(yǔ)法解析的方式解析 SQL，先將 SQL 拆成一個(gè)個(gè)詞根，再根據(jù) SQL 語(yǔ)法配合其上下文進(jìn)行語(yǔ)法解析。Sharding-JDBC 的 SQL 解析并不會(huì)產(chǎn)生 AST（抽象語(yǔ)法樹(shù)），而是直接將分片所需的解析

17、上下文提煉出來(lái)，如：Tables、Select Items、Conditions、Order Items、Group By Items、Limit 等。并直接將解析上下文應(yīng)用于路由，免去了對(duì) AST 的二次遍歷，進(jìn)一步提升了性能。Sharding-JDBC 的一個(gè)較為復(fù)雜的 SQL 解析大約需要 10ms，相對(duì)于 JSqlParser 等基于 JavaCC 的 SQL 解析器，性能會(huì)快數(shù)倍甚至十倍以上。2. Sharding-JDBC 對(duì)于分頁(yè)、排序和分組等查詢(xún)，是否需要將數(shù)據(jù)全部取到內(nèi)存中進(jìn)行操作，這樣內(nèi)存是否會(huì)被撐爆？回答： Sharding-JDBC 使用流式歸并和內(nèi)存歸并兩種歸并方式，

18、流式歸并是完全不占用內(nèi)存的，其原理與 JDBC 的 ResultSet 一樣，每調(diào)用一次 next，數(shù)據(jù)的游標(biāo)會(huì)下移一位；而內(nèi)存歸并是需要占用內(nèi)存的，會(huì)將 ResultSet 中所有的數(shù)據(jù)全部取出放入內(nèi)存才能進(jìn)行歸并?？赡芘c大部分人的想象不同，Sharding-JDBC 僅在一種情況下才會(huì)使用內(nèi)存歸并，即 ORDER BY 與 GROUP BY 同時(shí)存在且排序不一致時(shí)。而 LIMIT、僅 ORDER BY、僅 GROUP BY 以及 ORDER BY 與 GROUP BY 同時(shí)存在但順序相同的情況下，都是流式歸并，不會(huì)占用額外內(nèi)存。具體的實(shí)現(xiàn)細(xì)節(jié)在本文中無(wú)法詳盡說(shuō)明，以后會(huì)有更多的文章另行分析

19、?？傊琒harding-JDBC 在內(nèi)核方面做了大量?jī)?yōu)化。具不完全統(tǒng)計(jì)，已經(jīng)有幾十甚至上百家公司在使用 Sharding-JDBC，這其中不乏一些知名企業(yè)。在逐漸撥開(kāi)迷霧的同時(shí)，希望 Sharding-JDBC 能夠?yàn)榧夹g(shù)選型者帶來(lái)充足的信心。未來(lái)規(guī)劃 2018 年的 Sharding-JDBC 仍將是快速發(fā)展一年。未來(lái)的規(guī)劃重點(diǎn)在以下四個(gè)方面：云原生。Sharding-JDBC-Driver 已經(jīng)比較成熟，Sharding-JDBC-Server 即將于近期發(fā)布，Sharding-JDBC-Sidecar 也將于近期提上日程。Sharding-JDBC 將全面擁抱這三種架構(gòu)模型。讓其在云原生架構(gòu)中熠熠生輝。SQL 兼