Nacos简介—4.Nacos架构和原理三

大纲

1.Nacos的定位和优势

2.Nacos的整体架构

3.Nacos的配置模型

4.Nacos内核设计之一致性协议

5.Nacos内核设计之自研Distro协议

6.Nacos内核设计之通信通道

7.Nacos内核设计之寻址机制

8.服务注册发现模块的注册中心的设计原理

9.服务注册发现模块的注册中心的服务数据模型

10.服务注册发现模块的健康检查机制

11.配置管理模块的配置一致性模型

12.Zookeeper、Eureka和Nacos的对比总结

9.服务注册发现模块的注册中心的服务数据模型

(1)服务、服务实例和集群

(2)服务的定义

(3)服务的元数据

(4)实例的定义

(5)实例的元数据

(6)持久化属性

(7)集群的定义

(8)服务的生命周期

(9)实例的生命周期

(10)集群的生命周期

(11)元数据的生命周期

(1)服务、服务实例和集群

服务Service指的是由应用程序提供的⼀个或⼀组软件功能的⼀种抽象概念。它和应用有所不同，应用的范围更广，和服务属于包含关系，即⼀个应用可能会提供多个服务。而Nacos则选择了服务作为注册中心的最基本概念。

服务实例Instance(以下简称实例)是某个服务的具体提供能力的节点。⼀个实例仅从属于⼀个服务，而⼀个服务可以包含⼀个或多个实例。在许多场景下，实例又被称为服务提供者(Provider)，而使用该服务的实例被称为服务消费者(Consumer)。

集群Cluster是Nacos中⼀组服务实例的⼀个逻辑抽象的概念，它介于服务和实例之间，是⼀部分服务属性的下沉和实例属性的抽象。

(2)服务的定义

在Nacos中，服务的定义包括以下几个内容：

一.命名空间Namespace

命名空间是Nacos数据模型中最顶层、也是包含范围最广的概念，用于在类似环境或租户等需要强制隔离的场景中定义。Nacos的服务也需要使用命名空间来进行隔离。

二.分组Group

分组是Nacos数据模型中次于命名空间的⼀种隔离概念。区别于命名空间的强制隔离属性，分组属于⼀个弱隔离概念，主要用于逻辑区分⼀些服务使用场景或不同应用的同名服务。最常用的情况主要是同⼀个服务的测试分组和生产分组，或者将应用名作为分组以防止不同应用提供的服务重名。

三.服务名Name

服务名也就是服务实际的名字，⼀般用于描述该服务提供了某种功能或能力。

Nacos之所以将服务的定义拆分为命名空间、分组和服务名，除了方便隔离使用场景外，还有方便用户发现唯⼀服务的优点。

在注册中心的实际使用场景上，同个公司的不同开发者可能会开发出类似作用的服务，如果仅仅使用服务名来做服务的定义和表示，容易在⼀些通用服务上出现冲突，比如登陆服务等。

通常推荐使用如下方式来确保服务的天然唯⼀性：由运行环境作为命名空间、由应用名作为分组、由服务功能作为服务名。

当然使用者可以忽略命名空间和分组，仅使用服务名作为服务唯⼀标示。这就需要使用者在定义服务名时额外增加自己的规则，来确保在使用中能够唯⼀定位到该服务而不会发现到错误的服务上。

(3)服务的元数据

服务定义只是为服务设置⼀些基本信息，用于描述服务及快速找到服务。服务的元数据则是进⼀步定义了Nacos中服务的细节属性和描述信息，主要包含：

一.健康保护阈值ProtectThreshold

为了防止因过多实例故障，导致所有流量全部流入剩余实例，继而造成流量压力将剩余实例压垮导致的雪崩效应，我们应该将健康保护阈值定义为⼀个0到1之间的浮点数。

当健康实例数占总服务实例数的比例小于该值时，无论实例是否健康，都会将这个实例返回给客户端。这样做虽然损失了⼀部分流量，但保证了集群中剩余健康实例能正常工作。

二.实例选择器Selector

用于在获取服务下的实例列表时，过滤和筛选实例。该选择器也被称为路由器，或者负载均衡器的统一抽象。目前Nacos支持通过将实例的部分信息存储在外部元数据管理CMDB中，并在发现服务时使用CMDB中存储的元数据标签来进行筛选的能力。

三.拓展数据extendData

用于用户在注册实例时自定义扩展的元数据内容，形式为K-V。可以在服务中拓展服务的元数据信息，方便用户实现自己的自定义逻辑。

(4)实例的定义

由于服务实例是具体提供服务的节点，因此Nacos在设计实例的定义时，主要需要存储服务实例的⼀些网络相关的基础信息，主要包含以下内容：

一.网络IP地址

服务实例的IP地址，在Nacos2.0版本之后支持设置为域名。

二.网络端口

该实例的端口信息。

三.健康状态Healthy

用于表示服务实例是否为健康状态，会通过健康检查的手段进行维护。

四.集群Cluster

用于标示服务实例归属于哪个逻辑集群。

五.拓展数据extendData

用于用户自定义扩展的元数据内容，形式为K-V。可以在实例中拓展该实例的元数据信息，方便用户实现自己的自定义逻辑和标示该实例。

(5)实例的元数据

和服务元数据不同，实例的元数据主要作用于实例运维相关的数据信息，主要包含：

一.权重Weight

实例级别的配置，权重为浮点数，范围为0-10000。权重越大，分配给该实例的流量越大。

二.上线状态Enabled

标记该实例是否接受流量，优先级大于权重和健康状态。运维人员在不变动实例本身的情况下，可快速手动将某实例从服务中移除。

三.拓展数据extendData

不同于实例定义中的拓展数据。这个拓展数据是给予运维人员在不变动实例本身的情况下，快速地修改和新增实例的扩展数据，从而达到运维实例的作用。

在Nacos 2.0版本中，实例数据被拆分为实例定义和实例元数据。主要是因为这两类数据其实是同⼀个实例的两种不同场景：开发运行场景及运维场景。

对于上下线和权重这种实例元数据信息，⼀般认为在实例已经在运行时，需要运维人员手动修改和维护的数据。对于IP、端口和集群等这种实例定义信息，⼀般情况下在实例启动并注册后，则不会在进行变更。

将实例定义和实例元数据两部分数据合并后，就能得到实例完整信息，这也是Nacos 1.0版本中的实例数据结构。

(6)持久化属性

Nacos提供两种类型的服务：持久化服务和非持久化服务，分别给类DNS的基础服务组件场景和上层实际业务服务场景使用。

为了标示该服务是哪种类型，需要在创建服务时选择服务的持久化属性。考虑目前大多数使用动态服务发现的场景为非持久化服务的类型，比如Spring Cloud、Dubbo、Service Mesh等，默认为非持久化服务。

(7)集群的定义

在Nacos中，集群中主要保存了有关健康检查的⼀些信息和数据：

一.健康检查类型HealthCheckType

使用哪种类型的健康检查方式，目前支持：TCP、HTTP、MySQL，设置为NONE可以关闭健康检查。

二.健康检查端口HealthCheckPort

设置用于健康检查的端口。

三.是否使用实例端口进行健康检查UseInstancePort

如果使用实例端口进行健康检查，将会使用实例定义中的网络端口进行健康检查，而不再使用上述设置的健康检查端口进行。

四.拓展数据extendData

用于用户自定义扩展的元数据内容，形式为K-V。可自定义扩展该集群的元数据信息，方便用户实现自定义逻辑和表示集群。

(8)服务的生命周期

在注册中心中，实例数据都和服务实例的状态绑定，因此服务实例的状态直接决定了注册中心中实例数据的生命周期。而服务作为实例的聚合抽象，生命周期也会由服务实例的状态来决定。

服务的生命周期，开始于用户向注册中心发起服务注册的请求。

在Nacos中，发起服务注册有两种方式。⼀种是直接创建服务，⼀种是注册实例时自动创建服务。前者可以让发起者在创建时期就制定⼀部分服务的元数据信息，而后者只会使用默认的元数据创建服务。

在服务的生命周期期间，用户可以新增、删除服务实例，同时也能够对服务元数据进行修改。当用户主动发起删除服务的请求或⼀定时间内服务下没有实例后，服务才结束其生命周期，等待下⼀次创建。

(9)实例的生命周期

实例的生命周期，开始于注册实例的请求。但根据不同的持久化属性，实例后续的生命周期会有不同。

一.持久化的实例

会通过健康检查维护健康状态，但不会自动终止该实例的生命周期。在生命周期结束前，持久化实例可被修改数据，甚至可修改其健康状态。终止持久化实例生命周期的唯⼀方式就是注销实例的请求。

二.非持久化的实例

会根据版本的不同，采用不同的方式维持健康状态。如果是Nacos 1.0版本，会通过定时的心跳请求来进行续约。当超过⼀定时间没有心跳进行续约时，该非持久化实例则终止生命周期。如果是Nacos 2.0的版本，会通过gRPC的长连接来维持状态。当连接发生中断时，该非持久化实例则终止生命周期。

非持久化实例可通过主动注销实例的请求，主动终其生命周期。但由于长连接和心跳续约的存在，可能导致实例的生命周期刚被终止移除，马上又因为心跳和长连接的补偿请求，再次开启实例的生命周期，给人⼀种注销失败的假象。

(10)集群的生命周期

由于集群作为服务和实例的⼀个中间层，因此集群的生命周期与实例和服务的生命周期均有关。

集群的生命周期开始与该集群第⼀个实例的生命周期同时开始，因为⼀个实例必定归属于⼀个集群。因此当第⼀个实例的生命周期开始时，就是集群生命周期的开始。当⼀个集群下不存在实例时，集群的生命周期也不会立刻结束，而是会等到这个服务的生命周期结束时，才会⼀起结束生命周期。

(11)元数据的生命周期

由于元数据与其对应的数据模型紧密关联，所以元数据的生命周期基本和对应的数据模型保持⼀致。

但元数据会经常被运维人员主动操作，会被Nacos进行⼀段时间内的记忆，因此元数据的生命周期的终止相比对应的数据要滞后。若这滞后期间内，对应的数据又重新开始生命周期，则该元数据的生命周期将被立刻重置，不再终止。

10.服务注册发现模块的健康检查机制

(1)注册中心的健康检查机制

(2)Nacos健康检查机制

(3)Nacos临时实例的健康检查机制

(4)Nacos持久化实例的健康检查机制

(5)Nacos集群模式下的健康检查机制

(1)注册中心的健康检查机制

要知道⼀个服务是否健康：方式一是客户端主动上报，告诉服务端自己的健康状态。如果在⼀段时间没有上报，那么我们就认为服务已经不健康。方式二是服务端主动探测，检查客户端是否还能被探测。

如果所有服务都需要注册中心去主动探测，由于服务的数量会远远大于注册中心的数量，那么注册中心的任务量将很巨大，所以最好都采用服务主动上报的方式进行健康检查。如果服务本身没法主动进行健康上报，那么这时就可使用注册中心主动检查健康状态的方式。

想象这么⼀个场景，所在的地区突然发生地质灾害，A被掩盖在废墟下面。搜救队必须要知道A在废墟里，才能对A进行施救，那么有什么方法可以让救援队知道你在废墟下面？

第⼀种，A在废墟里面大喊，让搜救队知道你的位置和健康状态。第二种，搜救队使用了他们的专业检查设备，探测到A正埋在废墟下面。这两种检查方式可以类比到Nacos对于服务的探测。如果A在废墟中大声呼叫救援队并且提供A的位置和健康信息，那么相比于搜救队用探测设备挨着废墟探测会使探测队的工作量减轻很多，那么搜救队就可以专注于尽快将A救出。如果A在废墟之下因为身体状况无法呼救，那么搜救队就会放弃搜救吗？当然不是，搜救队肯定也会对废墟进行全面探测将A救出。

当前主流注册中心的健康检查机制主要都采用了TTL(Time To Live)机制。即客户端在⼀定时间内没向注册中心发送心跳，那么注册中心就会认为此服务不健康，进而触发后续的剔除逻辑。对于主动探测的方式，那么根据不同的场景，需要采用的方式可能会有不同。

(2)Nacos健康检查机制

既然以上两种健康检查机制都有应用的场景，且适用场景不⼀致，那么Nacos对于健康检查的机制又是如何抉择的？

在介绍Nacos的健康检查机制之前，先总结⼀下Nacos服务的特点。Nacos提供了临时实例和永久实例两种服务类型，供用户注册实例时选择。

临时实例只是临时存在于注册中心之中，会与注册中心保持心跳，会在服务下线或不可用时被注册中心剔除。注册中心会在⼀段时间没收到来自客户端的心跳后，将临时实例设置为不健康，然后在⼀段时间后进行剔除。

永久实例在被删除前会永久的存在于注册中心，且有可能并不知道注册中心存在，不会主动向注册中心上报心跳，那么这时就需要注册中心主动进行探活。

Nacos中健康检查的整体交互如下图示：

(3)Nacos临时实例的健康检查机制

用户可以通过两种方式进行临时实例的注册。

方式一：通过Nacos的OpenAPI进行服务注册

方式二：通过Nacos提供的SDK进行服务注册

OpenAPI的注册方式是用户根据自身需求调用HTTP接口对服务进行注册，然后通过HTTP接口发送心跳到注册中心。在注册服务的同时会注册⼀个全局的客户端心跳检测任务。如果⼀段时间没有收到来自客户端的心跳，该任务会将其标记为不健康。如果在间隔的时间内还未收到心跳，那么该任务会将其剔除。

SDK的注册方式是通过RPC与注册中心保持连接。客户端会定时通过RPC连接向注册中心发送心跳，来保持连接的存活。如果客户端和注册中心的连接断开，那么注册中心会主动剔除该客户端所注册的服务，达到下线的效果。同时Nacos注册中心会在启动时，注册⼀个过期客户端清除的定时任务，用于删除那些健康状态超过⼀段时间的客户端。

从上面的特点可以发现，对于不同类型的使用方式：Nacos健康检查的本质都是相同的，都是由客户端向注册中心发送心跳，注册中心会在连接断开或是心跳过期后将不健康的实例移除。

(4)Nacos持久化实例的健康检查机制

对于持久化实例的的健康检查，Nacos采用的是注册中心探测机制。注册中心会在初始化持久化实例时，启动一个探活的定时任务。

Nacos内置提供了三种探测协议，即HTTP、TCP、MySQL。⼀般而言，HTTP和TCP已经可以涵盖绝大多数的健康检查场景。

MySQL主要用于特殊的业务场景。例如数据库的主备需要通过服务名对外提供访问，需要确定当前访问数据库是否为主库时，那么此时的健康检查接口，就是⼀个检查数据库是否为主库的MySQL命令。

由于持久化的服务实例在被客户端服务主动删除前会⼀直存在，所以探活的定时任务会不断探测服务的健康状态，并且将无法探测成功的实例标记为不健康。

但有时会有这样的场景，有些服务不希望去校验其健康状态。于是Nacos也提供了对应的白名单配置，可以将服务配置到该白名单。那么Nacos会放弃对其进行健康检查，实例的健康状态由用户传入来决定。

(5)Nacos集群模式下的健康检查机制

⼀个完整的注册中心，应该具备高可用的特性。即注册中心是可以进行集群部署，然后作为⼀个整体对外提供服务。

集群部署时，客户端只会和其中⼀个注册中心服务保持连接和请求，但是客户端的服务信息需要注册到所有的注册中心服务节点上，这样其他客户端就可以从任意⼀个注册中心服务获取到所有的服务列表。

一.注册中心集群节点如何对不是和自己保持心跳连接的服务进行健康检查

在集群模式下，⼀个服务只会被集群中的某个注册中心节点所负责。但是该服务的实例信息也会以副本的形式同步到其他的注册中心节点中，这样服务的订阅者在查询服务列表时，就可以始终获取到全部的服务列表。

所以临时服务实例只会对负责自己的某个注册中心节点发送心跳信息，而一个注册中心节点只会对其负责的持久化服务实例进行健康探测，在获取到健康状态后再将健康信息同步到集群中的其他注册中心节点。

在Nacos中，从注册方式维度可以将服务的注册分为两大类。⼀是SDK方式，通过RPC连接进行注册。二是OpenAPI方式，通过IP + 端口进行注册。

二.服务实例如何寻找负责对自己进行健康检查的注册中心节点

一个服务实例只要和注册中心集群中的任意⼀个节点建立联系，那么就由这个注册中心节点负责对这个服务实例进行健康检查。

每个注册中心节点都会在启动时启动⼀个全局的同步任务，用于将其负责的所有服务实例信息同步到集群中的其他注册中心节点上。

注册中心节点对于不是由其负责的服务实例信息，会维护一个续约时间。当它收到其他注册中心节点同步过来的服务信息时，会更新其续约时间。

如果注册中心节点发现不是由自己负责的服务信息，其续约时间没有更新，则会认为此服务已不健康，从而实现对不是自己负责的服务的健康检查。

11.配置管理模块的配置一致性模型

(1)配置一致性模型

(2)Server间的数据一致性

(3)Client与Server的数据⼀致性

(1)配置一致性模型

Nacos配置管理⼀致性协议分为两个大部分：第⼀部分是Server间的⼀致性协议，第二部分是Client与Server的⼀致性协议。

配置作为分布式系统中非强⼀致数据，在出现脑裂时可用性高于⼀致性，因此阿里配置中心是采用AP⼀致性协议。

(2)Server间的数据一致性

一.有DB模式(读写分离架构)

⼀致性的核心是Server与DB保持数据⼀致性，从而保证Server数据⼀致。Server之间都是对等的，任何⼀个Server在处理配置数据的写入请求时，会先将数据持久化到DB，持久化成功后该Server再异步通知其他Server到DB中拉取最新的配置数据。

二.无DB模式

Server间采用Raft协议保证数据⼀致性，行业大部分产品采用此模式。Nacos提供此模式，是方便用户本机运行，降低对存储依赖。

(3)Client与Server的数据⼀致性

Client与Server的数据⼀致性是通过MD5值是否⼀致来保证的。如果发现不⼀致，Client就从Server拉取最新的数据。

一.Nacos 1.X

Nacos 1.X采用HTTP 1.1短连接模拟长连接。每30s发送⼀个心跳给Server，判断配置的MD5值是否和Server保持⼀致。如果⼀致就保持连接，如果有不⼀致配置，就把不⼀致的配置返回，然后Client就可以获取到最新的配置值。

二.Nacos 2.X

Nacos 2.x相比Nacos 1.x的30s⼀次的长轮询，升级成长连接模式。配置变更会启动建立长连接，配置变更后服务端推送变更配置列表。然后Clinet拉取配置更新，因此通信效率大幅提升。

12.Zookeeper、Eureka和Nacos的对比总结

(1)数据模型方面

(2)一致性协议方面

(3)容灾能力方面

(4)健康检查方面

(5)性能容量方面

(6)易用性方面

(7)集群扩展性方面

(8)用户扩展性方面

(1)数据模型方面

Zookeeper没有针对服务发现设计数据模型。

(2)一致性协议方面

如果使用定时心跳补偿数据，那么Paxos协议的单点瓶颈就会不太划算。这也是Eureka为什么不采用Paxos协议而采用自定义的Renew机制的原因。

而Dubbo服务往Zookeeper注册的就是临时节点，Dubbo服务要定时发送心跳到Zookeeper去进行节点的续约。

(3)容灾能力方面

Zookeeper虽然使用ZAB协议保证了数据的强⼀致，但是它缺乏机房容灾能力，无法适应⼀些大型场景。因为Zookeeper的单点写模式会存在断网恢复后的数据对账问题，所以Zookeeper比较难做到双机房容灾。

Eureka因为采用的是纯临时实例的注册模式 + 心跳补偿，所以天然支持多机房容灾。

Zookeeper和Eureka都没有给出官方的多数据中心方案，而Nacos则提供了采用Nacos-Sync组件来做数据中心之间的数据同步，所以Nacos具有机房容灾的能力。

(4)健康检查方面

Zookeeper和Eureka都实现了⼀种TTL机制，即如果客户端在⼀定时间内没有向注册中心发送心跳，则会摘除该客户端。Nacos也支持这种TTL机制，支持临时服务实例使用心跳上报方式维持活性。如果Nacos服务端在15秒没收到心跳，则会将该临时实例设置为不健康。如果Nacos服务端在30秒没收到心跳，则会将该临时实例摘除。

(5)性能容量方面

Zookeeper的写性能可达上万TPS，这得益于它精巧的设计。Zookeeper的写逻辑就是进行KV写入的，内部没有聚合。Zookeeper舍弃了服务发现的基本功能如健康检查。但Paxos协议本身就限制了Zookeeper集群的规模，3或5个Zookeeper节点是不能应对大规模的服务订阅和查询。

Zookeeper的容量，从存储实例数来说，可以达到百万级别。当大量的实例上下线时，Zookeeper在推送机制上的缺陷，会导致客户端的资源占用上升，从而影响客户端的性能。

Eureka在服务实例规模在5000左右时，会出现服务不可用，并发线程数过高会造成Eureka崩溃。

Nacos可以支撑的服务实例规模约为100万，服务规模可达10万+。

(6)易用性方面

Zookeeper的易用性比较差，客户端使用比较复杂，而且Zookeeper没有针对服务发现的模型设计以及相应的API封装。

Eureka和Nacos基于Spring Cloud体系的Starter，可帮助用户以非常低的成本、无感知地做到服务注册与发现，以及都提供官方控制台来查询服务注册情况。

(7)集群扩展性方面

Zookeeper使用的ZAB协议，由于是单点写，集群扩展性不具备优势。

Eureka理论上可以扩展到很大规模，但因为都是点对点的数据同步，Eureka集群在扩容后，性能上有很大问题。

(8)用户扩展性方面

Zookeeper和Eureka目前Server端都不支持用户扩展，Nacos已经通过SPI机制开放了对第三方CMDB的扩展支持。