目录

一、前言

二、服务Service和服务实例Instance

1、定义服务

2、服务元数据

3、定义实例

4、实例元数据

5、持久化属性

三、集群

1、定义集群

四、生命周期

1、服务的⽣命周期

2、实例的⽣命周期

3、集群的⽣命周期

4、元数据的⽣命周期

五、小结

💖 Spring家族及微服务系列文章

---

一、前言

    在上文 Nacos 注册中心的设计原理中简要介绍了服务发现的背景、业界对动态服务发现的解决方案及 Nacos 针对动态服务发现的总体设计思路让读者对服务发现及 Nacos 的注册中心有了⼀个框架性的了解。从本文开始本书将展开介绍 Nacos 注册中心中的各种技术概念、细节及设计帮助读者更好地理解 Nacos 注册中心。
    本节将较为详尽的展开介绍 Nacos 注册中心中的服务数据模型内容。主要会为读者详细介绍Nacos2.0 版本中注册中心所涉及到的数据模型、各个数据模型的含义及各个数据模型的生命周期并介绍 Nacos2.0 版本和 Nacos1.0 版本中服务数据模型的差异点。

二、服务Service和服务实例Instance

     在生活中我们被各式各样的服务包围例如如果生病了会到医院找医生诊断、如果网购遇到了问题会找客服咨询医生提供了诊断服务客服提供了咨询服务这位为你诊断病症的医生和为你解答问题的客服都是该服务的具体提供者。

    在程序世界中也存在类似的情形例如在使用支付宝进行付款的时候或许会要求你先登陆验证你的身份信息最后才能进行支付。而这其中可能涉及到了支付服务登陆服务信息验证服务等等。而这些都离不开服务的发现。

    在服务发现领域中服务指的是由应用程序提供的⼀个或⼀组软件功能的⼀种抽象概念例如上述例子的登陆或支付。它和应用有所不同应用的范围更广和服务属于包含关系即⼀个应用可能会提供多个服务。为了能够更细粒度地区分和控制服务Nacos 选择服务作为注册中心的最基本概念。

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

1、定义服务

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

• 命名空间NamespaceNacos 数据模型中最顶层、也是包含范围最广的概念用于在类似环境或租户等需要强制隔离的场景中定义。Nacos 的服务也需要使用命名空间来进行隔离。
• 分组GroupNacos 数据模型中次于命名空间的⼀种隔离概念区别于命名空间的强制隔离属性分组属于⼀个弱隔离概念主要用于逻辑区分⼀些服务使用场景或不同应用的同名服务最常用的情况主要是同⼀个服务的测试分组和生产分组、或者将应用名作为分组以防止不同应用提供的服务重名。
• 服务名Name该服务实际的名字⼀般用于描述该服务提供了某种功能或能力。

                图 1 定义服务 

    之所以 Nacos 将服务的定义拆分为命名空间、分组和服务名除了方便隔离使用场景外还有方便用户发现唯⼀服务的优点。在注册中心的实际使用场景上同个公司的不同开发者可能会开发出类似作用的服务如果仅仅使用服务名来做服务的定义和表示容易在⼀些通用服务上出现冲突比如登陆服务等。

    通常推荐使用由运行环境作为命名空间、应用名作为分组和服务功能作为服务名的组合来确保该服务的天然唯⼀性当然使用者可以忽略命名空间和分组仅使用服务名作为服务唯⼀标示这就需要使用者在定义服务名时额外增加自己的规则来确保在使用中能够唯⼀定位到该服务而不会发现到错误的服务上。
 

2、服务元数据

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

• 健康保护阈值ProtectThreshold为了防止因过多实例故障导致所有流量全部流入剩余实例继而造成流量压力将剩余实例被压垮形成的雪崩效应。应将健康保护阈值定义为⼀个 0 到 1之间的浮点数。当域名健康实例数占总服务实例数的比例小于该值时无论实例是否健康都会将这个实例返回给客户端。这样做虽然损失了⼀部分流量但是保证了集群中剩余健康实例能正常工作。
• 实例选择器Selector用于在获取服务下的实例列表时过滤和筛选实例。该选择器也被称为路由器目前 Nacos 支持通过将实例的部分信息存储在外部元数据管理 CMDB 中并在发现服务时使用 CMDB 中存储的元数据标签来进行筛选的能力。
• 拓展数据(extendData)用于用户在注册实例时自定义扩展的元数据内容形式为 K-V 。可以在服务中拓展服务的元数据信息方便用户实现自己的自定义逻辑。

        图 2 服务元数据 

3、定义实例

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

• 网络 IP 地址该实例的 IP 地址在 Nacos2.0 版本后支持设置为域名。
• 网络端口该实例的端口信息。
• 健康状态Healthy用于表示该实例是否为健康状态会在 Nacos 中通过健康检查的手段进行维护具体内容将在 Nacos 健康检查机制章节中详细说明读者目前只需要该内容的含义即可。
• 集群Cluster用于标示该实例归属于哪个逻辑集群有关于集群的相关内容将在后文详细说明。
• 拓展数据(extendData)用于用户自定义扩展的元数据内容形式为 K-V。可以在实例中拓展该实例的元数据信息方便用户实现自己的自定义逻辑和标示该实例。

4、实例元数据

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

• 权重Weight实例级别的配置。权重为浮点数范围为 0-10000。权重越大分配给该实例的流量越大。
• 上线状态Enabled标记该实例是否接受流量优先级大于权重和健康状态。用于运维人员在不变动实例本身的情况下快速地手动将某个实例从服务中移除。
• 拓展数据(extendData)不同于实例定义中的拓展数据这个拓展数据是给予运维人员在不变动实例本身的情况下快速地修改和新增实例的扩展数据从而达到运维实例的作用。

              图 3 实例

    在 Nacos2.0 版本中实例数据被拆分为实例定义和实例元数据主要是因为这两类数据其实是同⼀个实例的两种不同场景开发运行场景及运维场景。对于上下线及权重这种属性⼀般认为在实例已经在运行时需要运维人员手动修改和维护的数据而 IP端口和集群等信息⼀般情况下在实例启动并注册后则不会在进行变更。将这两部分数据合并后就能够得到实例的完整信息也是 Nacos1.0 版本中的实例数据结构。 

    同时在 Nacos2.0 版本中定义实例的这部分数据会受到持久化属性的的影响而实例元数据部分则⼀定会进行持久化这是因为运维操作需要保证操作的原子性不能够因为外部环境的影响而导致操作被重置例如在 Nacos1.0 版本中运维人员因为实例所处的网络存在问题操作⼀个实例下线以此摘除流量但是同样因为网络问题该实例与 Nacos 的通信也收到影响导致实例注销后重新注册这可能导致上线状态被重新注册而覆盖失去了运维人员操作的优先级。

    当然这部分元数据也不应该无限制的存储下去如果实例确实已经移除元数据也应该移除为此在 Nacos 2.0 版本后通过该接口更新的元数据会在对应实例删除后依旧存在⼀段时间如果在此期间实例重新注册该元数据依旧生效可以通过 nacos.naming.clean.expired-metadata.expired-time 及 nacos.naming.clean.expired-metadata.interval 对记忆时间进行修改。

5、持久化属性

    如 Nacos 注册中心的设计原理文中所述Nacos 提供两种类型的服务持久化服务和非持久化服务分别给类 DNS 的基础的服务组件场景和上层实际业务服务场景使用。为了标示该服务是哪种类型的服务需要在创建服务时选择服务的持久化属性。考虑到目前大多数使用动态服务发现的场景为非持久化服务的类型如 Spring CloudDubboService Mesh 等Nacos 将缺醒值设置为了非持久化服务。

    在 Nacos2.0 版本后持久化属性的定义被抽象到服务中⼀个服务只能被定义成持久化服务或非持久化服务⼀旦定义完成在服务生命周期结束之前无法更改其持久化属性。

    持久化属性将会影响服务及实例的数据是否会被 Nacos 进行持久化存储设置为持久化之后实例将不会再被自动移除需要使用者手动移除实例。

三、集群

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

1、定义集群

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

• 健康检查类型HealthCheckType使用哪种类型的健康检查方式目前支持TCPHTTPMySQL设置为 NONE 可以关闭健康检查。
• 健康检查端口HealthCheckPort设置用于健康检查的端口。
• 是否使用实例端口进行健康检查UseInstancePort如果使用实例端口进行健康检查将会使用实例定义中的网络端口进行健康检查而不再使用上述设置的健康检查端口进行。
• 拓展数据(extendData)用于用户自定义扩展的元数据内容形式为 K-V 。可以自定义扩展该集群的元数据信息方便用户实现自己的自定义逻辑和标示该集群。

        图 4 服务&集群&实例 

四、生命周期

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

1、服务的⽣命周期

    服务的生命周期相对比较简单是从用户向注册中心发起服务注册的请求开始。在 Nacos 中发起服务注册有两种方式⼀种是直接创建服务⼀种是注册实例时自动创建服务前者可以让发起者在创建时期就指定⼀部分服务的元数据信息而后者只会使用默认的元数据创建服务。

    在生命周期期间用户可以向服务中新增删除服务实例同时也能够对服务的元数据进行修改。

    当用户主动发起删除服务的请求或⼀定时间内服务下没有实例无论健康与否后服务才结束其生命周期等待下⼀次的创建。

2、实例的⽣命周期

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

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

    而非持久化的实例会根据版本的不同采用不同的方式维持健康状态如果是 Nacos1.0 的版本会通过定时的心跳请求来进行续约当超过⼀定时间内没有心跳进行续约时该非持久化实例则终止生命周期如果是 Nacos2.0 的版本会通过 gRPC 的长连接来维持状态当连接发生中断时该非持久化实例则终止生命周期。当然非持久化实例也可以通过注销实例的请求主动终止其生命周期但是由于长连接和心跳续约的存在可能导致前⼀个实例数据的生命周期刚被终止移除立刻又因为心跳和长连接的补偿请求再次开启实例的生命周期给人⼀种注销失败的假象。

3、集群的⽣命周期

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

    集群的生命周期开始与该集群第⼀个实例的生命周期同时开始因为⼀个实例必定归属于⼀个集群哪怕是默认的集群因此当第⼀个实例的生命周期开始时也就是集群生命周期的开始

    当⼀个集群下不存在实例时集群的生命周期也不会立刻结束而是会等到这个服务的生命周期结束时才会⼀起结束生命周期。

4、元数据的⽣命周期

    由于元数据的其对应的数据模型是紧密关联的所以元数据的生命周期基本和对应的数据模型保持⼀致。但是也如前文所说元数据通常为运维人员的主动操作的数据会被 Nacos 进行⼀段时间内的记忆因此元数据的生命周期的终止相比对应的数据要滞后若这滞后期间内对应的数据又重新开始生命周期则该元数据的生命周期将被立刻重置不再终止。

        图 5 各数据的生命周期图 

五、小结

    本文主要介绍了 Nacos 注册中心中的服务数据模型及其生命周期。作为 Nacos 注册中心的内容核 心正确理解服务、实例及集群中的数据内容以及他们之间的关系知晓各个数据的生命周期 才能够理解 Nacos 注册中心的工作原理和工作流程。在本文中多次提到了 生命周期的健康状态 及 维护 健康状态的 健康检查机制 这就是接下来的章节需要详细介绍的内容。