一、业务场景1、一张表水平分表后，可能会影响现有产品的功能。 同时汇总多个表的检索结果数据在sql中很麻烦，如果不知道表的表名就无法制作业务sql。
2、建立数据库齐全的集群后，由于复杂度的上升，主从准备、读写分离、故障切换、心率检测都很复杂，是否有解决上述各种繁杂问题的解决方案？
等等.
二、解决方案引进数据库中间件，如Cobar、MyCat、Atlas、TDDL。
(一)、数据库中间件的定义)介于底层数据库和用户APP应用系统之间，主要用于屏蔽异构数据库底层细节的中间件。 是客户端和后台数据库之间通信的桥梁。
(二)设计模式典型的数据库中间件设计模式有服务端代理、客户端代理两种。
下图显示了这两种方案的体系结构。
1、服务端代理模型(server-proxy )我们独立部署了一个代理服务，在此代理服务的背后管理多个数据库实例。 在APP应用程序中，通过常规数据源(c3p0、druid、dbcp等)连接到代理服务器，所有sql操作语句都发送到该代理，该代理操作基础数据库，然后生成APP应用程序在这种情况下，分区表和读写分离的逻辑对开发人员来说是完全透明的。
这种型号的典型中间件包括：
阿里开源的cobar
基于cobar开发的mycat(正在继续更新…) )。
mysql官方提供的mysql-proxy
奇虎360在mysql-proxy基础上开发的Atlas
当当网开源的sharing-sphere
优点：
1、多语言支持。 无论你使用的php、java还是其他语言，都可以支持。 以mysql数据库为例，如果proxy本身实现了mysql通信协议，则可以将其视为mysql服务器。 mysql官方团队为不同的语言提供了不同的客户端，如java语言的mysql-connector-java和python语言的mysql-connector-python，但正在运行。 因此，各种语言的开发人员可以使用mysql官方提供的相应驱动程序与此代理服务器进行通信。
2、对业务开发透明。 因为可以将proxy视为mysql服务器，所以理论上业务开发不需要太多代码改造，就可以完成访问。
缺点：
1、代理本身需要确保高可用性。 由于APP应用程序最初直接访问数据库，因此现在已更改为访问代理。 这意味着代理必须保证高可用性。 否则，如果数据库不会宕机，proxy锁定，无法正常访问数据库，就会很尴尬。
2、租户隔离。 proxy代理所基于的数据库可能可以访问多个APP应用程序，这必然会导致proxy自身的内存、网络、cpu等发生资源争用，proxy需要隔离的能力。
2、客户端代理模型(client-proxy )业务代码需要进行一些改造，引入支持读写分离或库划分功能的sdk。 客户端代理通常根据连接池或驱动程序封装，并在内部与不同的库连接。 由APP应用程序生成的sql将处理交给代理层，并在其内部对sql执行必要的操作。 例如，在读写分离情况下，选择是从库进行还是从主库进行； 对于分区表，执行sql分析、sql重写等操作，路由到不同的分区，合并得到的结果并返回到APP应用程序。
这种型号的典型中间件包括：
阿里开源的TDDL
大众点评开源zebra。
本网开源sharding-jdbc目前做得比较好，文件资料齐全。
优点：
1、实现简单。 代理必须实现数据库的服务端协议，但代理层不需要实现客户端通信协议。 这是因为许多数据库供应商已经提供了支持不同语言的数据库驱动程序。 例如，mysql为java语言提供了mysql-connector-java驱动程序。 客户端通信协议已经在驱动程序级别进行。 因此，通常只要在此基础上封装即可。
2、天然去中心化。
smart-client的方式，由于本身以sdk的方式，被应用直接引入，随着应用部署到不同的节点上，且直连数据库，中间不需要有代理层。因此相较于proxy而言，除了网络资源之外，基本上不存在任何其他资源的竞争，也不需要考虑高可用的问题。只要应用的节点没有全部宕机，就可以访问数据库。(这里的高可用是相比proxy而言，数据库本身的高可用还是需要保证的)
缺点：
1、通常仅支持某一种语言。例如tddl、zebra、sharding-jdbc都是使用java语言开发，因此对于使用其他语言的用户，就无法使用这些中间件，除非开发多语言客户端。
2、版本升级困难。因为应用使用数据源代理就是引入一个jar包的依赖，在有多个应用都对某个版本的jar包产生依赖时，一旦这个版本有bug，所有的应用都需要升级。而数据库代理升级则相对容易，因为服务是单独部署的，只要升级这个代理服务器，所有连接到这个代理的应用自然也就相当于都升级了。
三、部分中间件技术讲解 （一）Cobar
Cobar 是由 Alibaba 开源的 MySQL 分布式处理中间件，Cobar是关系型数据的分布式处理系统，它可以在分布式的环境下像传统数据库一样为您提供海量数据服务。
github地址：https://github.com/topics/cobar
特点：
解决了大数据量下的透明水平分表必须使用封装过的 MySQL 驱动包 Cobar Driver，无框架要求后端对 MySQL 是直接面向二进制协议的基于 LL(2) 手写的 SQL 解析器支持弱一致性事务（多库并行执行/提交）不支持跨库 join、分页、排序、子查询、读写分离在 MySQL 实例上没有 agentMySQL 主从数据同步使用 MySQL 解决方案主异常时切换到从后主恢复，没有 failback，只能手动切换回主后端对 MySQL 有连接池支持跨地域（二）MyCat
官网：Mycat1.6
前身 Cobar，开源，较为活跃。
特点：
遵守Mysql原生协议，跨语言，跨数据库的通用中间件代理。基于心跳的自动故障切换，支持读写分离，支持 MySQL 一双主多从，以及一主多从有效管理数据源连接，基于数据分库，而不是分表的模式。基于 NIO 实现，有效管理线程，高并发问题。支持数据的多片自动路由与聚合，支持 sum , count , max 等常用的聚合函数。支持2表 join，甚至基于 caltlet 的多表 join。支持通过全局表，ER 关系的分片策略，实现了高效的多表 join 查询。支持多租户方案。支持分布式事务（弱xa）支持全局序列号，解决分布式下的主键生成问题。分片规则丰富，插件化开发，易于扩展。强大的 web，命令行监控。支持前端作为 MySQL 通用代理，后端 JDBC 方式支持 Oracle、DB2、SQL Server 、 mongodb 、巨杉。集群基于 ZooKeeper 管理，在线升级，扩容，智能优化，大数据处理（2.0开发版）。
对比：开源的分布式数据库中间件系统Mycat和阿里巴巴Cobar的对比_axdc的博客-CSDN博客_cobar
（三）Atlas
较为活跃，Atlas 是由 360 Web平台部基础架构团队开发维护的一个基于 MySQL 协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。360内部使用 Atlas 运行的 MySQL 务，每天承载的读写请求数达几十亿条。
官网：Apache Atlas – Data Governance and Metadata framework for Hadoop
主要功能：
1. 读写分离
2. 从库负载均衡
3. IP过滤
4. SQL语句黑白名单
5. 自动分表
（四）sharing-sphere
Apache ShardingSphere 由 JDBC、Proxy 和 Sidecar（规划中）这 3 款既能够独立部署，又支持混合部署配合使用的产品组成。 它们均提供标准化的基于数据库作为存储节点的增量功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。
官网：ShardingSphere
手册：概览 :: ShardingSphere
四、结论
每项数据库中间件都有自己的优势和特点，在做技术选型的时候，先结合实际业务场景需要确定采用哪种模式的中间件，再去选择哪个中间件技术更符合实际需求。