我要评论cmdb在企业中，一般用于存放与机器设备、应用、服务等相关的元数据。当企业的机器及应用达到一定规模后就需要这样一个系统来存储和管理它们的元数据。有一些广泛使用的属性，例如机器的ip、主机名、机房、应用、region等，这些数据一般会在机器部署时录入到cmdb，运维或者监控平台会使用这些数据进行展示或者相关的运维操作。
在服务进行多机房或者多地域部署时，跨地域的服务访问往往延迟较高，一个城市内的机房间的典型网络延迟在1ms左右，而跨城市的网络延迟，例如上海到北京大概为30ms。此时自然而然的一个想法就是能不能让服务消费者和服务提供者进行同地域访问。
我们在集团内部的实践中，这样的需求是通过和cmdb打通来实现的。nacos的服务发现组件中，对接cmdb，然后通过配置的访问规则，来实现服务消费者到服务提供者的同地域优先。
这实际上就是一种负载均衡策略，在nacos的规划中，丰富的服务端的可配置负载均衡策略是我们的重要发展方向，这与当前已有的注册中心产品不太一样。在设计如何在开源的场景中，支持就近访问的时候，与企业自带的cmdb集成是我们考虑的一个核心问题。除此之外，我们也在考虑将nacos自身扩展为一个实现基础功能的cmdb。无论如何，我们都需要能够从某个地方获取ip的环境信息，这些信息要么是从企业的cmdb中查询而来，要么是从自己内置的存储中查询而来。
cmdb插件机制
先不考虑如何将cmdb的数据应用于负载均衡，我们需要首先在nacos里将cmdb的数据通过某种方法获取。在实际使用中，基本上每个公司都会通过购买或者自研搭建自己的cmdb，那么为了能够解耦各个企业的cmdb具体实现，一个比较好的策略是使用spi机制，约定cmdb的抽象调用接口，由各个企业添加自己的cmdb插件，无需任何代码上的重新构建，即可在运行状态下对接上企业的cmdb。
如图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插件开发流程
参考 ，这里已经给出了一个示例plugin实现。
具体步骤如下：
- 新建一个maven工程，引入依赖nacos-api:
plain <dependency> <groupid>com.alibaba.nacos</groupid> <artifactid>nacos-api</artifactid> <version>0.7.0</version> </dependency> - 引入打包插件：
plain <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，并在文件里将第三步中创建的实现类全名写入该文件:
- 代码自测完成后，执行命令进行打包：
plain mvn package assembly:single -dmaven.test.skip=true - 将target目录下的包含依赖的jar包上传到nacos cmdb插件目录：
plain {nacos.home}/plugins/cmdb - 在nacos的application.properties里打开加载插件开关：
plain 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。
然后我们修改服务的“服务路由类型”，并配置为基于同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，实现就近访问的实践。nacos是阿里巴巴开源的服务注册与配置管理产品，参考：《阿里启动新项目：nacos，比 eureka 更强！》。
本文原创首发于微信公众号：java技术栈（id:javastack），关注公众号在后台回复 "架构" 可获取更多，转载请原样保留本信息。
您可能感兴趣的文章:
如您对本文有疑问或者有任何想说的，请 点击进行留言回复，万千网友为您解惑！
网友评论