博主介绍：✌全网粉丝4W+，全栈开发工程师，从事多年软件开发，在大厂呆过。持有软件中级、六级等证书。可提供微服务项目搭建与毕业项目实战、定制、远程，博主也曾写过优秀论文，查重率极低，在这方面有丰富的经验✌
博主作品：《Java项目案例》主要基于SpringBoot+MyBatis/MyBatis-plus+MySQL+Vue等前后端分离项目，可以在左边的分类专栏找到更多项目。《Uniapp项目案例》有几个有uniapp教程，企业实战开发。《微服务实战》专栏是本人的实战经验总结，《Spring家族及微服务系列》专注Spring、SpringMVC、SpringBoot、SpringCloud系列、Nacos等源码解读、热门面试题、架构设计等。除此之外还有不少文章等你来细细品味，更多惊喜等着你哦
🍅开源项目免费哦：点击这里克隆或者下载 ，已经发布Vue3版 🍅
🍅文末获取联系🍅精彩专栏推荐订阅👇🏻👇🏻 不然下次找不到哟
Java项目案例《100套》
https://blog.csdn.net/qq_57756904/category_12173599.html
uniapp小程序《100套》
目录
一、前言
CMDB 在企业中，一般用于存放与机器设备、应用、服务等相关的元数据。一般当企业的机器及应用达到一定规模后就需要这样一个系统来存储和管理它们的元数据。有一些广泛使用的属性例如机器的IP、主机名、机房、应用、region 等，这些数据一般会在机器部署时录入到 CMDB，运维或者监控平台会使用这些数据进行展示或者相关的运维操作。
在服务进行多机房或者多地域部署时，跨地域的服务访问往往延迟较高，一个城市内的机房间的典型网络延迟在1ms 左右，而跨城市的网络延迟，例如上海到北京大概为 30ms 。此时自然而然的一个想法就是能不能让服务消费者和服务提供者进行同地域访问。阿里巴巴集团内部很早就意识到了这样的需求，在内部的实践中，这样的需求是通过和 CMDB 打通来实现的。在服务发现组件中，对接 CMDB，然后通过配置的访问规则，来实现服务消费者到服务提供者的同地域优先，这样的调用每天都在阿里巴巴集团内部大量执行。
图1 服务的同地域优先访问
这实际上就是一种负载均衡策略，在 Nacos 的规划中，丰富的服务端的可配置负载均衡策略是我们的重要发展方向，这与当前已有的注册中心产品不太一样。在设计如何在开源的场景中，支持就近访问的时候，与企业自带的 CMDB 集成是我们考虑的一个核心问题。除此之外，也在考虑将 Nacos 自身扩展为一个实现基础功能的CMDB。无论如何，都需要能够从某个地方获取IP的环境信息，这些信息要么是从企业的 CMDB 中查询而来，要么是从自己内置的存储中查询而来。
二、CMDB 插件机制
先不考虑如何将 CMDB 的数据应用于负载均衡，需要首先在 Nacos 里将 CMDB 的数据通过某种方法获取。在实际使用中，基本上每个公司都会通过购买或者自研搭建自己的 CMDB，那么为了能够解耦各个企业的CMDB 具体实现，一个比较好的策略是使用 SPI 机制，约定 CMDB 的抽象调用接口，由各个企业添加自己的CMDB 插件，无需任何代码上的重新构建，即可在运行状态下对接上企业的 CMDB。
图2 Nacos CMDB SPI机制原理
如图 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 插件开发流程
具体步骤如下：
- 新建一个 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: x1311.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。
图3 服务详情
然后我们修改服务的“服务路由类型”，并配置为基于同site优先的服务路由：
图4 编辑服务路由类型
这里将服务路由类型选择为标签，然后输入标签的表达式：
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。
💖微服务实战
✨【微服务】SpringCloud的OpenFeign与Ribbon配置
✨Spring Cloud Alibaba微服务第29章之Rancher
✨Spring Cloud Alibaba微服务第27章之Jenkins
✨Spring Cloud Alibaba微服务第24章之Docker部署
✨Spring Cloud Alibaba微服务第23章之Oauth2授权码模式
✨Spring Cloud Alibaba微服务第22章之Oauth2
✨Spring Cloud Alibaba微服务第21章之分布式事务
✨Spring Cloud Alibaba微服务第18章之消息服务
✨Spring Cloud Alibaba微服务第16章之服务容错
✨Spring Cloud Alibaba微服务第14章之分库分表
✨Spring Cloud Alibaba微服务第11章之MyBatis-plus
✨Spring Cloud Alibaba微服务第8章之OpenFeign
✨Spring Cloud Alibaba微服务第7章之负载均衡Ribbon
✨SpringCloud Alibaba微服务第6章之Gateway
