CMDB 在基础服务体系中的核心位置

以应用为核心来看，CMDB 中会保存“应用 - 分组 - 资源”的对应关系，这个关系对于周边系统来说都是需要的。

1、监控系统

我们需要以上的对应关系，监控到每个应用、每个集群以及每台机器上的关键信息。

2、发布系统

我们需要将每个应用对应的代码进行编译打包，然后发布到对应集群的主机上，也需要这个对应关系，这一点我在后面的持续交付中还会讲到。

3、服务化框架

需要依赖应用和集群分组两个信息，其中主要是对应用名和集群分组名的依赖，对于服务化框架来说，更多的是通过其配置管理中心注册的应用名，来实现应用的服务和 API 管理，这里要做到与 CMDB 统一。同样，像 LVS 和 Nginx 这样的四七层负载，以及 ZK 这样的开源分布式配置管理，凡是涉及服务注册、服务发现以及服务上下线的基础服务，都是类似思路。

4、基础服务中

如分布式 DB、分布式缓存和消息等，就需要应用的应用名，以及应用与资源 IP 的对应关系，或者集群分组与 IP 的对应关系。

• 应用名，是因为要建立应用与分布式服务实例之间的关系。如应用与缓存 NameSpace 的对应关系，应用与消息 Topic 的对应关系等，以便于这些基础服务的生命周期管理和自动化开发。
• 应用与资源的对应关系，是因为有些核心资源是要做 ACL 访问控制的。比如对于用户、交易或支付这样非常敏感的数据，它们对应的数据库就不允许随意连接，而应该是仅限于授权过的应用访问。这时就要针对应用对应的 IP 地址进行白名单配置。一方面，可以通过分布式 DB 中间件进行配置；另一方面，也可以通过在 DB 层面进行设置，比如 MySQL 就可以直接配置白名单策略；同时也可以在机器的 iptables 上配置，至于如何配置就看具体需求了，但是无论怎样，应用与资源的对应关系是非常重要的。

5、稳定性保障平台

针对系统的稳定性，我们会在应用中做很多的降级限流和开关预案策略，这些都是跟应用直接关联的。而且不同的集群分组，策略可能会有不同，所以又会跟集群分组相关。同时，这些策略最终下发到具体服务器上运行的应用实例上，就会需要应用、集群分组以及对应的资源关系。

总结基于以应用为核心的 CMDB 中，又衍生出“应用 - 集群服务分组 - 资源”这样一个运维体系中的核心关系。

此文章为3月Day16 学习笔记，内容来源于极客时间《赵成的运维体系管理课》，推荐该课程。