以应用为核心来看,CMDB 中会保存“应用 - 分组 - 资源”的对应关系,这个关系对于周边系统来说都是需要的。
我们需要以上的对应关系,监控到每个应用、每个集群以及每台机器上的关键信息。
我们需要将每个应用对应的代码进行编译打包,然后发布到对应集群的主机上,也需要这个对应关系,这一点我在后面的持续交付中还会讲到。
需要依赖应用和集群分组两个信息,其中主要是对应用名和集群分组名的依赖,对于服务化框架来说,更多的是通过其配置管理中心注册的应用名,来实现应用的服务和 API 管理,这里要做到与 CMDB 统一。同样,像 LVS 和 Nginx 这样的四七层负载,以及 ZK 这样的开源分布式配置管理,凡是涉及服务注册、服务发现以及服务上下线的基础服务,都是类似思路。
如分布式 DB、分布式缓存和消息等,就需要应用的应用名,以及应用与资源 IP 的对应关系,或者集群分组与 IP 的对应关系。
针对系统的稳定性,我们会在应用中做很多的降级限流和开关预案策略,这些都是跟应用直接关联的。而且不同的集群分组,策略可能会有不同,所以又会跟集群分组相关。同时,这些策略最终下发到具体服务器上运行的应用实例上,就会需要应用、集群分组以及对应的资源关系。
总结基于以应用为核心的 CMDB 中,又衍生出“应用 - 集群服务分组 - 资源”这样一个运维体系中的核心关系。
此文章为3月Day16 学习笔记,内容来源于极客时间《赵成的运维体系管理课》,推荐该课程。