Consul是一款服务器网络问题解决方案，安装软件自动化网络配置，安全运行连接，多个集群合并到一个服务网格中。支持服务到服务的连接授权，并且加密，方便管理!
Consul特点
与Kubernetes集成和扩展。
跨越任何运行时的服务网格
动态负载均衡
安全的多云服务网络
服务发现与健康检查
提供一个强大的生态系统
Consul问题说明
consul作为注册中心和eureka的机制不同。
当微服务启动后首先向注册中心发注册请求，这点两者一致。之后consul在维护可用服务列表时，采用的是主动向微服务发健康检查的接口(也可以配置成微服务主动向consul发心跳，但是我看完官网和各类文章都没说清楚具体怎么搞)。如果微服务正常返回，那么就认为服务正常。eureka是等待微服务主动向eureka发心跳，eureka收到心跳后，就给这个服务续约，认为服务是正常的。
正是因为这点差异就产生了大问题!
场景一：consul和微服务间的网络不稳定，断开了几分钟。
在此情况下，consul向微服务发的健康检查请求发不通，认为微服务挂了，就从服务列表里剔除他。
当网络恢复后，注意，已经剔除的服务，consul是不会主动再发健康检查的。那么服务列表里没有他，
也就不正常了。网关的转发都是需要获取可用服务列表，才能做转发的!
这时候，你想让微服务注册上consul就只能重启微服务了。这在生产环境意味着什么就不用多说了吧。
是不是很坑?
场景二：consul因为某种情况需要重启。(可能是consul也需要投产，或者其他原因，总之就是需要重启consul)
这个场景和上面的类似。当consul重启后，之前已经注册上来的，状态正常的服务，consul忘记了。
因为他重启了，他不记得前世的服务列表。
所以这种情况下，也需要重启我们的微服务，才能使状态正常。
综上，因为consul的健康检查机制是consul主动发，跟eureka不同才导致这种问题。
问题很清楚了，要怎么解决呢?
我查了很多资料，除了consul可以用ttl的方式，让微服务主动发心跳来续约外，好像没有想成的方案。
但是这个ttl的方案，官网没仔细说，网上的文章也是一大抄，没人说的明白。
我经过研究后，发现consul提供了好多rest接口。可以通过接口注册，注销，查询等。
那么我们就可以仿照eureka的方式，主动查consul的服务列表，类似心跳。
如果没查到，或者发不通(consul挂了)那么久开始发注册的接口，把自己注册上去。
不停的发，直至成功。
Consul测评
Consul一站式问题解决，轻松小巧的软件!
