DB分庫分表中關于使用框架還是自主開發以及sharding實現層面的考量是怎樣的

這篇文章將為大家詳細講解有關DB分庫分表中關于使用框架還是自主開發以及sharding實現層面的考量是怎樣的，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

當團隊對系統業務和數據庫進行了細致的梳理，確定了切分方案后，接下來的問題就是如何去實現切分方案了，目前在sharding方面有不少的開源框架和產品可供參考，同時很多團隊也會選擇自主開發實現，而不管是選擇框架還是自主開發，都會面臨一個在哪一層上實現sharding邏輯的問題，小編會對這一系列的問題逐一進行分析和考量。

一、sharding邏輯的實現層面

從一個系統的程序架構層面來看，sharding邏輯可以在DAO層、JDBC  API層、介于DAO與JDBC之間的Spring數據訪問封裝層(各種spring的template)以及介于應用服務器與數據庫之間的sharding代理服務器四個層面上實現。

圖1. Sharding實現層面與相關框架/產品

• 在DAO層實現

當團隊決定自行實現sharding的時候，DAO層可能是嵌入sharding邏輯的***位置，因為在這個層面上，每一個DAO的方法都明確地知道需要訪問的數據表以及查詢參數，借助這些信息可以直接定位到目標shard上，而不必像框架那樣需要對SQL進行解析然后再依據配置的規則進行路由。另一個優勢是不會受ORM框架的制約。由于現在的大多數應用在數據訪問層上會依賴某種ORM框架，而多數的shrading框架往往無法支持或只能支持一種orm框架，這使得在選擇和應用框架時受到了很大的制約，而自行實現sharding完全沒有這方面的問題，甚至不同的shard使用不同的orm框架都可以在一起協調工作。比如現在的java應用大多使用hibernate，但是當下還沒有非常令人滿意的基于hibernate的sharding框架，(關于hibernate  hards會在下文介紹)，因此很多團隊會選擇自行實現sharding。

簡單總結一下，在DAO層自行實現sharding的優勢在于：不受ORM框架的制約、實現起來較為簡單、易于根據系統特點進行靈活的定制、無需SQL解析和路由規則匹配，性能上表現會稍好一些;劣勢在于：有一定的技術門檻，工作量比依靠框架實現要大(反過來看，框架會有學習成本)、不通用，只能在特定系統里工作。當然，在DAO層同樣可以通過XML配置或是注解將sharding邏輯抽離到“外部”，形成一套通用的框架.  不過目前還沒有出現此類的框架。

• 在ORM框架層實現

在ORM框架層實現sharding有兩個方向，一個是在實現O-R  Mapping的前提下同時提供sharding支持，從而定位為一種分布式的數據訪問框架，這一類類型的框架代表就是guzz另一個方向是通過對既有ORM框架進行修改增強來加入sharding機制。此類型的代表產品是hibernate  shard.  應該說以hibernate這樣主流的地位，行業對于一款面向hibernate的sharding框架的需求是非常迫切的，但是就目前的hibernate  shards來看，表現還算不上令人滿意，主要是它對使用hibernate的限制過多，比如它對HQL的支持就非常有限。在mybatis方面，目前還沒有成熟的相關框架產生。有人提出利用mybatis的插件機制實現sharding,但是遺憾的是，mybatis的插件機制控制不到多數據源的連接層面，另一方面，離開插件層又失去了對sql進行集中解析和路由的機會，因此在mybatis框架上，目前還沒有可供借鑒的框架，團隊可能要在DAO層或Spring模板類上下功夫了。

• 在JDBC API層實現

JDBC API層是很多人都會想到的一個實現sharding的***場所，如果我們能提供一個實現了sharding邏輯的JDBC  API實現，那么sharding對于整個應用程序來說就是完全透明的，而這樣的實現可以直接作為通用的sharding產品了。但是這種方案的技術門檻和工作量顯然不是一般團隊能做得來的，因此基本上沒有團隊會在這一層面上實現sharding,甚至也沒有此類的開源產品。筆者知道的只有一款商業產品dbShards采用的是這一方案。

• 在介于DAO與JDBC之間的Spring數據訪問封裝層實現

在springd大行其道的今天，幾乎沒有哪個java平臺上構建的應用不使用spring，在DAO與JDBC之間，spring提供了各種template來管理資源的創建與釋放以及與事務的同步，大多數基于spring的應用都會使用template類做為數據訪問的入口，這給了我們另一個嵌入sharding邏輯的機會，就是通過提供一個嵌入了sharding邏輯的template類來完成sharding工作.這一方案在效果上與基于JDBC  API實現的方案基本一致，同樣是對上層代碼透明，在進行sharding改造時可以平滑地過度，但它的實現卻比基于JDBC  API的方式簡單，因此成為了不少框架的選擇，阿里集團研究院開源的Cobar Client就是這類方案的一種實現。

• 在應用服務器與數據庫之間通過代理實現

在應用服務器與數據庫之間加入一個代理，應用程序向數據發出的數據請求會先通過代理，代理會根據配置的路由規則，對SQL進行解析后路由到目標shard，因為這種方案對應用程序完全透明，通用性好，所以成為了很多sharding產品的選擇。在這方面較為知名的產品是mysql官方的代理工具：Mysql  Proxy和一款國人開發的產品:amoeba。mysql  proxy本身并沒有實現任何sharding邏輯，它只是作為一種面向mysql數據庫的代理，給開發人員提供了一個嵌入sharding邏輯的場所，它使用lua作為編程語言，這對很多團隊來說是需要考慮的一個問題。amoeba則是專門實現讀寫分離與sharding的代理產品，它使用非常簡單，不使用任何編程語言，只需要通過xml進行配置。不過amoeba不支持事務(從應用程序發出的包含事務信息的請求到達amoeba時，事務信息會被抹去，因此，即使是單點數據訪問也不會有事務存在)一直是個硬傷。當然，這要看產品的定位和設計理念，我們只能說對于那些對事務要求非常高的系統，amoeba是不適合的。

二、使用框架還是自主開發?

前面的討論中已經羅列了很多開源框架與產品，這里再整理一下：基于代理方式的有MySQL  Proxy和Amoeba，基于Hibernate框架的是Hibernate Shards，通過重寫spring的ibatis template類是Cobar  Client，這些框架各有各的優勢與短板，架構師可以在深入調研之后結合項目的實際情況進行選擇，但是總的來說，我個人對于框架的選擇是持謹慎態度的。一方面多數框架缺乏成功案例的驗證，其成熟性與穩定性值得懷疑。另一方面，一些從成功商業產品開源出框架(如阿里和淘寶的一些開源項目)是否適合你的項目是需要架構師深入調研分析的。當然，最終的選擇一定是基于項目特點、團隊狀況、技術門檻和學習成本等綜合因素考量確定的。

關于DB分庫分表中關于使用框架還是自主開發以及sharding實現層面的考量是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。