目前分庫分表的中間件有三種設計思路，分別是：
- 采用分散式架構，適用于用Java開發的高性能輕量級OLTP應用程序，以Sharding-JDBC為代表。
- 采用中間層Proxy架構，提供了靜態輸入和所有語言支持，適用于OLAP應用程序和分片數據庫的管理和操作情況，以Sharding-Proxy、Mycat 為代表。
- Database Mesh架構，適合k8s環境，以Sharding-Sidecar為代表。
分散式架構
以Sharding-JDBC為例，Sharding-JDBC它定位為輕量級 Java框架，在 Java的 JDBC層提供的額外服務。它使用客戶端直連數據庫，以 jar 包形式提供服務，無需額外部署和依賴，可理解為增強版的 JDBC 驅動，完全兼容JDBC和各種 ORM 框架。
優點：
1、輕量，范圍更加容易界定，只是 JDBC 增強，不包括 HA、事務以及數據庫元數據管理
2、開發的工作量較小，無需關注 nio，各個數據庫協議等
3、運維無需改動，無需關注中間件本身的 HA
4、性能高，JDBC 直連數據庫，無需二次轉發
5、可支持各種基于 JDBC 協議的數據庫，如：MySQL，Oralce，SQLServer
中間層Proxy架構
以Sharding-Proxy為例，中間層將自身定義為透明的數據庫代理，它提供了一種數據庫服務器，該服務器封裝了數據庫二進制協議以支持異構語言。對DBA友好的是，現在提供的MySQL版本可以使用與MySQL協議兼容的任何類型的終端（例如MySQL Command Client，MySQL Workbench等）。
優點：
1、 對應用程序完全透明，可以直接用作MySQL
2、適用于與MySQL和PostgreSQL協議兼容的任何類型的終端
2、更有效的管理數據庫的連接
3、整合大數據思路，將 OLTP 和 OLAP 分離處理
4、夸語言支持比較好
Database Mesh架構
以Sharding-Sidecar為代表。Sharding-Sidecar（TODO）將自己定義為Kubernetes環境的云原生數據庫代理，以sidecar的形式負責對數據庫的所有訪問。它提供了一個與數據庫交互的網格層，我們稱之為Database Mesh。
Database Mesh強調如何將分布式數據庫訪問應用程序與數據庫連接。著重于交互，它有效地組織了雜亂的應用程序與數據庫之間的交互。使用數據庫網格訪問數據庫的應用程序和數據庫將形成一個大型網格系統，只需將它們放在相應的正確位置即可。它們都由網格層控制。
混合架構
Sharding-JDBC采用分散式架構，適用于用Java開發的高性能輕量級OLTP應用程序；Sharding-Proxy提供了靜態輸入和所有語言支持，適用于OLAP應用程序和分片數據庫的管理和操作情況。
開源框架對比
| – | Mycat | Sharding-JDBC | Sharding-Proxy | Sharding-Sidecar |
|---|---|---|---|---|
| 官方網站 | 官方網站 | 官方網站 | 官方網站 | 官方網站 |
| 源碼地址 | gitcode | gitcode | gitcode | gitcode |
| 官方文檔 | Mycat 權威指南 | 官方文檔 | 官方文檔 | 官方文檔 |
| 開發語言 | Java | Java | Java | Java |
| 數據庫 | MySQL Oracle SQL Server PostgreSQL DB2 MongoDB SequoiaDB | MySQL Oracle SQLServer PostgreSQL 任何遵循 SQL92 標準的數據庫 | MySQL/PostgreSQL | MySQL/PostgreSQL |
| 連接數 | 低 | 高 | 低 | 高 |
| 應用語言 | 任意 | Java | 任意 | 任意 |
| 代碼入侵 | 無 | 需要修改代碼 | 無 | 無 |
| 性能 | 損耗略高 | 損耗低 | 損耗略高 | 損耗低 |
| 中心化 | 是 | 否 | 是 | 否 |
| 靜態入口 | 有 | 無 | 有 | 無 |
| 管理控制臺 | Mycat-web | Sharding-UI | Sharding-UI | Sharding-UI |
| 分庫分表 | 單庫多表/多庫單表 | ?? | ?? | ?? |
| 多租戶方案 | ?? | — | — | — |
| 讀寫分離 | ?? | ?? | ?? | ?? |
| 分片策略定制化 | ?? | ?? | ?? | ?? |
| 分布式主鍵 | ?? | ?? | ?? | ?? |
| 標準化事務接口 | ?? | ?? | ?? | ?? |
| XA強一致事務 | ?? | ?? | ?? | ?? |
| 柔性事務 | — | ?? | ?? | ?? |
| 配置動態化 | 開發中 | ?? | ?? | ?? |
| 編排治理 | 開發中 | ?? | ?? | ?? |
| 數據脫敏 | — | ?? | ?? | ?? |
| 可視化鏈路追蹤 | — | ?? | ?? | ?? |
| 多節點操作 | 分頁 去重 排序 分組 聚合 | 分頁 去重 排序 分組 聚合 | 分頁 去重 排序 分組 聚合 | 分頁 去重 排序 分組 聚合 |
| 跨庫關聯 | 跨庫 2 表 Join ER Join 基于 caltlet 的多表 Join | — | — | — |
| IP 白名單 | ?? | — | — | — |
| SQL 黑名單 | ?? | — | — | — |
| 存儲過程 | ?? | — | — | — |
結論
綜合目前已有資源、業務情況、前期改造投入成本和后期運營成本考慮，我建議選擇ShardingSphere，前期只采用分散架構只使用Sharding-JDBC，后期如果有需要可以部署Sharding-Proxy根據業務情況使用混合架構。
參考
https://blog.csdn.net/weixin_43549578/article/details/106709343
https://shardingsphere.apache.org/document/current/cn/overview/
https://blog.csdn.net/vc33569/article/details/133178385
)
