consul服务注册与发现机制

注册中心引入

最近，网关服务让下游服务接入consol，为了解决网关转发下游服务，下游服务刚好有节点不可用，转发到不可用的节点上报错。针对分布式多节点，上面的问题常会发生，就引入了注册中心。

那什么是注册中心呢？

大型互联网，业务领域都会细化不同的子系统，部署在不同的服务器上，也就是分布式部署，每个服务还部署多个节点，服务与服务之间需要相互调用，这时服务注册中心就出现了。

如上例子，网关要调用授信，授信服务部署了3个节点，那网关该调用哪个节点，哪个节点是可用的，哪个节点是不可用的，网关并不知道，这就需要注册中心。

授信服务每个节点在启动的时候，注册到注册中心，注册中心就像一个大管家一样，知道所有的服务节点可用情况。网关就可以通过注册中心的发现机制知道可用的服务节点。

consul服务注册中心的整体架构

基于consul的注册中心，分为两部分：consul server、consul agent；consul agent要在每个服务节点上部署，consul server要在多台服务器上部署，一般是3、5台，有一个leader，多个follower。服务注册与发现都是通过leader，leader接收到数据后，同步给follower。如果leader挂了，这时候会在选举出一个leader。如下图：

consul如何通过Raft协议实现数据一致性

我们都知道分布式，关注的是数据一致性、可用性，那consul是如何实现数据一致性呢？consul是采用Raft协议来实现的，leader接收到数据，不是立马响应成功，而是把数据同步给follower成功后，才注册成功。如果恰巧碰到leader宕机了，注册也就失败了。很显然，consul作为注册中心，数据是是一致性的，要么所有的server都接收到，要么都失败。

consul agent如何实现健康检查

 最后说说Consul是如何通过各个服务机器上部署Agent来实现分布式健康检查的。集中式心跳机制，会给server带来很大的压力，这边就采用agent。

consul agent部署在每个应用节点的服务器上，通过心跳机制向应用发出健康检查，把不可用的信息通知给consul server；这样大大减少了consul server 的压力。如下图：