[[346382]]

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

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

而數(shù)據(jù)庫中間件，也火了很長一段時間，基本上每個大廠都會自研一套。

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

2. 實現(xiàn)方式

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

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

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

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

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

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

2.2 框架層
主要是修改或增強現(xiàn)有ORM框架的功能，在SQL中增加一些自定義原語或者hint來實現(xiàn)。

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

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

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

2.3 驅(qū)動層
無論是從代碼層還是框架層做處理，都是高侵入、難維護的。

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

什么意思是smart-client呢？

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

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

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

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

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

優(yōu)點：

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

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

缺點：

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

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

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

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

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

優(yōu)點：

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

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

缺點：

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

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

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

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

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

優(yōu)點：

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

缺點：

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

目前還沒正式上線。

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

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

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

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

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

其他還有比如：

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

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

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

4. 展望
從上文的分析可以看出，盡管目前主流的數(shù)據(jù)庫中間件還是在smart-client和proxy兩個層面進行處理的，但是，已經(jīng)能看到未來的方向了。云原生的到來，數(shù)據(jù)庫中間件也會擁抱變化。

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

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