12-Factor 應用方法論的開源開發者指南

這 12 項基本原則能夠幫助團隊快速高效地構建高度可擴展的應用程序

12-Factor 應用方法論 為在短時間內構建應用程序並使其具有可擴展性提供了指導。它由 Heroku 的開發人員創建，用於軟體即服務（SaaS）應用程序、網路應用程序以及可能的通信平台即服務（CPaaS）。在有效組織項目和管理可擴展應用程序方面，12 要素應用程序方法論對開源開發具有強大的優勢。

12-Factor 應用方法論的原則

12-Factor 應用方法論的規則非常嚴格，也是開發和部署 SaaS 應用程序的基石，並且不受任何編程語言或資料庫的限制。

1：一份基準代碼，多份部署


每個應用程序都應該有一個具有多個不同環境/部署的代碼庫。

開發人員不應僅僅為了在不同環境中設置而開發另一個代碼庫。不同的環境代表不同的狀態，但這些不同的環境應該共享同一個代碼庫。

在許多開源項目都存儲在 GitLab 這樣的版本控制系統中的情況下，一個環境可以被視為一個分支。例如，你可以在任何中央版本控制系統中為名為 VoIP-app 的雲 VoIP 應用程序創建一個單獨的存儲庫，然後創建兩個分支：開發分支（development）和暫存分支（staging），並將主分支（master）作為發布分支。

2：明確聲明和隔離依賴關係

應聲明所有依賴關係。你的應用程序可能會依賴外部系統工具或庫，但不應對系統工具或庫有任何 隱含的 依賴。你的應用程序必須始終明確聲明所有依賴關係及其正確版本。

在代碼庫中包含依賴關係可能會產生問題，特別是在開源項目中，外部庫的更改可能會將錯誤引入代碼庫。例如，代碼庫可能會使用一個外部庫，但沒有明確聲明該依賴關係或版本。如果外部庫更新到更新的、未經測試的版本，這可能會與你的代碼產生兼容性問題。如果明確聲明了依賴關係及其正確版本，你的代碼庫就不會出現這種問題。

根據技術棧的不同，最好使用軟體包管理器，通過讀取代表依賴庫名稱和版本的依賴庫聲明清單，在各自的系統上下載依賴庫。

3：在環境中存儲配置

當需要支持多個環境或客戶端時，配置就成了應用程序的重要組成部分。不同部署之間的配置應存儲在環境變數中。這樣就可以在部署之間輕鬆更改配置，而無需更改代碼。

對於閉源應用程序來說，這一原則是有益的，因為你不會希望資料庫連接信息或其他秘密數據等敏感信息被公開。然而，在開放源代碼開發中，這些細節都是公開的。在這種情況下，好處是你不需要反覆修改代碼。你只需這樣設置變數，只需改變環境，就能讓代碼完美運行。

4：把後端服務當作附加資源

所有後備服務（如資料庫、外部存儲或消息隊列）都被視為附加資源，由執行環境附加或分離。根據這一原則，如果這些服務的位置或連接細節發生變化，仍無需更改代碼。這些細節可以在配置中找到。

備份服務可以從部署中快速附加或分離。例如，如果基於雲的電子表格的資料庫無法正常工作，開發人員應該能夠創建一個從最近備份恢復的新資料庫伺服器，而無需對代碼庫進行任何更改。

5：嚴格分離構建和運行

12-Factor 應用方法論要求嚴格區分構建、發布和運行階段。

• 第一階段是 構建 階段。在這一階段，源代碼被組裝或編譯成可執行文件，同時載入依賴關係並創建資產。每次需要部署新代碼時，構建階段就會開始。
• 第二階段是 發布 階段。在此階段，構建階段生成的代碼與部署的當前配置相結合。最終發布的版本包含構建和配置，可在執行環境中立即執行。
• 第三個階段是 運行 階段，也是最後階段：應用程序在執行環境中運行。該階段不應被其他任何階段打斷。

通過嚴格區分這些階段，我們可以避免代碼中斷，使系統維護更加易於管理。

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

應用程序作為一個或多個進程的集合在執行環境中執行。這些進程是無狀態的，其持久化數據存儲在資料庫等後台服務中。

這對開源非常有用，因為使用某版本應用程序的開發人員可以在其雲平台上創建多節點部署，以實現可擴展性。數據不會在其中持久化，因為如果其中任何一個節點崩潰，數據就會丟失。

7：通過埠綁定提供服務

你的應用程序應作為獨立的服務，獨立於其他應用程序。它它應該能通過URL供其他服務訪問，以服務形式存在。這樣，你的應用程序就可以在需要時作為其他應用程序的資源。利用這一概念，你可以構建 REST API。

8：通過進程模型進行擴展

該原則也稱為並發原則，它表明應用程序中的每個進程都應能夠自我擴展、重啟或克隆。

開發人員可以創建多個進程，並將應用程序的負載分配給這些進程，而不是將一個進程變大。通過這種方法，你可以將每種工作負載分配給一個進程類型，從而構建能處理不同工作負載的應用程序。

9：快速啟動和優雅終止以增強健壯性

你的應用應當基於簡單的進程構建，因此開發者可以放大進程的同時還能在發生問題時重啟它們。這使得應用的進程易於丟棄。

根據這一原則構建應用程序意味著代碼的快速部署、快速彈性擴展、更靈活的發布流程以及穩健的生產部署。所有這些在開源開發環境中都非常有用。

10：儘可能的保持開發、預發布、生產環境相同

同一項目的團隊應使用相同的操作系統、支持服務和依賴關係。這樣可以降低出現錯誤的可能性，減少開發所需的時間。

由於開源項目的開發人員分散在各地，他們可能無法就所使用的系統、服務和依賴關係進行 溝通 ，因此將這一原則付諸實踐對於開源項目來說可能是一個挑戰。減少這些差異的一種可能性是制定開發指南，建議使用何種操作系統、服務和依賴關係。

11：把日誌當作事件流

日誌對於排除生產問題或了解用戶行為至關重要。但是，12-Factor 應用方法論並不適合處理日誌的管理。

相反，應將日誌條目作為事件流，寫入標準輸出，並將其發送到單獨的服務進行分析和存檔。機器人流程自動化（RPA）技術可作為處理和分析日誌的第三方服務。執行環境將決定如何處理該數據流。這為反省應用程序的行為提供了更大的靈活性和能力。

12：後台管理任務當作一次性進程運行

這一原則實際上與開發無關，而是與應用程序管理有關。管理進程應在與應用程序常規長期運行進程相同的環境中運行。在本地部署中，開發人員可以直接使用應用程序簽出目錄內的 Shell 命令來執行一次性管理進程。

結論

使用 12-Factor 應用方法論開發應用程序，可以提高效率，加快發布速度。在開源開發中，偏離某些指導原則可能是有意義的，但最好還是儘可能嚴格遵守這些指導原則。

開源的 12-Factor 應用是可能的。一個很好的例子是 Jitsi, （一個開源視頻會議平台）, 在疫情期間擴展了 100 倍的規模，取得了巨大成功，它就是採用 12-Factor 應用方法論構建的。

（題圖：MJ/4bc8b463-49d0-4702-8ad3-6a07a718d5d9）

via: https://opensource.com/article/21/11/open-source-12-factor-app-methodology

作者：Richard Conn 選題：lujun9972 譯者：trisbestever 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive