云原生开发
云原生开发的核心定义、问题域、核心原则、七层技术栈与思维转变。
[!info] related notes
- 所属 MOC: 云原生 MOC
- 前置概念: Docker, microservices
- 并列概念: twelve-factor-app, cloud-native-resilience
- 实践: BodySense 云原生实践 MOC
云原生开发
一句话定义
云原生开发 = 面向自动化部署、弹性扩缩容、故障自恢复、可观测、快速迭代的软件开发方式。
CNCF 定义：云原生实践让组织可以在公有云、私有云、混合云等环境中，以程序化、可重复、可规模化的方式开发、构建和部署工作负载。
云原生解决什么问题？
传统开发流程：
本地写代码 → 打包 → 登录服务器 → 上传文件 → 改配置 → 重启进程 → 出问题看日志 → 手动修这种方式在小项目里没问题，但项目一复杂就会出现：
- 服务越来越多，部署容易乱
- 开发/测试/生产环境不一致
- 服务挂了需要人工重启
- 流量上涨时扩容麻烦
- 出问题后不知道卡在前端、后端、数据库还是第三方
- 版本回滚、灰度发布、配置变更都很危险
云原生就是为了解决这些问题，让系统变成：
- 代码提交后自动测试、自动构建、自动部署
- 应用运行在容器里，环境一致
- 服务挂了平台自动拉起
- 流量高了自动扩容
- 日志、指标、链路追踪统一观测
- 配置、密钥、资源声明式管理
- 部署和回滚可重复、可审计
核心思想
应用要”适合被平台管理”
云原生应用不是只会在某台固定服务器上跑的程序，而是可以被平台调度、复制、销毁、重建的工作负载。
无状态化。 服务不把关键状态存在本机磁盘或内存里。登录态、任务状态、会话状态应放到 Redis、数据库、对象存储、消息队列等外部系统。
配置外置。 不同环境的数据库地址、API Key 不应写死在代码里。12-Factor App 强调配置从代码分离，用环境变量或外部配置管理。
可健康检查。 应用提供 /healthz、/readyz 接口，让平台知道它是”活着""可接流量”还是”正在启动”。
优雅退出。 平台升级、缩容时会给应用发停止信号。应用应处理未完成请求、关闭连接、保存状态，而不是直接崩掉。
日志标准化。 不写本地 log 文件，输出结构化日志到 stdout/stderr，让平台统一收集。
七层技术栈
第 1 层：应用代码层
开发者最直接参与的一层。云原生思维要求：
- 接口稳定，配置外置
- 支持水平扩容
- 任务可重试，错误可观测
- 日志结构化
- 服务间调用有超时、重试、熔断
- 有健康检查接口
- 可被容器化
第 2 层：容器层
容器化之后：“这个镜像里包含运行所需的一切环境，到哪里都能跑。”
核心价值：环境一致、部署可重复、版本明确、回滚简单、适合自动调度。
Docker 不是云原生的全部，只是入口。详见 Docker MOC。
第 3 层：编排层（Kubernetes）
当你只有一个容器，Docker 就够了。但几十个、几百个容器就需要编排平台。
Kubernetes 解决：容器调度、故障重启、多副本部署、滚动更新、服务发现、负载均衡、配置管理、自动扩缩容。
详见 Kubernetes MOC。
第 4 层：CI/CD 层
代码提交 → 自动测试 → 构建镜像 → 推送仓库 → 更新部署 → 滚动发布 → 健康检查 → 观测。
第 5 层：可观测层
一次用户请求可能经过前端 → API Gateway → Go API → Python Agent → 模型服务 → 向量数据库 → PostgreSQL → Redis。必须知道卡在哪里。
三类可观测数据：
- Logs：记录发生了什么
- Metrics：记录系统状态（QPS、错误率、延迟、CPU、内存）
- Traces：记录一次请求经过了哪些服务，每步耗时多少
第 6 层：弹性层
任何东西都会失败。服务会挂、网络会抖、模型 API 会超时、SSE 会断开。
第 7 层：安全层
镜像安全、运行时安全、密钥安全、网络安全、RBAC、供应链安全、API 安全。
云原生 vs 普通开发
| 维度 | 普通开发 | 云原生开发 |
|---|---|---|
| 关注点 | 功能能不能跑 | 功能 + 部署 + 扩容 + 恢复 + 观测 |
| 部署 | 手动上传 | 自动流水线 |
| 环境 | 开发/生产不一致 | 容器化，环境一致 |
| 扩容 | 手动加机器 | 自动扩缩容 |
| 故障 | 人工重启 | 自动恢复 |
| 回滚 | 危险操作 | Git 历史回滚 |
| 观测 | 看日志 | Logs + Metrics + Traces |
微服务不是必须的
云原生经常和微服务一起出现，但它们不是一回事。
微服务是架构拆分方式。云原生是面向云平台的软件构建和运行方式。
一个单体应用也可以是云原生的：容器化、配置外置、日志标准化、健康检查、自动部署、可观测、可水平扩容、无状态。
反过来，拆成 20 个服务但全靠手动部署、没有监控、配置写死，也不算云原生。
云原生与 DevOps
云原生不是单纯开发，也不是单纯运维，而是开发和运维边界融合。
理想方式：
- 平台团队提供 K8s、CI/CD、监控、日志、网关、密钥管理等基础设施
- 业务开发者用标准方式写服务、写配置、交付镜像
- 平台负责自动化运行
这就是 Platform Engineering（平台工程）。
AI Agent 应用的云原生需求
AI Agent 应用天然需要云原生能力，因为通常有：
- 长任务（LLM 调用慢）
- 流式输出（SSE/WebSocket）
- 工具调用链路长
- 模型依赖不稳定
- 状态恢复需求
- 异步队列
- 可观测成本
云原生思维会追问：
- Python Agent 超时怎么办？
- 重复请求会不会创建重复任务？
- 服务重启后任务状态还在吗？
- 调用失败是否可重试？
- 有没有 trace_id / metrics / 限流 / 降级？
- SSE 中断后前端能否恢复？
关键词地图
基础设施层： Cloud、Kubernetes、Container、Docker、OCI、Node、Pod、Cluster
部署层： CI/CD、GitOps、Helm、Kustomize、Argo CD、Flux、Rolling Update、Canary、Blue-Green
应用架构层： Microservices、Stateless、Config、Service Discovery、API Gateway、Event-Driven、Message Queue
稳定性层： Health Check、Readiness、Liveness、Timeout、Retry、Circuit Breaker、Rate Limit、Backpressure
可观测层： Logging、Metrics、Tracing、OpenTelemetry、Prometheus、Grafana、Jaeger、Loki
安全层： Secret、RBAC、Network Policy、Image Scan、Supply Chain Security、Zero Trust
AI Agent 特有层： Run、Thread、Checkpoint、Tool Call、Event Log、Human-in-the-loop、RAG、Model Gateway、Token Usage、Trace