3. 服务目录平台架构：服务注册、服务发现、服务依赖关系、元数据管理
服务目录平台是现代微服务与云原生体系中的“服务百科全书”。它不仅要记录服务的基本信息，还需要承载服务注册、动态发现、依赖拓扑以及元数据治理等核心能力。在 Kyverno 策略驱动的基线核验场景中，服务目录平台是策略评估的数据源与执行锚点——策略引擎需要从目录中获取服务标签、命名空间、暴露端口、依赖链等信息，才能判断部署是否合规。
3.1 核心架构分层
服务目录平台通常采用四层逻辑架构，每一层对应不同的职责与数据模型：
| 层级 | 核心职责 | 关键组件 / 数据 | 与 Kyverno 策略的关联 |
|---|---|---|---|
| 接入层 | 提供 API 网关、gRPC/HTTP 端点，供服务实例注册与查询 | 注册 API、心跳接口、查询 API | 策略可拦截注册请求，校验服务标签是否合规 |
| 存储层 | 持久化服务实例、元数据、依赖关系 | etcd / 关系数据库 / 图数据库 | 策略引擎通过 CRD 或 API 读取存储层数据 |
| 计算层 | 服务发现、健康检查、依赖拓扑计算 | 服务发现模块、拓扑引擎、健康检查器 | 拓扑数据用于策略中的依赖合规校验 |
| 治理层 | 元数据管理、版本控制、策略执行 | 元数据注册表、版本管理、策略执行点 | Kyverno 策略直接作用于治理层定义的基线 |
架构要点： 在云原生环境中，服务目录平台通常以 Operator 或 CRD 的形式运行在 Kubernetes 集群内，存储层直接使用 etcd，计算层与治理层通过自定义控制器实现。Kyverno 策略可以监听这些 CRD 的变更事件，实现“注册即校验”。
3.2 服务注册与发现机制
服务注册是目录平台的数据入口，服务发现是目录平台的价值出口。两者构成闭环：
- 服务注册： 服务实例启动时，向目录平台发送注册请求，包含服务名称、命名空间、端点地址、端口、健康检查路径、标签集合等。注册信息写入存储层，并设置 TTL 用于心跳续约。
- 服务发现： 消费者服务通过目录平台查询目标服务的可用实例列表。平台返回健康实例的端点集合，支持轮询、长轮询或 Watch 机制。
- 健康检查： 目录平台定期对已注册实例发起健康探测（HTTP / TCP / gRPC），不健康的实例自动从发现结果中摘除。
基线核验场景： Kyverno 策略可以定义“所有服务必须注册到目录平台”的规则。如果某个 Deployment 的 Pod 启动后未在指定时间内完成注册，策略引擎可以触发告警或阻止流量接入。
3.3 服务依赖关系管理
服务依赖关系是服务目录平台中最重要的关系型数据之一。它描述了服务之间的调用链路、数据流向以及依赖强度。在基线核验中，依赖关系用于：
- 合规性检查： 策略可以规定“核心支付服务不得依赖外部非认证服务”。
- 变更影响分析： 当某个服务版本升级时，目录平台可以列出所有下游依赖方。
- 熔断与限流策略： 依赖关系图帮助确定熔断优先级。
依赖关系的存储通常采用 有向图 模型，每个服务是一个节点，每条调用关系是一条有向边。目录平台提供拓扑查询 API，支持按服务名、命名空间、版本等维度过滤。
| 依赖类型 | 描述 | 示例 | 策略关注点 |
|---|---|---|---|
| 强依赖 | 调用失败会导致本服务功能不可用 | 订单服务 → 库存服务 | 强依赖服务必须满足高可用基线 |
| 弱依赖 | 调用失败仅影响部分非核心功能 | 订单服务 → 推荐服务 | 弱依赖允许降级，但需记录 |
| 异步依赖 | 通过消息队列解耦，非实时调用 | 订单服务 → 消息队列 → 物流服务 | 异步依赖需校验消息可靠性 |
| 外部依赖 | 调用集群外部的第三方服务 | 支付服务 → 银行 API | 外部依赖必须经过安全认证 |
基线核验风险点： 如果服务目录平台中的依赖关系数据不准确（例如遗漏了某个强依赖），Kyverno 策略将基于错误数据做出错误判断。因此，依赖关系必须通过运行时调用链自动采集，而非人工维护。
3.4 元数据管理
元数据是服务目录平台中除注册信息外的“附加属性”，用于描述服务的非功能性特征。元数据通常以键值对（Label/Annotation）的形式存储，是 Kyverno 策略评估的核心数据源。
常见的元数据分类：
- 业务元数据： 服务所属业务域、负责人、SLA 等级、PII 标识。
- 技术元数据： 编程语言、框架版本、容器镜像地址、暴露端口协议。
- 运维元数据： 部署环境（prod/staging）、金丝雀标识、日志采集开关、监控 Dashboard 链接。
- 合规元数据： 数据分类等级、加密要求、审计日志保留天数。
3.5 元数据与策略的映射关系
在 Kyverno 策略驱动的基线核验中，元数据是策略规则的“输入变量”。以下表格展示了常见元数据字段与策略规则的映射：
| 元数据字段 | 策略规则示例 | 核验动作 |
|---|---|---|
compliance-level |
如果 compliance-level == L4，则必须启用 mTLS | 检查 Service 是否配置了 mTLS Annotation |
data-classification |
如果 data-classification == PII，则日志必须脱敏 | 检查日志采集配置是否包含脱敏规则 |
sla-tier |
如果 sla-tier == gold，则副本数必须 ≥ 3 | 校验 Deployment 的 replicas 字段 |
exposed-protocol |
如果 exposed-protocol == http，则必须配置 Ingress TLS | 检查 Ingress 资源是否包含 tls 段 |
dependency-list |
禁止依赖 compliance-level < L2 的服务 | 查询依赖服务的元数据并做比较 |
最佳实践： 建议在服务目录平台中为每个服务维护一个
metadata.labels 集合，与 Kubernetes 资源的 Label 保持一致。这样 Kyverno 策略可以直接通过 labelSelector 匹配目标服务，无需额外转换。
3.6 架构总结
服务目录平台的架构设计直接影响 Kyverno 策略的核验精度与执行效率。四个核心能力——服务注册、服务发现、依赖关系、元数据管理——构成了策略引擎的数据底座。在实际落地中，建议：
- 将服务目录平台以 CRD 形式部署在 Kubernetes 集群内，与 Kyverno 共享 etcd 存储。
- 依赖关系通过 Service Mesh（如 Istio）的调用链数据自动生成，避免人工维护。
- 元数据 Schema 由平台团队统一定义，并通过 Kyverno 策略强制校验元数据的完整性。