Mysql group replication(MGR)实现高可用切换应用无感知方案的思考

一开始考虑使用ProxySQL+MGR来实现数据库切换应用无感知方向，考虑了可能的两种部署模型的优缺点：
ProxySQL部署的两种模型：
1、靠近应用端
方式：在应用服务器上直接部署
优点：
  A、每个应用服务器有自己的配置 ，配置内容简单，不容易相互影响故障，变更故障风险最小
  B、没有瓶颈压力，故障容错最好，单机故障影响最小
  C、数据库上可以清楚看到SQL来自哪台应用机器，方便排查故障
  D、无需单独机器资源
缺点：
  A、每台应用服务器上都需要配置，当数据库架构扩容或者其他变动时，需要应用则的ProxySQL做相应改动
  B、当一台应用上需要连接多套数据库时，配置也会开始稍微复杂
2、靠近数据库端
方式：通过独立的ProxySQL集群来提供服务
优点：
  A、不需要每台应用服务器上配置，集中修改
缺点：
  A、容易出现瓶颈，网络、机器性能等
  B、集中配置，导致配置非常复杂，可能相互影响，变更故障风险高
  C、全部应用通过ProxySQL来连接，数据库上看到具体问题连接来自哪台应用机器，无法进行故障定位
  D、需要单独的机器资源来部署ProxySQL，因为流量集中且是应用层，需要考虑性能瓶颈，占用机器资源相对较多
  E、机器故障时，影响是面级，通过额外高可用技术来减少影响


综合上面的优缺点，ProxySQL+MGR来实现应用切换无感知方式并不大合适，haproxy等方案也有类似问题，建议：
1、使用浮动IP来实现Mysql MGR的写高可用（浮动IP需要自己实现）
2、使用LVS来实现Mysql MGR或者普通复制（扩展库）读库的高可用和负载均衡

3、使用DNS域名切换来实现不同机房的切换

角色职责分层的思考：
1、数据库层
  A、负责数据库CELL级别高可用方案，提供写高可用入口与读高可用入口
  B、多个逻辑库从一个CELL拆到多个CELL
2、需要应用层考虑的：
  A、读写分离逻辑
  B、逻辑库的分库分表
为什么归到应用层，这些读写分离逻辑与分库分表逻辑，更加接近应用层的数据理解，所以目前的真正独立的数据库中间件好像没有真大互联公司的实际考验，已经知道的使用应用侧分库分表组件的互联网公司有：
  A、阿里--TDDL
  B、当当--sharding-jdbc，已经开源
  C、原大众点评--Zebra
  D、美团--MTDDL（Meituan Distributed Data Layer），参考链接：https://tech.meituan.com/mtddl.html
也有使用proxy方案的，如京东自己开发JProxy，但也是根据自己业务特点开发的。

ProxySQL的应用方向应该是公司没有能力开发自己的中间件组件时使用，但应该在应用端使用，应用层需要在应用中考虑使用配置，并在应用服务器上直接部署，由于底层的数据库CELL提供给应用层的读接口、写接口已经在高可用和性能可扩展，配置只需要考虑业务逻辑与逻辑库的关系，不需要考虑数据库的机器细节：
1、应用层没有自己读写分离实现方案，在应用端使用，用于实现读写分离

2、应用层没有自己分库分表实现方案，在应用端使用，用于实现分库分表

其实也应该考虑开源的组件如sharding-jdbc