为云原生环境设计软件

定义所需行为

云原生实践支持在公有、私有或混合环境中开展可重复的开发和运维。CNCF 强调系统应在变化中保持可管理、可观察和有韧性。容器和编排可以支持这种方式，但单靠它们不能证明具备所有特性。

从一个虚构报表服务开始。AI 工具创建了端点、任务处理进程（worker）和容器镜像。演示生成了正确的 PDF。进入生产前，团队必须回答另一个问题：任务执行期间，平台替换任务处理进程时会怎样？

这既是基础设施问题，也是应用设计问题。重启可能恢复进程，却丢失未完成工作。

原型将排队任务和已完成报表保存在容器磁盘上。替换容器可能同时丢失二者。增加任务处理进程数量后，也可能因接收请求的进程不同而得到不同结果。

修改后的设计使用持久化任务存储和获准的对象存储。请求记录任务标识。任务处理进程领取任务、生成结果并记录结果位置。用户下载报表时，访问检查仍然适用。

关注点	报表服务需要回答的问题
状态	进程替换后，哪些记录必须仍然保留？
配置	同一个制品如何在各环境运行？
身份	哪个服务身份可以读取任务并写入结果？
健康状态	任务处理进程能否接收工作，又能否完成？
停止	任务处理进程停止时，已领取任务会怎样？
容量	哪项限制最先出现：任务处理进程、数据库、存储，还是其他服务？

不要将秘密信息放入镜像。通过获准的秘密信息系统提供它们。记录哪些配置修改需要新发布，或需要重启进程。

假设任务处理进程保存 PDF 后，在确认任务之前停止。队列再次投递任务。第二次尝试不得向客户重复收费，也不得发送互相矛盾的完成消息。

在适当情况下采用幂等操作。重复同一个逻辑请求，应保持预期效果不变。定义稳定的请求标识，持久记录结果，并检查每个故障点会发生什么。AWS 在安全重试指南中介绍了这项技术。

重试也需要限制。使用超时、重试次数上限，以及避免同时重复请求的延迟。保留失败任务供检查，不要无限重试。

声明式配置说明预期部署。控制器负责维持该状态。例如，Kubernetes Deployment 管理应用副本和受控更新。应用仍必须正确处理替换。

为基础设施和应用配置管理版本。通过正常交付流程审查修改。观察实际任务完成情况、队列中任务的等待时间、失败情况和依赖限制。进程即使仍在运行，也可能无法生成报表。

云原生不要求每个应用都拆成微服务。运行在托管运行时上的模块化应用，也可以满足要求。更多服务意味着更多接口、部署决策和运维工作。

向开发智能体提供实际平台约定：受支持的运行时、身份方式、数据服务、部署规则和必要证据。除了成功请求，也测试中断和替换行为。继续学习可用性与故障边界。