Cloud Native 12 Factor

基准代码

从一个代码库部署到多个环境。 一个代码库,包括生产环境软件包,确保了单一的信任源,从而保证了更少的配置错误和更强的容错和复原能力。

依赖

依赖管理是声明式的。 云平台根据这些声明管理依赖,确保云应用所需的库和服务。

配置

配置信息保存在环境中。 环境变量是一种清楚、容易理解和标准化的配置方法,特别适合用不同编程语言编写的无状态应用的使用。

后端服务

将后台服务视为附加的资源。 将每一种资源都视为一种远程的资源,应用因此具有容错和复原能力,因为它一方面要求编码时就要考虑资源不可用的情况,另外一方面也增强微服务方法的好处。

构建、发布、运行

区分构建、发布和运行阶段。 Cloud Native应用的构建流程把大部分发布配置挪到开发阶段,包括实际的代码构建和运行应用所需的生产环境配置。

进程

作为无状态进程运行。 尽量保持应用栈每一层的轻量级,保证Cloud Native基础设施的速度和效率。

端口绑定

通过端口绑定对外暴露服务。 Cloud Native应用的服务接口优先选择 HTTP API 作为通用的集成框架。

并发

通过添加无状态进程实现横向扩展。 强调无状态、无共享的设计,这意味着依赖底层平台就能实现横向扩展,不需要技术难度高的多线程编码。

易处理

快速地启动,优雅地关停。 假设任何进程随时都能启动和关停。

开发环境和线上环境等价

开发、预发布和生产环境运行同样的应用和依赖配置。 由于强调自动化和在每个阶段使用同一个云平台,如果每个人用同样的服务器配置,那么“应用在我这里是可以的”就意味着在其他人或者环境那里也是可以的。

日志

日志输出到标准输出,方便日志聚合和事件响应。 当日志是由云平台而不是应用包含的库处理时,日志处理机制必须保持简单。

管理进程

零时任务作为短时进程运行。 在Cloud Native中,管理任务也是一个进程,而不是特别的工具;同样重要的是,管理任务的进程不应使用秘密的 API 或者内部机制。

0%