明天来自pivotal的老师要讲云原生应用的12要素，可惜听不了了，今晚自学一下。
-
一份基准代码（Codebase），多份部署（deploy）
图片发自简书App 显式声明依赖关系（ dependency ），比如你的应用依赖了哪些第三方库，要显示地定义在某个文件里。
代码和配置严格分离，配置要和代码完全分离，不同环境共享一套代码。推荐将应用的配置存储于 环境变量 中（ env vars, env ）。环境变量可以非常方便地在不同的部署间做修改，却不动一行代码。
-
把后端服务(backing services)当作附加资源，后端服务是指程序运行所需要的通过网络调用的各种服务，如数据库（MySQL，CouchDB），消息/队列系统（RabbitMQ，Beanstalkd），SMTP 邮件发送服务（Postfix），以及缓存系统（Memcached）。
图片发自简书App -
严格分离构建、发布和运行。构建是指将代码仓库转化为可执行包的过程。发布会将构建的结果和当前部署所需配置相结合，并能够立刻在运行环境中投入使用。运行是指针对选定的发布版本，在执行环境中启动一系列应用程序进程。
图片发自简书App 以一个或多个无状态进程运行应用，用户session 是 12-Factor 极力反对的，Session 中的数据应该保存在诸如 Memcached 或 Redis 这样的带有过期时间的缓存中。
通过端口绑定(Port binding)来提供服务，互联网应用 通过端口绑定来提供服务 ，并监听发送至该端口的请求。比如本地环境中，开发人员通过类似http://localhost:5000/的地址来访问服务。
通过进程模型进行扩展，在云原生应用中，进程是一等公民。云原生应用的进程主要借鉴于 unix 守护进程模型 。开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的 进程类型 。例如，HTTP 请求可以交给 web 进程来处理，而常驻的后台工作则交由 worker 进程负责。
可快速启动和优雅终止的进程可最大化健壮性，云原生应用的进程是 易处理（disposable）的，意思是说它们可以瞬间开启或停止。
尽可能的保持开发，预发布，线上环境相同。
把日志当作事件流，日志应该是 事件流 的汇总，将所有运行中进程和后端服务的输出流按照时间顺序收集起来。尽管在回溯问题时可能需要看很多行，日志最原始的格式确实是一个事件一行。
后台管理任务当作一次性进程运行，一次性管理进程应该和正常的常驻进程使用同样的环境。这些管理进程和任何其他的进程一样使用相同的代码和配置，基于某个 发布版本 运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。
