Heroku是業內知名的云應用平臺，從對外提供服務以來，他們已經有上百萬應用的托管和運營經驗。前不久，創始人Adam Wiggins根據這些經驗，發布了一個“十二要素應用宣言（The Twelve-Factor App）”,該宣言由國內工作于安居客的程序員梁山將其翻譯為中文，InfoQ中文站摘錄如下。

十二要素應用宣言

簡介：

如今，軟件通常會作為一種服務來交付，它們被稱為網絡應用程序，或“軟件即服務”（SaaS）。“十二要素應用程序”（12-Factor App）為構建如下的SaaS應用提供了方法論：

• 使用標準化流程自動配置，從而使新的開發者花費最少的學習成本加入這個項目；
• 和操作系統之間盡可能的劃清界限，在各個系統中提供最大的可移植性；
• 適合部署在現代的云計算平臺，從而在服務器和系統管理方面節省資源；
• 將開發環境和生產環境的差異降至最低，并使用持續交付實施敏捷開發；
• 可以在工具、架構和開發流程不發生明顯變化的前提下實現擴展；

這套理論適用于任意語言和后端服務（數據庫、消息隊列、緩存等）開發的應用程序。

背景

本文的貢獻者者參與過數以百計的應用程序的開發和部署，并通過Heroku平臺間接見證了數十萬應用程序的開發，運作以及擴展的過程。

本文綜合了我們關于SaaS應用幾乎所有的經驗和智慧，是開發此類應用的理想實踐標準，并特別關注于應用程序如何保持良性成長，開發者之間如何進行有效的代碼協作，以及如何避免軟件污染?。

我們的初衷是分享在現代軟件開發過程中發現的一些系統性問題，并加深對這些問題的認識。我們提供了討論這些問題時所需的共享詞匯，同時使用相關術語給出一套針對這些問題的廣義解決方案。本文格式的靈感來自于Martin Fowler的書籍：?Patterns of Enterprise Application Architecture，?Refactoring?。

讀者應該是哪些人？

任何SaaS應用的開發人員。部署和管理此類應用的運維工程師。

I. 基準代碼

一份基準代碼，多份部署

基準代碼和應用之間總是保持一一對應的關系：

• 一旦有多個基準代碼，就不能稱為一個應用，而是一個分布式系統。分布式系統中的每一個組件都是一個應用，每一個應用可以分別使用12-Factor進行開發。
• 多個應用共享一份基準代碼是有悖于12-Factor原則的。解決方案是將共享的代碼拆分為獨立的類庫，然后使用依賴管理策略去加載它們。

盡管每個應用只對應一份基準代碼，但可以同時存在多份部署。

所有部署的基準代碼相同，但每份部署可以使用其不同的版本。

II. 依賴

顯式聲明依賴關系

12-Factor規則下的應用程序不會隱式依賴系統級的類庫。 它一定通過依賴清單?，確切地聲明所有依賴項。此外，在運行過程中通過 依賴隔離 工具來確保程序不會調用系統中存在但清單中未聲明的依賴項。這一做法會統一應用到生產和開發環境。

III. 配置

在環境中存儲配置

12-Factor推薦將應用的配置存儲于環境變量 中 (env vars, env) 。環境變量可以非常方便地在不同的部署間做修改，卻不動一行代碼；與配置文件不同，不小心把它們簽入代碼庫的概率微乎其微；與一些傳統的解決配置問題的機制（比如Java的屬性配置文件）相比，環境變量與語言和系統無關。

12-Factor應用中，環境變量的粒度要足夠小，且相對獨立。它們永遠也不會組合成一個所謂的“環境”，而是獨立存在于每個部署之中。當應用程序不斷擴展，需要更多種類的部署時，這種配置管理方式能夠做到平滑過渡。

IV. 后端服務

把后端服務當作附加資源

12-Factor應用不會區別對待本地或第三方服務。 對應用程序而言，兩種都是附加資源，通過一個url或是其他存儲在 配置 中的服務定位/服務證書來獲取數據。12-Factor應用的任意 部署 ，都應該可以在不進行任何代碼改動的情況下，將本地MySQL數據庫換成第三方服務(例如 Amazon RDS)。類似的，本地SMTP服務應該也可以和第三方SMTP服務(例如Postmark)互換。

V. 構建，發布，運行

嚴格分離構建和運行

12-facfor應用嚴格區分構建，發布，運行這三個步驟。

每一個發布版本必須對應一個唯一的發布ID。

新的代碼在部署之前，需要開發人員觸發構建操作。但是，運行階段不一定需要人為觸發，而是可以自動進行。

VI. 進程

以一個或多個無狀態進程運行應用

12-factor應用的進程必須無狀態且無共享 。任何需要持久化的數據都要存儲在后端服務內，比如數據庫。粘性Session是twelve-factor極力反對的。Session中的數據應該保存在諸如Memcached 或 Redis 這樣的帶有過期時間的緩存中。

VII. 端口綁定

通過端口綁定提供服務

12-factor應用完全自我加載而不依賴于任何網絡服務器就可以創建一個面向網絡的服務。互聯網應用 通過端口綁定來提供服務，并監聽發送至該端口的請求。

VIII. 并發

通過進程模型進行擴展

在12-factor應用中，進程是一等公民。 12-factor應用的進程主要借鑒于 unix守護進程模型 。開發人員可以運用這個模型去設計應用架構，將不同的工作分配給不同的進程類型 。

IX. 易處理

快速啟動和優雅終止可最大化健壯性

12-factor應用的進程是可支配的，意思是說它們可以瞬間開啟或停止。 這有利于快速、彈性的伸縮應用，迅速部署變化的代碼或配置，穩健地部署應用。進程應當追求最小啟動時間；進程一旦接收終止信號(SIGTERM) 就會優雅的終止 。進程還應當在面對突然死亡時保持健壯 ，

X. 開發環境與線上環境等價

盡可能的保持開發、預發布、線上環境相同

12-factor應用想要做到持續部署就必須縮小本地與線上差異。12-factor應用的開發人員應該反對在不同環境間使用不同的后端服務 ，即使適配器已經可以幾乎消除使用上的差異。

XI. 日志

把日志當作事件流

12-factor應用本身從不考慮存儲自己的輸出流。 不應該試圖去寫或者管理日志文件。相反，每一個運行的進程都會直接的標準輸出(stdout)事件流。開發環境中，開發人員可以通過這些數據流，實時在終端看到應用的活動。

XII. 管理進程

后臺管理任務當作一次性進程運行

一次性管理進程應該和正常的 常駐進程 使用同樣的環境。這些管理進程和任何其他的進程一樣使用相同的代碼和配置，基于某個發布版本運行。后臺管理代碼應該隨其他應用程序代碼一起發布，從而避免同步問題。所有進程類型應該使用同樣的依賴隔離技術。12-factor尤其青睞那些提供了REPL shell的語言，因為那會讓運行一次性腳本變得簡單。

希望詳細了解“十二要素應用宣言”的同學，可以點擊這里查看英文版，或是直接查看梁山同學翻譯的中文版。

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

https://www.12factor.net/

?

總結

以上是生活随笔為你收集整理的Heroku创始人Adam Wiggins发布十二要素应用宣言的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。