共计 5217 个字符，预计需要花费 14 分钟才能阅读完成。
CMDB 在企业中，一般用于存放与机器设备、应用、服务等相关的元数据。当企业的机器及应用达到一定规模后就需要这样一个系统来存储和管理它们的元数据。有一些广泛使用的属性，例如机器的 IP、主机名、机房、应用、region 等，这些数据一般会在机器部署时录入到 CMDB，运维或者监控平台会使用这些数据进行展示或者相关的运维操作。
在服务进行多机房或者多地域部署时，跨地域的服务访问往往延迟较高，一个城市内的机房间的典型网络延迟在 1ms 左右，而跨城市的网络延迟，例如上海到北京大概为 30ms。此时自然而然的一个想法就是能不能让服务消费者和服务提供者进行同地域访问。
我们在集团内部的实践中，这样的需求是通过和 CMDB 打通来实现的。Nacos 的服务发现组件中，对接 CMDB，然后通过配置的访问规则，来实现服务消费者到服务提供者的同地域优先。
<div data-type=”alignment” data-value=”center” style=”text-align:center”> <div data-type=”p”> 图 1 服务的同地域优先访问 </div></div>
这实际上就是一种负载均衡策略，在 Nacos 的规划中，丰富的服务端的可配置负载均衡策略是我们的重要发展方向，这与当前已有的注册中心产品不太一样。在设计如何在开源的场景中，支持就近访问的时候，与企业自带的 CMDB 集成是我们考虑的一个核心问题。除此之外，我们也在考虑将 Nacos 自身扩展为一个实现基础功能的 CMDB。无论如何，我们都需要能够从某个地方获取 IP 的环境信息，这些信息要么是从企业的 CMDB 中查询而来，要么是从自己内置的存储中查询而来。
CMDB 插件机制
先不考虑如何将 CMDB 的数据应用于负载均衡，我们需要首先在 Nacos 里将 CMDB 的数据通过某种方法获取。在实际使用中，基本上每个公司都会通过购买或者自研搭建自己的 CMDB，那么为了能够解耦各个企业的 CMDB 具体实现，一个比较好的策略是使用 SPI 机制，约定 CMDB 的抽象调用接口，由各个企业添加自己的 CMDB 插件，无需任何代码上的重新构建，即可在运行状态下对接上企业的 CMDB。
<div data-type=”alignment” data-value=”center” style=”text-align:center”> <div data-type=”p”> 图 2 Nacos CMDB SPI 机制原理 </div></div>
如图 2 所示，Nacos 定义了一个 SPI 接口，里面包含了与第三方 CMDB 约定的一些方法。用户依照约定实现了相应的 SPI 接口后，将实现打成 jar 包放置到 Nacos 安装目录下，重启 Nacos 即可让 Nacos 与 CMDB 的数据打通。整个流程并不复杂，但是理解 CMDB SPI 接口里方法和相应概念的含义不太简单。在这里对 CMDB 机制的相关概念和接口含义做一个详细说明。
CMDB 抽象概念
实体（Entity）
实体是作为 CMDB 里数据的承载方，在一般的 CMDB 中，一个实体可以指一个 IP、应用或者服务。而这个实体会有很多属性，例如 IP 的机房信息，服务的版本信息等。
实体类型（Entity Type）
我们并不限定实体一定是 IP、应用或者服务，这取决于实际的业务场景。Nacos 有计划在未来支持不同的实体类型，不过就目前来说，服务发现需要的实体类型是 IP。
标签（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<String> getLabelNames();
这个方法将返回 CMDB 中需要被 Nacos 识别的标签名集合，CMDB 插件可以按需决定返回什么标签个 Nacos。不在这个集合的标签将会被 Nacos 忽略，即使这个标签出现在实体的属性里。我们允许这个集合会在运行时动态变化，Nacos 会定时去调用这个接口刷新标签集合。
获取实体类型
Set<String> getEntityTypes();
获取 CMDB 里的实体的类型集合，不在这个集合的实体类型会被 Nacos 忽略。服务发现模块目前需要的实体类似是 ip，如果想要通过打通 CMDB 数据来实现服务的高级负载均衡，请务必在返回集合里包含“ip”。
获取标签详情
Label getLabel(String labelName);
获取标签的详细信息。返回的 Label 类里包含标签的名字和标签值的集合。如果某个实体的这个标签的值不在标签值集合里，将会被视为无效。
查询实体的标签值
String getLabelValue(String entityName, String entityType, String labelName);
Map<String, String> getLabelValues(String entityName, String entityType);
这里包含两个方法，一个是获取实体某一个标签名对应的值，一个是获取实体所有标签的键值对。参数里包含实体的值和实体的类型。注意，这个方法并不会在每次在 Nacos 内部触发查询时去调用，Nacos 内部有一个 CMDB 数据的缓存，只有当这个缓存失效或者不存在时，才会去访问 CMDB 插件查询数据。为了让 CMDB 插件的实现尽量简单，我们在 Nacos 内部实现了相应的缓存和刷新逻辑。
查询实体
Map<String, Map<String, Entity>> getAllEntities();
Entity getEntity(String entityName, String entityType);
查询实体包含两个方法：查询所有实体和查询单个实体。查询单个实体目前其实就是查询这个实体的所有标签，不过我们将这个方法与获取所有标签的方法区分开来，因为查询单个实体方法后面可能会进行扩展，比查询所有标签获取的信息要更多。
查询所有实体则是一次性将 CMDB 的所有数据拉取过来，该方法可能会比较消耗性能，无论是对于 Nacos 还是 CMDB。Nacos 内部调用该方法的策略是通过可配置的定时任务周期来定时拉取所有数据，在实现该 CMDB 插件时，也请关注 CMDB 服务本身的性能，采取合适的策略。
查询实体事件
List<EntityEvent> getEntityEvents(long timestamp);
这个方法意在获取最近一段时间内实体的变更消息，增量的去拉取变更的实体。因为 Nacos 不会实时去访问 CMDB 插件查询实体，需要这个拉取事件的方法来获取实体的更新。参数里的 timestamp 为上一次拉取事件的时间，CMDB 插件可以选择使用或者忽略这个参数。
CMDB 插件开发流程
参考 https://github.com/nacos-group/nacos-examples，这里已经给出了一个示例 plugin 实现。具体步骤如下：
新建一个 maven 工程，引入依赖 nacos-api:
<dependency>
<groupId>com.alibaba.nacos</groupId>
<artifactId>nacos-api</artifactId>
<version>0.7.0</version>
</dependency>
引入打包插件：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</plugin>
定义实现类，继承 com.alibaba.nacos.api.cmdb.CmdbService，并实现相关方法。
在 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 数据的强大威力来实现多种灵活的负载均衡策略了，下面举例来说明如何使用 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。
<div data-type=”alignment” data-value=”center” style=”text-align:center”> <div data-type=”p”> 图 3 服务详情 </div></div>
然后我们修改服务的“服务路由类型”，并配置为基于同 site 优先的服务路由：
<div data-type=”alignment” data-value=”center” style=”text-align:center”> <div data-type=”p”> 图 4 编辑服务路由类型 </div></div>
这里我们将服务路由类型选择为标签，然后输入标签的表达式：
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，实现就近访问的实践。Nacos 是阿里巴巴开源的服务注册与配置管理产品，参考：《阿里启动新项目：Nacos，比 Eureka 更强！》。
本文原创首发于微信公众号：Java 技术栈（id:javastack），关注公众号在后台回复 “ 架构 ” 可获取更多，转载请原样保留本信息。
