一、为什么要用十二要素来审视云原生应用¶

云原生十二要素本质上是一组关于应用设计、交付和运行方式的实践准则。

它的价值在于帮助我们回答三个关键问题：

• 应用是否足够标准化，能否稳定交付到不同环境。
• 应用是否足够解耦，能否适应弹性扩缩容和实例替换。
• 应用是否足够自动化，能否被平台高效治理。

如果一个应用连这些基础条件都不满足，那么即使放进 Kubernetes，也很难真正发挥云原生平台的价值。

二、云原生十二要素逐条拆解¶

2.1 一份基准代码，多份部署¶

一个应用应该对应一个代码仓库，再通过不同配置适配开发、测试和生产环境。这样可以避免多仓库复制代码，确保版本管理一致。

2.2 显式声明依赖¶

所有依赖项和版本都应该通过 Maven、npm、Gradle 等工具明确声明，减少环境差异带来的运行问题，并为容器化构建提供稳定基础。

2.3 在环境变量中存储配置¶

数据库连接、API 密钥等配置应与代码分离，通过环境变量或配置中心管理，避免把环境差异硬编码进仓库或镜像。

2.4 把后端服务当做附加资源¶

数据库、缓存、消息队列等都应视为独立资源，通过网络进行访问，而不是与应用强耦合打包在一起。

2.5 严格分离构建、发布和运行¶

构建阶段产出制品，发布阶段注入配置，运行阶段启动应用。这样才能通过 CI/CD 流水线稳定交付，避免直接改生产代码。

2.6 应用无状态化¶

进程不保存关键本地状态，会话数据存放到 Redis 或数据库等外部服务里，从而支持水平扩展和实例替换。

2.7 通过端口绑定来提供服务¶

应用应自包含服务能力，直接通过端口对外提供访问，而不是过度依赖外部服务器注入运行环境。

2.8 通过进程模型进行扩展¶

扩展优先考虑增加实例数量，而不是只提升单机硬件配置，这样更符合云平台和 Kubernetes 的弹性伸缩方式。

2.9 快速启动和优雅终止¶

应用需要具备秒级启动能力，并能处理终止信号，在滚动更新、迁移和缩容时安全释放资源。

2.10 运行环境一致性¶

开发、测试和生产环境应保持高度一致，尤其是依赖版本和操作系统层面。容器化是实现一致性的关键手段之一。

2.11 日志当做事件流¶

日志应输出到标准输出，由外部日志系统统一收集和分析，而不是把日志散落在本地文件中。

2.12 后台管理任务当作一次性进程运行¶

数据迁移、初始化脚本和后台管理任务应作为独立进程执行，例如 Kubernetes Job，而不是混入主服务进程。

三、云原生应用有哪些基础最佳实践¶

除了十二要素之外，开发云原生应用时还应尽量做到下面这些实践：

• 应用日志直接输出到控制台。
• 应用数据不要直接写在本地。
• 应用配置与代码严格分离。
• 服务治理尽量借助云平台或平台侧能力实现。
• 应用优先微服务化。
• 应用具备容器化能力。
• 提供可靠的健康检查接口。
• 提供 Metrics 接口，方便平台做监控和自动化治理。

这些实践和十二要素并不冲突，可以把它们理解为更贴近平台落地的一组执行清单。

四、什么是云原生 AI（CNAI）¶

CNCF 官方链接：https://landscape.cncf.io/?group=cnai

云原生人工智能（CNAI）是指使用云原生技术构建和部署人工智能应用与工作负载。

它的核心不是简单地“把 AI 跑在云上”，而是把 AI 与云原生技术组合起来，例如：

• 容器化
• 微服务
• DevOps
• 平台自动化交付

最终目标是让 AI 应用的开发、部署与运维更高效、更灵活、更可靠。

五、为什么学习云原生的人也要关注 AI 工作负载¶

随着 AI 应用和大模型推理逐渐平台化，未来很多企业平台都会同时承载传统业务服务和 AI 工作负载。

这意味着：

• 平台不仅要管理容器化业务应用，也要管理模型服务和数据处理任务。
• 交付流程不再只服务 Web 系统，还要服务训练、推理和批处理任务。
• 资源治理会从 CPU、内存进一步扩展到 GPU、存储和更复杂的弹性调度。

因此，理解 CNAI 的意义，不只是了解一个新名词，而是提前看到云原生平台未来的演进方向：从承载应用，走向承载更广义的智能化工作负载。