医院网站备案流程,手机端什么可以替代迅雷,公司的网站可以用个人备案吗,软件开发和网站开发有何不同CMDB在企业中#xff0c;一般用于存放与机器设备、应用、服务等相关的元数据。当企业的机器及应用达到一定规模后就需要这样一个系统来存储和管理它们的元数据。有一些广泛使用的属性#xff0c;例如机器的IP、主机名、机房、应用、region等#xff0c;这些数据一般会在机器…CMDB在企业中一般用于存放与机器设备、应用、服务等相关的元数据。当企业的机器及应用达到一定规模后就需要这样一个系统来存储和管理它们的元数据。有一些广泛使用的属性例如机器的IP、主机名、机房、应用、region等这些数据一般会在机器部署时录入到CMDB运维或者监控平台会使用这些数据进行展示或者相关的运维操作。 在服务进行多机房或者多地域部署时跨地域的服务访问往往延迟较高一个城市内的机房间的典型网络延迟在1ms左右而跨城市的网络延迟例如上海到北京大概为30ms。此时自然而然的一个想法就是能不能让服务消费者和服务提供者进行同地域访问。 我们在集团内部的实践中这样的需求是通过和CMDB打通来实现的。Nacos的服务发现组件中对接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插件必须实现的接口 获取标签列表 SetString getLabelNames(); 这个方法将返回CMDB中需要被Nacos识别的标签名集合CMDB插件可以按需决定返回什么标签个Nacos。不在这个集合的标签将会被Nacos忽略即使这个标签出现在实体的属性里。我们允许这个集合会在运行时动态变化Nacos会定时去调用这个接口刷新标签集合。 获取实体类型 SetString getEntityTypes(); 获取CMDB里的实体的类型集合不在这个集合的实体类型会被Nacos忽略。服务发现模块目前需要的实体类似是ip如果想要通过打通CMDB数据来实现服务的高级负载均衡请务必在返回集合里包含“ip”。 获取标签详情 Label getLabel(String labelName); 获取标签的详细信息。返回的Label类里包含标签的名字和标签值的集合。如果某个实体的这个标签的值不在标签值集合里将会被视为无效。 查询实体的标签值 String getLabelValue(String entityName, String entityType, String labelName);
MapString, String getLabelValues(String entityName, String entityType); 这里包含两个方法一个是获取实体某一个标签名对应的值一个是获取实体所有标签的键值对。参数里包含实体的值和实体的类型。注意这个方法并不会在每次在Nacos内部触发查询时去调用Nacos内部有一个CMDB数据的缓存只有当这个缓存失效或者不存在时才会去访问CMDB插件查询数据。为了让CMDB插件的实现尽量简单我们在Nacos内部实现了相应的缓存和刷新逻辑。 查询实体 MapString, MapString, Entity getAllEntities();
Entity getEntity(String entityName, String entityType); 查询实体包含两个方法查询所有实体和查询单个实体。查询单个实体目前其实就是查询这个实体的所有标签不过我们将这个方法与获取所有标签的方法区分开来因为查询单个实体方法后面可能会进行扩展比查询所有标签获取的信息要更多。 查询所有实体则是一次性将CMDB的所有数据拉取过来该方法可能会比较消耗性能无论是对于Nacos还是CMDB。Nacos内部调用该方法的策略是通过可配置的定时任务周期来定时拉取所有数据在实现该CMDB插件时也请关注CMDB服务本身的性能采取合适的策略。 查询实体事件 ListEntityEvent getEntityEvents(long timestamp); 这个方法意在获取最近一段时间内实体的变更消息增量的去拉取变更的实体。因为Nacos不会实时去访问CMDB插件查询实体需要这个拉取事件的方法来获取实体的更新。参数里的timestamp为上一次拉取事件的时间CMDB插件可以选择使用或者忽略这个参数。 CMDB插件开发流程 参考 https://github.com/nacos-group/nacos-examples这里已经给出了一个示例plugin实现。 具体步骤如下 新建一个maven工程引入依赖nacos-api:plain dependency groupIdcom.alibaba.nacos/groupId artifactIdnacos-api/artifactId version0.7.0/version /dependency引入打包插件plain plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId configuration descriptorRefs descriptorRefjar-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.skiptrue将target目录下的包含依赖的jar包上传到nacos CMDB插件目录plain {nacos.home}/plugins/cmdb在nacos的application.properties里打开加载插件开关plain nacos.cmdb.loadDataAtStarttrue重启nacos Server即可加载到您实现的nacos-cmdb插件获取您的CMDB数据。使用Selector实现同机房优先访问 在拿到CMDB的数据之后就可以运用CMDB数据的强大威力来实现多种灵活的负载均衡策略了下面举例来说明如何使用CMDB数据和Selector来实现就近访问。 假设目前Nacos已经通过CMDB拿到了一些IP的机房信息且它们对应的标签信息如下 11.11.11.11site: x1122.22.22.22site: x1233.33.33.33site: x1144.44.44.44site: x1255.55.55.55site: 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。 图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.1144.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关注公众号在后台回复 架构 可获取更多转载请原样保留本信息。 转载于:https://www.cnblogs.com/javastack/p/10256401.html
