The 12-Factor App Principles

63 阅读 0 评论 42 点赞

我是靠谱客的博主温柔戒指，最近开发中收集的这篇文章主要介绍The 12-Factor App Principles，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

今天翻阅资料书的时候看到一个词"12要素程序", 对这个词不是很了解, 于是查阅资料, 记录一下.

1. 什么是12要素应用程序?

12-Factor App methodology was drafted by developers at Heroku, a platform-as-a-service company, and was first presented by Adam Wiggins circa 2011.

维基百科给出的定义是:

"The Twelve-Factor App methodology is a methodology for building software-as-a-service applications. These best practices are designed to enable applications to be built with portability and resilience when deployed to the web."

他的大致想要表达的就是:

12-Factor 为构建软件服务提供了方法论, 使得应用程序的构建更具有可移植性和弹性.

2. 12要素具体指哪12要素?

(1)Codebase(代码库)
There should be exactly one codebase for a deployed service with the codebase being used for many deployments.
一份代码, 多份部署. 每个应用程序都应具有自己的代码库; 不要在应用程序之间共享代码, 如果需要共享, 则需要构建一个库并将其作为依赖项, 并通过像maven这样的软件包进行管理.
(2)Dependencies(依赖关系)
All dependencies should be declared, with no implicit reliance on system tools or libraries.
显式声明并隔离依赖关系.
使用依赖管理工具从外部管理依赖项, 而不是将依赖添加到代码库中. 例如Java可以使用 Maven 和 Gradle 进行依赖管理.
(3)Config(配置-在环境中存储配置)
Configuration that varies between deployments should be stored in the environment.
不应将代码库中配置值硬编码为常量, 而应该提取配置保存. 例如:数据库连接,外部服务凭据等等. Java中有很多组件可以实现配置管理, 比如 Apollo.
(4)Backing services(后端服务-把后端服务当作附加资源)
All backing services are treated as attached resources and attached and detached by the execution environment.
应用不会区别对待本地或第三方服务. 对应用程序而言, 两种都是附加资源, 通过一个 url 或是其他存储在配置中的服务定位/服务证书来获取数据, 并且这些资源和它们的附属的部署保持松耦合, 部署可以按需加载或者卸载资源, 可以动态变更组件而不会影响系统.
(5)Build, release, run(构建, 发布和运行-严格分离构建和运行)
The delivery pipeline should strictly consist of build, release, run.
应用应该严格区分构建,发布和运行三个步骤. 可以使用 CI/CD 工具来自动化构建和部署.

(6)Processes(进程-以一个或多个无状态进程运行应用程序)
Applications should be deployed as one or more stateless processes with persisted data stored on a backing service.
应用程序不应该将数据存储在内存中, 任何需要持久化的数据都应该存储在后端服务内,比如数据库中, 而不是存在进程的内存中.
避免使用粘性 Session(粘性Session指将用户 session 中的数据缓存至某进程的内存中，并将同一用户的后续请求路由到同一个进程), 如果需要存储 Session 信息,可以选择 Redis, memcached 等.
(7)Port binding(端口绑定-通过端口绑定提供服务)
Self-contained services should make themselves available to other services by specified ports.
应用完全自我加载, 不需要依赖任何网络服务器即可创建一个面向网络的服务. 程序独立运行, 不需要将其部署到任何一个外部web服务器中.
(8)Concurrency(并发-通过进程模型扩展)
Concurrency is advocated by scaling individual processes.
考虑将应用程序作为多个进程或者实例运行, 而不是在一个大型系统运行, 可以选择加入线程改善对请求的并发处理, 主张采用水平缩放而非垂直缩放.(水平缩放:添加实例; 垂直缩放:添加硬件.)
(9)Disposability(易处理-快速启动和优雅终止可最大化健壮性)
Fast startup and shutdown are advocated for a more robust and resilient system.
可以瞬间开启或者停止, 添加或者删除实例,系统不受到影响. 进程一旦接收终止信号就会优雅地终止, 比如网络进程拒绝所有新的请求并继续执行当前已接收的请求,然后退出; 或者worker进程将当前任务退回队列. 支持重复执行(通过事务或者幂等来实现).
(10)Dev/Prod parity(开发环境与线上环境等价-尽可能的保持开发，预发布，线上环境相同)
All environments should be as similar as possible.
应用想要做到持续部署就必须缩小本地与线上的差异, 例如:缩小时间差异, 缩小人员差异, 缩小工具差异等.
(11)Logs(日志-把日志当做事件流)
Applications should produce logs as event streams and leave the execution environment to aggregate.
日志对于解决生产问题和了解用户行为至关重要. 每一个运行的进程都会直接的标准输出（stdout）事件流, 然后由其他中间件负责捕获, 存储, 管理日志.
(12)Admin Processes(管理进程-后台管理任务当作一次性进程运行)
Any needed admin tasks should be kept in source control and packaged with the application.
任何需要的管理任务都应保存在源代码控制中并与应用程序打包在一起.