Heroku創始人Adam Wiggins發佈十二要素應用宣言

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的語言，由於那會讓運行一次性腳本變得簡單。

但願詳細瞭解「十二要素應用宣言」的同窗，能夠點擊這裏查看英文版，或是直接查看梁山同窗翻譯的中文版。