title: 12-Factors
author: Gamehu
tags:
  - 12-Factors
categories:
  - 学习
date: 2018-07-04 12:05:00
---

**背景**

现公司是传统的ToB业务公司，现在要新开一条产品线，因为公司的之前的产品已经10年了，因为技术等的限制，无法应对现在的快速迭代，公司高层想用现在流行的玩法，寻求突破，刚好之前那家公司的leader，支付宝出来的刚从公司离职，他和事业部的总经理是高中同学，所以瞌睡遇到枕头，就找到他来领头做个事，事业部研发中心在天津，他想做这个事必须得带几个自己信得过并且好用的人（是滴，我很好用），所以我和另外一个同事就通过他的内推去了天津（我是对现在的公司及其失望），那番场景那真就是，新老两派之间充满爱意的碰撞，我们抛弃了之前事业部的所有技术积累，全部从0开始。

这篇文章讲的就是在开垦一个后端脚手架的过程中发现了12-Factors，其实很早以前就听过12-Factors，这次逮着机会好好了解下，刚好最近看jimmysong翻译的《迁移到云原生应用架构》，里面提到了12-Factors，这套理论看来是没过时的，借机学习学习。

**I. 基准代码**

一份基准代码（Codebase），多份部署（deploy）

我们项目是采用类似git flow的方式来管理代码，首先每个应用肯定只有一份基准代码（master），不管是新功能的开发、bugfix、hostfix、release、tag等最终都是基于master的。这样就保证了所有部署的基准代码相同，但每份部署可以使用其不同的版本

{% asset_img codebase-deploys.png 来源于12factor.net  %}

**II. 依赖**

显式声明依赖关系（ dependency ）

每个应用都有自己的依赖清单，前端是package.json，后端是pom.xml。每个应用都会显示的列出依赖。

**III. 配置**

在环境中存储配置。

每个应用都有自己的配置文件（yaml），针对不同的场景有不同的配置，发布、预发布、测试等。杜绝把配置写死在代码里的情况发生。

**IV. 后端服务**

把后端服务(backing services)当作附加资源

数据库、消息队列、数据中心等都是作为基础设施存在的，每个应用是与这些组件都是松耦合。不足是现有的客户场景对可能只能做到逻辑上的隔离，比如数据库虽然逻辑上和应用是隔离的但是物理上可能在一个主机上，因为客户现场可能就跟我们提供几台机器。

{% asset_img attached-resources.png 来源于12factor.net  %}

**
V. 构建，发布，运行**

严格分离构建和运行。

项目采用的是阿里云的ci/cd方案，构建、发布、运行都是分离的。每个版本对应唯一ID。

{% asset_img release.png 来源于12factor.net  %}

**VI. 进程**

以一个或多个无状态进程运行应用

12-Factor 应用的进程必须无状态且 无共享 。 任何需要持久化的数据都要存储在 后端服务 内，比如数据库。

项目中，进程中无共享，权限、session等都存到redis中。

**VII. 端口绑定**

通过端口绑定(Port binding)来提供服务

这点没什么说的，项目所有的应用提供服务都是通过端口与应用绑定的。

**VIII. 并发**

通过进程模型进行扩展。

这一点没做好，后端采用的java语言，都知道java是典型的线程模式。所以只能给应用分配相应的资源，让其能纵向扩展，但其实效果不是很好。当然我们有比较简单的方式可以使其进行横向扩展，即每个应用部署多实例的方式进行横向扩展，不过目前没有实践。后续会完善。

{% asset_img process-types.png 来源于12factor.net  %}

**IX. 易处理**

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

该原则要求应用可以瞬间启动和停止，因为这将有利于应用快速进行横向扩展和变更或者故障后的重新部署，而这两者都是程序健壮性的体现。

快速启动是做到了，但是优雅的终止还带完善。

**X. 开发环境与线上环境等价**

尽可能的保持开发，预发布，线上环境相同。

我们的发布部署统一走的阿里云效的流水线，流水线的配置除了机器不同其他都一样。

**XI. 日志**

把日志当作事件流。

这块没做好，待完善。个人觉得是很有必要的，后期会酌情加上日志处理分析组件。从日志输出到读取，到分析，到加工，到视图一条龙服务。

**XII. 管理进程**

后台管理任务当作一次性进程运行

*官方说明：*

 开发人员经常希望执行一些管理或维护应用的一次性任务，例如：
	
-   运行数据移植
-   运行一些提交到代码仓库的一次性脚本。

一次性管理进程应该和正常的 常驻进程 使用同样的环境。这些管理进程和任何其他的进程一样使用相同的 代码 和 配置 ，基于某个 发布版本 运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。


>我理解意思就是应用的管理工具应该随产品一起提供，并且管理任务应该从生产环境中运行最新版本的生产代码的机器上执行此任务。换句话说，从与生产相同的环境中运行一次性管理任务。而不要做类似直接对数据库运行更新这种操作，我理解意思应该是有配套的管理工具而且管理工具是与生产环境同步的，如果需要做一些一次性的维护管理任务，比如数据库移植、A/B测试等任务时不要做手动去改数据库这样很容易造成环境搞乱的操作。

这点在我们项目还是比较弱的，0.1阶段基本上没有统一的管理工具，大家都是通过手动改库等操作达到目的。后期会争取做到这一点。

**12-factor 到底好不好，适不适用，我觉得不是绝对的，目前我们遵循这套是因为我们觉得它对我们有指导意义而且是有效的够用的。**

源引：
{% blockquote 12-Factor https://12factor.net/zh_cn/ https://12factor.net/zh_cn/ %}
{% endblockquote %}

{% blockquote 12-Factor Apps in Plain English | clearlytech http://www.clearlytech.com/2014/01/04/12-factor-apps-plain-english/ %}
{% endblockquote %}

`本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。`