云原生稳定性架构参考 v3.2

来源：AIoT 后端稳定性保障方案 v3.2（二审终稿）审查：5 位专家二轮审查（架构师 8.2/10、SRE 78/100、一线开发 7.5/10、安全、财务）最后更新：2026-05-13 完整方案：02-Projects/AIoT平台稳定性架构/AIoT后端稳定性保障方案-v3.2-二审终稿.md

核心变更（v3.0 → v3.2 共 60 项）

| 变更项 | v3.0 | v3.2 | 原因 | |--------|------|------|------| | 设计原则 | AI-native first | SRE-first, AI-enhanced | 3/5 审查本末倒置 | | 架构分层 | 9 层 | 5 层 | 跨层协调成本高 | | 阶段 1 | 10 个交付物 | 拆 1a+1b，各 4-5 个 | 做不完 | | Karmada | 阶段 2 | 阶段 4+ | 孵化项目不成熟 | | Istio | Ambient 3-6 月 | Sidecar 6-12 月 | Ambient 不成熟 | | Flink | 2.0 | 1.x LTS | .0 不稳定 | | 告警 | ML 替代阈值 | 静态阈值为主 | ML 误报>60% | | On-call | 7×24 | 阶段 1 仅 8:00-22:00 | 不可持续 | | 自愈 | 全自动 | 半自动 + 安全护栏 | 需要成熟 Runbook | | MTTR | <5 分钟 | <10 分钟（四阶段定义） | 不切实际 | | 安全 | 清单级 | 基线清单 9 项 + 护栏 | 多个🔴高危 | | 成本 | 偏乐观 | 修正 + 合规预算 | 严重低估 |

核心技术选型

| 领域 | 推荐 | 备选 | 关键理由 | |------|------|------|---------| | K8s | TKE 托管 | EKS | 阶段 1-2 单云 | | 多集群 | ArgoCD | Karmada（阶段 4+） | 先做好单集群 | | CNI | Cilium | Calico | eBPF + Hubble | | IaC | Terraform + Terragrunt | Pulumi | 运维友好 | | GitOps | ArgoCD | Flux | Manual Sync 先 | | 服务网格 | Istio Sidecar | Cilium Mesh | Ambient 不成熟 | | API 网关 | Apache APISIX + WAF | Kong | 云原生 + 开源 | | 消息队列 | Kafka (KRaft) + SASL_ACL | Pulsar | IoT 吞吐 | | MQTT | EMQX Enterprise | Mosquitto | 百万连接 | | 时序 DB | TDengine（PoC 验证） | TimescaleDB | BI 兼容需验证 | | 数据湖 | Apache Iceberg | Hudi | 阶段 3 引入 | | OLAP | StarRocks | Doris | Join 性能 | | 实时计算 | Flink 1.x LTS | Spark Streaming | LTS 稳定 | | 监控 | VictoriaMetrics | Prometheus | 省 3-5x 资源 | | 日志 | Grafana Loki | ELK | 轻量 | | 链路 | Grafana Tempo | Jaeger | 低成本 | | BI | Apache Superset | Metabase | 开源 | | 混沌 | Chaos Mesh | Litmus | K8s 原生 | | 安全 | Trivy + Snyk + Falco + cosign | Grype | 全链路 | | AI 审查 | CodeRabbit（≤5 条 summary） | GitHub Copilot | MR 聚合 |

设计原则

SRE-first, AI-enhanced — 先做好可观测性→SLO→告警→混沌，AI 是加速器
SLO 驱动 — Error Budget 第一优先级
渐进演进 — 先看见，再守住，然后才智能
多云务实 — 阶段 1-2 单云，按需扩展
安全左移 — 等保合规前置，安全基线先行
运维友好 — 组件数量与团队匹配
AI 引入约束 — 手工流程成熟 ≥3 个月后才引入 AI

落地节奏

安全基线 (1-2 周): K8s 加固 + WAF + 备份 + 脱敏 + ACL + 镜像签名
阶段 1a (0-6 周):  可观测性 + SLO + CI/CD + 基础告警 + 安全基线
阶段 1b (7-12 周):  日志/链路 + On-call + IaC + GitOps + EMQX
阶段 2a (3-4 月):   APISIX + Kafka + StarRocks + AI Code Review + 等保启动
阶段 2b (5-6 月):   Istio Sidecar + Flink + Runbook + 组件健康度
阶段 3  (6-12 月):  Flink + Iceberg + RCA Agent + 自愈 + 等保认证
阶段 4  (12-36 月): 千万级 + 边缘 + 全栈 AIOps + FinOps

成本估算（修正后）

| 阶段 | 总计（月） | 关键变化 | |------|-----------|---------| | 1a | ~ $33, 000 - 35, 000∣ 安全基线 9 项 ∣∣1 b ∣$ 55,000-58,000 | EMQX PoC | | 2 | ~ $92, 000 - 101, 000∣ + E M QX 企业版，云资源修正 ∣∣2 等保一次性 ∣$ 30,000-50,000 | 单独列项 | | 3 | ~ $165, 000 - 188, 000∣ F l ink + I ce b er g + 等保认证 ∣∣4∣$ 235,000-285,000 | 千万级规模 |

关键 Gate Review

| Gate | 条件 | |------|------| | 1a → 1b | VM+Grafana + 3 SLO + 告警 + CI + 第一次 Post-mortem | | 1b → 2a | Loki+Tempo + On-call 运行 ≥2 周 + Terraform + ArgoCD 稳定 + EMQX 10 万 + GameDay | | 2a → 2b | Kafka+StarRocks+Dashboard 稳定 ≥2 周 + 等保差距完成 + AI Review ≥2 周 | | 3 → 4 | 50 万压测通过 + 等保认证 + 可观测性成熟 + 混沌 ≥80% |

P0 升级链

L1: on-call 值班（SRE）
    ↓ 15 分钟未响应
L2: SRE Lead / Tech Lead
    ↓ 15 分钟未响应
L3: CTO / VP

MTTR 四阶段

| 阶段 | 时间 | 说明 | |------|------|------| | Detect | < 2 分钟 | 告警触发 | | Triage | < 3 分钟 | 确认问题 | | Mitigate | < 5 分钟 | 止血/降级 | | Resolve | 不限 | 彻底修复 |

降级架构

| 层级 | 阶段 1-2 | 阶段 3+ | |------|---------|---------| | L1 | 关闭非核心功能 | 同左 | | L2 | 限流 + 429 | 同左 | | L3 | 返回缓存/默认值 | 同左 | | L4 | 设备端 SDK 离线 | 边缘 K3s | | L5 | 跨 AZ 熔断 | 跨云熔断 |

安全基线清单（阶段 1a 前）

K8s Pod Security Standards
NetworkPolicy 默认拒绝
RBAC 最小权限
APISIX WAF 启用
日志脱敏规则
备份策略
多租户隔离
Kafka ACL
AI 安全护栏

需要 CEO 决策

| 决策 | 影响 | 何时 | |------|------|------| | 单云策略 | 年省 ¥500 万+ | 阶段 1 前 | | 阶段 2-3 成本 | ¥92-188 万/月 | 阶段 1b 前 | | SRE 独立建制 | 组织架构 | 阶段 1 前 | | 等保合规 | 一次性 ¥21-55 万 | 阶段 1 前 | | EMQX Enterprise | 年费 ¥50-100 万+ | 阶段 1b PoC |

完整方案含 5 层架构、60 项变更清单、成本估算、合规要求、Gate Review 标准。

📚 喵喵的笔记库

探索

云原生稳定性架构参考-v3.2