2. 服务目录基础：概念、核心组件与策略治理关系
服务目录（Service Catalog）是云原生治理体系中连接基础设施能力与策略合规的桥梁。它通过标准化定义“可被消费的云服务”，使 Policy as Code 规则能够精确绑定到服务版本、配额计划和部署约束上，从而将策略治理从“事后审计”前移到“事前预防”。
2.1 服务目录的核心概念
服务目录本质上是一个受控的服务注册表，它记录了组织内所有可被自助申请或自动化编排的云服务元数据。与传统的 CMDB 不同，服务目录更关注服务的消费接口和治理属性。
| 概念 | 定义 | 与策略治理的关联 |
|---|---|---|
| 服务（Service） | 一个可独立部署和管理的功能单元，如“托管 Kubernetes 集群”、“RDS 实例”、“对象存储桶”。 | 策略规则通过 service.type 标签匹配目标服务。 |
| 版本（Version） | 服务的 API 或配置版本，如 v1、v2beta。不同版本可绑定不同策略集。 |
策略可针对旧版本实施“禁止新建”或“强制升级”规则。 |
| 计划（Plan） | 服务的定价/性能/容量层级，如 small、large、production。 |
策略可限制某些计划的使用范围（如禁止非生产环境使用 production 计划）。 |
| 绑定（Binding） | 服务实例与消费方（应用、项目、团队）的关联关系。 | 策略通过绑定关系判断“谁”在“用什么”服务，实现基于角色的资源约束。 |
关键认知： 服务目录不是静态的 Excel 清单，而是一个可编程的治理边界。每个服务、版本、计划都携带标签（labels）和注解（annotations），Policy Check 引擎正是通过这些元数据来匹配和执行自定义规则。
2.2 核心组件：服务、版本、计划
服务目录的三层模型（Service → Version → Plan）构成了策略治理的最小作用域单元。下面通过一个具体示例说明其结构：
# 服务目录定义示例（YAML 风格）
service:
name: managed-kubernetes
display_name: "托管 Kubernetes 集群"
type: container-orchestration
versions:
- version: v1.24
status: deprecated
plans:
- name: small
spec: { nodes: 3, cpu: 4, memory: 16Gi }
- name: large
spec: { nodes: 10, cpu: 16, memory: 64Gi }
- version: v1.28
status: active
plans:
- name: small
spec: { nodes: 3, cpu: 4, memory: 16Gi }
- name: medium
spec: { nodes: 6, cpu: 8, memory: 32Gi }
- name: large
spec: { nodes: 10, cpu: 16, memory: 64Gi }
在这个模型中，策略规则可以精确到：
- 服务级别： 禁止创建
managed-kubernetes之外的容器编排服务。 - 版本级别： 拒绝使用
v1.24（已弃用）版本创建新集群。 - 计划级别： 仅允许生产环境项目使用
large计划。
实践要点： 在定义服务目录时，建议为每个计划显式声明
allowed_projects 或 denied_teams 标签。这些标签是 Policy Check 规则中 match 语句的直接输入源，能显著减少规则编写量。
2.3 服务目录与策略治理的关系
服务目录为策略治理提供了结构化的上下文。没有服务目录，策略规则只能针对原始云资源（如 VPC、Subnet、Security Group）编写，粒度粗且难以维护。有了服务目录，策略可以上升到业务语义层。
下图展示了服务目录如何作为策略引擎的“数据平面”：
上图展示了三个核心交互流程：
- 元数据注入： 服务目录将服务、版本、计划、绑定等结构化信息传递给 Policy Check 引擎。
- 规则查询与匹配： 引擎根据传入的元数据，在策略规则库中查找匹配的规则（如版本弃用检查、计划配额检查）。
- 决策反馈： 引擎将
允许/拒绝/警告结果返回给服务目录，服务目录据此决定是否执行创建、更新或绑定操作。
常见误区： 不要将服务目录仅仅当作“资源清单”使用。如果策略规则直接写死资源 ID（如
vpc-12345），那么服务目录的版本管理和计划隔离能力就完全被绕过了。正确的做法是：策略规则只引用服务目录的标签和属性，让服务目录成为策略与基础设施之间的“语义适配层”。
2.4 服务目录的治理价值总结
| 治理维度 | 无服务目录 | 有服务目录 |
|---|---|---|
| 策略粒度 | 只能按资源类型（如 AWS::EC2::Instance）粗粒度控制 |
可按服务版本、计划、绑定关系细粒度控制 |
| 策略维护 | 资源属性变化时需同步修改所有相关规则 | 只需更新服务目录定义，策略规则自动适配 |
| 合规审计 | 审计报告需要人工关联资源与业务含义 | 审计日志直接携带服务名、版本、计划等业务标签 |
| 自助服务 | 用户申请资源时容易超出合规边界 | 服务目录在申请阶段即执行策略检查，提前拦截违规 |