十二因子应用程序

参考　http://www.the12factorapp.com/

　“十二因子应用程序”源自于Heroku开发团队在收集及观察大量的SaaS(Software as a Service)应用程序开发和执行过程后，所整理出来的十二条开发SaaS应用程序时的方针。

    遵守这些方针可以增进应用程序本身的稳定性及扩充性，从程序开发到系统上线过程也会快捷很多。

1. 基准代码(codebase)：

    一对一的程序代码版本管理

    "十二因子"的程序必须存储在版本管理系统中，比如git,svn。程序代码和应用应该以“一对一”的关系存储：

• 如果你的系统需要有多个代码管理系统，那么你的系统就是个分散式系统（Distributed System)，分散式系统由多个应用程序组成，而这些应用程序都应分别套用“十二因子”。
  

• “十二因子”反对一套程序的原代码有多个应用程序在使用。如果需要分享部分的程序代码，正确的解决方式应该是把共享的程序代码封装成库(library，例如java的jar包），然后有需要的其他应用程序以“依赖性”程序库来使用。
  

        每个“十二因子应用程序”都有属于它专属的程序代码，透过专有的源代码版本管理，可以清楚的安装在不同的环境。也许每个环境有不同的版本，但每个系统所拥有的源代码还是非常清楚干净的。有问题出现时，也可以简单的回溯到之前的版本。

2. 依赖 （dependencies)

    明确定义所有依赖的程序库

    “十二因子”要求应用程序必须使用依赖关系管理系统，比如java中的maven，或是ruby的rubygems，而且所有的第三方类库必须明确定义出来，即使有些来自系统的程序库也应列出来管理。这样一来当新的工程师加入开发时，随时都可以通过该管理系统简单的安装设置自己的开发环境，无论任务平台都不会有冲突。

    一般来说容易被疏忽的部分是系统本身的程序库或工具，“十二因子应用程序”必须将这些有相依赖性的程序以第三方程序库的方式安装，以避免应用程序被安装在不支持的系统上。例如linux的curl command如果直接在程序码里使用，那这个应用程序就不能轻易的安装在windows环境中。

3. 配置 （Config)

    将配置存储在环境变量中

    配置(config)所指的是每个应用软件在不同的安装环境会设定的不同的参数。

    一般常见的例子：

• 数据库连接设置，例如URL，用户，密码。
  

• 第三方服务的连接设定，例如微信 API的URL，帐号，密码等。
  

    “十二因子应用程序”反对将这些配置变量存储在原始代码里，建议把所有的配置都存储在环境变量中。将配置变量存储在原始中会有安全性的问题，一但程序代码开发给其它团队或个人时，这些机密的帐号密码也容易不小心外露。另外配置参数是随着环境在改变的，而应用程序的代码跟版本的关系是固定的，同版本的应用程序在任务安装的环境都是一样的，所以配置参数需要另外管理。一般来说要个别定义在服务器的环境变量中，如此也可以改善应用程序的扩充性（Scalability)。

4. 后端服务 （Backing Services)

    所有后端支持系统都应视为外接的资源

    所谓后端支持服务是指应用程序通过网络传输得到的服务，例如数据库，SMTP，缓存，API（微信公共号API）之类的的服务。

    负责管理这些支持服务的种类主要有本地的（local）跟第三方(3rd party)，例如数据库通常是同公司的系统工程师在管理，但如果主机架在云端，大多数服务就都是通过第三方提供的了。“十二因子”的程序对待所有这些服务的种类必须是一致的。同一类后端服务都使用一样的程序代码来处理。唯一不同的地方只有连接用到的参数，如url，密码，用户，这些参数通过Config来管理。

    通过程序代码一致，“十二因子应用程序”可以简单的切换提供服务的来源。例如：如果要把mysql提供者从本地换到阿里云，只要改连结的配置

5. 构建，发布，运行 

    明确分离构建和运行的阶段，使用工具 

    应用程序从代码到发行／执行可以分为以下三个阶段：

    第一阶段：构建(build)，指通过构建系统将程序代码及依赖包封装起来。例如java程序打包成jar或是war包。

    第二阶段：发行(release），将打包好的程序库，加上环境配置通过发行管理系统上传到要执行的环境里，一般来说发行管理系统的另一个主要工作是将每个发行版本号的编码规范定义好。每个不同版本的程序都应有对应的发行版本，版本定义可以用日期（2016-01-01 11:59:01)或是渐进的数字（v1.1.3)。

    第三阶段：执行(run)，所指的是发行的版本(包含程序包+配置)，在该环境中执行。

    “十二因子应用程序"强调这三个阶段必须清楚地分开并定义好。例如在执行阶段不可以有任何的程序代码改变。如果这三个阶段可以分别设定好，应用程序就可以进入自动化的发行与执行，工程师开发新的功能，构建系统自动包装，发行系统自动定义版本，然后新版本的应用程序跟配置一起发行到执行的环境中。出问题时也可以在发行中系统中选择之前的版本回退回去。

6. 进程（Processes) 

    应用程序必须以“无状态”的方式在进程上执行

    一般应用程序会在一个或多个进程中执行，例如在工程师的本地开发环境通常会用一个进程，而正式上线时系统通常会有多个进程来执行。

    “无状态”指的是应用程序不会预设任务的状态，每个request在执行完后，执行过程中所用到的状态都不会被存储下来。

    执行“十二因子应用程序”进程绝对是“元状态”且不直接分享信息的，每个进程之间不会有任何的沟通，也不会预设互通的状态。有需要互通的信息一律由后端支持服务存储，例如数据库或独立缓存(如redis)。因为应用程序会由多个进程执行，而无法预期下个request来时会由哪个进程执行，所以只有通过共用的后端服务才可以确保状态信息的完整性。

    另外，应用程序可以在上线的状态下可以随时增加进程甚至是新的服务器，如果应用是有状态　的，则无法保证执行所需信息的完整性。例如常见的http sesion，就不应用直接存储在内存里，而应该利用可设置自动失效的memcached或是redis来存储。

7. 端口绑定（port binding)

    通过端口绑定提供服务

    “十二因子应用程序”的服务一律都已经完整定义在程序代码中了，要对外提供服务时，只要网络服务器通过端口绑定就可以执行。例如一般的java　web程序通常是通过tomcat或jetty之类的服务器，将连接绑定在8080上，对外就可以通过对外路径设定路由到该应用程序上。如在本地一般就是直接连接上http://localhost:8080/。一个常见的例子就是一个服务器同时有客户使用的应用程序和管理者使用的应用程序，只是绑定在不同的端口上了。 

    端口绑定的应用不只限于web程序，也可以是各种的网络服务，例如ftp，或是种定制的服务。“十二因子应用程序”也可以成为其他应用程序的“后端支持服务”，例如很多应用程序本生的服务只提供Restful API，而没有任何界面。

8. 并发 

    通过并发进行扩展

    一般程序的执行环境都支持使用多个处理序列来执行应用程序，例如java的jvm就是通过线程让软件同步执行多个任务。

    “十二因子应用程序”利用这些同步执行的能力来增加应用程序的效率和扩充性。例如http requet由一个处理序列执行，需要定期执行的作业由另一个处理序列执行。

     这样的设计配合“十二因子”中的无状态跟不直接分享执行资源的原则，应用程序则可以简单的通过增加硬件资源或云端上的执行单元来最佳化执行的效率。

9. 快速启用与终止(disposability)

    快速启动和优雅终止可最大化健壮性

    "十二因子应用程序”在开发的任何阶段，都要确保程序的启动速度要快，同时要确保程序终止时不会无法恢复或丢失重要数据的状况。如果可以保持这两个原则，应用程序本身就可以简单的达到扩充性，或者是硬件迁移的过程也会简化很多。

    应用程序在终止时要确认资料跟作业的完整度，通过后端支持服务来分享状态，这样当一个处理序列终止后，其他执行中的处理序列可以接着完成作业。例如有些程序有很多在后台执行的程序，可以通过queuing service（例如rabbitmq）来分配要执行的工作，而无论哪个处理序列都可以分别执行，这样单个应用程序才可以安全的终止服务。 

10. 环境的一致性(Dev/Prod Parity)

    保持不同环境(dev,qa,staging,production)的一致性

    传统应用软件的开发环境(dev)通常会跟production生产环境不同，通常原因可能是资源跟人员的分配的差异性。这种差异性会造成三个软件开发的落差：

•     时间：从工程师的软件开发环境到可以发行到生产环境需要很长的时间，有时需要几周甚至几个月才能发行新的版本。
  

•     人力资源：软件工程师负责开发软件，需要通过系统工程师来发行软件到生产环境。
  

•     工具：软件工程师在开发时使用较轻便的工具，而生产环境则使用功能完整的工具。例如工程师使用sqllit开发，而生产环境用mysql。

    “十二因子应用程序”强调“不间断的发行环境”，发行的环境设定一律自动化，测试过的新功能要自动打包成新自动本，有时一天发行一个版本，有时甚至可以一天发行多个版本。

    另外“十二因子应用程序”强调任务环境都应用使用相同的工具或后端支持服务，例如数据库或缓存。如果工具不同，会发生新版本在开发环境测试都通过了，但发行到生产环境就出问题的情况。如果真正要确保“不间断发行”的稳定性，就要尽量达到在各环境都使用与生产环境一样的工具或后端服务。

    遵守”十二因子“的原则，则应用程序开发的环境就会稳定很多，且之前提到的落差就会减低：

•     时间：从开发到发行时间减为一天内。
  

•     人力资源：发行环境设置好后，软件工程师就可以自行发行新版本，不需要通过系统工程师。
  

•     工具：任何环境的工具都与生产环境的一样。
  

11. 日志 

    通过外接服务将日志整合起来

    应用程序的执行过程通常都是通过日志记录存储起来的，一般的存储方式为将日志写在服务器的文件中，一旦日志文件开启后，应用程序的执行内容就会一行一行的写在文件内，在程序终止前都会不断的记录着程序开发者认为重要的信息，例如错误信息或是未来可以用来分析的信息。由于saas的应用程序通过会在多个主机上执行，这就造成日志文件可能处于不连续的状态，所以需要额外的服务来将这些日志记录整合起来。

    “十二因子应用程序”本身不管理任何关于整合记录的服务，将这类整合的任务交给执行环境去处理。“十二因子”只负责将记录写入该执行环境的日志文件中。

    目前已经有很多整合日志的工具（例如logplex或是fluent)，这些工具可以将每个主机上的日志传输到一个服务器上，将每个记录的内容依据发生时间整合起来，提供未来除错或是分析使用。

12. 管理过程（Admin Processes)

    在相同环境下执行管理任务

    应用程序在上线一段时间后，难免需要执行一些管理任务，例如数据库迁移，或是需要登录控制台之类的界面管理系统。有时候工程师为了方便，在本地环境执行更新其他环境的工作，这样的结果会造成应用程序本身的不稳定，且严重影响程序代码版本的一致性。

    “十二因子应用程序”的管理相关任务必须跟程序本身在同一个环境执行，例如在qa的环境执行aq的管理任务，生产环境的管理任务就在生产环境执行。关于管理相关任务的程序代码必须跟应用程序本身的代码以同一个版本发行到该环境，配合该环境的配置参数来执行。