Nacos注册中心-创新互联

目录

1. 注册中心是什么

2. Nacos 的服务结构模型

3. 服务节点类型

3.1 临时节点

3.2 永久节点

4. 阈值保护功能

5. Nacos元数据

微服务场景下，服务被划分为多个应用，而这些应用间可能存在调用关系，例如用户服务调用订单服务来查看用户的订单。

用户服务若想调用订单服务，首先得知道订单服务在哪里？当知道 IP 和端口后，就可以发送 HTTP 请求完成调用。

那么如何知道目标服务在哪里呢？

注册中心就是解决如何知道目标服务的地址信息在哪里的问题

一个服务将自己的信息（ ip 和 端口等）告知注册中心，这个告知的过程称为注册，即代表向注册中心注册了一个服务。

调用方就从注册中心根据名称查询目标服务的详细信息，来完成自己的调用工作。

对于注册中心来说，首先得有一个服务，比如说订单服务，提供订单相关操作。

此时结构如下

随着业务的增长，单个服务不够用了，现在需要将OrderService部署多份来分散压力。

订单服务由三个节点提供服务

由于OrderService基本信息都一样（服务名称、健康检查方式、路由机制、保护机制等一些其他配置），但是只有地址不一样。所以，优化一下，将Service抽出来，这样结构也更清晰好管理。

现在具体的服务叫做实例 Instance。

当应用并发量高了，为了承受住请求，可能需要部署上千上万个服务。

为了传输速度，全国各地都会部署服务。而用户，就直接访问距离他地址位置最近的服务。

也就是，同城优先访问。

如何让注册中心支持这个功能呢？

此时再优化一下结构。

service 代表一个服务

cluster 代表一个服务的集群。如上图，将三个实例放入集群西安，然后西安的消费方指定西安的集群，就可以访问到西安的实例。如果不需要这个功能，当然也可以只使用一个默认的集群。

上面就是一个服务，但是在开发、测试、生产的环境下，服务都是一样的。开发的不能调用到生产环境服务，所以需要进行服务的区分。

看上去，cluster就可以做服务的区分，比如做多个cluster, cluster dev、cluster test、cluster prod。不过cluster并不能实现这个功能。

因为当指定访问的cluster挂掉后，客户端就会访问其他cluster。本地开发环境肯定是不能调用线上环境的。

所以，优化一下此时的结构。在service上层增加一个分组的概念，将服务进行分组。

开发环境调用开发分组的服务。线上环境调用线上分组的服务。

现在整体看起来都完善了，但是作为一个公司来说，可能不只是有一个产品，一个系统。不同系统之间的服务又是不同的。所以需要一个资源隔离功能。

在nacos中，这个资源隔离叫做namespace，nacos也称它为租户。namespace在后台新建。

服务注册的时候，指定 namespce id ，即可将服务注册到指定命名空间下。

总结

namespace：相当于租户的概念，用于资源的隔离

group：数据的分组

service：服务

cluster: 服务下的集群

instance：具体提供服务的实例

来源于官网的两张结构图 Nacos 架构

在Nacos中，将服务的节点类型分为 临时节点 和 永久节点

在 SpringCloud 中使用 Nacos 时，引入了以下依赖

com.alibaba.cloudspring-cloud-starter-alibaba-nacos-discovery

spring-cloud-starter-alibaba-nacos-discovery 里引入了 nacos-client 模块

NacosClient 代表一个 Nacos 客户端，负责完成服务注册等功能。

服务注册代表 成为一个 Nacos 服务，成为一个临时节点。

可以用过 spring.cloud.nacos.discovery.ephemeral=false 改为永久节点 （默认值true）

临时节点是什么意思呢？

临时节点代表节点临时存在，需要不断发送心跳包来续命。否则就会下线，调用方就查不到服务了。

NacosClient 向 NacosServer 注册服务有两种方式

1. GRPC 注册服务

观察 Nacos Client 2.2.0 版本的客户端源码，发现客户端通过 GRPC 发送消息完成注册服务

NacosClient 本身会作为 GRPC 客户端 向 GRPC 服务端 也就是 NacosServer 每隔 5 秒就发送心跳包。来维持 GRPC 的长链接，也就是说这种方式的健康检查是通过 GRPC 长连接特性实现的。

当 NacosClient 出现异常例如网络波动，将会断开与 NacosServer 的 GRPC 长连接，NacosServer则会监听到断开连接的事件，然后对该 NacosClient 注册的服务进行全部剔除操作。

2. HTTP 接口注册

旧版本的 1.4.x 使用的是 HTTP 接口注册

节点的彻底不可用会经历过两个阶段，状态设为不健康、节点直接剔除

Nacos 服务端会定时监听注册的临时节点：

1. 状态设为不健康：如果 15 秒没有收到发来的心跳包，就会先将节点状态设置为不健康状态。

看看 Nacos 如何判断节点为不健康状态

// com.alibaba.nacos.naming.healthcheck.heartbeat.UnhealthyInstanceChecker#isUnhealthy
​
private booleanisUnhealthy(Service service, HealthCheckInstancePublishInfo instance) {
    // 获取超时时间 默认 15 秒；可通过配置更改。
    long beatTimeout = getTimeout(service, instance);
    // 当前时间距离上一次发送心跳包时间  超过了 规定的超时时间  则返回 true,代表节点不健康了
    return System.currentTimeMillis() - instance.getLastHeartBeatTime() >beatTimeout;
}

15 秒这个参数 可通过配置更改当前服务超时时间。 （超时时间是配置给单独的服务，不是全局的。）

spring:
  cloud:
    nacos:
      discovery:
        username: nacos
        password: nacos
        server-addr: 127.0.0.1:8848
        metadata:
          # 心跳超时时间，超时后节点状态将设置为不健康. 单位毫秒
          preserved.heart.beat.timeout: 30000

2. 节点直接剔除：如果再过 30 秒，临时节点如果还没有发来心跳包，就将节点下线剔除掉。

// com.alibaba.nacos.naming.healthcheck.heartbeat.ExpiredInstanceChecker
​
private boolean isExpireInstance(Service service, HealthCheckInstancePublishInfo instance) {
    // 获取超时时间 默认 30 秒；可通过配置更改。
    long deleteTimeout = getTimeout(service, instance);
    // 当前时间距离上一次发送心跳包时间  超过了 规定的超时时间  则返回 true,代表节点过期了，需要进行节点剔除操作
    return System.currentTimeMillis() - instance.getLastHeartBeatTime() >deleteTimeout;
}

30 秒这个参数 可通过配置更改当前服务超时时间。 （超时时间是配置给单独的服务，不是全局的。）

spring:
  cloud:
    nacos:
      discovery:
        username: nacos
        password: nacos
        server-addr: 127.0.0.1:8848
        metadata:
          # 心跳超时后 距离多久时间（毫秒） 就删除掉服务
          preserved.ip.delete.timeout: 40000

永久节点的意思是它永远存在，除非主动注销服务。

可以发现临时节点都是通过客户端自己注册服务发送心跳，也就是说这个服务我们可以修改源码（比如刚才开发的 order-server 服务，修改了源码，引入了 Nacos 依赖）

而有些服务比如开源的第三方框架等，我们得到的也许直接就是一个可执行文件，无法修改它的源码。

那么此时我们还是想用 Nacos 管理这个服务，比如将这个服务注册上去后，应用就可以拿到这个服务，得到了地址信息就可以请求了从而完成一些业务功能。

所以，永久实例就诞生了，用于解决这个问题。

永久实例如何完成注册呢，那就是我们手动请求 Nacos Server 的接口完成注册。

这样看起来好像和 临时实例的 1.4.x 版本看起来一样，实则不是，因为差距在于健康检查方式。

临时实例1.4.x 虽然也是请求了接口，不过它还要自己上报心跳来保活。

而永久实例是采用服务端主动探测的方式，例如服务端请求永久服务的 HTTP 接口，如果状态返回 200 代表服务正常，如果返回了 503 Service Unavailable 或者 302 Temporary Redirect 则代表服务不可用了。

其次永久实例会一直存在，不会被剔除，就算检测到服务不可用了也不会被剔除。

服务主动探测先支持以下几种方式

1. HTTP 健康检查

处理类 com.alibaba.nacos.naming.healthcheck.v2.processor.HttpHealthCheckProcessor

健康检查方式：NacosServer 请求服务的指定IP + PORT ，如果返回200代表健康，返回503或302代表不健康。

2. MySQL 健康检查

处理类 com.alibaba.nacos.naming.healthcheck.v2.processor.MysqlHealthCheckProcessor

健康检查方式：请求一段配置的 SQL 命令，如果能够成功请求(没有进入 catch 异常) 代表健康，进入了异常代表不健康。

3. TCP 健康检查

处理类 com.alibaba.nacos.naming.healthcheck.v2.processor.TcpHealthCheckProcessor

健康检查方式：通过 java.nio.channels.SocketChannel 发送消息，能够访问通代表健康，超时了代表不健康

防止过多实例不健康导致流量全部流向健康实例，从而压垮健康实例。

假设在Nacos上注册了100个服务，由于一些原因等部分服务下线，只剩下20个服务，此时，大量请求来临，本来是有100个服务提供服务，但是现在却只剩了20个服务，结果不言而喻，这20个服务本来是正常的，但是却因为大量的请求则会挂掉。

此时阈值保护功能就有了作用，消费方此时拿到的服务不再是正常的服务，而是全部服务包含已下线的服务。虽然说，返回了下线的服务会导致请求失败，但这样不会导致剩下的好的服务被击垮。

阈值保护功能默认没有开启，需要开启，配置如下。

图中的配置 0.5 表示 当还剩下 50% 的健康实例时 开启保护阈值功能。

Nacos 支持为服务以及实例单独设置元数据。

配置方式如下：

spring:
  cloud:
    nacos:
      discovery:
        username: nacos
        password: nacos
        server-addr: 127.0.0.1:8848
        metadata:
          # 元数据配置，自定义 key value
          name: zhangsan

也可以通过后台管理直接编辑元数据。

元数据可以用作临时标记某个服务，记录一些信息，或者用于实现自定义路由等功能。

玩法多种多样，主要就是给服务或实例配置一些数据，然后我们就拿到这些数据做一些自己的特殊业务处理。

你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧