管理层概览
Cirrus CDN 面向需要精细掌控源站路由、TLS 自动化与运维可观测性的运营团队，提供可编排的内容分发网络。控制平面由 FastAPI 服务、Redis 配置存储与 Next.js 管理门户构成；数据平面依赖 OpenResty 承载与缓存业务流量。本章概述平台使命、关键利益相关方、差异化优势以及指导原则。
项目背景与目标
随着全球内容分发与边缘计算的迅速普及，传统 CDN 架构在延迟、灵活性与成本控制方面面临瓶颈。企业在应对多地域流量调度、跨云接入、安全合规与智能化运维时，迫切需要一套可自主部署、可二次开发、可持续演进的 CDN 控制体系。
Cirrus CDN 控制平面（以下简称“Cirrus”）旨在提供统一的配置中心、调度引擎与可观测系统；支持跨云、跨地域的节点治理，实现高可用、高自治的内容分发。
平台差异化能力
- 端到端自动化：ACME 申请与续签内建于控制平面，由 Celery worker 执行，消除零散脚本。
- 集成式权威 DNS：系统合成权威 DNS 区域（隐藏主节点 + NSD 从节点），使用一致性哈希将流量引导至健康边缘节点。
- Redis 配置中心：所有可变状态——域名、节点、证书、缓存清理队列——均存于 Redis，具备原子更新、发布订阅与易于排查的特性。
- 前端与 API 一体化：Next.js 管理门户与外部客户端调用同一套 REST API，确保手动与自动流程一致。
- 可观测性优先：OpenResty 输出 Prometheus 指标，健康检查刷新节点状态，日志自动轮转；这些能力在设计中被优先考虑。
指导原则
- 运营透明：API、DNS、边缘、自动化各子系统倾向于使用可观测的 Redis 键与显式动作，避免隐式行为。
- 确定性行为：通过一致性哈希、带锁的 ACME 流程与幂等 API 规避竞态条件。
- 默认安全：密码使用 Argon2 哈希、令牌为 SHA-256 哈希、TLS 证书仅存在于 Redis/边缘内存，主令牌控制特权操作。
- 易于扩展：基于 Docker 的部署与模块化 Python/Lua 组件，便于替换外部集成（如扩展 DNS 从节点或新增指标后端）。
- 提升开发效率：
justfile固化常用流程（just up、just pytest、just deploy），帮助贡献者保持一致实践。
核心价值
| 维度 | 传统 CDN 痛点 | Cirrus 价值 |
|---|---|---|
| 架构灵活性 | 配置割裂、中心化控制 | 模块化设计 + 控制平面可自托管 |
| 调度智能性 | 静态策略滞后、地域粒度粗 | 基于健康感知的一致性哈希与动态副本分配 |
| 可观测性 | 缺乏端到端可追踪 | Prometheus 指标 + 结构化日志，覆盖 API/DNS/边缘 |
| 合规安全 | 数据出境风险高 | 私有部署、本地证书托管、令牌哈希存储 |
| 运维效率 | 手工操作多、可重复性差 | ACME 自动化、确定性缓存清理、模板化发布 |
适用场景与目标用户
- 适用场景：
- 企业级私有 CDN（金融、医疗、政企）
- 跨境与多云接入
- IoT 与边缘应用
- 内容分发与视频加速
- 目标用户：
- 中大型企业 IT 团队
- 数据安全要求高的组织
- 混合云/边缘应用开发者与厂商
- 基础设施提供商
竞争与差异化定位
Cirrus 的定位是面向工程主导团队的自托管 CDN 控制平面，强调数据主权、自动化与可扩展性。它与托管型 CDN 形成互补：保留私有部署与精细运维控制，同时保持 API 优先。
| 对比维度 | Cirrus CDN | 托管型 CDN（Cloudflare、AWS、阿里云） |
|---|---|---|
| 部署形态 | 自托管或混合 | 全托管 |
| 控制平面所有权 | 团队自有 | 供应商 |
| 数据主权 | 本地托管 | 云/区域托管 |
| 自动化 | 内建 ACME，API 优先流程 | 依产品而异 |
| 可观测性 | Prometheus + 结构化日志 | 各产品自带工具 |
| 成本模型 | 基础设施+带宽，可控 | 按 GB/请求计费 |
关键 KPI 示例（参考值）
参考值汇总自公开的 NGINX/OpenResty 基准（见 nginx-openresty_performance.csv）。
| 指标 | 参考值 |
|---|---|
| HTTP QPS（1KB，缓存静态） | ≈ 131 万 rps（32–36 workers） |
| HTTPS QPS（1KB，缓存静态） | ≈ 124 万 rps（36 workers） |
| TLS TPS（每次请求新握手） | ≈ 5.8 万 tps（Ingress，24 workers） |
| 1MB 对象吞吐 | ≈ 8.8 Gbps（≥ 4 workers） |
如何解读这些样例指标
- 数值为公开基准的参考值；请在目标硬件与业务上验证。
- 比较缓存前后 p95 延迟，量化缓存收益。
- 持续跟踪一周内缓存状态分布的趋势变化。
更多规模指标（依环境而定）
| 指标 | 如何衡量 | 说明 |
|---|---|---|
| 单节点 QPS（缓存流量） | Prometheus nginx_http_requests_total | 主要受 CPU 约束；请在目标硬件上验证。 |
| 并发连接 | worker_processes * worker_connections | 默认 auto * 1024；可在构建时调优。 |
| 延迟下降 | p95 nginx_http_request_duration_seconds vs 源站 RTT | 命中应显著消除源站 RTT。 |
| TLS 稳定性 | nginx_ssl_handshake_errors_total | 应接近 0。 |
文档阅读指引
以下章节分别介绍各子系统，可按需跳转：
文中会交叉引用代码路径（例如 control-plane/src/cirrus/app.py:21 的 API 启动流程），以确保与仓库实现保持一致。
未来迭代路线图
- Celery 指标导出：通过 Prometheus 输出 worker/beat 任务耗时与结果，补齐可观测性。
- 会话存储迁移至 Redis：将内存会话迁移至 Redis，支撑 API 无状态横向扩展。
- 托管/集群 Redis：支持高可用部署与故障切换演练。
- 扩展 DNS 功能：在保持一致性哈希稳定性的前提下，增加地理覆写与更多记录类型。
- Webhooks 与审计：支持外发 Webhooks 与追加式审计日志。
- 边缘能力：引入 Origin Shield、按路径预取、更丰富的缓存规则谓词。
- 安全加固：令牌分级/过期、可选客户端 TLS、生产环境可配置的 CORS。