99 · Reference Architecture · 标准参考架构

一份长期沉淀的"这套系统应该长什么样"，每个模块给出选型 + 备选 + 迁移路径。

一、全景架构图

                        [ Internet / Public ]
                                │
                    ┌───────────▼───────────┐
                    │    Cloudflare CDN     │  ← DDoS + WAF + Global
                    └───────────┬───────────┘
                                │
                    ┌───────────▼───────────┐
                    │       Nginx           │  ← TLS + LB
                    └───────────┬───────────┘
                                │
                    ┌───────────▼───────────┐
                    │      API Gateway      │  ← Auth + Rate Limit
                    │       (FastAPI)       │     Billing + Routing
                    └───────────┬───────────┘
                                │
        ┌───────────────────────┼───────────────────────┐
        │                       │                       │
        ▼                       ▼                       ▼
   [ Scheduler ]           [ Queue ]              [ Metering ]
   Kubernetes         Redis Streams              Kafka / PG
   + Volcano
        │                       │                       │
        ▼                       ▼                       ▼
    [ vLLM Cluster ]      [ Cache ]              [ Storage ]
    vLLM / SGLang       Redis + KV Pool        MinIO / NFS
    TRT-LLM               Prefix Cache          Model Repository
        │
        ▼
    [ GPU Pool ]
    NVIDIA H100/H200/H800
    RTX 5090 (dev/spot)
        │
        ▼
    [ Physical Layer ]
    IDC / 液冷 / 高密柜

    横向支持：

    ┌─ Monitoring ─┐    ┌─ Data Layer ─┐    ┌─ Security ─┐
    │ Prometheus   │    │ PostgreSQL   │    │ Vault      │
    │ DCGM         │    │ ClickHouse   │    │ Cloudflare │
    │ Grafana      │    │ Kafka        │    │ WAF        │
    │ Loki         │    │ Loki         │    │ Audit Log  │
    │ Tempo        │    │ Grafana      │    │ Snort      │
    └──────────────┘    └──────────────┘    └────────────┘

二、每层组件选型（选型 + 备选 + 理由）

Layer 1：Edge（CDN / DDoS / WAF）

选型：Cloudflare

• 备选：AWS CloudFront + Shield / 阿里云 CDN + 高防 IP
• 理由：免费级好、全球覆盖、DDoS 天花板高
• 迁移路径：Cloudflare → 阿里云（国内合规压力时）

Layer 2：反向代理 / LB

选型：Nginx

• 备选：Caddy（自动 TLS 简单）/ Envoy / Traefik
• 理由：稳、社区大、性能好、大家熟
• 迁移路径：Nginx → Envoy（规模大时更好观测）

Layer 3：API Gateway

选型：FastAPI（Python 自研）

• 备选：APISIX / Kong / Higress
• 理由：与 vLLM 生态一致、上手快、可读性好
• 迁移路径：FastAPI → APISIX（QPS > 5000 时）

Layer 4：调度 / 编排

选型：Kubernetes + Volcano + NVIDIA GPU Operator

• 备选：Slurm（HPC）/ Ray / Docker Swarm
• 理由：云原生标准、Volcano 支持 gang scheduling + 优先级抢占
• 迁移路径：K8s → K8s + Karmada（跨集群）

Layer 5：推理引擎

选型：vLLM 为主，SGLang 补长上下文，TensorRT-LLM 补低延迟

• 备选：TGI（不推荐）/ LMDeploy（国产选项）
• 理由：见 02-Plan-B-Token-MaaS/comparison-engines.md
• 迁移路径：vLLM 主 → 多引擎路由 → 自研引擎（可选，长期）

Layer 6：队列 / 消息

选型：Year 1 Redis Streams，Year 2 Kafka

• 备选：RabbitMQ / NATS / PostgreSQL LISTEN/NOTIFY
• 理由：早期简单，规模化用 Kafka
• 迁移路径：Redis → Kafka

Layer 7：主数据库

选型：PostgreSQL 16

• 备选：MySQL 8 / CockroachDB
• 理由：JSONB 灵活、事务强、社区大
• 迁移路径：PG 单机 → PG 主从 → CockroachDB / TiDB（多区）

Layer 8：缓存

选型：Redis 7

• 备选：KeyDB / Dragonfly
• 理由：全能、社区大
• 迁移路径：Redis Standalone → Redis Cluster

Layer 9：分析仓库

选型：ClickHouse

• 备选：Doris / StarRocks / BigQuery / Snowflake
• 理由：性能强、成本低、开源
• 迁移路径：ClickHouse Single → Cluster → 云服务

Layer 10：对象存储

选型：MinIO（自建）or 阿里云 OSS

• 备选：Ceph（更复杂）/ AWS S3 兼容任意
• 理由：MinIO 起步便宜、S3 兼容
• 迁移路径：MinIO → 阿里 OSS + MinIO 缓存

Layer 11：文件存储

选型：Year 1 NFS，Year 2 JuiceFS，Year 3 Weka（可选）

• 备选：CephFS / GPFS / Lustre
• 理由：早期够用，规模化性能升级
• 迁移路径：NFS → JuiceFS → Weka

Layer 12：网络

选型：Cilium（eBPF）

• 备选：Calico / Flannel
• 理由：eBPF 现代、可观测、性能强
• 迁移路径：Calico（初期）→ Cilium（成熟后）

Layer 13：监控 / Metrics

选型：Prometheus + Grafana

• 备选：VictoriaMetrics（大规模）/ Datadog（商业）
• 理由：开源标配
• 迁移路径：Prometheus → VictoriaMetrics（当基础 Prom 撑不住）

Layer 14：日志

选型：Loki + Promtail

• 备选：ELK / Vector + ClickHouse
• 理由：轻量、Grafana 一体化
• 迁移路径：Loki 单实例 → 集群 → 分离存储

Layer 15：Tracing

选型：Tempo / Jaeger

• 备选：Zipkin / SkyWalking
• 理由：Grafana 一体化
• 迁移路径：Tempo → OpenTelemetry Collector

Layer 16：密钥

选型：HashiCorp Vault OSS

• 备选：Bitwarden / AWS KMS / 阿里 KMS
• 理由：开源标配、HSM 支持
• 迁移路径：Vault OSS → Vault Enterprise（合规需要）

Layer 17：CI/CD

选型：GitLab CI + ArgoCD

• 备选：GitHub Actions + Flux / Jenkins
• 理由：GitOps 现代实践
• 迁移路径：初期直连 → GitOps

Layer 18：门户前端

选型：Next.js + React + Tailwind CSS

• 备选：Vue + Nuxt / SolidJS / SvelteKit
• 理由：生态大、招人易
• 迁移路径：Vercel 托管 → 自建 Nginx

三、扩展决策清单

什么时候上 K8s？

• < 100 卡：systemd + docker 够
• ≥ 100 卡：必上 K8s

什么时候上 Kafka？

• < 100 QPS：Redis Streams 够
• ≥ 500 QPS：必上 Kafka

什么时候上 ClickHouse？

• < 1000 万条 / 月：PG 直接查
• ≥ 1000 万条：必上 ClickHouse

什么时候上多 Region？

• 单 Region 满载 70%+
• 或客户对延迟 / 合规有跨区要求

什么时候上液冷？

• 单柜功耗 > 30kW
• 或 PUE 需要压到 1.2 以下

四、迁移路径总表

40 卡      →  100 卡         →  1000 卡        →  10000 卡

systemd    →  K8s            →  K8s + Volcano →  K8s + Karmada
Nginx      →  Nginx          →  Nginx / Envoy →  APISIX
FastAPI    →  FastAPI        →  APISIX        →  Go 网关
PG single  →  PG 主从        →  PG 分片        →  CockroachDB
Redis      →  Redis Cluster  →  Redis Cluster →  Redis Cluster
无 Kafka   →  Redis Streams  →  Kafka          →  Kafka Cluster
无 CH      →  ClickHouse     →  ClickHouse     →  ClickHouse Cluster
NFS        →  JuiceFS        →  JuiceFS        →  Weka + JuiceFS
Calico     →  Calico         →  Cilium         →  Cilium
无 Vault   →  Vault OSS      →  Vault Enterprise → Vault Enterprise

五、"为什么不用 XX"（常见问题）

Q：为什么不用 Kong 而用 FastAPI？

• A：Kong 学习成本 + 定制复杂。40 卡阶段 FastAPI 一天就搭起来，规模化再切。

Q：为什么不用 Ray？

• A：Ray 适合分布式训练，推理服务 Vollm + K8s 更成熟。

Q：为什么不用 Milvus / Weaviate？

• A：本平台不做 RAG 后端，客户 RAG 后端自己搞。

Q：为什么不用 Nvidia Triton？

• A：Triton 通用，但 LLM 场景 vLLM 优化更专。

Q：为什么不上 Serverless？

• A：GPU 冷启动几十秒，Serverless 体验差。除非纯批量场景。

Q：为什么用 MinIO 而不是 Ceph？

• A：40 卡阶段 Ceph 部署运维成本太高。

六、关键判断

架构不是一次做对的，是一路演进的。

三个原则：

1. 能用现成就用现成（开源 + SaaS）
2. 可迁移比最优选更重要（今天选的东西 3 年后可能不适用）
3. 每次扩容都是重新评估的时机

别做的：

• 别一开始就设计万卡架构（40 卡阶段用不上）
• 别自研核心组件（vLLM / K8s / Redis 别改造）
• 别追求微服务潮流（40 卡阶段单体够）

最大 ROI：一份好的架构文档 = 团队对齐 + 招人加分 + 融资加分。