Heroku创始人Adam Wiggins发布十二要素应用宣言

  • 时间:
  • 浏览:0
  • 来源:uu快3诀窍_uu快3app安卓_导航网

http://www.infoq.com/cn/news/2012/09/12-factor-app

https://www.12factor.net/

12-Factor应用中,环境变量的粒度要足够小,且相对独立。它们永远本来 会组合成原本所谓的“环境”,本来 独立占据 于每个部署之中。当应用程序不断扩展,不能否 更多种类的部署时,本身配置管理法律法律依据不要再能否 做到平滑过渡。

本文的贡献者者参与过数以百计的应用程序的开发和部署,并通过Heroku平台间接见证了数十万应用程序的开发,运作以及扩展的过程。

12-Factor应用不要再区别对待本地或第三方服务。 对应用程序而言,本身不是附加资源,通过原本url或是一些存储在 配置 中的服务定位/服务证书来获取数据。12-Factor应用的任意 部署 ,都应该能否 不能在不进行任何代码改动的情况表下,将本地MySQL数据库加进第三方服务(之类 Amazon RDS)。之类的,本地SMTP服务应该不能否 不能否 和第三方SMTP服务(之类Postmark)互换。

一次性管理应用程序应该和正常的 常驻应用程序 使用同样的环境。本身管理应用程序和任何一些的应用程序一样使用相同的代码和配置,基于某个发布版本运行。后台管理代码应该随一些应用程序代码一起去发布,从而出理 同步难题。所有应用程序类型应该使用同样的依赖隔离技术。12-factor尤其青睐本身提供了REPL shell的语言,前一天那会让运行一次性脚本变得简单。

12-factor应用本身未必考虑存储自己的输出流。 不应该试图去写前一天管理日志文件。相反,每原本运行的应用程序总要直接的标准输出(stdout)事件流。开发环境中,开发人员能否 不能通过本身数据流,实时在终端都看应用的活动。

12-Factor规则下的应用程序不要再隐式依赖系统级的类库。 它一定通过依赖清单 ,确切地声明所有依赖项。此外,在运行过程中通过 依赖隔离 工具来确保程序不要再调用系统中占据 但清单中未声明的依赖项。本身做法会统一应用到生产和开发环境。

大伙 的初衷是分享在现代软件开发过程中发现的一些系统性难题,并加深对本身难题的认识。大伙 提供了讨论本身难题时所需的共享词汇,一起去使用相关术语给出一套针对本身难题的广义出理 方案。本文格式的灵感来自于Martin Fowler的书籍: Patterns of Enterprise Application Architecture, Refactoring 。

12-factor应用的应用程序不能否 无情况表且无共享 。任何不能否 持久化的数据不是存储在后端服务内,比如数据库。粘性Session是twelve-factor极力反对的。Session中的数据应该保占据 诸如Memcached 或 Redis 原本 的中有 过期时间的缓存中。

12-Factor推荐将应用的配置存储于环境变量 中 (env vars, env) 。环境变量能否 不能非常方便地在不同的部署间做修改,却不动一行代码;与配置文件不同,不小心把它们签入代码库的概率微乎其微;与一些传统的出理 配置难题的机制(比如Java的属性配置文件)相比,环境变量与语言和系统无关。

希望删改了解“十二主次应用宣言”的同学,能否 不能点击这里查看英文版,或是直接查看梁山同学翻译的中文版。

本文综合了大伙 关于SaaS应用几乎所有的经验和智慧网,是开发此类应用的理想实践标准,并不怎么才能 关注于应用程序怎么才能 才能 保持良性成长,开发者之间怎么才能 才能 进行有效的代码商务商务合作,以及怎么才能 才能 出理 软件污染 。

12-factor应用删改自我加载而不依赖于任何网络服务器就能否 不能创建原本面向网络的服务。互联网应用 通过端口绑定来提供服务,并监听发送至该端口的请求。

每原本发布版本不能否 对应原本唯一的发布ID。

Heroku是业内知名的云应用平台,从对外提供服务以来,大伙 前一天有上百万应用的托管和运营经验。前不久,创始人Adam Wiggins根据本身经验,发布了原本“十二主次应用宣言(The Twelve-Factor App)”,该宣言由国内工作于安居客的程序员梁山将其翻译为中文,InfoQ中文站摘录如下。

这套理论适用于任意语言和后端服务(数据库、消息队列、缓存等)开发的应用程序。

任何SaaS应用的开发人员。部署和管理此类应用的运维工程师。

尽管每个应用只对应一份基准代码,但能否 不能一起去占据 多份部署。

基准代码和应用之间一个多劲保持一一对应的关系:

12-facfor应用严格区分构建,发布,运行这原本步骤。

所有部署的基准代码相同,但每份部署能否 不能使用其不同的版本。

新的代码在部署前一天,不能否 开发人员触发构建操作。并且,运行阶段不一定不能否 人为触发,本来 能否 不能自动进行。

12-factor应用的应用程序是可支配的,意思是说它们能否 不能瞬间开启或停止。 这助于快速、弹性的伸缩应用,更慢部署变化的代码或配置,稳健地部署应用。应用程序应当追求最小启动时间;应用程序一旦接收终止信号(SIGTERM) 就会优雅的终止 。应用程序还应当在面对一个多劲死亡时保持健壮 ,

12-factor应用我要我做到持续部署就不能否 缩小本地与线上差异。12-factor应用的开发人员应该反对在不同环境间使用不同的后端服务 ,即使适配器前一天能否 不能几乎消除使用上的差异。

在12-factor应用中,应用程序是一等公民。 12-factor应用的应用程序主要借鉴于 unix守护应用程序模型 。开发人员能否 不能运用本身模型去设计应用架构,将不同的工作分配给不同的应用程序类型 。

如今,软件通常会作为本身服务来交付,它们被称为网络应用程序,或“软件即服务”(SaaS)。“十二主次应用程序”(12-Factor App)为构建如下的SaaS应用提供了法律法律依据论: