建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
1.前言
隨著業(yè)務(wù)的發(fā)展，MySQL數(shù)據(jù)庫(kù)中的表會(huì)越來(lái)越多，表中的數(shù)據(jù)量也會(huì)越來(lái)越大，相應(yīng)地，數(shù)據(jù)操作的開(kāi)銷(xiāo)也會(huì)越來(lái)越大；另外，無(wú)論怎樣升級(jí)硬件資源，單臺(tái)服務(wù)器的資源（CPU、磁盤(pán)、內(nèi)存、網(wǎng)絡(luò)IO、事務(wù)數(shù)、連接數(shù)）總是有限的，最終數(shù)據(jù)庫(kù)所能承載的數(shù)據(jù)量、數(shù)據(jù)處理能力都將遭遇瓶頸。
為龍安等地區(qū)用戶(hù)提供了全套網(wǎng)頁(yè)設(shè)計(jì)制作服務(wù)，及龍安網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、龍安網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專(zhuān)業(yè)、用心的態(tài)度為用戶(hù)提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶(hù)的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！
分表、分庫(kù)和讀寫(xiě)分離可以有效地減小單臺(tái)數(shù)據(jù)庫(kù)的壓力。
而數(shù)據(jù)庫(kù)中間件，也火了很長(zhǎng)一段時(shí)間，基本上每個(gè)大廠(chǎng)都會(huì)自研一套。
本文主要針對(duì)業(yè)界主流的數(shù)據(jù)庫(kù)中間件的實(shí)現(xiàn)、功能、成本等方面進(jìn)行對(duì)比，總結(jié)數(shù)據(jù)庫(kù)中間件的實(shí)現(xiàn)方式，并展望未來(lái)的可能發(fā)展。
2. 實(shí)現(xiàn)方式
一般來(lái)說(shuō)，對(duì)于數(shù)據(jù)庫(kù)中間件，可以在以下六個(gè)層次做切入。
2.1 代碼層
在同一個(gè)項(xiàng)目中創(chuàng)建多個(gè)數(shù)據(jù)源，采用if else的方式，直接根據(jù)條件在代碼中路由。
Spring中有動(dòng)態(tài)切換數(shù)據(jù)源的抽象類(lèi)，具體參見(jiàn)AbstractRoutingDataSource。
如果項(xiàng)目不是很龐大，使用這種方式能夠快速的進(jìn)行分庫(kù)。但缺點(diǎn)也是顯而易見(jiàn)的，這種海量的代碼侵入是絕不能被接受的。
而且當(dāng)查詢(xún)結(jié)果返回時(shí)，需要對(duì)跨庫(kù)、聚合等查詢(xún)結(jié)果進(jìn)行歸并，開(kāi)發(fā)工作量非常巨大。
這種方式了解一下即可，一般不會(huì)去使用。
2.2 框架層
主要是修改或增強(qiáng)現(xiàn)有ORM框架的功能，在SQL中增加一些自定義原語(yǔ)或者h(yuǎn)int來(lái)實(shí)現(xiàn)。
常見(jiàn)的比如實(shí)現(xiàn)一些攔截器（比如Mybatis的Interceptor接口），增加一些自定義解析來(lái)控制數(shù)據(jù)的流向，效果雖然較好，但會(huì)改變一些現(xiàn)有的編程經(jīng)驗(yàn)。
這種情況適合公司ORM框架統(tǒng)一的情況，但在很多情況下不太現(xiàn)實(shí)。
而且大部分情況下要修改框架源碼，因此，也不推薦。
2.3 驅(qū)動(dòng)層
無(wú)論是從代碼層還是框架層做處理，都是高侵入、難維護(hù)的。
因此，常見(jiàn)的數(shù)據(jù)庫(kù)中間件，至少需要從驅(qū)動(dòng)層開(kāi)始，我們可以理解為一個(gè)smart-client。
什么意思是smart-client呢？
通常smart-client是在連接池或者driver的基礎(chǔ)上進(jìn)行了一層封裝。
這個(gè)smart-client內(nèi)部可以與不同的數(shù)據(jù)庫(kù)建立連接。
服務(wù)需要查詢(xún)的sql，就交給smart-client進(jìn)行解析、優(yōu)化，然后發(fā)送給具體的數(shù)據(jù)庫(kù)進(jìn)行操作。
例如在讀寫(xiě)分離情況下，smart-client會(huì)選擇sql走從庫(kù)還是主庫(kù)；在分庫(kù)分表的情況下，進(jìn)行sql解析、sql改寫(xiě)等操作，然后路由到不同的分庫(kù)，將得到的結(jié)果進(jìn)行合并，返回給應(yīng)用。
我們熟知的TDDL、Sharding-JDBC等，都是在此層切入。
優(yōu)點(diǎn)：
1）實(shí)現(xiàn)方便，業(yè)務(wù)無(wú)入侵。smart-client不需要實(shí)現(xiàn)客戶(hù)端通信協(xié)議，只需要在數(shù)據(jù)數(shù)據(jù)庫(kù)廠(chǎng)商提供的不同語(yǔ)言的數(shù)據(jù)庫(kù)驅(qū)動(dòng)上做封裝即可。例如mysql針對(duì)java語(yǔ)言提供了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。因此相較于代理方式而言，不需要考慮高可用的問(wèn)題。只要應(yīng)用的節(jié)點(diǎn)沒(méi)有全部宕機(jī)，就可以訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)。(這里的高可用是相比代理層proxy而言，數(shù)據(jù)庫(kù)本身的高可用還是需要保證的)
缺點(diǎn)：
1）通常僅支持某一種語(yǔ)言。例如tddl、zebra、sharding-jdbc都是使用java語(yǔ)言開(kāi)發(fā)，因此對(duì)于使用其他語(yǔ)言的用戶(hù)，就無(wú)法使用這些中間件。如果其他語(yǔ)言要使用，那么就要開(kāi)發(fā)多語(yǔ)言客戶(hù)端。
2）版本升級(jí)困難。因?yàn)閼?yīng)用使用數(shù)據(jù)源代理就是引入一個(gè)jar包的依賴(lài)，在有多個(gè)應(yīng)用都對(duì)某個(gè)版本的jar包產(chǎn)生依賴(lài)時(shí)，一旦這個(gè)版本有bug，所有的應(yīng)用都需要升級(jí)。而數(shù)據(jù)庫(kù)代理升級(jí)則相對(duì)容易，因?yàn)榉?wù)是單獨(dú)部署的，只要升級(jí)這個(gè)代理服務(wù)器，所有連接到這個(gè)代理的應(yīng)用自然也就相當(dāng)于都升級(jí)了。
3）去中心化的缺點(diǎn)，比如無(wú)法做全局的sql限流
2.4 代理層
在應(yīng)用中，我們通過(guò)一個(gè)普通的數(shù)據(jù)源(c3p0、druid、dbcp等)與代理服務(wù)器建立連接，所有的sql操作語(yǔ)句都是發(fā)送給這個(gè)代理，由這個(gè)代理去操作底層數(shù)據(jù)庫(kù)，得到結(jié)果并返回給應(yīng)用。在這種方案下，分庫(kù)分表和讀寫(xiě)分離的邏輯對(duì)開(kāi)發(fā)人員是完全透明的。
像MySQL Router、MyCat、ShardingSphere（proxy模式）等，都是在此層切入。
優(yōu)點(diǎn)：
1）多語(yǔ)言支持。也就是說(shuō)，不論你用的php、java或是其他語(yǔ)言，都可以支持。以mysql數(shù)據(jù)庫(kù)為例，如果proxy本身實(shí)現(xiàn)了mysql的通信協(xié)議，那么你可以就將其看成一個(gè)mysql 服務(wù)器，因此不同語(yǔ)言的開(kāi)發(fā)者都可以使用mysql官方提供的對(duì)應(yīng)的驅(qū)動(dòng)來(lái)與這個(gè)代理服務(wù)器建通信。
2）對(duì)業(yè)務(wù)開(kāi)發(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ù)庫(kù)server端的通信協(xié)議，實(shí)現(xiàn)難度較大。
2）proxy本身需要保證高可用。由于應(yīng)用本來(lái)是直接訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)，現(xiàn)在改成了訪(fǎng)問(wèn)proxy，意味著proxy必須保證高可用。否則，數(shù)據(jù)庫(kù)沒(méi)有宕機(jī)，proxy掛了，導(dǎo)致數(shù)據(jù)庫(kù)無(wú)法正常訪(fǎng)問(wèn)，就尷尬了。
3）租戶(hù)隔離?？赡苡卸鄠€(gè)應(yīng)用訪(fǎng)問(wèn)proxy代理的底層數(shù)據(jù)庫(kù)，必然會(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ù)庫(kù)代理，以DaemonSet的形式代理所有對(duì)數(shù)據(jù)庫(kù)的訪(fǎng)問(wèn)。
通過(guò)無(wú)中心、零侵入的方案提供與數(shù)據(jù)庫(kù)交互的的嚙合層，即Database Mesh，又可稱(chēng)數(shù)據(jù)網(wǎng)格。Database Mesh的關(guān)注重點(diǎn)在于如何將分布式的數(shù)據(jù)訪(fǎng)問(wèn)應(yīng)用與數(shù)據(jù)庫(kù)有機(jī)串聯(lián)起來(lái)，它更加關(guān)注的是交互，是將雜亂無(wú)章的應(yīng)用與數(shù)據(jù)庫(kù)之間的交互有效的梳理。使用Database Mesh，訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)的應(yīng)用和數(shù)據(jù)庫(kù)終將形成一個(gè)巨大的網(wǎng)格體系，應(yīng)用和數(shù)據(jù)庫(kù)只需在網(wǎng)格體系中對(duì)號(hào)入座即可，它們都是被嚙合層所治理的對(duì)象。
優(yōu)點(diǎn)：
分布式云原生的數(shù)據(jù)庫(kù)中間件模式，集成了jdbc和proxy各自的優(yōu)點(diǎn)，能滿(mǎn)足高可用、跨語(yǔ)言、無(wú)感知升級(jí)等多種優(yōu)勢(shì)特性
缺點(diǎn)：
需要整體架構(gòu)支持云原生體系
目前還沒(méi)正式上線(xiàn)。
2.6 存儲(chǔ)層
這個(gè)層次實(shí)際上不應(yīng)該叫數(shù)據(jù)庫(kù)中間件了，需要更換存儲(chǔ)。
比如Aurora、polardb、tidb等分布式數(shù)據(jù)庫(kù)，通過(guò)計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)分離，計(jì)算節(jié)點(diǎn)scale up，存儲(chǔ)節(jié)點(diǎn)scale out的理念將公有云的關(guān)系數(shù)據(jù)庫(kù)產(chǎn)品推向了一個(gè)新的高度。
這樣一來(lái)，實(shí)際上已經(jīng)不再需要傳統(tǒng)的數(shù)據(jù)庫(kù)中間件了，一切問(wèn)題天然就不存在了。
3. 功能對(duì)比
從上文可以了解到，目前最主流的數(shù)據(jù)庫(kù)中間件主要是從驅(qū)動(dòng)層smart-client和代理層proxy切入的。
下面，我們來(lái)了解下業(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ǎng)都擼過(guò)一遍自己的中間件產(chǎn)品。不過(guò)目前開(kāi)源而且比較火的已經(jīng)不多了，主要還是以shardingsphere為主。
我們從功能維度，來(lái)對(duì)比一下幾個(gè)產(chǎn)品。
4. 展望
從上文的分析可以看出，盡管目前主流的數(shù)據(jù)庫(kù)中間件還是在smart-client和proxy兩個(gè)層面進(jìn)行處理的，但是，已經(jīng)能看到未來(lái)的方向了。云原生的到來(lái)，數(shù)據(jù)庫(kù)中間件也會(huì)擁抱變化。
一方面是作為sidecar的模式，可能會(huì)有一個(gè)新的階段，比如shardingsphere推出sidecar模式后。
而另一方面，云數(shù)據(jù)庫(kù)通過(guò)全新的計(jì)算存儲(chǔ)分離的架構(gòu)方式，打破傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)的性能瓶頸，傳統(tǒng)數(shù)據(jù)庫(kù)中間件將不再需要關(guān)注，一切都將以數(shù)據(jù)庫(kù)基礎(chǔ)設(shè)施的形式提供給使用者。
分享標(biāo)題：數(shù)據(jù)庫(kù)中間件漫談——看看云時(shí)代，它會(huì)走向何方
分享地址：http://fisionsoft.com.cn/article/djedshp.html
