先放一張圖

資料庫中介軟體的主要作用是嚮應用程式開發人員遮蔽讀寫分離和分庫分表面臨的挑戰，並隱藏底層實現細節，使得開發人員可以像操作單庫單表那樣去操作資料。

以前的單庫架構

在單庫單表的情況下，我們是直接在應用中通過資料來源(c3p0、druid、dbcp等)與資料庫建立連線，進行讀寫操作。而對於讀寫分離和分庫分表，應用都要操作多個數據庫例項，在這種情況下，我們就需要使用到資料庫中介軟體。

主流的資料庫中介軟體設計方案

典型的資料庫中介軟體設計方案有2種：服務端代理(代理資料庫)、客戶端代理(代理資料來源)。下圖演示了這兩種方案的架構：

• 在資料庫代理中：

我們獨立部署一個代理服務，這個代理服務背後管理多個數據庫例項。而在應用中，我們通過一個普通的資料來源(c3p0、druid、dbcp等)與代理伺服器建立連線，所有的sql操作語句都是傳送給這個代理，由這個代理去操作底層資料庫，得到結果並返回給應用。在這種方案下，分庫分表和讀寫分離的邏輯對開發人員是完全透明的。

• 在資料來源代理中：

應用程式需要使用一個特定的資料來源，其作用是代理，內部管理了多個普通的資料來源(c3p0、druid、dbcp等)，每個普通資料來源各自與不同的庫建立連線。應用程式產生的sql交給資料來源代理進行處理，資料來源內部對sql進行必要的操作，如sql改寫等，然後交給各個普通的資料來源去執行，將得到的結果進行合併，返回給應用。資料來源代理通常也實現了JDBC規範定義的API，因此能夠直接與orm框架整合

中介軟體實現

資料庫代理

    目前的實現方案有：阿里巴巴開源的cobar，mycat團隊在cobar基礎上開發的mycat，mysql官方提供的mysql-proxy，奇虎360在mysql-proxy基礎開發的atlas。目前除了mycat，其他幾個專案基本已經沒有維護。

    優點：多語言支援。也就是說，不論你用的php、java或是其他語言，都可以支援。原因在於資料庫代理本身就實現了mysql的通訊協議，你可以就將其看成一個mysql 伺服器。mysql官方團隊為不同語言提供了不同的客戶端卻動，如java語言的mysql-connector-java，python語言的mysql-connector-python等等。因此不同語言的開發者都可以使用mysql官方提供的對應的驅動來與這個代理伺服器建通訊。

     缺點：實現複雜。因為代理伺服器需要實現mysql服務端的通訊協議，因此實現難度較大。

資料來源代理

    目前的實現方案有：阿里巴巴開源的tddl，大眾點評開源的zebra，噹噹網開源的sharding-jdbc。需要注意的是tddl的開源版本只有讀寫分離功能，沒有分庫分表，且開源版本已經不再維護。大眾點評的zebra開源版本程式碼已經很久更新，基本上處於停滯的狀態。噹噹網的sharding-jdbc目前算是做的比較好的，程式碼時有更新，文件資料比較全。

     優點：更加輕量，可以與任何orm框架整合。這種方案不需要實現mysql的通訊協議，因為底層管理的普通資料來源，可以直接通過mysql-connector-java驅動與mysql伺服器進行通訊，因此實現相對簡單。

     缺點：僅支援某一種語言。例如tddl、zebra、sharding-jdbc都是使用java語言開發，因此對於使用其他語言的使用者，就無法使用這些中介軟體。版本升級困難，因為應用使用資料來源代理就是引入一個jar包的依賴，在有多個應用都對某個版本的jar包產生依賴時，一旦這個版本有bug，所有的應用都需要升級。而資料庫代理升級則相對容易，因為服務是單獨部署的，只要升級這個代理伺服器，所有連線到這個代理的應用自然也就相當於都升級了。

ORM框架代理：

        目前有hibernate提供的hibernate-shards，也可以通過mybatis外掛的方式編寫。相對於前面兩種方案，這種方案可以說是隻有缺點，沒有優點。  

Dragon專案採用的方案是代理客戶端資料來源的方式