一、服务注册和发现架构

Nacos 另一个非常重要的特性就是服务注册与发现，说到服务的注册与发现相信大家应该都不陌生，它们是服务治理的最基础功能。

Nacos 支持几乎所有主流类型的 “服务” 的发现、配置和管理。

了解过 Dubbo 的同学，应该对 Dubbo 的架构非常熟悉，最经典的一张架构图如下所示：

Dubbo架构

图中的6个步骤的含义解释如下：

0、服务容器负责启动，加载，运行服务提供者。
1、服务提供者在启动时，向注册中心注册自己提供的服务。
2、服务消费者在启动时，向注册中心订阅自己所需的服务。
3、注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4、服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5、服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

其中图中最上方的 Registry 就是注册中心，负责服务的注册与发现。Dubbo 有自己的 Registry 实现，而 Nacos 则是另一种 Registry 实现。

二、Nacos服务发现

相对服务注册而言服务发现就简单很多了。就是Nacos客户端调用Open API或者SDK查询服务列表，服务端接受到请求后根据将查询到服务包装成json格式返回。

既然如此，客户端是啥时候发起服务列表查询？
如果客户端查的时差内，刚好有服务实例有down掉，那客户端的请求岂不是有请求到刚好down的服务实例？下面进行解答。

三、客户端每秒发起服务列表查询

客户端有一个HostReactor类，在com.alibaba.nacos.client.naming.core包下。

跟踪进去在scheduleUpdateIfAbsent方法中发现新增了一个任务。

scheduleUpdateIfAbsent方法

HostReactor它里面有一个UpdateTask线程，每1s发送一次pull拉取请求，获取服务最新的地址列表。
更新服务的核心逻辑在updateService方法中：

updateServiceg更新服务地址

再看看processServiceJson方法，本地维护一个Map<String,ServiceInfo> serviceInfoMap存储服务信息，同时调用DiskCache.write(serviceInfo, this.cacheDir)方法把服务信息写入本地缓存文件中;

四、服务端发送通知

服务端采取的是基于push的方式向客户端通知，由于服务端和服务提供者（各个微服务provider）建立了心跳机制，一旦某个服务出现故障，服务端察觉出后，会发送一个push消息给Nacos客户端，也就是我们的消费者。这个push消息是使用DatagramSocket来实现的。
服务消费者收到服务端发来的push消息之后，使用HostReactor中提供的ServiceInfo processServiceJson(String json)方法解析消息，并更新本地服务地址列表。