蓝鲸6.0.3CMDB产品设计反推

346 阅读6分钟

四、蓝鲸CDMB基本产品设计

4.1、基本产品action、以及数据流

bk-cmdb.2021.11.2.png

4.2、数据模型与数据关系设计

WechatIMG199.png

WechatIMG200.png

五、蓝鲸CMDB设计反推

5.1、基本概念

  • 空闲机池

运维部门,在游戏行业的场景下。管理虚拟机、物理机。

> 因为无法做到敏捷或者说分钟级扩缩容,所以引入空闲机池的概念。即机器申请后,并未投产前的状态。
还有一个成因,物理机、虚拟机申请,需要周期,故需要提前储备资源。

> 所以主机具备全局空闲机以及各业务空闲机属性。因此,主机未分配状态可以转移至各业务空闲机,以及全局空闲机资源池。
而全局空闲机,声明空间为有操作权限的各运维,即不同负责人映射不同业务、
不同业务映射不同具备隔离的个人namespace的全局空闲机池
  • 云区域、云账号、云资源自动发现
> 显然是为适应多云后加的能力,云区域+管控能力重组了node节点管理能。
这里可配置以及云资源发现后同步目的地【包括云的区域、以及全局空闲机池】,也是为了 CMDB设计的自维护特性。

> 但显然也是为了兼顾现有全局资源池概念。如果重新设计,完全可以允许配置映射关系即云tag与CMDB业务关联和同步
  • 消息订阅
> 支持主机、业务拓扑、组织结构、网络、以及自定义数据模型 当发生变化后,push至其他三方系统。
比如 主机池新增、删除主机,主机 模块转移、身份变化等event事件
所以像,云资源自动发现后,即可作为event事件类型之一被push

那么,如何存储事件消息
功能:运营分析/操作审计
  • 业务拓扑模型

算是最有特点的设计,是最可以被称为产品而不仅仅是工具的特性。即该设计足够强大、足够灵活、足够适配各类型业务和场景,而且灵活的设计使得用户可以根据各自场景和阶段来灵活构建使用。 但初次上手新手会感觉非常复杂、一点也不现代化,也可以理解毕竟是2013年左右创建的概念和设计。

> 首先从上往下。不同账号/权限,具备不同的业务拓扑空间。

> 不同业务拓扑具备不同集群、模块,以及集群模板、模块模板等资源类型。且默认不可跨业务对同一个实例化对象进行操作。

> 这个设计类似多租户、原本的设计是为了隔离不同运维对所负责不同业务拓扑的权限,但现在更接近租户的概念。
  • 组成业务拓扑的资源间关联关系
> 业务拓扑模型,由 集群 以及 业务全局空闲机资源池组成

> 集群,由 一个或多个 模块组成。主机被模块以实例化主机include。
而集群,因为关联了模块所以也包括了实例化的主机对象集群集合。

> 主机,被包括在 模块、集群,或 空闲机池中

5.2、简化设计与灵活设计

资源模板的简化设计

> 为方便构建模块,引入 服务模板。
> 服务模板,包括 服务类别和服务进程。服务类别用于区分该服务的类型。服务进程,用于定义该服务的进程、监控等信息
所以,新建模块,可以直接新建模块,也可以通过服务模板新建模块。
服务分类,允许自定义。并被引用。

> 集群模板,同理,可以包括多个服务模板。注意不是模块,而是服务模板。
只有集群 才关联模块。集群模板关联的是服务模板

资源属性的灵活设计

  • 支持自定义字段
  • 自定义字段实际是:数据模型自定义功能的简化和快捷入口。新增自定义字段即新建模型
> 集群、模块、主机,三个核心对象,允许增加删除自定义字段,允许在各对象对于自定义字段构建value,
且自定义字段类型支持丰富类型,如列表、布尔、字符串等。

> 自定义字段的设计,会非常灵活。比如在集群增加字段定义 集群环境。在主机,增加备注信息 等
  • 支持主机属性自动应用
> 操作单元为模块,不是集群。支持对模块下主机的属性自动应用。
作用是加入到该模块下主机,自动修改其特定字段的值。比如 该主机主要负责人、备岗负责人、主机重要性等字段值并应用
  • 模型关系
> 模型关系,默认内置了一个模型关系。即主机同交换机的上联关系。关系类型可以自定义,可选有很多种

> 这里大大丰富了数据模型同数据模型的关系,比如可以新建自定义模型,构建主机同appid关系为关系类型为run的模型关系

5.3、简化设计带来的限制与使用规范

  • 通过集群模板新建集群
> 通过集群模板新建的集群,若CRUD集群下模块(比如增加或者删除集群关联的模块),必须在集群模板中修改。
且修改后会影响其他通过集群模板实例化的集群(手动同步),注意事实上影响的是集群,其模块并未受影响。
比如,手动新建的集群,通过服务模板构建的模块,并不受影响。
一句话解释:通过集群模板创建的集群,同集群下的模块,属于共享生命周期。

> 主机对象在关联模块后,成为主机实例化对象并构建了和模块的关联。
删除模块必须先清空模块下的实例化主机,同理删除集群,必须清理集群下的模块且模块下不包括实例化主机。

> 当模块引用了服务模板后,若服务模板发生变化(即进程增加删除或者配置修改)
同上,涉及同步配置类操作。都需要人工干预和确认(除自定义字段功能)。
因为模板会被多个上级对象调用和关联,这样的设计是必须的。

> 服务模板影响的作用于仅仅是被引用的模块
从主机视角重新看待这个问题。如:同样一台主机,同时处于A模块【通过服务模板构建】、B模块【直接新建】
那么主机在A模块下具备服务模板对象(即进程信息),在B模块下并未具备

如果之后。主机新增关联了C模块模块,同时继续关联A模块模板,当A和C都发生变化后。
主机服务实例的更新同步,必须在A和C所在模块进行配置更新的同步,
更新后主机在A和C的模块下,主机具备了变化后A和C的最新配置
  • 默认值
> 主机被清理所有模块关联关系后,默认会重回初始化值(即回到空闲机池)