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中存储的元数据标签来进行筛选的能力。

三.拓展数据extendD