Consul

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一站式问题解决，轻松小巧的软件!