nacos使用_使用Nacos的CMDB实现微服务的就近访问！

你知道的越多，不知道的就越多，业余的像一棵小草！

你来，我们一起精进！你不来，我和你的竞争对手一起精进！

编辑：业余草

juejin.cn/post/6892343440705585159

推荐：https://www.xttblog.com/?p=5123

使用Nacos的CMDB实现微服务的就近访问！

Nacos 提供了一大堆很香的功能，很多人估计都没听过，也没用过。

上图中的功能，Nacos 提供的都有，你了解过多少？

基于 Nacos 的强大能力，本文就来说一说 Nacos 提供的 CMDB 功能。

❝

CMDB 用于存放规模化的机器设备、应用、服务等相关的元数据。基本属性例如机器的 IP、主机名、机房、应用、所在区域等，这些元数据一般会在机器部署时录入到 CMDB。
在微服务实例进行多机房或者多地域部署时，跨地域的微服务访问往往延迟较高，一个城市内的机房间的典型网络延迟在 1ms 左右，而跨城市的网络延迟，例如南京到上海大概为 20ms。如何让服务消费者和服务提供者进行同地域访问。在实践中，此需求是通过和 CMDB 打通来实现的。在服务发现组件中，对接 CMDB，然后通过路由组件配置的访问规则，来实现服务消费者到服务提供者的同地域优先。

❞

服务的同区域优先访问

支持就近访问的时候，需要能够从某个地方获取 IP 的环境信息，该部署信息要么是从企业的 CMDB 中查询而来，要么是从元数据中心获取。

CMDB 插件机制

首先 Nacos 里将 CMDB 的数据通过某种方法获取。一个比较好的策略是使用 SPI 机制，约定 CMDB 的抽象调用接口，由各个企业添加自己的 CMDB 插件，无需任何代码上的重新构建，即可在运行状态下对接上企业的 CMDB。

Nacos CMDB SPI机制原理

Nacos 定义了一个 SPI 接口，里面包含了与第三方 CMDB 约定的一些方法。用户依照约定实现了相应的 SPI 接口后可实现 Nacos 与 CMDB 的数据打通。

SPI 定义

在这里对 CMDB 机制的相关概念和接口含义做一个详细说明。

CMDB 抽象概念

实体(Entity)：实体是作为 CMDB 里数据的承载方，在一般的 CMDB 中，一个实体可以指一个 IP、应用或者服务。而这个实体会有很多属性，例如 IP 的机房信息，服务的版本信息等。

实体类型(Entity Type)：我们并不限定实体一定是 IP、应用或者服务，这取决于实际的业务场景。目前服务发现需要的实体类型是 IP 与 Service。

标签(Label)：Label 是我们抽象出的 Entity 属性，Label 定义为一个描述 Entity 属性的 K-V 键值对。Label 的 key 和 value 的取值范围一般都是预先定义好的，当需要对 Label 进行变更，如增加新的 key 或者 value 时，需要调用单独的接口并触发相应的事件。一个常见的 Label 的例子是 IP 的机房信息，我们认为机房(site)是 Label 的 key，而机房的集合(site1, site2, site3)是 Label 的 value，这个 Label 的定义就是：site: {site1, site2, site3}。

实体事件(Entity Event)：实体的标签的变更事件。当 CMDB 的实体属性发生变化，需要有一个事件机制来通知所有订阅方。为了保证实体事件携带的变更信息是最新准确的，这个事件里只会包含变更的实体的标识以及变更事件的类型，不会包含变更的标签的值。

CMDB 约定接口：在设计与 CMDB 交互接口的时候，我们参考了内部对 CMDB 的访问接口与外部客户进行了讨论。我们最终确定了以下要求第三方 CMDB 插件必须实现的接口：

获取标签列表

Set getLabelNames();

这个方法将返回 CMDB 中需要被 Nacos 识别的标签名集合，CMDB 插件可以按需决定返回什么标签个 Nacos。不在这个集合的标签将会被 Nacos 忽略，即使这个标签出现在实体的属性里。我们允许这个集合会在运行时动态变化，Nacos 会定时去调用这个接口刷新标签集合。

获取实体类型

Set getEntityTypes();

获取 CMDB 里的实体的类型集合，不在这个集合的实体类型会被 Nacos 忽略。服务发现模块目前需要的实体类似是 ip，如果想要通过打通 CMDB 数据来实现服务的高级负载均衡，请务必在返回集合里包含“ip”。

获取标签详情

Label getLabel(String labelName);

获取标签的详细信息。返回的 Label 类里包含标签的名字和标签值的集合。如果某个实体的这个标签的值不在标签值集合里，将会被视为无效。

查询实体的标签值

String getLabelValue(String entityName, String entityType, String labelName);Map getLabelValues(String entityName, String entityType);

这里包含两个方法，一个是获取实体某一个标签名对应的值，一个是获取实体所有标签的键值对。参数里包含实体的值和实体的类型。注意，这个方法并不会在每次在 Nacos 内部触发查询时去调用，Nacos 内部有一个 CMDB 数据的缓存，只有当这个缓存失效或者不存在时，才会去访问 CMDB 插件查询数据。为了让 CMDB 插件的实现尽量简单，我们在 Nacos 内部实现了相应的缓存和刷新逻辑。

查询实体

Map> getAllEntities();Entity getEntity(String entityName, String entityType);

查询实体包含两个方法：查询所有实体和查询单个实体。查询单个实体目前其实就是查询这个实体的所有标签，不过我们将这个方法与获取所有标签的方法区分开来，因为查询单个实体方法后面可能会进行扩展，比查询所有标签获取的信息要更多。

查询所有实体则是一次性将 CMDB 的所有数据拉取过来，该方法可能会比较消耗性能，无论是对于 Nacos 还是 CMDB。Nacos 内部调用该方法的策略是通过可配置的定时任务周期来定时拉取所有数据，在实现该 CMDB 插件时，也请关注 CMDB 服务本身的性能，采取合适的策略。

查询实体事件

List getEntityEvents(long timestamp);

这个方法意在获取最近一段时间内实体的变更消息，增量的去拉取变更的实体。因为 Nacos 不会实时去访问 CMDB 插件查询实体，需要这个拉取事件的方法来获取实体的更新。参数里的 timestamp 为上一次拉取事件的时间，CMDB 插件可以选择使用或者忽略这个参数。

CMDB 插件开发流程

具体步骤如下：

新建一个 maven 工程，引入依赖 nacos-api:

<dependency>    <groupId>com.alibaba.nacosgroupId>    <artifactId>nacos-apiartifactId>    <version>0.7.0version>dependency>

引入打包插件：

<plugin>  <groupId>org.apache.maven.pluginsgroupId>  <artifactId>maven-assembly-pluginartifactId>  <configuration>      <descriptorRefs>          <descriptorRef>jar-with-dependenciesdescriptorRef>      descriptorRefs>  configuration>plugin>

定义实现类，继承 com.alibaba.nacos.api.cmdb.CmdbService，并实现相关方法。

public class ExampleCmdbServiceImple implements CmdbService{ private int index =1 ;}

在src/main/resource/目录下新建目录：META-INF/services

在src/main/resources/META-INF/services目录下新建文件com.alibaba.nacos.api.cmdb.CmdbService，并在文件里将第三步中创建的实现类全名写入该文件:

执行命令进行打包：

mvn package assembly:single -Dmaven.test.skip=true

将target目录下的包含依赖的jar包上传到nacos CMDB插件目录：

{nacos.home}/plugins/cmdb

在nacos的application.properties里打开加载插件开关：

nacos.cmdb.loadDataAtStart=true

重启nacos Server，即可加载到您实现的nacos-cmdb插件获取您的CMDB数据。

使用 Selector 实现同机房优先访问

通过 CMDB 的数据就可以实现多种灵活的负载均衡策略，下面举例来说明如何使用 CMDB 数据和 Selector 来实现就近访问。

Nacos 通过 CMDB 获取 IP 机房信息，对应的标签信息如下：

11.11.11.11    site: x11

22.22.22.22    site: x12

33.33.33.33    site: x11

44.44.44.44    site: x12

55.55.55.55    site: x13

11.11.11.11、22.22.22.22、33.33.33.33、44.44.44.44和55.55.55.55.55都包含了标签site，且它们对应的值分别为x11、x12、x11、x12、x13。
我们先注册一个服务，下面挂载IP11.11.11.11和22.22.22.22。

然后我们修改服务的“服务路由类型”，并配置为基于同site优先的服务路由：

这里我们将服务路由类型选择为标签，然后输入标签的表达式：

CONSUMER.label.site = PROVIDER.label.site

这个表达式的格式和我们抽象的Selector机制有关，具体将会在另外一篇文章中介绍。在这里您需要记住的就是，任何一个如下格式的表达式：

CONSUMER.label.labelName = PROVIDER.label.labelName

将能够实现基于同labelName优先的负载均衡策略。
然后假设服务消费者的IP分别为33.33.33.33、44.44.44.44和55.55.55.55，它们在使用如下接口查询服务实例列表：

naming.selectInstances("nacos.test.1", true)

那么不同的消费者，将获取到不同的实例列表。33.33.33.33获取到11.11.11.11，44.44.44.44将获取到22.22.22.22，而55.55.55.55将同时获取到11.11.11.11和22.22.22.22。

以上就是 Nacos 提供的 CMDB 实现微服务的就近访问的简单案例学习内容了！更多内容，推荐大家去他的官网阅读官方文档。