小米官宣：2023年上半年出貨量中國第一！
今日早間，小米電視官方微博帶來消息，稱2023年小米電視上半年出貨量達到了中國第一，同時還表示小米電視的巨屏風暴即將開始。“公布一個好消息2023年#小米電視上半年出貨量中國
12-Factor 應用方法論 為在短時間內構建應用程序并使其具有可擴展性提供了指導。它由 Heroku 的開發人員創建，用于軟件即服務（SaaS）應用程序、網絡應用程序以及可能的通信平臺即服務（CPaaS）。在有效組織項目和管理可擴展應用程序方面，12 要素應用程序方法論對開源開發具有強大的優勢。
12-Factor 應用方法論的規則非常嚴格，也是開發和部署 SaaS 應用程序的基石，并且不受任何編程語言或數據庫的限制。
一個說明圖表：顯示了一個由左邊的綠線代表的代碼庫，引導到右邊由綠色方塊代表的四個部署。橙色方塊代表暫存環境，而紅色方塊代表生產環境。
一個說明圖表：顯示了一個由左邊的綠線代表的代碼庫，引導到右邊由綠色方塊代表的四個部署。橙色方塊代表暫存環境，而紅色方塊代表生產環境。
每個應用程序都應該有一個具有多個不同環境/部署的代碼庫。
開發人員不應僅僅為了在不同環境中設置而開發另一個代碼庫。不同的環境代表不同的狀態，但這些不同的環境應該共享同一個代碼庫。
在許多開源項目都存儲在 GitLab 這樣的版本控制系統中的情況下，一個環境可以被視為一個分支。例如，你可以在任何中央版本控制系統中為名為 VoIP-app 的云 VoIP 應用程序創建一個單獨的存儲庫，然后創建兩個分支：開發分支（development）和暫存分支（staging），并將主分支（master）作為發布分支。
應聲明所有依賴關系。你的應用程序可能會依賴外部系統工具或庫，但不應對系統工具或庫有任何 隱含的
在代碼庫中包含依賴關系可能會產生問題，特別是在開源項目中，外部庫的更改可能會將錯誤引入代碼庫。例如，代碼庫可能會使用一個外部庫，但沒有明確聲明該依賴關系或版本。如果外部庫更新到更新的、未經測試的版本，這可能會與你的代碼產生兼容性問題。如果明確聲明了依賴關系及其正確版本，你的代碼庫就不會出現這種問題。
根據技術棧的不同，最好使用軟件包管理器，通過讀取代表依賴庫名稱和版本的依賴庫聲明清單，在各自的系統上下載依賴庫。
當需要支持多個環境或客戶端時，配置就成了應用程序的重要組成部分。不同部署之間的配置應存儲在環境變量中。這樣就可以在部署之間輕松更改配置，而無需更改代碼。
對于閉源應用程序來說，這一原則是有益的，因為你不會希望數據庫連接信息或其他秘密數據等敏感信息被公開。然而，在開放源代碼開發中，這些細節都是公開的。在這種情況下，好處是你不需要反復修改代碼。你只需這樣設置變量，只需改變環境，就能讓代碼完美運行。
所有后備服務（如數據庫、外部存儲或消息隊列）都被視為附加資源，由執行環境附加或分離。根據這一原則，如果這些服務的位置或連接細節發生變化，仍無需更改代碼。這些細節可以在配置中找到。
備份服務可以從部署中快速附加或分離。例如，如果基于云的電子表格的數據庫無法正常工作，開發人員應該能夠創建一個從最近備份恢復的新數據庫服務器，而無需對代碼庫進行任何更改。
12-Factor 應用方法論要求嚴格區分構建、發布和運行階段。
通過嚴格區分這些階段，我們可以避免代碼中斷，使系統維護更加易于管理。
應用程序作為一個或多個進程的集合在執行環境中執行。這些進程是無狀態的，其持久化數據存儲在數據庫等后臺服務中。
這對開源非常有用，因為使用某版本應用程序的開發人員可以在其云平臺上創建多節點部署，以實現可擴展性。數據不會在其中持久化，因為如果其中任何一個節點崩潰，數據就會丟失。
你的應用程序應作為獨立的服務，獨立于其他應用程序。它它應該能通過URL供其他服務訪問，以服務形式存在。這樣，你的應用程序就可以在需要時作為其他應用程序的資源。利用這一概念，你可以構建 REST API。
該原則也稱為并發原則，它表明應用程序中的每個進程都應能夠自我擴展、重啟或克隆。
開發人員可以創建多個進程，并將應用程序的負載分配給這些進程，而不是將一個進程變大。通過這種方法，你可以將每種工作負載分配給一個進程類型，從而構建能處理不同工作負載的應用程序。
你的應用應當基于簡單的進程構建，因此開發者可以放大進程的同時還能在發生問題時重啟它們。這使得應用的進程易于丟棄。
根據這一原則構建應用程序意味著代碼的快速部署、快速彈性擴展、更靈活的發布流程以及穩健的生產部署。所有這些在開源開發環境中都非常有用。
同一項目的團隊應使用相同的操作系統、支持服務和依賴關系。這樣可以降低出現錯誤的可能性，減少開發所需的時間。
由于開源項目的開發人員分散在各地，他們可能無法就所使用的系統、服務和依賴關系進行 溝通 ，因此將這一原則付諸實踐對于開源項目來說可能是一個挑戰。減少這些差異的一種可能性是制定開發指南，建議使用何種操作系統、服務和依賴關系。
日志對于排除生產問題或了解用戶行為至關重要。但是，12-Factor 應用方法論并不適合處理日志的管理。
相反，應將日志條目作為事件流，寫入標準輸出，并將其發送到單獨的服務進行分析和存檔。機器人流程自動化（RPA）技術可作為處理和分析日志的第三方服務。執行環境將決定如何處理該數據流。這為反省應用程序的行為提供了更大的靈活性和能力。
這一原則實際上與開發無關，而是與應用程序管理有關。管理進程應在與應用程序常規長期運行進程相同的環境中運行。在本地部署中，開發人員可以直接使用應用程序簽出目錄內的 Shell 命令來執行一次性管理進程。
使用 12-Factor 應用方法論開發應用程序，可以提高效率，加快發布速度。在開源開發中，偏離某些指導原則可能是有意義的，但最好還是盡可能嚴格遵守這些指導原則。
開源的 12-Factor 應用是可能的。一個很好的例子是 Jitsi, （一個開源視頻會議平臺）, 在疫情期間擴展了 100 倍的規模，取得了巨大成功，它就是采用 12-Factor 應用方法論構建的。
本文鏈接：http://www.www897cc.com/showinfo-26-27581-0.html12-Factor 應用方法論的開源開發者指南
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： Rust、Zig，能夠干翻Java、C？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號