CMDB 用于存放规模化的机器设备、应用、服务等相关的元数据。基本属性例如机器的IP、主机名、机房、应用、所在区域等，这些元数据一般会在机器部署时录入到CMDB。
在微服务实例进行多机房或者多地域部署时，跨地域的微服务访问往往延迟较高，一个城市内的机房间的典型网络延迟在1ms左右，而跨城市的网络延迟，例如南京到上海大概为20ms。如何让服务消费者和服务提供者进行同地域访问。在实践中，此需求是通过和CMDB打通来实现的。在服务发现组件中，对接CMDB，然后通过路由组件配置的访问规则，来实现服务消费者到服务提供者的同地域优先。
支持就近访问的时候 ，需要能够从某个地方获取IP的环境信息，该部署信息要么是从企业的CMDB中查询而来，要么是从元数据中心获取。
CMDB插件机制
首先Nacos里将CMDB的数据通过某种方法获取。一个比较好的策略是使用SPI机制，约定CMDB的抽象调用接口，由各个企业添加自己的CMDB插件，无需任何代码上的重新构建，即可在运行状态下对接上企业的CMDB。
Nacos定义了一个SPI接口，里面包含了与第三方CMDB约定的一些方法。用户依照约定实现了相应的SPI接口后可实现Nacos与CMDB的数据打通。
在这里对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忽略。服务发现模块目前需要的实体类似是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插件开发流程
具体步骤如下：
1.新建一个maven工程，引入依赖nacos-api:
com.alibaba.nacos
nacos-api
0.7.0
2.引入打包插件：
org.apache.maven.plugins
maven-assembly-plugin
jar-with-dependencies
3.定义实现类，继承com.alibaba.nacos.api.cmdb.CmdbService，并实现相关方法。
public class ExampleCmdbServiceImple implements CmdbService{
private int index =1 ;
}
4.在src/main/resource/目录下新建目录：META-INF/services
5.在src/main/resources/META-INF/services目录下新建文件com.alibaba.nacos.api.cmdb.CmdbService，并在文件里将第三步中创建的实现类全名写入该文件:
mvn package assembly:single -Dmaven.test.skip=true
7.将target目录下的包含依赖的jar包上传到nacos CMDB插件目录：
{nacos.home}/plugins/cmdb
8.在nacos的application.properties里打开加载插件开关：
nacos.cmdb.loadDataAtStart=true
9.重启nacos Server，即可加载到您实现的nacos-cmdb插件获取您的CMDB数据。
使用Selector实现同机房优先访问
通过CMDB的数据就可以实现多种灵活的负载均衡策略，下面举例来说明如何使用CMDB数据和Selector来实现就近访问。
1.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
2.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。
3.我们先注册一个服务，下面挂载IP11.11.11.11和22.22.22.22。
4.然后我们修改服务的“服务路由类型”，并配置为基于同site优先的服务路由：
里我们将服务路由类型选择为标签，然后输入标签的表达式：
CONSUMER.label.site = PROVIDER.label.site
5.这个表达式的格式和我们抽象的Selector机制有关，具体将会在另外一篇文章中介绍。在这里您需要记住的就是，任何一个如下格式的表达式：
CONSUMER.label.labelName = PROVIDER.label.labelName
6.将能够实现基于同labelName优先的负载均衡策略。
7.然后假设服务消费者的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
作者：肖哥弹架构
链接：https://juejin.cn/post/6892343440705585159
来源：掘金