mjunz的博客

本文详细分析了gRPC客户端和服务端的初始化过程、心跳机制、连接处理及请求映射机制。首先，gRPC客户端通过初始化与服务器建立连接，并通过心跳机制进行健康检查。服务端启动时，通过BaseGrpcServer的startServer()方法启动，并使用建造者模式创建Server对象。在处理客户端连接请求时，服务端通过connectionId与Client对象进行绑定，具体通过ConnectionManager的register()方法实现。此外，gRPC服务端通过addServices()方法将请求映射到对应

文章主要分析了gRPC客户端的初始化、心跳机制以及服务端处理连接请求的过程。首先，gRPC客户端通过NacosNamingService的registerInstance()方法进行服务实例注册，并根据实例类型选择使用gRPC或HTTP客户端代理。gRPC客户端代理的初始化包括创建RpcClient对象、启动RPC客户端连接以及注册处理服务端推送请求的Handler。其次，gRPC客户端的心跳机制通过两个线程任务实现：一个处理连接成功或断开时的通知，另一个处理重连或健康检查。健康检查通过向服务端发送Heal

文章主要分析了Nacos中的事件驱动架构及其实现机制。首先，服务端通过事件驱动的方式处理客户端的变化，如客户端注册、注销等事件，并通过Distro协议或Raft协议进行集群数据同步。文章详细介绍了如何处理ClientChangedEvent和ClientDeregisterServiceEvent事件，分别对应客户端注册和注销时的操作。接着，文章探讨了ServiceChangeEvent事件的处理，即服务变动时通知订阅者更新本地缓存。最后，文章总结了Nacos事件驱动架构的使用方法，包括自定义事件、订阅者以

本文详细介绍了服务端对服务实例进行健康检查的设计逻辑、源码实现以及服务下线时的注销处理流程。健康检查通过探活机制，定期检查客户端连接的最后活跃时间，若超过20秒则将其加入待移除集合，并通过探活请求确认客户端是否下线。若探活失败，则执行注销操作，移除连接对象并发布客户端注销事件。服务下线时，客户端通过gRPC请求通知服务端，服务端处理请求后移除实例信息并发布相关事件，同步集群节点数据并更新注册表。此外，文章还分析了Nacos事件驱动架构的源码，包括事件发布、订阅者注册及通知机制的实现。

在微服务架构中，服务变动时通知订阅的客户端以及微服务实例信息的同步是确保系统一致性和可用性的关键。当服务实例注册或注销时，服务端会发布ClientChangedEvent事件，该事件触发集群节点间的数据同步。具体流程如下： 事件发布：服务实例注册或注销时，服务端发布ClientChangedEvent事件，触发集群节点同步服务实例数据。 事件处理：DistroClientDataProcessor处理ClientChangedEvent事件，调用syncToAllServer方法，通过DistroProto

在微服务架构中，服务变动和订阅通知是确保服务发现和通信的关键机制。本文详细描述了Nacos服务端如何处理客户端注册和订阅事件，并通过事件发布机制通知相关客户端。当客户端注册或注销服务实例时，Nacos服务端会发布ClientRegisterServiceEvent或ClientDeregisterServiceEvent事件，并更新注册表。随后，服务端会发布ServiceChangedEvent事件，通知所有订阅该服务的客户端。对于服务订阅事件，Nacos服务端会发布ClientSubscribeServi

Nacos 2.x版本在服务注册与发现机制上进行了显著优化，客户端通过gRPC发起服务注册，服务端则处理注册请求并管理服务实例。客户端进行服务发现时，借助Ribbon实现负载均衡，通过NacosServerList获取服务实例列表。服务端处理订阅请求时，首先根据Service对象读取缓存中的服务实例，然后添加订阅者并发布相关事件。Nacos客户端通过NacosNamingService进行服务发现，若本地缓存无数据，则通过gRPC请求服务端获取实例信息。服务端通过ServiceStorage和ClientS

Nacos 2.x版本在客户端和服务端的交互方式、注册表结构以及事件驱动机制上进行了显著优化。首先，客户端和服务端的通信从HTTP升级为gRPC，提升了性能和效率。其次，注册表结构从双重Map简化为轻量级Map，减少了并发冲突的可能性。此外，Nacos 2.x大量采用事件驱动机制，如服务注册、销毁和变更等操作均通过事件通知中心处理，增强了系统的灵活性和可扩展性。客户端在启动时会自动通过gRPC发起服务注册，服务端则通过多个Map和事件处理机制来管理服务实例的注册和订阅。这些改进使得Nacos 2.x在微服务

在异步任务AsyncTask的run()方法中，会一直从queue中获取通知任务，以便将配置数据同步到对应的集群节点。当集群节点处理"/v1/cs/communication/dataChange"这个HTTP请求时，会调用CommunicationController的notifyConfigInfo()方法，接着调用DumpService的dump()方法将请求包装成DumpTask同步数据任务，然后调用TaskManager的addTask()方法将DumpTask同步数据任务放入map。

但要注意共享配置文件里的配置不要和自身应用配置文件里的配置重复，因为自身应用配置文件比共享配置文件的优先级高。在调用PropertySourceLocator实现类的locateCollection()方法时，会先调用PropertySourceLocator扩展接口的locateCollection()方法，从而才会触发调用PropertySourceLocator实现类实现的locate()方法，比如调用NacosPropertySourceLocator的locate()方法。

Follower节点拿到Leader节点返回的Instance服务实例信息后，会继续调用RaftStore.write()、PersistentNotifier.notify()这两个方法，一个将数据持久化到本地文件、一个将数据同步到内存注册表，从而最终完成以Leader节点为准的心跳请求同步数据的流程。Follower节点拿到心跳包中的key之后，发现部分key在自身节点是不存在的，那么这时Follower节点就会根据这些key向Leader节点获取Instance的详细信息进行同步。

当Leader节点接收到一个数据写入请求时：首先会在自身的节点进行数据处理，然后马上同步给集群的其他节点，此时Leader节点的这个数据的状态是uncommit状态。假设原本的Leader节点是B，但由于B突然下线，节点A、C会重新发起投票，最终节点C成为新的Leader节点。只是节点C和节点A、B之间的数据略有差异，但不影响节点的正常使用。在心跳传输过程中，Leader节点会把最新的数据传给其他Follower节点，以保证Follower节点中的数据和Leader节点的数据是一致的。分区指的是网络分区。

如果调用ServiceManager的containService()方法时发现服务不存在，则先通过ServiceManager的createEmptyService()方法创建空的服务，然后会调用DistroProtocol的onReceive()方法注册服务实例，接着会调用DistroConsistencyServiceImpl的processData()方法进行处理，最后又会调用实例注册时的DistroConsistencyServiceImpl的onPut()方法。

而其他的集群节点，并不会去执行对该Service的心跳健康检查。当Nacos服务端也就是Service的init()方法执行完成心跳健康检查任务后，ServiceManager的init()方法会有一个定时任务，同步检查结果到其他节点。在ServiceController的serviceStatus()方法中，如果通过对比入参和注册表的ServiceChecksum后，发现服务状态发生了改变，那么就会调用ServiceManager.addUpdatedServiceToQueue()方法。

Nacos服务端处理服务下线的入口是InstanceController的deregister()方法，然后会调用ServiceManager的removeInstance()方法移除注册表里的实例，也就是调用ServiceManager的substractIpAddresses()方法。在Service的updateIPs()方法中：会先调用Cluster的updateIps()方法通过写时复制机制去修改注册表，然后调用PushService的serviceChanged()方法发布服务变动事件。

在nacos-client的NacosNamingService的selectInstances()方法中：首先会调用HostReactor的getServiceInfo()方法获取服务实例列表，然后调用HostReactor的getServiceInfo0()方法尝试从本地缓存获取，接着调用HostReactor的updateServiceNow()方法查询并更新缓存，也就是调用HostReactor的updateService()方法查询并更新缓存。：找出哪些Instance服务实例是不健康的。

在这个register()方法的最后，会调用Notifier的addTask()方法，也就是把key、action包装成Pair对象，放入到一个BlockingQueue里。在ServiceManager的addInstance()方法中：首先构建出要注册的服务实例对应的服务的key，然后使用synchronized锁住要注册的服务实例对应的服务，接着获取要注册的服务实例对应的服务的最新服务实例列表，最后执行DelegateConsistencyServiceImpl的put()方法更新服务实例列表。

调用AbstractAutoServiceRegistration的onApplicationEvent()方法时，首先会调用AbstractAutoServiceRegistration的bind()方法，然后调用AbstractAutoServiceRegistration的start()方法，接着调用AbstractAutoServiceRegistration的register()方法发起注册，也就是调用this.serviceRegistry的register()方法完成服务注册的具体工作。

Server之间都是对等的，任何⼀个Server在处理配置数据的写入请求时，会先将数据持久化到DB，持久化成功后该Server再异步通知其他Server到DB中拉取最新的配置数据。如果所有服务都需要注册中心去主动探测，由于服务的数量会远远大于注册中心的数量，那么注册中心的任务量将很巨大，所以最好都采用服务主动上报的方式进行健康检查。但由于长连接和心跳续约的存在，可能导致实例的生命周期刚被终止移除，马上又因为心跳和长连接的补偿请求，再次开启实例的生命周期，给人⼀种注销失败的假象。

后者则是⼀个事件接口，当MemberLookup需要进行成员节点信息更新时，会将当前最新的成员节点信息通知给ServerMemberManager，具体的节点管理方式，则是隐藏到具体的MemberLookup实现中。在对容量的评估时，不仅要评估现有的服务规模，也要预测未来3到5年的扩展规模。阿里的中间件在内部支撑着集团百万级别服务实例，在容量上遇到的挑战可以说不会小于任何互联网公司，这个容量不仅仅意味着整体注册的实例数，也同时包含单个服务的实例数、整体的订阅者的数目以及查询QPS等。

并且在实现具体的⼀致性协议时，采用了插件可插拔的形式，进⼀步将⼀致性协议的逻辑，从服务注册发现、配置管理模块中解耦。用于进行租户粒度的配置隔离。Nacos中的某个配置集的ID，配置集ID是划分配置的维度之⼀。服务注册发现、配置管理模块依然要在显式处理⼀致性协议的读写逻辑，以及要自己实现⼀个对接⼀致性协议的存储，这并不优雅。因此为了解决这个问题，必然要对Nacos的⼀致性协议进行抽象以及下沉，使一致性协议成为内核模块的功能，让服务注册发现模块只充当计算角色，同时为配置模块去外部数据库存储打下架构基础。

Label是Nacos抽象出的Entity属性，Label定义为一个描述Entity属性的K-V键值对，Label的key和value的取值范围一般都是预先定义好的。实体的标签的变更事件。为了保证实体事件携带的变更信息是最新的，该事件只会包含变更实体的标识以及变更事件的类型，不会包含变更标签的值。Nacos的这个实体会有很多属性，比如IP的机房信息，服务的版本信息等。Nacos约定CMDB的抽象调用接口，然后由各企业添加自己的CMDB插件，无需任何代码上的重新构建，即可在运行状态下对接上企业的CMDB。

某个节点宕机后，该节点的数据不会全部不可用，可能会丢失部分数据。对Nacos集群节点进行随机读的时候，由于每个节点只负责处理部分数据，所以可能出现读取不到刚向集群注册的数据的随机读问题。Nacos集群中的每个节点，虽然通过写路由只写入由自己处理的数据，但同时也会定期执行同步任务，把本节点负责的数据同步到其他节点，最终每个节点都会存储全量的集群数据。新加入Nacos集群的节点会轮询Nacos集群的所有节点，然后发送请求出去拉取各节点的数据，所以Nacos集群的每个节点上都会有所有已注册的服务实例的数据。

保护阈值，可以设置为0~1之间的比例。如果健康的服务实例比例太低，则把不健康的服务实例也返回服务调用方。此时会有很多请求交给不健康的服务实例来处理，会导致请求失败，但可以避免健康的服务实例出现因为请求流量过大而被压垮的问题。一种是临时的服务实例，一种是持久化的服务实例。临时的服务实例默认会每隔5s上报一次心跳给Nacos，Nacos如果15s没收到心跳就标记该服务实例为不健康，Nacos如果超过30s没收到心跳就摘除这个服务实例。假设有10个服务实例，每个服务实例的极限QPS是700，当前QPS是500。