MySQL和consul服务的高可用方案

 这是学习笔记的第 1757篇文章

这两天写了一篇高可用的思考，其实只是一个初步开始，后面会有一波文章出来讨论这方面的内容。 

其实初步的高可用建设到位之后，我们能够实现基本的高可用，就会有更高的要求提出来。 

在VIP的基础上，如果要实现跨机房的方案，其实有蛮多的改进之处，方向上的改进是去除硬IP的绑定方式，而采用域名来柔化业务连接。

假设我们要连接到一个数据库，如果我们采用如下的方式，相对来说会更加轻量，而且更加易于理解，比如这个配置里面，我们可以定义业务的维度，定义实例的角色（读还是写），还可以定义服务的范围（比如domain等），这样一来，整个服务比IP的方式要更加具有业务意义。

# mysql -uxxx -p -htest4306-mysql_r.service.test -P4306

当然有读的业务域名，我们还可以定义其他的，比如混合访问，比如读写分离等。比如中间件要实现的读写分离，我们做好了域名转发，甚至都可以不用配置中间件即可完成这种需求。 

    在这里还有一个重要的概念就是服务发现，我们提供的域名其实真正对应的是一种服务，这种服务如何被识别和注册等，这些都是需要我们来指定相应的规则的。 整体来说，zookeeper,consul,etcd,Eureka等，从我的角度来说，我是建议consul和zookeeper的。 consul相对来说会更加完整，很多功能和接口都是打包好的，和Python里面的Django有点类似，而且对于consul来说，有一个优点是对于域名的支持很好。 

    一般来说，我们要配置域名，一种是本地域名，我们可能需要在/etc/hosts里配置，或者配置域名服务器来完成，这种情况下这种域名配置一来资源是定量的，你没法直接扩展，而来你要同步配置改动，一般来说这列操作是比较笨重的。轻量一层的方法就是基于分布式协议来完成，zookeeper可以，consul也可以。

    这样一来我们的域名服务就可以通过consul server来完成了，而后续的域名转发或者域名的外部服务则可以通过网络层面的域名服务器来实现定向转发或者配置识别。 

    我们可以基于consul设计几类高可用方案。

基于传统MHA层的设计如下，对于DNS服务层来说，我们可以直接通过consul server来完成，也可以间接通过DNS层的域名转发来完成。

这个方案是基于双主的方案，当然这种方案看起来架构简单，但是缺点也很明显。在网络不好的情况下，很容易出现问题，可以作为一种备选方案，但是不推荐首选。

第三种是基于MGR的方案，这种方案相对来说会轻量一些，不需要MHA层，本身MGR层面通过paxos分布式协议设计来保证数据强一致。默认情况下是推荐单主模式的，对于多主模式目前可以认为是提供了一种可行方案，但是暂不推荐在异机多活的场景中。