究竟為什么要引入數據庫中間件
不少朋友經常會問我以下問題：
- 58到家有沒有使用數據庫中間件
- 使用了什么數據庫中間件，是自研，還是第三方
- 怎么實現的，是基于客戶端的中間件，還是基于服務端的中間件
- 使用中間件后，join/子查詢/集函數/事務等問題是怎么解決的
- …
你是不是也有類似的疑問?
然而，“究竟為什么要引入數據庫中間件”卻很少有人問及。 “架構師之路”文章思路，以解決“為什么”為優先，借著近期撰寫互聯網分層架構系列文章，講一講這個核心問題：
- 究竟為什么要引入數據庫中間件
經過連續分層架構演進，DAO層，基礎數據服務化，通用業務服務化，前后端分離之后，一個業務系統的后端結構如上：
- web-view層通過http接口，從web-data獲取json數據(前后端分離)
- web-data層通過RPC接口，從biz-service獲取數據(通用業務服務)
- biz-service層通過RPC接口，從base-service獲取數據(基礎數據服務)
- base-service層通過DAO，從db獲取數據(DAO)
- db存儲數據
隨著時間的推移，數據量會越來越大，base-service通過DAO來訪問db的性能會越來越低，需要開始考慮對db進行水平切分，一旦db進行水平切分，原來很多SQL可以支持的功能，就需要base-service層來進行特殊處理：
- 有些數據需要路由到特定的水平切分庫
- 有些數據不確定落在哪一個水平切分庫，就需要訪問所有庫
- 有些數據需要訪問全局的庫，拿到數據的全局視野，到service層進行額外處理
- …
更具體的，對于前臺高并發的業務，db水平切分后，有這么幾類典型的業務場景及應對方案。特別強調一下，此處應對的是“前臺”“高并發”“db水平切分”的場景，對于后臺的需求，將通過前臺與后臺分離的架構處理，不在此處討論。
一：partition key上的單行查詢
典型場景：通過uid查詢user
場景特點：
- 通過patition key查詢
- 每次只返回一行記錄
解決方案：base-service層通過patition key來進行庫路由
如上圖：
- user-service底層user庫，分庫patition key是uid
- uid上的查詢，user-service可以直接定位到庫
二、非patition key上的單行查詢
典型場景：通過login_name查詢user
場景特點：
- 通過非patition key查詢
- 每次只返回一行記錄
解決方案1：base-service層訪問所有庫
如上圖：
- user-service通過login_name先查全庫
- 結果集在user-service再合并，最終返回一條記錄
解決方案2：base-service先查mapping庫，再通過patition key路由
如上圖：
- 新建mapping庫，記錄login_name到uid的映射關系
- 當有非 patition key的查詢時，先通過login_name查詢uid
- 再通過patition key進行路由，最終返回一條記錄
解決方案3：基因法
關于“基因法”解決非patition key上的查詢需求詳見《分庫后，非patition key上訪問的多種解決辦法》。
三、patition key上的批量查詢
典型場景：用戶列表uid上的IN查詢
場景特點：
- 通過patition key查詢
- 每次返回多行記錄
解決方案1：base-service層訪問所有庫，結果集到base-service合并
解決方案2：base-service分析路由規則，按需訪問
如上圖：
- base-service根據路由規則分析，判斷出有些數據落在庫1，有些數據落在庫2
- base-service按需訪問相關庫，而不是訪問全庫
- base-service合并結果集，返回列表數據
四、非patition key上的夸庫分頁需求
關于分庫后，夸庫分頁的查詢需求，詳見《業界難題，夸庫分頁的四種方案》。
五、其他需求…
本文寫到這里，上述一、二、三、四、五其實都不是重點，base-service層通過各種各樣的奇技淫巧，能夠解決db水平切分后的數據訪問問題，只不過：
base-service層的復雜度提高了
數據的獲取效率降低了
當需要進行db水平切分的base-service越來越多以后，此時分層架構會變成下面這個樣子：
底層的復雜性會擴散到各個base-service，所有的base-service都要關注：
- patition key路由
- 非patition key查詢，先mapping，再路由
- 先全庫，再合并
- 先分析，再按需路由
- 夸庫分頁處理
- …
這個架構圖是不是看上去很別扭?如何讓數據的獲取更加高效快捷呢?
數據庫中間件的引入，勢在必行。
這是“基于服務端”的數據庫中間件架構圖：
- base-service層，就像訪問db一樣，訪問db-proxy，高效獲取數據
- 所有底層的復雜性，都屏蔽在db-proxy這一層
這是“基于客戶端”的數據庫中間件架構圖：
- base-service層，通過db-proxy.jar，高效獲取數據
- 所有底層的復雜性，都屏蔽在db-proxy.jar這一層
結論：
當數據庫水平切分，base-service層獲取db數據過于復雜，成為通用痛點的時候，就應該抽象出數據庫中間件，簡化數據獲取過程，提高數據獲取效率，向上游屏蔽底層的復雜性。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
