关于Consul测试的几点补充

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

最近在完善Consul相关的一些高可用方向的升级，目前是基于MHA+Consul的方案，对于Consul方面算是做一些普及和推广，而对于MHA则是处于保守的维护状态，相信不久就会使用orch来做替代。

当然前提是一些版本规划能够统一，而且是与时俱进，在此补充几点关于service_name测试的一些建议。

首先对于线上业务来说，要做高可用升级，基本上对于服务的影响是非常短暂的，对于很多应用来说，从业务的闪断到升级完成，这个过程需要大概是1-2秒钟，可以理解这种发布是可持续的，而如果要完整模拟MHA的故障过程，需要的时间是远大于2秒的，所以对于有些业务来说，就难以接受了，所以我设想了如下的一些改进方案。

1）首先业务方需要对基于Consul的域名服务进行连接性测试，这种情况下可以直接使用最新配置的域名服务，做一些业务侧的验证和测试，如果要做升级，则可以理解在业务低峰期直接做切换测试，然后测试验证无误后切换到线上服务。

2）而如果对一些业务优先级较高的业务，做在线切换是不现实的，也即上面所说的闪断会大于2秒以上，则可以使用平行的业务测试来进行对接。 比如我们搭建一套平行的环境，端口配置不同，则可以和业务方进行对接测试，测试的时候使用的都是新的端口，这样我们可以在线上真实的模拟服务的切换情况，而等待测试完成之后，则将环境重置，恢复原来的端口和服务配置，这可以理解是一种配置的平滑切换，是目前较为折中的测试方案。

3）在线升级服务，有了基于域名的服务之后，保证应用重连机制，那么我们可以对MySQL服务做在线升级，比如与时俱进，把服务的版本从5.7.16升级到5.7.26，而整个切换的过程时间是在1秒钟左右，对于业务几乎无感知。

4）在第3步的基础之上，我们可以开启新的服务的MGR特性，然后重新构建新的MGR secondary节点，这样我们就可以快速的把MySQL服务从原本的MHA切换到了MGR,前提是应用的基础配置满足（比如表要有主键等，节点在同机房内）

5）在满足一些基础业务的前提下，对已有的读请求做负载均衡，可以配置同样的域名服务，挂载多个读节点，由consul实现负载均衡。

6）对于域名的使用，对于很多业务来说，其实会有更高的要求，我们可以借助ACL实现这种Consul API服务，即应用端可以通过接口的方式来得到对应的数据库服务IP信息，而应用端本身是有连接池的配置，在应用端需要时可以进行轮询获得相应的信息，这样一来应用一来的就不是单纯的域名服务，而是对这两类服务做了解耦，当然从这个层面来看，对于应用端的逻辑改造会有一定的代码量，但是收益也是巨大的。