「干货」nacos服务发现注册简单解析

本文通过学习图灵学院诸葛老师的微服务课程而做的笔记，感谢诸葛老师的公开课。

1.Nacos核心架构图

• 微服务在启动的时候会将自己注册到nacos服务注册中心，同时对外发布http接口供其他系统进行调用。
• 服务消费者基于Feign调用服务提供者对外发布的接口，先对调用的本地接口加上注解@FeignClient，Feign会针对加了注解的接口生成动态代理，服务消费者针对Feign生成的动态代理调用方法时，会在底层生成Http协议格式的请求。
• Feign 最终会调用Ribbon从本地的Nacos注册表的缓存里根据服务名取出服务提供在机器的列表，然后进行负载均衡并选择一台机器出来，对选出来的机器IP和端口拼接之前生成的url请求，生成调用的Http接口地址，最后基于HTTPClient调用请求。

2.服务注册，如何实现服务注册的高并发

各服务通过nacos client向注册中心发送注册请求，发送的注册请求数据放在一个阻塞队列中（set集合），客户端即刻返回注册成功。

Nacos server通过一个异步任务去阻塞队列中进行消费，然后去写进注册表，最终完成注册。

问题：在服务注册的过程中是如何实现的高并发？

解答：通过内存队列+异步任务的形式。

3.心跳机制

• nacos client通过一个心跳任务来保持与注册中心的连接，也就是保活。
• zookeeper、netty也是通过心跳机制进行保活，但是使用的是轻量级的socket来实现；nacos底层使用的是http接口。
• 心跳机制：通过线程池来进行实现，延时5秒启动。源码里面有个setBeat()方法。
• 服务端接收到心跳之后需要做什么？
• 解答：服务端需要更新本次心跳的时间，也就是最后更新时间。
• 服务端如何进行感知心跳的？
• 解答：通过Helthcheck()方法，进行健康检查任务，runnable 默认延时5秒处理。
• 服务端拿到Instance的set集合后，遍历判断，使用（当前时间-最后更新时间>设置的健康超时时间（默认15秒）），如果超过了15秒，则将状态改为不健康。
• 里面还有一个遍历判断：使用（当前时间-最后更新时间>设置的健康超时时间（默认30秒）），如果超过了30秒，则认为服务挂掉了，则从注册表中将该服务剔除。

4.nacos如何解决注册表的的读写高并发冲突？

（1）使用COW机制，也就是写实复制技术Copy On Write

首先一个概念：注册表的结构是一个双层Map的结构

Map<string,map></string,map

Space--Group--Service--Cluster--Instance

例子：develop（开发版本）--组（订单服务组、积分服务组）--服务（订单服务）--地区（BJ、NJ）--实例（机器8001/8002）

（2）读写数据如何避免数据错乱？保证读写的一致性？

一种是加锁，但加锁无法实现读写的高并发。

一种是写时复制COW。也就是在注册时：复制一份注册表（根据Instance，复制其中的一部分），在副本中进行写，写完进行替换。复制的内容其实是一个set集合，也就是Map结构里面的内层结构，根据Instance名称进行定位，并非复制的整个注册表。

服务发现时，读取原数据，拉取到本地，然后经过Feign接口去调用其他服务，当然Feign调用的时候也要借助ribbon进行负载均衡，所以说ribbon实际上是做的客户端的负载均衡。实际上nacos是一个读写分离的机制，从而实现了高并发。

（3）那么问题来了：假设两个服务同时注册、同时都复制了一份然后进行副本修改，替换的时候会产生并发覆盖问题吗？

解答：不会。因为消费的时候是从阻塞队列中进行消费，是一个单线程的消费，所以不会出现并发覆盖的问题。

那么问题又来了：既然是单线程的消费，会不会导致队列任务的积压，因为单线程毕竟消费慢？

解答：这是一个极小的概率事件，内存队列也比较的快，可以处理得来。

就算出现了也无所谓，稍微延迟一点没有关系，eureka还延迟一分钟以上呢。除非你同时启动上千台才会出现这种情况

注：官方大大表示nacos的TPS为13000/S.

TPS为吞吐量，吞吐量为每秒内的访问数值，QPS为峰值时的每秒钟访问数值。

5.关于Feign的简单说明

Fiegn的核心思想是做动态代理，然后拼接url，借助ribbon进行负载均衡。

6.脑裂问题（zookeeper、nacos的cp模式如何避免脑裂问题）

解答：集群数必须为（2N+1），只有当半数节点投票之后才会成为leader。

当leader与flower之间由于网络问题断开连接时，剩下的会自动进行投票选举出新的leader。当此时像集群中写数据时，是否会出现往两个leader都写入数据，等网络恢复时，老的leader会自动变成为flower，并且老的leader上的数据会自动清除，然后新leader会将自身数据同步过去。

实际上是无法向两个leader都写入数据，这里的数据写入其实是分了2个步骤，第一先向leader写入数据，第二部向flower去同步数据，只有当半数以上的机器都写入成功才会真正的成功，所以老leader无法成功写入数据，进而避免了脑裂问题。

注：nacos可配置AP模式，也可配置CP模式。

其中zookeeper支持的是CP模式，Eureka支持的是AP模式。Nacos既可以AP也可以CP。

CAP：一致性、可用性、分区容错性

BASE理论：最终一致性。

7.集群中leader的选举机制是什么（ZAB协议）？

根据ZAB协议

话说在分布式系统中一般都要使用主从系统架构模型，指的是一台leader服务器负责外部客户端的写请求，然后其他的都是follower服务器。leader服务器将客户端的写操作数据同步到所有的follower节点中。

就这样，客户端发送来的写请求，全部给Leader，然后leader再转给Follower。这时候需要解决两个问题：

• leader服务器是如何把数据更新到所有的Follower的。
• Leader服务器突然间失效了，该怎么办？

因此ZAB协议为了解决上面两个问题，设计了两种模式：

(1)消息广播模式：

把数据更新到所有的Follower。

如果你了解过2PC协议的话，理解起来就简单很多了，消息广播的过程实际上是一个简化版本的二阶段提交过程。我们来看一下这个过程：

• Leader将客户端的request转化成一个Proposal（提议）
• Leader为每一个Follower准备了一个FIFO队列（先进先出），并把Proposal发送到队列上。‘
• leader若收到follower的半数以上ACK反馈
• Leader向所有的follower发送commit。

其实通俗的理解就比较简单了，我是领导，我要向各位传达指令，不过传达之前我先问一下大家支不支持我，若有一半以上的人支持我，那我就向各位传达指令了。

• leader首先把proposal发送到FIFO队列里
• FIFO取出队头proposal给Follower
• Follower反馈一个ACK给队列
• 队列把ACK交给leader
• leader收到半数以上ACK，就会发送commit指令给FIFO队列
• FIFO队列把commit给Follower。

这就是整个消息广播模式。下面我们开始看一下，如果这个leader节点崩溃了，怎么办？也就是第二种模式：崩溃回复模式。

(2)崩溃恢复模式

Leader发生崩溃时，如何恢复？

leader就是一个领导，既然领导挂了，整个组织肯定不会散架，毕竟离开谁都能活下去是不是，这时候我们只需要选举一个新的领导即可，而且还要把前leader还未完成的工作做完，也就是说不仅要进行leader服务器选取，而且还要进行崩溃恢复。

(1)leader服务器的选举

我们先来看服务器的三种状态：

looking状态：也就是观望状态。

following状态：组织成员跟随leader做事情。

leading状态：组织成员老大，发号司令。

当leading节点由于网络原因或者其他原因，挂了，那么此时每一个follow节点都会变成looking观望状态。每个处于looking状态的节点都想着成为leader，于是开始进行选举新的leader节点。

半数机制：集群中半数以上的机器存活，集群可用。

假设有五台服务器12345开始重新投票选举，服务器启动顺序为1-5依次进行：

1.服务器1启动，发起一次投票选举。服务器1投自己一票。此时服务器1票数为1，不够半数以上，选举无法完成，服务器1处于looking状态；

2.服务器2启动，发起一次投票选举。服务器1和2分别投自己一票并交换选票信息。此时服务器1发现服务器2的ID比自己目前投票选举的服务器1大，更改选票为投票给服务器2。此时服务器1票数为0，服务器2票数为2。没有达到半数以上的投票，选举无法完成。服务器1、服务器2状态为looking状态。

3.服务器3启动，发起一次投票选举。此时服务器1服务器2都会更改选票为服务器3。此时投票结果为：服务器1票数为0，服务器2票数0，服务器3票数为3。服务器3票数超过半数以上，服务器3当选为leader服务器。服务器1、服务器2状态更改为following状态，服务器3更改为leading状态。

4.服务器4启动，发起一次投票选举。此时服务器1、服务器2、服务器3已经不是looking状态，不会更改选票信息。交换选票信息之后，服务器1/2/3位0票，服务器3为3票，服务器4位1票。此时服务器4会少数服从多数，更改选票信息为服务器3，并且更改状态为following状态。

5.服务器5启动，发起一次投票选举。同服务器4一样的步骤。

（2）leader选举完之后，要进行崩溃恢复

zab协议奔溃恢复需要满足以下2个条件：第一、确保已经被leader提交的proposal必须最终被所有的follower服务器提交。第二、确保丢弃已经被leader出的但是没有被提交的proposal。

奔溃恢复步骤：

第一步：选取当前取出最大的ZXID，代表当前的事件是最新的。

第二步：新leader把这 个事件proposal提交给其他的ollower节点。

第三步：fllower节点会根据leader的消息进行回退或者是数据同步操作。最终目的要保证集群中所有节点的数据副本保持一致。

这就是整个恢复的过程，其实就是相当于有个日志一样的东西，记录每一次操作, 然后把出事前的最新操作恢复，然后进行同步即可。

欢迎关注公众号：