现如今市面上注册中心的轮子很多，我实际使用过的就有三款：Eureka、Nacos，Zookeeper、Consul 由于当前参与Nacos 集群的维护和开发工作，期间也参与了 Nacos 社区的一些开发和 bug fix 工作，过程中对 Nacos 原理有了一定的积累，今天给大家分享一下 Nacos 动态服务发现的原理。

服务发现是指使用一个注册中心来记录分布式系统中的全部服务的信息，以便其他服务能够快速的找到这些已注册的服务。在单体应用中，DNS+Nginx 可以满足服务发现的要求，此时服务的IP列表配置在 nginx 上。在微服务架构中，由于服务粒度变的更细，服务的上下线更加频繁，我们需要一款注册中心来动态感知服务的上下线，并且推送IP列表变化给服务消费者，架构如下图。

讯享网

Nacos实现动态服务发现的核心原理如下图，我们接下来的内容将围绕这个图来进行。

整个服务注册与发现过程，都离不开通讯协议，在1.x的 Nacos 版本中服务端只支持 http 协议，后来为了提升性能在2.x版本引入了谷歌的 grpc，grpc 是一款长连接协议，极大的减少了 http 请求频繁的连接创建和销毁过程，能大幅度提升性能，节约资源。据官方测试，Nacos服务端 grpc 版本，相比 http 版本的性能提升了9倍以上。

简单来讲，服务注册的目的就是客户端将自己的ip端口等信息上报给 Nacos 服务端，过程如下：
创建长连接
Nacos SDK 通过Nacos服务端域名解析出服务端ip列表，选择其中一个ip创建 grpc 连接，并定时检查连接状态，当连接断开，则自动选择服务端ip列表中的下一个ip进行重连。
健康检查请求
在正式发起注册之前，Nacos SDK 向服务端发送一个空请求，服务端回应一个空请求，若Nacos SDK 未收到服务端回应，则认为服务端不健康，并进行一定次数重试，如果都未收到回应，则注册失败。
发起注册
当你查看Nacos java SDK的注册方法时，你会发现没有返回值，这是因为Nacos SDK做了补偿机制，在真实给服务端上报数据之前，会先往缓存中插入一条记录表示开始注册，注册成功之后再从缓存中标记这条记录为注册成功，当注册失败时，缓存中这条记录是未注册成功的状态，Nacos SDK开启了一个定时任务，定时查询异常的缓存数据，重新发起注册。
Nacos SDK注册失败时的自动补偿机制时序图。

相关源码如下：

执行补偿定时任务RedoScheduledTask

讯享网

服务端数据同步(Distro协议)：
Nacos SDK只会与服务端某个节点建立长连接，当服务端接受到客户端注册的实例数据后，还需要将实例数据同步给其他节点。Nacos自己实现了一个一致性协议名为Distro，服务注册的时候会触发Distro一次同步，每个Nacos节点之间会定时互相发送Distro数据，以此保证数据最终一致。关于Distro协议更多信息可以阅读《Nacos 自研Distro协议》
服务实例上线推送：
Nacos服务端收到服务实例数据后会将服务的最新实例列表通过grpc推送给该服务的所有订阅者。
服务注册过程源码时序图：
整理了一下服务注册过程整体时序图，对源码实现感兴趣的可以按照根据这个时序图view一下源码。

目前主流的注册中心，比如Consul、Eureka、Zk包括我们公司自研的Gsched，都是通过心跳机制来感知服务的下线。Nacos也是通过心跳机制来实现的。
Nacos目前SDK维护了两个分支的版本（1.x、2.x），这两个版本心跳机制的实现不一样。其中1.x版本的SDK通过http协议来定时向服务端发送心跳维持自己的健康状态，2.x版本的SDK则通过grpc自身的心跳机制来保活，当Nacos服务端接受不到服务实例的心跳，会认为实例下线。如下图：

部分源码
grpc监测到连接断开事件，发送ClientDisconnectEvent

移除客户端注册的服务实例

讯享网

当一个服务发生上下线，Nacos如何知道要推送给哪些客户端？
Nacos SDK 提供了订阅和取消订阅方法，当客户端向服务端发起订阅请求，服务端会记录发起调用的客户端为该服务的订阅者，同时将服务的最新实例列表返回。当客户端发起了取消订阅，服务端就会从该服务的订阅者列表中把当前客户端移除。
当客户端发起订阅时，服务端除了会同步返回最新的服务实例列表，还会异步的通过grpc推送给该订阅者最新的服务实例列表，这样做的目的是为了异步更新客户端本地缓存的服务数据。
当客户端订阅的服务上下线，该服务所有的订阅者会立刻收到最新的服务列表并且将服务最新的实例数据更新到内存。

我们也看一下相关源码，服务端接收到订阅数据，首先保存到内存中。

然后发布订阅事件。

讯享网

服务端自己消费订阅事件，并且推送给订阅的客户端最新的服务实例数据。

推送方式
前面说了服务的注册和订阅都会发生推送（服务端->客户端），那推送到底是如何实现的呢？
在早期的Nacos版本，当服务实例变化，服务端会通过udp协议将最新的数据发送给客户端，后来发现udp推送有一定的丢包率，于是新版本的Nacos支持了grpc推送。Nacos服务端会自动判断客户端的版本来选择哪种方式来进行推送，如果你使用1.4.2以前的SDK进行注册，那Nacos服务端会使用udp协议来进行推送，反之则使用grpc。
推送失败重试
当发送推送时，客户端可能正在重启，或者连接不稳定导致推送失败，这个时候Nacos会进行重试。Nacos将每个推送都封装成一个任务对象，放入到队列中，再开启一个线程不停的从队列取出任务执行，执行之前会先删除该任务，如果执行失败则将任务重新添加到队列，该线程会记录任务执行的时间，如果超过1秒，则会记录到日志。
推送部分源码
添加推送任务到执行队列中。

讯享网

推送任务PushExecuteTask 的执行。

执行推送任务线程InnerWorker 的执行。

讯享网

服务消费者首先需要调用Nacos SDK的接口来获取最新的服务实例，然后才能从获取到的实例列表中以加权轮询的方式选择出一个实例（包含ip，port等信息），最后再发起调用。
前面已经提到Nacos服务发生上下线、订阅的时候都会推送最新的服务实例列表到当客户端，客户端再更新本地内存中的缓冲数据，所以调用Nacos SDK提供的查询实例列表的接口时，不会直接请求服务端获取数据，而是会优先使用内存中的服务数据，只有内存中查不到的情况下才会发起订阅请求服务端数据。Nacos SDK内存中的数据除了接受来自服务端的推送更新之外，自己本地也会有一个定时任务定时去获取服务端数据来进行兜底。Nacos SDK在查询的时候也了容灾机制，即从磁盘获取服务数据，而这个磁盘的数据其实也是来自于内存，有一个定时任务定时从内存缓存中获取然后加载到磁盘。Nacos SDK的容灾机制默认关闭，可通过设置环境变量failover-mode=true来开启。
架构图

用户查询流程

查询服务实例部分源码

本篇文章向大家介绍Nacos服务发现的基本概念和核心能力以及实现的原理，旨在让大家对Nacos的服务注册与发现功能有更多的了解，做到心中有数。