写写十二因子应用 12-factor App

请参看 https://12factor.net/ ，记录我的一些解读和实践故事。

我的前言

在微服务如此流行的今日，我们大量的使用独立责任的微服务来完成我们的业务逻辑以及基础设施，组织架构由大组向两个披萨饼团队转换，由单一的 monolithic 应用转向由微服务组成的网，使用更多的工具帮助我们完成 CI/CD 来确保时时发布，使用 Docker 等来帮助我们整理维护开发与部署环境等等。这一切都是为了适应产品的快速变动以及释放工程师的生产能力。

这篇 The Twelve-Factor App 很好的描述了在构建 microservice 日常中的情景，在更高的层级上描述了我们该如何建设 microservice。请一定不要进行以下的断言：微服务等于 docker 化，或是就是拆分成小服务罢了。

Docker 不论是在日常开发中为我们提供了便利，也使得部署十分简单。image 为我们提供了标准化的部属单位，同时多个 image 所产生的容器可以完成复杂的任务。在我们的项目中，一个 instance 中可能有多个 containers 协作完成，但是往往只有一个 container 运行业务相关的应用，其他的可以提供 reverse proxy，log forwarder 以及 APM 性能监控等。

Docker 同时还为基础设施建设提供了便利，想象一下我们的城市，有医院、学校、工厂等等设施，里面的人们所做的工作就是我们的业务层的表述，医院只负责治疗病人就如同一个库存服务只负责管理库存，而不在乎商品入库是因为进货还是退货。而这些设施实体之间的关键却像网一样，而不是直线的数据流动。再可以联想一下，我们的城市污水系统、电力系统、公共交通等都是统一的，而所有的城市设施都是基于统一的基础设施之上的。

I. Codebase

总体来说 12-Factory App 严格要求一个 app 一个 repo （对于 SVN 管理可能有些困难），但是会有多个用于 deploy 的 repo。但是在 dockerized app 的今日，我们的应用对于的一个 repo 并且产生一个相应的 docker image，而 deploy 的 repo 也是唯一的，只是在 CI 上的参数配置不同来区分不同的运行环境。对于本地运行环境可以在 code repo 中定义 docker-compose，特别是当 app 对其他系统有依赖的情况下，可以直接使用其他系统的 image 支持本地环境。

当然，deploy repo 尽量包含所有的参数，我们不想让 CI 上的命令、脚本（过于复杂的 CI Task 或者 pipeline 是十分危险的）等失去版本控制。也可以将 deploy repo 与 code repo 结合在一起（当你认为该 repo 没有开源必要的时候），特别是你使用了代码即是 CI 的集成工具后。但是中心是：分离部署环境，尽量让 CI 中的配置可被代码管理。

II. Dependency

12-Factor App 希望我们显示的处理应用中的依赖