不少朋友經(jīng)常會(huì)問(wèn)我以下問(wèn)題：

• 58到家有沒(méi)有使用數(shù)據(jù)庫(kù)中間件
• 使用了什么數(shù)據(jù)庫(kù)中間件，是自研，還是第三方
• 怎么實(shí)現(xiàn)的，是基于客戶端的中間件，還是基于服務(wù)端的中間件
• 使用中間件后，join/子查詢/集函數(shù)/事務(wù)等問(wèn)題是怎么解決的
• …

你是不是也有類(lèi)似的疑問(wèn)?

然而，“究竟為什么要引入數(shù)據(jù)庫(kù)中間件”卻很少有人問(wèn)及。 “架構(gòu)師之路”文章思路，以解決“為什么”為優(yōu)先，借著近期撰寫(xiě)互聯(lián)網(wǎng)分層架構(gòu)系列文章，講一講這個(gè)核心問(wèn)題：

• 究竟為什么要引入數(shù)據(jù)庫(kù)中間件

經(jīng)過(guò)連續(xù)分層架構(gòu)演進(jìn)，DAO層，基礎(chǔ)數(shù)據(jù)服務(wù)化，通用業(yè)務(wù)服務(wù)化，前后端分離之后，一個(gè)業(yè)務(wù)系統(tǒng)的后端結(jié)構(gòu)如上：

• web-view層通過(guò)http接口，從web-data獲取json數(shù)據(jù)(前后端分離)
• web-data層通過(guò)RPC接口，從biz-service獲取數(shù)據(jù)(通用業(yè)務(wù)服務(wù))
• biz-service層通過(guò)RPC接口，從base-service獲取數(shù)據(jù)(基礎(chǔ)數(shù)據(jù)服務(wù))
• base-service層通過(guò)DAO，從db獲取數(shù)據(jù)(DAO)
• db存儲(chǔ)數(shù)據(jù)

隨著時(shí)間的推移，數(shù)據(jù)量會(huì)越來(lái)越大，base-service通過(guò)DAO來(lái)訪問(wèn)db的性能會(huì)越來(lái)越低，需要開(kāi)始考慮對(duì)db進(jìn)行水平切分，一旦db進(jìn)行水平切分，原來(lái)很多SQL可以支持的功能，就需要base-service層來(lái)進(jìn)行特殊處理：

• 有些數(shù)據(jù)需要路由到特定的水平切分庫(kù)
• 有些數(shù)據(jù)不確定落在哪一個(gè)水平切分庫(kù)，就需要訪問(wèn)所有庫(kù)
• 有些數(shù)據(jù)需要訪問(wèn)全局的庫(kù)，拿到數(shù)據(jù)的全局視野，到service層進(jìn)行額外處理
• …

更具體的，對(duì)于前臺(tái)高并發(fā)的業(yè)務(wù)，db水平切分后，有這么幾類(lèi)典型的業(yè)務(wù)場(chǎng)景及應(yīng)對(duì)方案。特別強(qiáng)調(diào)一下，此處應(yīng)對(duì)的是“前臺(tái)”“高并發(fā)”“db水平切分”的場(chǎng)景，對(duì)于后臺(tái)的需求，將通過(guò)前臺(tái)與后臺(tái)分離的架構(gòu)處理，不在此處討論。

一：partition key上的單行查詢

典型場(chǎng)景：通過(guò)uid查詢user

場(chǎng)景特點(diǎn)：

• 通過(guò)patition key查詢
• 每次只返回一行記錄

解決方案：base-service層通過(guò)patition key來(lái)進(jìn)行庫(kù)路由

如上圖：

• user-service底層user庫(kù)，分庫(kù)patition key是uid
• uid上的查詢，user-service可以直接定位到庫(kù)

二、非patition key上的單行查詢

典型場(chǎng)景：通過(guò)login_name查詢user

場(chǎng)景特點(diǎn)：

• 通過(guò)非patition key查詢
• 每次只返回一行記錄

解決方案1：base-service層訪問(wèn)所有庫(kù)

如上圖：

• user-service通過(guò)login_name先查全庫(kù)
• 結(jié)果集在user-service再合并，最終返回一條記錄

解決方案2：base-service先查mapping庫(kù)，再通過(guò)patition key路由

如上圖：

• 新建mapping庫(kù)，記錄login_name到uid的映射關(guān)系
• 當(dāng)有非 patition key的查詢時(shí)，先通過(guò)login_name查詢uid
• 再通過(guò)patition key進(jìn)行路由，最終返回一條記錄

解決方案3：基因法

關(guān)于“基因法”解決非patition key上的查詢需求詳見(jiàn)《分庫(kù)后，非patition key上訪問(wèn)的多種解決辦法》。

三、patition key上的批量查詢

典型場(chǎng)景：用戶列表uid上的IN查詢

場(chǎng)景特點(diǎn)：

• 通過(guò)patition key查詢
• 每次返回多行記錄

解決方案1：base-service層訪問(wèn)所有庫(kù)，結(jié)果集到base-service合并

解決方案2：base-service分析路由規(guī)則，按需訪問(wèn)

如上圖：

• base-service根據(jù)路由規(guī)則分析，判斷出有些數(shù)據(jù)落在庫(kù)1，有些數(shù)據(jù)落在庫(kù)2
• base-service按需訪問(wèn)相關(guān)庫(kù)，而不是訪問(wèn)全庫(kù)
• base-service合并結(jié)果集，返回列表數(shù)據(jù)

四、非patition key上的夸庫(kù)分頁(yè)需求

關(guān)于分庫(kù)后，夸庫(kù)分頁(yè)的查詢需求，詳見(jiàn)《業(yè)界難題，夸庫(kù)分頁(yè)的四種方案》。

五、其他需求…

本文寫(xiě)到這里，上述一、二、三、四、五其實(shí)都不是重點(diǎn)，base-service層通過(guò)各種各樣的奇技淫巧，能夠解決db水平切分后的數(shù)據(jù)訪問(wèn)問(wèn)題，只不過(guò)：

base-service層的復(fù)雜度提高了

數(shù)據(jù)的獲取效率降低了

當(dāng)需要進(jìn)行db水平切分的base-service越來(lái)越多以后，此時(shí)分層架構(gòu)會(huì)變成下面這個(gè)樣子：

底層的復(fù)雜性會(huì)擴(kuò)散到各個(gè)base-service，所有的base-service都要關(guān)注：

• patition key路由
• 非patition key查詢，先mapping，再路由
• 先全庫(kù)，再合并
• 先分析，再按需路由
• 夸庫(kù)分頁(yè)處理
• …

這個(gè)架構(gòu)圖是不是看上去很別扭?如何讓數(shù)據(jù)的獲取更加高效快捷呢?

數(shù)據(jù)庫(kù)中間件的引入，勢(shì)在必行。 

這是“基于服務(wù)端”的數(shù)據(jù)庫(kù)中間件架構(gòu)圖：

• base-service層，就像訪問(wèn)db一樣，訪問(wèn)db-proxy，高效獲取數(shù)據(jù)
• 所有底層的復(fù)雜性，都屏蔽在db-proxy這一層 

這是“基于客戶端”的數(shù)據(jù)庫(kù)中間件架構(gòu)圖：

• base-service層，通過(guò)db-proxy.jar，高效獲取數(shù)據(jù)
• 所有底層的復(fù)雜性，都屏蔽在db-proxy.jar這一層

結(jié)論：

當(dāng)數(shù)據(jù)庫(kù)水平切分，base-service層獲取db數(shù)據(jù)過(guò)于復(fù)雜，成為通用痛點(diǎn)的時(shí)候，就應(yīng)該抽象出數(shù)據(jù)庫(kù)中間件，簡(jiǎn)化數(shù)據(jù)獲取過(guò)程，提高數(shù)據(jù)獲取效率，向上游屏蔽底層的復(fù)雜性。 

【本文為51CTO專(zhuān)欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文