Nacos作为阿里巴巴开源的服务发现、配置管理和服务管理平台，在微服务架构中扮演着至关重要的角色。本文将从源码层面，深入剖析其服务注册与发现的核心机制。

一、核心架构与模块

Nacos的服务注册与发现功能主要位于nacos-naming模块。其核心模型围绕Service、Cluster和Instance展开。

• Service: 代表一个微服务，如“user-service”。
• Cluster: 服务下的集群，通常用于区分不同环境（如Docker集群、物理机集群）或实现流量隔离。
• Instance: 服务的具体实例，包含IP、端口、健康状态、元数据等信息。

服务注册表的核心是内存数据结构ConcurrentHashMap<String, Service>，键为服务名（Service Name），实现了高效的服务管理。

二、服务注册流程源码解析

客户端发起注册请求（如通过NamingService.registerInstance）后，流程如下：

1. 客户端发送请求：请求体为Instance对象，通过HTTP API（/nacos/v1/ns/instance）或gRPC发送到Nacos Server。

1. 服务端控制器处理：请求由InstanceController的register方法处理。它进行参数校验，并调用核心服务层。

1. 服务层处理：进入ServiceManager的registerInstance方法。这是核心逻辑所在：

• 创建或获取Service对象：首先从注册表serviceMap中查找对应的Service。如果不存在，则创建一个新的Service并放入Map。创建过程是线程安全的，使用了双重检查锁模式。

• 构建Cluster并添加实例：在Service内部，找到或创建对应的Cluster对象，最终将Instance对象添加到Cluster的实例列表（persistentInstances 或 ephemeralInstances Map）中。这里根据实例的ephemeral属性（是否临时实例）进行区分，临时实例基于内存，持久化实例会写入Derby数据库。

• 触发监听器：实例添加成功后，发布InstanceChangeEvent事件，通知所有订阅该服务变化的客户端（基于长轮询或gRPC双向流）。

1. 健康检查与心跳：对于临时实例，注册成功后，客户端需要定期（默认5秒）向服务器发送心跳（HTTP API /nacos/v1/ns/instance/beat）。服务端的BeatReactor线程会检查心跳超时（默认15秒），超时则将实例标记为不健康并从服务列表中剔除。对于持久化实例，则由服务器端主动进行健康检查（如TCP探测）。

三、服务发现与订阅流程源码解析

客户端获取服务列表（如通过NamingService.selectInstances）或订阅服务变化，流程如下：

1. 获取服务列表：客户端调用InstanceController的list方法。服务端从ServiceManager中查询对应的Service，遍历其下所有Cluster中健康的Instance列表，过滤后返回给客户端。

1. 服务订阅机制：这是Nacos实现实时服务发现的关键。客户端通过subscribe方法发起订阅。

• Push还是Pull？ Nacos采用了客户端长轮询（Long Polling） 的机制来模拟服务端推送。客户端定时（默认10秒）发起一个超时时间较长的HTTP查询请求（如30秒），询问服务列表是否有变化。

• 服务端处理长轮询：请求到达InstanceController的list方法。服务端会检查请求中携带的客户端最后已知的实例哈希值（checksum）与当前服务实例列表的哈希值是否一致。

• 如果一致，说明服务无变化。服务端会将这个请求放入一个延迟队列（属于ClientBeatCheckTask相关的机制），并挂起（阻塞）这个HTTP连接，直到超时或服务有变化被唤醒。这减少了无谓的响应。

• 如果不一致，则立即返回最新的实例列表。

• 变化通知：当某个服务的实例列表发生变化时（注册、下线、健康状态变更），会触发Service的onChange方法。它会遍历所有挂起的长轮询连接，找到订阅了该服务的连接，立即返回变化信息，结束挂起状态。

1. gRPC实现：在1.x版本后，Nacos提供了基于gRPC的双向流通信方式作为长轮询的替代。客户端建立连接后，服务端可以主动推送服务变更，实时性更高，减少了HTTP轮询的开销。相关核心类为GrpcClient和ConnectionManager。

四、一致性协议：AP与CP模式

Nacos服务注册表的数据一致性是其设计亮点，支持AP（高可用）和CP（强一致）两种模式，对应ephemeral为true或false。

- AP模式（临时实例，默认）：使用自研的Distro协议。这是一个异步最终一致性协议。每个Nacos Server节点负责一部分服务数据，是这些数据的“责任节点”。写请求会被路由到责任节点，由该节点异步地将数据同步给其他节点。该模式保证高可用和分区容错，适合服务发现场景。
- CP模式（持久化实例）：使用Raft协议（基于JRaft实现）。当实例的ephemeral为false时，其创建、删除等操作会作为一条日志，通过Raft共识算法确保在集群多数节点上达成一致后才返回成功，保证了数据的强一致性，适合配置管理等场景。
相关逻辑在ConsistencyDelegate一致性委托接口及其实现PersistentConsistencyService（CP）和EphemeralConsistencyService（AP）中。

五、与设计思想

通过对Nacos服务注册与发现源码的剖析，我们可以看到其核心设计思想：

1. 分层与模块化：清晰的Controller-Service-Manager模型，职责分离。
2. 数据模型抽象：Service-Cluster-Instance三级模型灵活支撑了复杂的服务治理需求。
3. 高效的内存设计：核心注册表基于内存，保证了高并发读写的性能。
4. 可扩展的一致性：通过一致性委托接口，优雅地支持了AP和CP两种模式，适应不同场景。
5. 实时性权衡：长轮询机制在服务端推送（实时性高、连接压力大）和客户端纯拉取（延迟高、服务器压力小）之间取得了良好平衡，后续gRPC升级提供了更优解。

理解这些源码细节，不仅能帮助我们在使用Nacos时更好地定位问题、优化配置，也能为我们设计自己的分布式系统提供宝贵的借鉴。