适用范围：运维平台架构师、CMDB 建设负责人、SRE、平台工程团队；适用于服务树建设、应用集群分组管理、多环境/多IDC/多服务分组编排、CMDB 与周边系统联动等场景。
更新摘要（v2 · 2026-08 更新）：
- 结构化升级为 6 节骨架（导言 / 核心方法论 / 关键流程 / 工具与实战 / 常见误区 / 进阶延展）
- 所有 Mermaid 图补充 frontmatter（--- title: ... ---）
- 原文图片引用保留但补充文字化描述，便于无图环境阅读
- 补充 Kubernetes Namespace/Label 自动化服务树、Istio DestinationRule、KEDA 弹性伸缩等 2025 关键实践
📅 原文发布：2018-2019 | 本次更新：2025-06 | 更新等级：🔴全面重写增强
📌 2025年更新要点：
应用是整个微服务架构体系下运维的核心，而CMDB又是整个运维平台的基石。本文阐述在CMDB中如何落地应用这一核心概念，以及如何建立应用集群分组的思路。
微服务架构下会产生大量应用，少则十几、几十个，多则上百甚至上千个。面临的第一个问题是如何有效地组织和管理这些应用，避免命名方式和层次结构不统一导致的散乱状态。
"服务树"概念最早由百度运维体系提出，经小米在早期互联网运维实践中传播开来。阿里和腾讯体系中对应称为"应用"，业界通用叫法也为应用。无论称谓如何，关键在于掌握其管理方式。
服务树的核心思想是将应用组织成树形的层次结构。这种管理模式在BAT及其他互联网公司基本一致，虽叫法不同但思路相通。
基于业务维度的拆分，对应产生了应用拆分原则。以电商公司为例：
技术团队的组织架构基本对应着整个业务技术架构的拆分：业务架构决定技术架构，技术架构决定研发团队的组织架构，不同团队单元分别承担对应业务的需求开发和实现职责。
基于上述逻辑，应用管理思路明晰为：产品线-业务团队-应用。
示例：电商技术-商品团队-商品中心-商品详情
各公司对组织架构定义方式不同（如一、二级部门），但具体团队的分工和职责必然来源于业务架构决定的技术架构。只有如此，各业务团队才会职责清晰，配合协作顺畅。
软件运维阶段的工作效率，很大程度上在前面的业务架构拆分阶段就已确定。业务架构拆分的合理性、职责的清晰度，决定了后续团队组织架构的合理性和团队职责的清晰性。若此环节未做好，运维阶段必然混乱。
运维能力的体现一定是整体技术架构能力的体现，割裂两者单独看待均无意义。对于当前仍然将运维割裂建设的研发团队，需要重新审视组织架构建设的合理性。
传统模式痛点：手动维护服务树，应用上下线、组织架构调整时需人工同步，易出现数据不一致。
2025年演进方向：
| 维度 | 传统模式 | 2025年自动化方案 |
|---|---|---|
| 数据来源 | 人工录入/Excel导入 | Kubernetes原生对象自动生成 |
| 层次映射 | 手动配置父子关系 | Namespace → Team → Application |
| 开源实现 | 自研脚本 | Backstage (Spotify)、Port、InnerSource Catalog |
| 命名规范 | 内部约定 | DNS subdomain format（符合RFC 1123） |
基础规范：
2025年扩展 - Kubernetes资源命名规范：
- 和 .示例：商品中心命名为 itemcenter，商品详情命名为 itemcenter-detail
应用的组织管理相对清晰，但再往下的集群服务分组建设则更为复杂。集群服务分组源于以下三个典型需求场景。
常见环境包括开发联调环境、集成测试环境、预发环境、线上环境等。持续交付实践中所需环境会更多。
2025年演进：
大型互联网业务的单元化部署或海外拓展需求，会在多个IDC机房部署相同代码的应用，但配置可能不同。
2025年演进：
此场景与具体业务场景相关。以商品中心IC（Item Center）为例，对外依赖包括商品详情、交易下单、订单、购物车、评价、广告、秒杀活动、会场活动、商家、店铺等一系列应用，但这些依赖应用的优先级不同。
核心应用与非核心应用分级：
因此IC应用下会产生IC交易分组、IC广告分组、IC电商分组等，这些分组相对固定和静态。
2025年演进：
以电商大促秒杀场景为例：参加秒杀活动的商品瞬时访问量极大，不参加活动的商品访问量正常。为隔离较大流量，需要多个不同的秒杀IC分组进行资源层面隔离；上层秒杀活动应用在配置中心配置依赖时，需配置到对应的秒杀IC集群分组上，即使秒杀IC出现问题也不影响正常的商品IC访问。
根据场景，不同阶段会有IC的大促秒杀分组，这种类型的分组需根据实际业务场景动态调整，需要开发和运维共同讨论验证。
2025年演进：
一般情况下，集群服务分组由以上三个维度中的一个或多个来决定。以商品中心IC为例：
至此，"应用-集群服务分组-资源"的对应关系建立完成。此信息被称为"应用树"或"服务树"，是CMDB中最为关键和核心的信息。
| 维度 | 分组依据 | 特征 | 2025年技术方案 | 调整频率 |
|---|---|---|---|---|
| 多环境 | 部署阶段 | 相对固定 | K8s Namespace + FluxCD/ArgoCD GitOps | 低（变更时调整） |
| 多IDC | 物理位置 | 固定 | Karmada/OCM + Cluster API | 极低 |
| 多服务分组 | 业务优先级/场景 | 混合（固定+动态） | Istio DestinationRule + KEDA Autoscaling | 中高（随业务需求变化） |
CMDB以应用为核心保存"应用-分组-资源"的对应关系，该关系对于周边系统至关重要。
传统需求：监控每个应用、每个集群及每台机器上的关键信息。
2025年演进：
传统需求：将每个应用对应的代码编译打包，发布到对应集群的主机。
2025年演进：
传统需求：依赖应用名和集群分组名，通过配置管理中心注册应用名实现服务和API管理，需与CMDB统一。LVS/Nginx四七层负载、ZK分布式配置管理等涉及服务注册、发现及上下线的基础服务均采用类似思路。
2025年演进：
传统需求：分布式DB、缓存和消息队列等需要应用名，以及应用与资源IP或集群分组与IP的对应关系。
2025年演进：
传统需求：针对系统稳定性的降级限流和开关预案策略直接关联应用；不同集群分组策略可能不同，最终下发到具体服务器上的应用实例，需要应用、集群分组及对应的资源关系。
2025年演进：
使用 Istio DestinationRule 实现核心应用与非核心应用的流量分组管理：
# Istio DestinationRule 示例
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: itemcenter
spec:
host: itemcenter.default.svc.cluster.local
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
outlierDetection:
consecutive5xxErrors: 5
interval: 30s
baseEjectionTime: 30s
subsets:
- name: core-transaction
labels:
tier: core
group: transaction
- name: normal-ecommerce
labels:
tier: normal
group: ecommerce基于 Prometheus 指标（QPS、延迟）自动触发扩缩容，支持多种事件源：
# KEDA ScaledObject 示例
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: itemcenter-seckill-scaler
spec:
scaleTargetRef:
name: itemcenter-seckill
minReplicaCount: 3
maxReplicaCount: 50
pollingInterval: 30
triggers:
- type: prometheus
metadata:
serverAddress: http://prometheus:9090
metricName: http_requests_per_second
threshold: "1000"
query: sum(rate(http_requests_total{service="itemcenter",group="seckill"}[2m]))监控、发布、基础服务以及稳定性平台均依赖CMDB中"应用-集群服务分组-资源"的对应关系信息。当CMDB中的这些关系发生变化（如新增/下线IP），信息传递机制经历了以下演进：
| 时期 | 同步机制 | 特点 |
|---|---|---|
| 2018-2019 | 定时轮询API / 消息队列推送 | 延迟较高，一致性难保证 |
| 2020-2022 | Webhook事件驱动 + 最终一致性 | 实时性好，需处理幂等性 |
| 2023-2025 | GraphQL统一查询层 + CRD事件广播 | 声明式、可观测、支持订阅 |
2025推荐架构：
| 维度 | 原文隐含方案(2019) | 当前推荐(2025) | 变更原因 |
|---|---|---|---|
| 服务树数据源 | 人工录入/Excel | Kubernetes Namespace + Label | 自动化、实时同步 |
| 多环境隔离 | 独立物理/虚拟环境 | K8s Namespace + GitOps | 资源利用率高、配置统一 |
| 多IDC管理 | 手动维护拓扑 | Karmada/OCM + Cluster API | 多集群编排、声明式 |
| 流量分组 | LVS/Nginx配置 | Istio DestinationRule | 细粒度、动态、可观测 |
| 弹性伸缩 | 提前扩容 | KEDA事件驱动 | 按需伸缩、成本优化 |
| 数据同步 | 定时轮询API | GraphQL + Webhook事件驱动 | 实时、按需、可订阅 |
基于Kubernetes原生对象自动生成服务树
集群分组按维度正交分解
CMDB作为单一事实来源（Source of Truth）
❌ 手动维护服务树
❌ 动态分组配置后忘记回收
❌ 忽视命名规范
❌ CMDB数据同步依赖定时轮询
基于以应用为核心的CMDB，衍生出"应用-集群服务分组-资源"这一运维体系中的核心关系。CMDB不是简单的资产台账，而是连接业务架构与技术架构的枢纽。2025年的CMDB应具备自动化数据采集（Kubernetes原生对象）、声明式API（GraphQL）、事件驱动同步三大能力，真正成为云原生时代的"单一事实来源"（Single Source of Truth）。