概述
英文版
https://12factor.net/zh_cn/
中文版
https://12factor.net/
这篇文章是Spring Cloud文档的总述部分提到的。12要素指的是构建SaaS应用的方法论的总结，一共有12条。
当得知这12要素是在2011年就提出的时候，我不禁由衷地钦佩。想想11年的时候我[消音–]都在做些啥。。。
从另外一个角度可以学习到的是如何从实践中提炼和总结经验，然后总结为理论。通过“实践-理论-实践-理论”这样的循环，实现螺旋式地提升。
意义
类似“社会主义核心价值观”（手动狗头），12要素对我们的意义主要在对实现的指导性。我们有些时候会觉得当前的代码管理/配置管理/部署方案/运维方案不够好，但又不知道怎么改进；有些时候看到了多种改进方案，但不知道哪一种更好。在这种时候可以参考12要素来决策。
12要素归类
我认为12要素可以粗略分为几类：
代码管理
I. 基准代码/II. 依赖
配置管理
III. 配置/IV. 后端服务
部署
V. 构建，发布，运行/VI. 进程/VII. 端口绑定/VIII. 并发
线上运维
IX. 易处理/X. 开发环境与线上环境等价/XI. 日志/XII. 管理进程
12要素的修订和引申
毕竟是在8年前的2011年提出的，随着技术的发展，也有对12要素提出了一些修订。比如如下这篇：
MRA(Microservices Reference Architecture), Part 5: Adapting the Twelve Factor App for Microservices
主要有以下几点：
- 对于“II. 依赖”，不仅限于类库依赖，还包括部署环境依赖。非容器环境，使用运维管理工具（Chef, Puppet, Ansible）来安装系统依赖；对于容器环境，使用Dockerfile。后面也有几点是基于容器化方案的改进意见。
- 对于“VII. 端口绑定”，将原则扩展到数据隔离。即如果要获取另一个微服务的数据，只能通过API，而不能通过其他方式（例如读取数据库）另外要避免微服务之间有明显的依赖。
反思我们当前不符合12要素的实现
配置
现在的生产配置的加密方式还很粗糙。
另外现在配置还没有实现从环境变量中读取。
以上两点将在实施配置中心后改善。
服务间依赖
部分微服务之间还有明显的依赖，无法避免雪崩效应。后续将引入服务发现和服务注册来改善。
进程无状态
部分应用的登录接口还带有粘性session。这是12-Factor极力反对的。
但避免粘性Session的一个必要条件是保持缓存服务的高可用。后续需要对Redis的高可用进行升级。
日志
日志分析/统计/告警已经迈出了第一步，还有待后续改进措施的实施。