优化Spring Cloud微服务注册架构详解 一点课堂（多岸学院）

一、什么是服务注册中心？

先回顾一下什么叫作服务注册中心？

顾名思义，假设你有一个分布式系统，里面包含了多个服务，部署在不一样的机器上，而后这些不一样机器上的服务之间要互相调用。

举个现实点的例子吧，好比电商系统里的订单服务须要调用库存服务，以下图所示。

如今的问题在于，订单服务在192.168.31.154这台机器上，库存服务在192.137.1.33这台机器上。

如今订单服务是想要调用库存服务，可是他并不知道库存服务在哪台机器上啊！毕竟人家都是在不一样机器上的。

因此这个时候就须要服务注册中心出场了，这个时候你的系统架构中须要引入独立部署在一台机器上的服务注册中心，以下图所示。

而后订单服务、库存服务之类的兄弟，都须要配置上服务注册中心部署在哪台机器上，好比192.168.31.45这台机器。

接着订单服务、库存服务他们本身启动的时候，就得发送请求到到服务注册中心上去进行服务注册。

也就是说，得告诉服务注册中心，本身是哪一个服务，而后本身部署在哪台机器上。

而后服务注册中心会把你们注册上来的信息放在注册表里，以下图。

接着订单服务假如想要调用库存服务，那么就找服务注册中心问问：能不能告诉我库存服务部署在哪台机器上？

服务注册中心是知道这个信息的，因此就会告诉订单服务：库存服务部署在192.1371.133这台机器上，你就给这台机器发送请求吧。

而后，订单服务就能够往库存服务的那台机器发送请求了，完成了服务间的调用。

整个过程，以下图所示：

上述就是服务注册中心的做用、地位以及意义，如今你们应该知道服务注册中心的做用了吧。

好！接着咱们就来看看Consul做为服务注册中心，他的架构设计原理是什么？

二、Consul服务注册中心的总体架构

若是要基于Consul做为服务注册中心，那么首先必须在每一个服务所在的机器上部署一个Consul Agent，做为一个服务所在机器的代理。

而后还得在多台机器上部署Consul Server，这就是核心的服务注册中心。

这个Consul Agent能够用来收集你的服务信息而后发送给Consul Server，还会对你的服务不停的发送请求检查他是否健康。

而后你要发现别的服务的时候，Consul Agent也会帮你转发请求给Consul Server，查询其余服务所在机器。

Consul Server通常要求部署3~5台机器，以保证高可用以及数据一致性。

他们之间会自动实现数据同步，并且Consul Server集群会自动选举出一台机器做为leader，其余的Consul Server就是follower。

我们看下面的图，先感觉一下这个Consul他总体的架构。

三、Consul如何经过Raft协议实现强一致性？

Eureka服务注册中心是不保证数据一致性的。

这样的话，极可能你注册的服务，其余人是发现不了的，或者很迟才能发现。

OK，那么这里就来讨论一下Consul是如何实现数据一致性的。

首先，你们知道Consul Server是部署集群的，并且他会选举出来一台Server做为Leader。

接下来各个服务发送的注册请求都会落地给Leader，由Leader同步给其余Follower。

因此首先第一点，Leader Server是绝对有最新的服务注册信息的，是否是？

好比库存服务发起注册了，那么Leader Server上必定有库存服务的注册信息。

接着若是好比订单服务要发现库存服务的话，这个查询请求会发送给Leader Server。

这样服务注册和发现，都是经过一台Leader Server来进行的，就能够保证服务注册数据的强一致性了，你们看下图。

接着你们想，假如说库存服务在注册的时候数据刚写到Leader Server，结果Leader Server就宕机了，这时候怎么办？

那么此时这条注册数据就丢失了，订单服务就无法发现那个库存服务了。不要紧，这里Consul会基于Raft协议来解决这个问题。

首先，库存服务注册到Leader Server的时候，会采起Raft协议，要求必须让Leader Server把这条注册数据复制给大部分的Follower Server才算成功。

这就保证了，若是你认为本身注册成功了，那么必然是多台Consul Server都有这条注册数据了。

若是你刚发送给Leader Server他本身就宕机了，那么此次注册会认为失败。

此时，Consul Server集群会从新选举一个Leader Server出来，你须要再次从新注册。

这样就能够保证你注册成功的数据绝对不会丢，而后别人发现服务的时候必定能够从Leader Server上获取到最新的强一致的注册数据。

整个过程，以下图所示：

上面的图就能够看到，只要你注册的时候基于Raft协议强制同步到大多数Server，哪怕是Leader挂了，也会选举新的Leader。

这样就可让别人重新的Leader Server来发现你这个服务，因此数据是绝对强一致的。

四、Consul如何经过Agent实现分布式健康检查？

最后说说Consul是如何经过各个服务机器上部署Agent来实现分布式健康检查的。

集中式的心跳机制，好比传统的Eureka，是让各个服务都必须每隔必定时间发送心跳到Eureka Server。

若是一段时间没收到心跳，那么就认为这个服务宕机了。

可是这种集中式的心跳机制会对Eureka Server形成较大的心跳请求压力，实际上平时Eureka Server接收最多的请求之一就是成千上万服务发送过来的心跳请求。

因此Consul在这块进行了架构优化，引入了Agent概念。

每一个机器上的Consul Agent会不断的发送请求检查服务是否健康，是否宕机。若是服务宕机了，那么就会通知Consul Server。

怎么样？是否是发现各个服务本身不用再发送心跳请求去Server了？减少了Server这部分的压力吧？

没错，这就是Consul基于Agent实现的分布式健康检查机制，能够大幅度的减少Server端的压力。

这样一来，哪怕你就部署个三五台机器，能够轻松支持成千上万个服务。

我们再来一张图，一块儿来看看：

QQ讨论群组：984370849 706564342 欢迎加入讨论

想要深刻学习的同窗们能够加入QQ群讨论，有全套资源分享，经验探讨，没错，咱们等着你，分享互相的故事!