阿里巴巴是如何打通 CMDB，实现就近访问的？

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实现。
具体步骤以下：

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

   <dependency>
               <groupId>com.alibaba.nacos</groupId>
               <artifactId>nacos-api</artifactId>
               <version>0.7.0</version>
           </dependency>

2. 引入打包插件：

   <plugin>
                   <groupId>org.apache.maven.plugins</groupId>
                   <artifactId>maven-assembly-plugin</artifactId>
                   <configuration>
                       <descriptorRefs>
                           <descriptorRef>jar-with-dependencies</descriptorRef>
                       </descriptorRefs>
                   </configuration>
               </plugin>

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

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

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

1. 代码自测完成后，执行命令进行打包：

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

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

   {nacos.home}/plugins/cmdb

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

   nacos.cmdb.loadDataAtStart=true

4. 重启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.十一、22.22.22.2二、33.33.33.3三、44.44.44.44和55.55.55.55.55都包含了标签site，且它们对应的值分别为x十一、x十二、x十一、x十二、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.3三、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），关注公众号在后台回复 "架构" 可获取更多，转载请原样保留本信息。