揭祕Sharding-Proxy——面向DBA的資料庫中間層
大家好，我今天想跟大家分享的是Sharding-Sphere的第二個產品Sharding-Proxy。
在上個月亮相的Sharding-Sphere 3.0.0.M1中首次釋出了Sharding-Proxy，希望這次分享能夠通過幾個優化實踐，幫助大家管中窺豹，從幾個關鍵細節想象出Sharding-Proxy的全貌。至於更詳細的MySQL協議、IO模型、Netty等議題，以後有機會再和大家專題分享。
一、Sharding-Proxy簡介
1Sharding-Proxy概覽
Sharding-Proxy定位為透明化的資料庫代理端，提供封裝了資料庫二進位制協議的服務端版本，用於完成對異構語言的支援。目前先提供MySQL版本，它可以使用任何相容MySQL協議的訪問客戶端操作資料（如：MySQLCommandClient、MySQLWorkbench等），對DBA更加友好。
對應用程式完全透明，可直接當做MySQL使用；適用於任何相容MySQL協議的客戶端。
與其他兩個產品（Sharding-JDBC、Sharding-Sidecar）的對比：
它們既可以獨立使用，也可以相互配合，以不同的架構模型、不同的切入點，實現相同的功能目標。而其核心功能，如資料分片、讀寫分離、柔性事務等，都是同一套實現程式碼。
舉個例子，對於僅使用Java為開發技術棧的場景，Sharding-JDBC對各種Java的ORM框架支援度非常高，開發人員可以非常便利地將資料分片能力引入到現有的系統中，並將其部署至線上環境執行，而DBA就可以通過部署一個Sharding-Proxy例項，對資料進行查詢和管理。
2Sharding-Proxy架構
整個架構可以分為前端、後端和核心元件三部分來看：
前端（Frontend）負責與客戶端進行網路通訊，採用的是基於NIO的客戶端/伺服器框架，在Windows和Mac作業系統下采用NIO模型，Linux系統自動適配為Epoll模型，在通訊的過程中完成對MySQL協議的編解碼；核心元件（Core-module）得到解碼的MySQL命令後，開始呼叫Sharding-Core對SQL進行解析、改寫、路由、歸併等核心功能；後端（Backend）與真實資料庫的互動暫時藉助基於BIO的Hikari連線池。BIO的方式在資料庫叢集規模很大，或者一主多從的情況下，效能會有所下降。所以未來我們還會提供NIO的方式連線真實資料庫。