这是在做微服务时经常被提及的一套原则，提出者具有很多Cloud上微服务的开发经验，主要在Heroku平台上的应用开发，所以有很高参考价值。我在读完这12条原则后，感觉还是非常认同的，特别是对于刚起步做微服务的团队来说非常有指导意义。官网链接: https://12factor.net/
保持App和代码库是1：1关系。这里“代码库”可以理解为Git里面的一个Repository。一份代码，多处部署。并不是说多个部署跑的版本都是一样的，完全可以例如D上跑最新的代码；Q上跑在测试的次新的代码；P上跑比较老但是很稳定的代码。
我们的程序不要偷偷去依赖一些东西，哪怕它一定存在于绝大多数操作系统层面，要把这种依赖声明出来。不同操作系统之间甚至同样系统的不同版本之间的差异是我们没法提前预知的，一旦它们给我们的应用造成影响那我们面对的可能是一堆操作系统级别或是很奇怪的log，解决起来比较劳神。如果能详细明示依赖，发生问题时应用会以更容易理解的形式报警：如在编译或部署时告诉我们缺少依赖ABC。
把程序中使用的配置信息通过环境变量来存，而不是具体的文件。优点包括：
灵活，不同环境只需改环境变量，代码不动 保密，配置不公开，避免放在代码库被看到很多Spring的application.properties内容可以移到环境变量，技术性信息如DB Driver等还是可以放在文件里。
力求让“服务”非常容易替换，如数据库、邮箱等。无论第三方还是自有服务都应保持可替换性。理想状态下，不用改代码，只需系统管理员操作即可替换服务。这是微服务的重要原则：独立性、可替换性。
项目中要严格划分这三个阶段：
构建：程序打包过程
发布：将打包程序结合配置，准备上线，需有唯一版本号
运行：启动某个版本，自动化恢复等，线上版本选择一般需人工
程序应假设所有请求都是无状态的，不依赖进程内缓存或状态数据，除非是明确持久化的数据。
这样程序更简单，服务器负担减轻，健壮性更好。但对开发理念有冲击，尤其是习惯session开发的同学。
要求：
应用应内嵌服务器，不依赖外部环境提供 应用可被管理员绑定到某端口后直接提供服务这样12 factor app高度内聚，环境耦合性低，使用简单。
结构应参考Unix守护进程模式，将不同类型操作分发给不同进程，进程间共享少，便于扩容。
不要自己管理进程，应依赖操作系统的进程管理工具。
进程应能快速启动，便于服务恢复，系统简单独立，易于重启。
遇到失败时能有序终止，网络进程能先关闭新请求，处理完现有工作后退出。
开发和生产常见三大不同：部署频率、人员、环境。12-Factor标准是拒绝这些不一致。
部署频率：追求开发到生产几分钟内完成，需CI流程 人员：开发和运维最好不分，推崇DevOps 环境：保持一致，复杂服务的安装也要尽量一致目的是保证开发到生产的成功率，减少线上故障影响。
日志应视为“事件流”，与数据库等后台服务日志合并形成全局视图。
程序应直接向stdout输出日志，文件输出由操作系统管理。日志分析由操作系统收集后交给分析软件。
应用中常有供管理员命令行管理的程序，这些管理进程要和工作进程代码同步，放在同一库，运行环境一致。
这样可避免不同步和接口不兼容问题，分开和合并各有优缺点。