软件开发12要素原则

1. “12要素”原则简介

“12要素”英文全称是The Twelve-Factor App，来源于Heroku平台的实践。Heroku平台创始人Adam Wiggins汇总了这些实践经验，发布了一个“十二要素应用宣言（The Twelve-Factor App）”。英文原版地址：https://www.12factor.net/。

如今的软件产品通常都会采用服务方式进行交付，其总结有如下六点内容：

• 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。

• 和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性。

• 适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。

• 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发。

• 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。

• 适用于任意语言和后端服务如数据库、消息队列、缓存等开发的应用程序。

“十二要素应用宣言”这套理论适用于任意语言和后端服务应用程序，同样也可以作为微服务应用的参考方法论。微服务应用的特征就是需要遵循一套设计契约，同时微服务应用所面临的高自动化、容器驱动型、基础设施管理等环境也对编写方式提出了要求。微服务开发人员必须改变自己的编程习惯来满足自动化、容器和基础设施管理的要求。这需要在开发运维人员与微服务应用之间创建出一套用于指导应用程序运行的新型“契约”。这套理想的“契约”机制大部分就存在于“应用十二要素”中所提出的基本原则中，其内容包括：（1）基准代码；（2）依赖；（3）配置；（4）后端服务；（5）构建、发布、运行；（6）进程；（7）端口绑定；（8）并发；（9）易处理；（10）环境等价；（11）日志；（12）管理进程等12项。

下面就微服务应用与“十二要素应用宣言”之间的关系做一个适应性分析。

2. 微服务应用的“12要素”原则

 

2.1 基准代码

基本含义，一份基准代码（Codebase），多份部署（deploy）。

该要素原则体现到微服务应用有三点实践：

• 微服务基准代码和微服务应用之间总是保持一对一关系。微服务应用和微服务部署实例是一对多关系。微服务基准代码是以代码方式存在，而微服务应用是以二进制程序方式存在，而微服务应用部署实例是以运行实例方式存在。

• 对于微服务应用程序的源码管理，必须要有统一的版本控制中心。这样可以实现在版本控制代码库中追踪每一个部署的微服务应用。

• 部署的环境性质多种多样，如应用环境，有开发环境、测试环境、生产环境等，也有某种环境的多个介质，如容器、虚拟机、硬件上等。运行环境和配置参数有较大差别，但是程序源码只有一份基准的版本。

 

2.2. 依赖

基本含义，显式声明依赖关系。

该要素原则体现到微服务应用有三点实践：

• 对于每个微服务，要声明所依赖的编译包和运行包清单，便于构建工具能很正确地构造微服务应用，例如Maven的pom.xml文件、Gradle的build.gradle文件。这是编译和构造过程的显式声明依赖关系。

• 微服务应用可以很清晰地表明对部署环境公开和隔绝依赖性的信息，而不是模糊地对部署环境产生依赖性。这种关系可以通过工具来声明实现。在容器环境中，可采用DockerFile来声明；在非集成环境中，可使用配置管理工具（Chef，Puppet，RunDeck）来显式声明服务之间依赖关系。这是安装部署的显式声明依赖关系。

• 业务微服务之间也要明确相互之间的依赖关系，可以通过一些服务编制和服务编排相关框架平台来实现。这是业务层面上的显式依赖关系。

 

2.3. 配置

基本含义，在环境中存储配置。

该要素原则体现到微服务应用有四点实践：

• 微服务应用的代码分为两类。一类是程序源码，一类是配置代码。任何部署之间的差异都可以视为配置编码类。微服务应用的配置代码存储在环境中，而不是将其提交到存储库。严格区分程序源码和配置代码的产生机制和管理机制。

• 根据不同的环境配置信息和配置代码，微服务应用的实例运行在不同的环境中，环境的配置编程代码也归属为配置信息。

• 微服务应用环境配置开发基于非版本模式，采用附加文件模式加载到微服务应用程序中。而微服务应用的程序源码必须进入版本控制，见第一要素原则基准代码。

• 在微服务应用的程序源码避免使用与环境信息关联的硬编码。

• 微服务开发和交付分为两个完全隔离的阶段和环境。开发阶段编写基准代码，交付阶段负责管理环境变量。

 

2.4. 后端服务

基本含义，把后端服务当作附加资源。

该要素原则体现到微服务应用有四点实践：

• 微服务组件依赖的服务都归属为依赖资源，依赖资源包括后端服务、第三方服务，甚至是其他微服务。后端服务包括且不限于数据库服务、消息/队列、缓冲服务、目录服务、邮件服务、数据存储服务等。

• 微服务所依赖的资源都是完全可移植的，并且可以松散地耦合地整合其他类似资源。

• 微服务组件内部不应该具有依赖资源的功能，如果有这方面的需要，通过接口引用外部的依赖资源来实现资源重用，但容错、容灾和备份等特殊要求除外。

• 微服务组件只关注内部微服务的实现，同时仅需要了解外部资源提供的接口，而不用详细了解外部依赖资源的具体实现。

 

2.5. 构建、发布、运行

基本含义，严格分离构建和运行。

该要素原则体现到微服务应用有三点实践：

• 微服务应用严格区分构建、发布、运行这3个阶段。其明确的区别在于，构建阶段就是微服务应用就是通过自动或手动方式，把微服务源码形成微服务组件（可独立运行的二进制程序）。发布阶段是把微服务组件放置到对应的发布库（如容器镜像）上，提供给外部运行环境来下载。运行阶段把微服务组件部署到对应的运行环境中。

• 使用持续集成/持续交付（CI / CD）工具来自动构建、发布和运行三个阶段的工作。例如，容器镜像可以轻松分离构建和发布阶段。理想情况下，微服务源码每次被编译形成组件后，提交到容器镜像，并被视为发布工作。同时，每次从容器镜像获取微服务组件并移植到运行环境中，都视为部署工作。这几个过程与容器的Build-Ship-Run阶段完全吻合。

• 三个阶段持续运行过程中，前一个阶段的任何一点改动，都认为是微服务应用的整体改变，需要重新确定新的、唯一的版本发布ID。

 

2.6. 进程

基本含义，以一个或多个无状态进程运行应用。

该要素原则体现到微服务应用有三点实践：

• 微服务最好地无状态且共享的，任何有状态的服务信息都持久化到后端服务中（如缓存、对象存储、关系数据存储等）。这样可以实现随意启动和立刻停止微服务，也不会有数据丢失的情况发生。

• 由于服务无状态，可以通过简单地添加更多无状态的服务实例来轻松扩展微服务。将任何有状态的数据或需要在实例之间共享的数据都存储在后端服务中。

• 微服务组件在设计时就必须按照随时随地会失败或者宕掉来设计。这种设计可以实现微服务进程会被随时拉起或消失，特别是在弹性扩容阶段。

 

2.7. 端口绑定

基本含义，通过端口绑定提供服务。

该要素原则体现到微服务应用有三点实践：

• 微服务自带运行容器，自我加载而不依赖于任何外部软件就可以启动一个面向大众的服务。

• 微服务通过端口提供的服务。不同的端口绑定不同支持请求协议（包括HTTP、RPC、XMPP、Redis 协议等），监听所有发送至该端口的请求。

• 微服务统一通过暴露端口来提供服务，尽量避免通过本地文件或进程来通信，每种端口服务通过服务发现机制而对外提供服务。

 

2.8. 并发

基本含义，通过进程模型进行扩展。

该要素原则体现到微服务应用有三点实践：

• 微服务架构借鉴Unix进程模型实现。虽然微服务应用本身只是一个进程，但可以根据业务分支来开启多个线程以分散进程瓶颈。

• 对于同一服务功能，可以对应启动多个微服务实例，这样可以实现水平扩展。

• 通过添加无状态进程实现横向扩展。

 

2.9. 易处理

基本含义，快速启动和优雅终止可最大化健壮性。

该要素原则体现到微服务应用有三点实践：

• 微服务启动时可以同时并发多个线程，采用懒加载方式，这样实现快速启动。

• 微服务终止是检查所有资源都是否销毁，所有监听都要关闭，释放所有的资源，最后什么也不留下地离开。

• 当非正常结束时，微服务自动恢复到默认状态上。

 

2.10. 环境等价

基本含义，尽可能的保持开发、预发布、线上环境相同。

该要素原则体现到微服务应用有四点实践：

• 保持微服务的研发、测试和生产环境尽可能相似，这样可以保证微服务应用的高质量，持续发布和持续部署。

• 通过容器部署方式来实现微服务的版本化，通过适配器来保证各个不同环境的差异性，同时还能大大减少环境不同带来的排错等成本沟通问题。

• 对于后台数据，差异性是不可避免的。这需要在开发过程中建立隔离机制。

• 最好开发运维一体化。

 

2.11. 日志

基本含义，把日志当作事件流。

该要素原则体现到微服务应用有四点实践：

• 微服务应用要建立统一的服务日志管理机制。

• 每个运行的微服务都要求直接标准输出（stdout）和错误输出（stderr）事件流。日志是事件流的汇总，最后形成日志数据源。通过集中服务，执行环境收集、聚合、索引和分析这些日志事件。

• 采用服务调用链来解决服务之间调用的问题。

• 通过日志来进行微服务应用的监控。

 

2.12. 管理进程

基本含义，后台管理任务当作一次性进程运行。

该要素原则体现到微服务应用有三点实践：

• 微服务本身应用和微服务的后台管理应用要严格分离。这两者采用的技术架构、框架和实现都不一样。

• 微服务后台管理应用也可以采用微服务模式来实现。

• 微服务管理或维护系统是微服务应用维护的基础部分，要作为一次性程序运行。