以应用为中心的资源组织模型

更新: 2022.03.15

针对「以应用为中心的资源组织模型」，结合CH云原生和FinOps的工作经历，做出如下调整：

• 资源组织的最小单位是应用组、不是单一应用。云原生带动了微服务理念落地，应用做了充分的微服务化、而非应用资源(如PaaS)尚无必要，这就造成应用到非应用的多对一关系，单一应用也就无法做为资源组织的最小单位

借本次更新，将标题修改为”以应用为中心的资源组织模型”，修改前为 “运维平台之松耦合设计”。

原文: 2016.02.14

工作以来，一直坚信”平台化、易复用”的设计理念。在阿里、小米，先后见识了不少运维子系统，多多少少都和业务耦合、被业务所累，几乎找不到一个可以轻松移植的子系统。本文尝试提出一种松耦合的运维系统设计思路，纯属个人YY、当前没有实践做支撑。

概述

为什么，要以松耦合的方式，构建运维体系呢？很简单，方便运维子系统的复用。最好能做到，运维子系统 可以轻易接入 不同公司的运维体系。

怎样，才能让运维系统，松耦合的发生关联呢？运维系统，包含众多子系统，各子系统分别负责不同的运维业务。子系统之间往往”取长补短”、相互依赖，如Deploy需要CMDB的服务器信息才能完成部署业务、Monitor需要ACL才能完成数据的准入&准出等等。只要遵循统一的协议，子系统就可以享受其他子系统提供的服务；如果这个协议可以封装公司的业务属性，那么各子系统就可以蜕化成纯平台、进而可以跨公司复用——这正是本文的设计思路。

业务树

思来想去，业务树是最适合的协议平台。一方面，很多公司的运维体系以传统的服务树为核心展开，不同的子系统都挂载到服务树；服务树成为运维系统的统一portal(很多时候，我们把服务树当成CMDB的一种展示形态，略狭隘)。另一方面，以树状结构抽象公司的业务逻辑，已经证明是一条可行的道路。

定义

不妨下一个定义: 业务树，是公司业务的抽象，是统一的协议平台，是独立存在的实体，简写为BT。请注意，业务树是独立的实体，不是CMDB的”附庸”!!!

描述

一棵典型的BT，如下，

不同公司，BT的组织形式、描述方式不尽相同。一种可行的BT模型，为: 用字符串来命名BT的一个节点，再通过”字符串包含”运算来确定节点的父子关系。按照这种方式，上图中的BT可以描述为:

其中，cop.tycs是根节点，代表一个公司；节点cop.tycs_owt.inf代表公司下面的团队，是根节点cop.tycs的子节点，因为该节点”字符串包含”根节点。

接入

运维子系统接入BT，其实就是和BT的节点建立关联。这个关联，可以通过节点ID建立，也可以通过节点Name建立，各有优劣。

使用ID建立关联，优点为: ID在节点的生命周期内几乎不发生变化, 修改节点Name不影响关联关系；缺点为:ID是BT维护的逻辑信息，对于用户来说太抽象、不利于和用户端交互。使用Name建立关联则正好相反，容易受到节点Name变更的影响，但对用户更友好。鉴于，(1)BT节点Name变更不频繁 (2)需要提供友好的用户接口，我们选择，使用BT节点Name，与各运维子系统建立关联。

运维子系统接入BT，关系描述如下。本文之描述了资产管理、权限、监控、部署这几个系统，接入BT的情况，其他子系统接入BT的情况 后续会逐渐完善。

CMDB

CMDB接入BT的一个典型场景，就是将设备挂载到对应的业务线(BT节点)上。对应的，就是一条数据库记录，描述设备host_id和业务树节点bt_tag的对应关系。用户，可以查找某个业务线上的所有设备，可以查看某台设备属于哪些业务线。

ACL

权限系统ACL接入BT，本质上是利用BT的层级关系、实现权限的继承&覆盖等。一种典型的设计，见这里。最终，通过BT，用户 与 资源、操作发生关联。

CMDB和ACL属于基础服务，接入BT，是为了方便其他子系统使用CMDB和ACL提供的服务。

Monitor

监控系统Monitor接入BT，体现在两个方面。一方面，用户通过BT来配置监控策略，把指定的报警规则”绑定到”指定的BT节点。BT节点代表了一个业务线，关联了相应的监控数据，这样，用户就可以将特定的报警规则，应用到某业务线的监控数据上。另一方面，用户可以指定BT节点，来查看某业务线的历史数据。某个用户，可以在哪些业务线添加监控策略、可以查看哪些业务线的监控历史数据呢？这可以借助ACL实现。如，在ACL中加如下两条记录，用户A就可以在业务线cop.tycs_owt.inf_pdl.falcon添加监控策略&查看历史数据。

(1) 用户A，在BT节点cop.tycs_owt.inf_pdl.falcon，监控添加策略
(2) 用户A，在BT节点cop.tycs_owt.inf_pdl.falcon，监控查看历史数据

Deploy

部署系统Deploy接入BT后，一个典型的发布过程，可以描述为: 用户，在有权限(ACL)的业务线上，配置部署任务单；然后借助CMDB，筛选出目标服务器；最终发起上线部署。一旦Deploy接入BT，就可以享受CMDB、ACL等子系统提供的服务，多么美妙的一件事~

Init

初始化系统Init，是为了提高 初始化服务器环境 的效率 而设计的，装机上架、服务器重装时被使用。本文的Init系统，设计时遵循了如下前提:

• （1）初始化的对象，是服务器
• （2）初始化是”一组有序的操作”，可以通过”有序的执行一系列脚本”来实现
• （3）一台服务器，只用于一个业务线；不同业务线，不共用服务器
• （4）不同业务的服务器，初始化操作，有相同的基础操作、也有业务上的差异操作；先执行基础操作、后执行业务相关的操作

Init接入BT后，按照BT节点来组织初始化脚本，将通用基础操作的脚本列表 挂在高层父节点、将业务线独有的脚本列表 放在低层的子节点(越通用的操作，在BT上所处的层级越高)，每个节点的脚本列表都是有序的。执行初始化操作时，根据用户填写的机器，查询到对应的BT节点(借助CMDB)，对用户验权(借助ACL)，然后从根节点向底层节点 依次执行BT节点上所挂载的脚本列表。

补充一句，节点挂载脚本的有序性，可以通过脚本的命名规范来解决，也可以由用户配置执行顺序。用规范来解决更好，”约定优于配置”。

Cert

运维平台不同子系统的后端存在相互调用的需求，外部系统也会有调用运维子系统后端的需求。子系统后端被调用时，需要做适度的身份认证、访问控制管理，可以通过运维平台服务认证子系统cert来实现。cert的原理，参见这里。

结尾

未完待续。不同的运维子系统，会逐渐融入到本模型中。