1.前言

隨著業(yè)務(wù)的發(fā)展，MySQL數(shù)據(jù)庫中的表會(huì)越來越多，表中的數(shù)據(jù)量也會(huì)越來越大，相應(yīng)地，數(shù)據(jù)操作的開銷也會(huì)越來越大；另外，無論怎樣升級(jí)硬件資源，單臺(tái)服務(wù)器的資源（CPU、磁盤、內(nèi)存、網(wǎng)絡(luò)IO、事務(wù)數(shù)、連接數(shù)）總是有限的，最終數(shù)據(jù)庫所能承載的數(shù)據(jù)量、數(shù)據(jù)處理能力都將遭遇瓶頸。

分表、分庫和讀寫分離可以有效地減小單臺(tái)數(shù)據(jù)庫的壓力。

本文主要針對(duì)業(yè)界主流的數(shù)據(jù)庫中間件的實(shí)現(xiàn)、功能、成本等方面進(jìn)行對(duì)比，總結(jié)數(shù)據(jù)庫中間件的實(shí)現(xiàn)方式，并展望未來的可能發(fā)展。

2. 實(shí)現(xiàn)方式

一般來說，對(duì)于數(shù)據(jù)庫中間件，可以在以下六個(gè)層次做切入。

2.1 代碼層

在同一個(gè)項(xiàng)目中創(chuàng)建多個(gè)數(shù)據(jù)源，采用if else的方式，直接根據(jù)條件在代碼中路由。

Spring中有動(dòng)態(tài)切換數(shù)據(jù)源的抽象類，具體參見AbstractRoutingDataSource。

如果項(xiàng)目不是很龐大，使用這種方式能夠快速的進(jìn)行分庫。但缺點(diǎn)也是顯而易見的，這種海量的代碼侵入是絕不能被接受的。

而且當(dāng)查詢結(jié)果返回時(shí)，需要對(duì)跨庫、聚合等查詢結(jié)果進(jìn)行歸并，開發(fā)工作量非常巨大。

這種方式了解一下即可，一般不會(huì)去使用。

2.2 框架層

主要是修改或增強(qiáng)現(xiàn)有ORM框架的功能，在SQL中增加一些自定義原語或者h(yuǎn)int來實(shí)現(xiàn)。

常見的比如實(shí)現(xiàn)一些攔截器（比如Mybatis的Interceptor接口），增加一些自定義解析來控制數(shù)據(jù)的流向，效果雖然較好，但會(huì)改變一些現(xiàn)有的編程經(jīng)驗(yàn)。

這種情況適合公司ORM框架統(tǒng)一的情況，但在很多情況下不太現(xiàn)實(shí)。

而且大部分情況下要修改框架源碼，因此，也不推薦。

2.3 驅(qū)動(dòng)層

無論是從代碼層還是框架層做處理，都是高侵入、難維護(hù)的。

因此，常見的數(shù)據(jù)庫中間件，至少需要從驅(qū)動(dòng)層開始，我們可以理解為一個(gè)smart-client。

什么意思是smart-client呢？

通常smart-client是在連接池或者driver的基礎(chǔ)上進(jìn)行了一層封裝。

這個(gè)smart-client內(nèi)部可以與不同的數(shù)據(jù)庫建立連接。

服務(wù)需要查詢的sql，就交給smart-client進(jìn)行解析、優(yōu)化，然后發(fā)送給具體的數(shù)據(jù)庫進(jìn)行操作。

例如在讀寫分離情況下，smart-client會(huì)選擇sql走從庫還是主庫；在分庫分表的情況下，進(jìn)行sql解析、sql改寫等操作，然后路由到不同的分庫，將得到的結(jié)果進(jìn)行合并，返回給應(yīng)用。

我們熟知的TDDL、Sharding-JDBC等，都是在此層切入。

優(yōu)點(diǎn)：

1）實(shí)現(xiàn)方便，業(yè)務(wù)無入侵。smart-client不需要實(shí)現(xiàn)客戶端通信協(xié)議，只需要在數(shù)據(jù)數(shù)據(jù)庫廠商提供的不同語言的數(shù)據(jù)庫驅(qū)動(dòng)上做封裝即可。例如mysql針對(duì)java語言提供了mysql-connector-java驅(qū)動(dòng)，針對(duì)python提供了mysql-connector-python驅(qū)動(dòng)。

2）天然去中心化。smart-client以sdk的方式被應(yīng)用引入，然后部署到不同的服務(wù)節(jié)點(diǎn)上，不需要有代理層proxy。因此相較于代理方式而言，不需要考慮高可用的問題。只要應(yīng)用的節(jié)點(diǎn)沒有全部宕機(jī)，就可以訪問數(shù)據(jù)庫。(這里的高可用是相比代理層proxy而言，數(shù)據(jù)庫本身的高可用還是需要保證的)

缺點(diǎn)：

1）通常僅支持某一種語言。例如tddl、zebra、sharding-jdbc都是使用java語言開發(fā)，因此對(duì)于使用其他語言的用戶，就無法使用這些中間件。如果其他語言要使用，那么就要開發(fā)多語言客戶端。

2）版本升級(jí)困難。因?yàn)閼?yīng)用使用數(shù)據(jù)源代理就是引入一個(gè)jar包的依賴，在有多個(gè)應(yīng)用都對(duì)某個(gè)版本的jar包產(chǎn)生依賴時(shí)，一旦這個(gè)版本有bug，所有的應(yīng)用都需要升級(jí)。而數(shù)據(jù)庫代理升級(jí)則相對(duì)容易，因?yàn)榉?wù)是單獨(dú)部署的，只要升級(jí)這個(gè)代理服務(wù)器，所有連接到這個(gè)代理的應(yīng)用自然也就相當(dāng)于都升級(jí)了。

3）去中心化的缺點(diǎn)，比如無法做全局的sql限流

2.4 代理層

在應(yīng)用中，我們通過一個(gè)普通的數(shù)據(jù)源(c3p0、druid、dbcp等)與代理服務(wù)器建立連接，所有的sql操作語句都是發(fā)送給這個(gè)代理，由這個(gè)代理去操作底層數(shù)據(jù)庫，得到結(jié)果并返回給應(yīng)用。在這種方案下，分庫分表和讀寫分離的邏輯對(duì)開發(fā)人員是完全透明的。

像MySQL Router、MyCat、ShardingSphere（proxy模式）等，都是在此層切入。

優(yōu)點(diǎn)：

1）多語言支持。也就是說，不論你用的php、java或是其他語言，都可以支持。以mysql數(shù)據(jù)庫為例，如果proxy本身實(shí)現(xiàn)了mysql的通信協(xié)議，那么你可以就將其看成一個(gè)mysql 服務(wù)器，因此不同語言的開發(fā)者都可以使用mysql官方提供的對(duì)應(yīng)的驅(qū)動(dòng)來與這個(gè)代理服務(wù)器建通信。

2）對(duì)業(yè)務(wù)開發(fā)同學(xué)透明。由于可以把proxy當(dāng)成mysql服務(wù)器，理論上業(yè)務(wù)同學(xué)不需要進(jìn)行太多代碼改造，既可以完成接入。

缺點(diǎn)：

1）實(shí)現(xiàn)復(fù)雜。因?yàn)閜roxy需要實(shí)現(xiàn)被代理的數(shù)據(jù)庫server端的通信協(xié)議，實(shí)現(xiàn)難度較大。

2）proxy本身需要保證高可用。由于應(yīng)用本來是直接訪問數(shù)據(jù)庫，現(xiàn)在改成了訪問proxy，意味著proxy必須保證高可用。否則，數(shù)據(jù)庫沒有宕機(jī)，proxy掛了，導(dǎo)致數(shù)據(jù)庫無法正常訪問，就尷尬了。

3）租戶隔離。可能有多個(gè)應(yīng)用訪問proxy代理的底層數(shù)據(jù)庫，必然會(huì)對(duì)proxy自身的內(nèi)存、網(wǎng)絡(luò)、cpu等產(chǎn)生資源競(jìng)爭(zhēng)，proxy需要需要具備隔離的能力。

2.5 Sidecar

Sharding-Sidecar是ShardingSphere的第三個(gè)產(chǎn)品，目前仍然在規(guī)劃中。 定位為Kubernetes或Mesos的云原生數(shù)據(jù)庫代理，以DaemonSet的形式代理所有對(duì)數(shù)據(jù)庫的訪問。

通過無中心、零侵入的方案提供與數(shù)據(jù)庫交互的的嚙合層，即Database Mesh，又可稱數(shù)據(jù)網(wǎng)格。 Database Mesh的關(guān)注重點(diǎn)在于如何將分布式的數(shù)據(jù)訪問應(yīng)用與數(shù)據(jù)庫有機(jī)串聯(lián)起來，它更加關(guān)注的是交互，是將雜亂無章的應(yīng)用與數(shù)據(jù)庫之間的交互有效的梳理。使用Database Mesh，訪問數(shù)據(jù)庫的應(yīng)用和數(shù)據(jù)庫終將形成一個(gè)巨大的網(wǎng)格體系，應(yīng)用和數(shù)據(jù)庫只需在網(wǎng)格體系中對(duì)號(hào)入座即可，它們都是被嚙合層所治理的對(duì)象。

優(yōu)點(diǎn)：

分布式云原生的數(shù)據(jù)庫中間件模式，集成了jdbc和proxy各自的優(yōu)點(diǎn)，能滿足高可用、跨語言、無感知升級(jí)等多種優(yōu)勢(shì)特性

缺點(diǎn)：

需要整體架構(gòu)支持云原生體系

目前還沒正式上線。

2.6 存儲(chǔ)層

這個(gè)層次實(shí)際上不應(yīng)該叫數(shù)據(jù)庫中間件了，需要更換存儲(chǔ)。

比如Aurora、polardb、tidb等分布式數(shù)據(jù)庫，通過計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)分離，計(jì)算節(jié)點(diǎn)scale up，存儲(chǔ)節(jié)點(diǎn)scale out的理念將公有云的關(guān)系數(shù)據(jù)庫產(chǎn)品推向了一個(gè)新的高度。

這樣一來，實(shí)際上已經(jīng)不再需要傳統(tǒng)的數(shù)據(jù)庫中間件了，一切問題天然就不存在了。

3. 功能對(duì)比

從上文可以了解到，目前最主流的數(shù)據(jù)庫中間件主要是從驅(qū)動(dòng)層smart-client和代理層proxy切入的。

下面，我們來了解下業(yè)界主流的中間件產(chǎn)品在這兩個(gè)層次的站隊(duì)情況與實(shí)現(xiàn)的功能對(duì)比。

其他還有比如：

Atlas、Kingshard、DBProxy、mysql router、MaxScale、58 Oceanus、ArkProxy、Ctrip DAL、Tsharding、Youtube vitess、網(wǎng)易DDB、Heisenberg、proxysql、Mango、DDAL、Datahekr、MTAtlas、

我們可以看到，基本各個(gè)大廠都擼過一遍自己的中間件產(chǎn)品。不過目前開源而且比較火的已經(jīng)不多了，主要還是以shardingsphere為主。

我們從功能維度，來對(duì)比一下幾個(gè)產(chǎn)品。

4. 展望

從上文的分析可以看出，盡管目前主流的數(shù)據(jù)庫中間件還是在smart-client和proxy兩個(gè)層面進(jìn)行處理的，但是，已經(jīng)能看到未來的方向了。云原生的到來，估計(jì)會(huì)做進(jìn)一步的降維打擊。

一方面是作為sidecar的模式，可能會(huì)有一個(gè)新的階段，比如shardingsphere推出sidecar模式后。

而另一方面，云數(shù)據(jù)庫通過全新的計(jì)算存儲(chǔ)分離的架構(gòu)方式，打破傳統(tǒng)關(guān)系型數(shù)據(jù)庫的性能瓶頸，傳統(tǒng)數(shù)據(jù)庫中間件將不再需要關(guān)注，一切都將以數(shù)據(jù)庫基礎(chǔ)設(shè)施的形式提供給使用者。

都看到最后了，原創(chuàng)不易，點(diǎn)個(gè)關(guān)注，點(diǎn)個(gè)贊吧～
知識(shí)碎片重新梳理，構(gòu)建Java知識(shí)圖譜：https://github.com/saigu/JavaKnowledgeGraph（歷史文章查閱非常方便）
掃碼關(guān)注我的公眾號(hào)“阿丸筆記”，第一時(shí)間獲取最新更新。同時(shí)能免費(fèi)獲取海量Java技術(shù)棧電子書、各個(gè)大廠面試題哦。

總結(jié)

以上是生活随笔為你收集整理的java中间件是什么意思_数据库中间件漫谈的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。