12-Factor App

Cloud Native

12-Factor是早些年heroku工程师开发过程中总结的12条构建应用的原则，其核心的方法论为：

  • 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。
  • 和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性。
  • 适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。
  • 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发。
  • 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。

具体来说：

1. Codebase 基准代码

一份基准代码（Codebase），对应一个应用，一个应用可以有多份部署（deploy）。如果多个应用共享一份基准代码，则有悖于12-Factor原则。

2. Dependency 依赖

需要显式声明依赖关系，并通过依赖清单，确切地声明所有依赖项，在运行过程中通过依赖隔离 工具来确保程序不会调用系统中存在但清单中未声明的依赖项。

3. Config 配置

在环境中存储配置。通过环境变量/CMDB将配置排除在代码之外

4. Backing Services 后端服务

把后端服务当作附加资源，不区分远程还是本地

5. Build, Release, Run 构建，发布，运行

严格分离构建，发布，运行三个阶段。

6. Process 进程

以一个或多个无状态进程运行应用，必要的状态都需要被服务化到后端服务，确保进程share-nothing。

7. Port binding 端口绑定

通过端口绑定来提供服务，避免通过IPC等方式来通信，服务间通过服务发现来进行服务通信

8. Concurrency 并发

进程是一等公民，可以通过就水平扩展app来实现并发性，或者通过线程模型进行扩展，确保应用进程的shard-nothing，水平分区特性。

9. Disposability 易处理

应用应当具备快速启动及优雅终止的健壮特性，可以瞬间开启或停止，从而允许系统进行快速弹性扩缩容，同时应当追求最小启动时间，可以快速改变部署和及时故障恢复的特性。

10. Dev/prod parity 开发环境与线上环境等价

保持开发，预发布，线上环境相同

11. Logs 日志

把日志当作事件流，通过集中式的日志服务，执行日志收集、聚合、索引及分析等操作。

12. Admin Processes 管理进程

后台管理任务当作一次性进程运行。一次性管理进程应该和正常的常驻进程 使用同样的环境(代码、配置)，从而避免同步问题，保持一致性。

–

12-Factor原则，基本可以认为是云原生架构下的应用构建方针，按照这种方针，应用构建过程中会非常自然的使用到CNCF云原生定义中代表技术的 容器化、微服务、不可变基础设施、服务网格、声明式API

12-Factor非常强调应用的无状态，比如2，3，4，10。这些原则要求应用对环境进行松耦合，而这部分正式容器化的基石，Docker技术的出现，通过分层镜像机制完成了应用与环境的解耦，进而完成了应用层面的不可变。而随着容器化的深入已经及kubernetes类的容器编排技术的出现，为了更好的满足9的特性，不可变会下沉更底层的基础设施，这样就进一步衍生出了不可变基础设施（Pouch这类富容器显然是违背这类原则的，这也是集团在做去富容器化的根本原因），在不可变基础设施支持的环境中，任意的设施可以被替换，被收容扩容，应用的弹性能力进一步增强。

为了更好的实现9里的弹性能力，应用的启动时间及健壮性品质要求应用尽可能的轻量级及高度自治，因此，微服务乃至Function成为了一等公民。

然而微服务应用的高度自治性带来了固有的复杂性。管理好服务间通信对于保证端到端的性能及可靠性非常重要，因此服务间通信层开始出现，不可变基础设施要求其需要以sidecar的方式存在，于是服务网格类技术出现。

云原生环境下，我们管理（运维）应用类比linux下管理进程，我们应该只关注状态，不关注过程，因此k8s倡导的声明式API成为了我们DevOps的最佳工具。