2. 服务目录平台架构总览：分层架构设计
服务目录平台作为云原生环境下的“服务注册中心”与“治理策略中枢”，其架构设计必须兼顾高可用、可扩展与安全隔离。本章采用经典的四层分层架构模型，将平台拆解为接入层、服务层、数据层与基础设施层，每层职责清晰、解耦独立，便于团队并行开发与运维。
架构设计原则： 每一层仅通过定义良好的 API 与下层通信，上层不感知下层实现细节。这种设计使得替换数据库、升级网络策略引擎或更换前端框架时，不会影响其他层。
2.1 四层架构总览
下图展示了服务目录平台的整体分层结构及各层核心组件。从用户请求入口到最终的数据持久化与网络策略执行，流量自上而下逐层处理。
2.2 各层职责详解
| 架构层 | 核心职责 | 关键组件 | 与 Cilium 的关系 |
|---|---|---|---|
| 接入层 | 统一流量入口、认证鉴权、限流、TLS 卸载 | Kong / APISIX / Nginx | 通过 Cilium 策略限制入口流量来源 |
| 服务层 | 服务注册发现、健康检查、策略编排、准入控制 | Service Registry、Policy Engine、Cilium Admission Webhook | 直接调用 Cilium API 生成网络策略 |
| 数据层 | 元数据持久化、缓存加速、集群状态存储 | PostgreSQL、Redis、etcd | 存储 Cilium 策略规则与审计日志 |
| 基础设施层 | 容器编排、网络通信、安全策略执行 | Kubernetes、Cilium CNI、eBPF | 作为策略执行面，承载所有网络规则 |
2.3 接入层：统一流量入口
接入层是平台对外的唯一门户，所有客户端请求（CLI、Web UI、第三方 API 调用）均通过此层进入。该层主要承担以下职责：
- 身份认证与授权： 验证请求方身份（JWT / OAuth2 / mTLS），拒绝未授权访问。
- 请求路由： 根据请求路径与版本号，将流量转发至服务层对应微服务。
- 限流与熔断： 防止突发流量冲垮后端服务，保障平台稳定性。
- TLS 终止： 卸载 HTTPS 加密，降低后端服务处理开销。
实践建议： 在接入层配合 Cilium 的
NetworkPolicy 限制仅允许特定来源 IP 或 ServiceAccount 访问 API Gateway，实现“入口安全前置”。
2.4 服务层：核心业务逻辑
服务层是平台的大脑，包含所有业务逻辑与策略编排能力。该层由多个微服务组成，彼此通过 gRPC 或 REST API 通信。
2.4.1 核心子服务
| 子服务 | 功能描述 | 关键接口 |
|---|---|---|
| Service Registry | 管理服务注册、元数据存储、版本追踪 | RegisterService()、DiscoverService() |
| Health Checker | 定期探测服务健康状态，更新可用性标记 | CheckHealth()、GetStatus() |
| Policy Engine | 编排 Cilium 网络策略，生成策略 YAML | GeneratePolicy()、ValidatePolicy() |
| Admission Webhook | 拦截 Pod 创建请求，动态注入网络策略 | Mutate()、Validate() |
| Audit Logger | 记录所有策略变更与操作日志 | LogEvent()、QueryLog() |
2.4.2 服务层与 Cilium 的深度集成
服务层中的 Policy Engine 与 Admission Webhook 是连接平台与 Cilium 的关键桥梁：
- 策略生成： Policy Engine 根据服务注册信息自动生成 Cilium
CiliumNetworkPolicy或CiliumClusterwideNetworkPolicy资源。 - 准入控制： Admission Webhook 在 Pod 创建时动态注入标签与策略注解，确保新服务立即受到安全策略保护。
- 策略验证： 在应用策略前，通过 Cilium 的
cilium policy validate接口进行语法与语义校验，避免错误策略导致网络中断。
2.5 数据层：持久化与缓存
数据层负责存储平台运行所需的所有持久化数据，采用读写分离与缓存加速策略保障高性能。
| 存储组件 | 存储内容 | 访问模式 | 高可用方案 |
|---|---|---|---|
| PostgreSQL | 服务元数据、策略规则、审计日志、用户信息 | 读写频繁，强一致性要求 | 主从复制 + Patroni 自动故障切换 |
| Redis | 服务缓存、会话状态、限流计数器 | 读多写少，毫秒级响应 | Redis Sentinel / Cluster |
| etcd | 集群状态、服务发现元数据、分布式锁 | 强一致性，低延迟写入 | etcd 集群（Raft 协议） |
注意： Cilium 自身的策略状态存储在 Kubernetes 的 etcd 中，但服务目录平台的数据层会额外维护一份策略规则副本用于审计与回滚。两者之间通过 Policy Engine 保持最终一致性。
2.6 基础设施层：Kubernetes + Cilium
基础设施层是平台运行的底座，提供容器编排、网络通信与安全策略执行能力。Cilium 作为 CNI 插件与网络策略引擎，是这一层的核心组件。
2.6.1 基础设施层关键能力
- Kubernetes 集群： 提供 Pod 调度、服务发现、自动扩缩容等基础能力。
- Cilium CNI： 基于 eBPF 实现高性能网络数据面，替代传统 iptables 模式。
- Cilium Network Policy： 支持 L3/L4/L7 层网络策略，实现精细化访问控制。
- Hubble： 提供网络流量可观测性，用于策略效果验证与故障排查。
- 服务网格集成： 可与 Istio 集成，提供 mTLS 与灰度发布能力。
2.6.2 Cilium 在基础设施层的位置
下图展示了 Cilium 在 Kubernetes 节点内的部署架构，以及它与服务目录平台各层的交互关系。
2.7 分层架构的优势
| 优势 | 说明 | 实际收益 |
|---|---|---|
| 解耦独立 | 每层职责清晰，可独立开发、测试、部署 | 团队并行开发效率提升 40%+ |
| 弹性扩展 | 各层可独立水平扩缩容 | 接入层与服务层按需扩展，数据层通过读写分离提升吞吐 |
| 安全隔离 | 每层可配置独立的网络策略 | 通过 Cilium 实现微隔离，限制东西向流量 |
| 技术栈灵活 | 每层可选用最适合的技术组件 | 接入层用 Nginx，服务层用 Go/Java，数据层用 PostgreSQL + Redis |
| 故障隔离 | 单层故障不影响其他层 | 数据层主从切换时，服务层仍可提供缓存数据 |
架构总结： 服务目录平台的四层架构设计充分体现了“关注点分离”原则。接入层负责流量治理，服务层承载业务逻辑，数据层保障数据可靠，基础设施层提供运行底座。Cilium 作为基础设施层的核心组件，通过 eBPF 技术实现高性能网络策略执行，并与服务层的 Policy Engine 和 Admission Webhook 深度集成，形成“策略编排 → 策略下发 → 策略执行 → 策略审计”的完整闭环。