有狀態和無狀態應用程序：它們如何影響 DevOps

2022/08/12

有狀態和無狀態是兩種不同類型的計算架構，它們定義了應用程序如何管理長期進程。一些系統本質上是無狀態的，而另一些系統則傾向於有狀態建模。無論您選擇哪種方法，都會影響設計和運營團隊構建和維護解決方案的方式。

在本文中，您將了解有狀態和無狀態應用程序之間的區別，以及何時可以使用它們。您還將看到這兩個模型如何影響 DevOps 實施的要求。

什麼是狀態？

服務的“狀態”是在一個事務或事件期間記錄並在另一個事務或事件期間調用的持久信息。最簡單的狀態示例之一是數據庫服務器：它管理需要安全存儲的存儲數據。保存在一個會話中的記錄必須可用於下一個會話。

需要仔細管理該狀態，以便將來可以使用它。外部系統不需要提供太多信息來引用先前的事件。一個簡單的標識符（例如支付交易編號）允許該服務恢復與該操作相關的其他數據，例如支付金額和送貨地址。

並非每個應用程序都有狀態。有些系統不處理長期存在的數據，或者緩存它只是為了提高性能。如果以前保存的數據丟失，它們仍然可以工作。

無狀態應用程序單獨處理每個事件。這些事件不知道彼此或應用程序正在運行的更大上下文。這種質量簡化了對無狀態系統的考慮。以前的活動不會影響當前的操作，不存在風險。

一些應用程序模糊了有狀態和無狀態模型之間的界限。同一個系統可以有狀態也可以沒有狀態，這取決於你從哪個角度來看待它。

從服務運營商的角度來看，客戶端 Web 應用程序通常被視為無狀態的。它們可以託管在獨立於任何其他組件的靜態 Web 服務器上。應用程序在使用過程中可能仍會累積狀態，例如保存在用戶設備上的設置和最近的頁面歷史記錄。這種形式的狀態與 DevOps 團隊無關，因為它不影響應用程序部署。

您可以通過查看應用程序存儲數據的方式來確定應用程序是否需要有狀態或無狀態部署模型。如果沒有持久性或數據僅存儲在用戶的設備或不相關的存儲提供商（如 Amazon S3）中，則沒有狀態。如果應用程序通過文件系統寫入和其他更改直接更改其環境，則應用程序將保持狀態，然後要求這些更改無限期地保持。

現代應用程序通常作為容器部署在雲中。容器被設計為可以在沒有副作用的情況下替換的臨時功能單元。這意味著它們主要是無狀態的計算組件。

然而，容器可以用來封裝有狀態的系統。持久卷提供了一種安裝持久存儲的方法，該存儲比單個容器實例更持久。與傳統的虛擬機和裸機部署相比，不同之處在於管理容器狀態的內部意圖。

容器化有狀態系統需要您預測狀態發生的位置和存儲方式。您不能天真地編寫任意文件系統路徑，因為它們不會映射到卷。如果沒有捲，如果容器停止或更換，數據將會丟失。可能需要一個重構週期來確保您的應用程序始終如一地寫入已安裝卷的路徑，因此您需要提前確定您的數據存儲需求。

DevOps 流程需要根據您使用的是有狀態服務還是無狀態服務進行調整。無狀態部署模型提供了更多的餘地。您可以輕鬆啟動新容器並跨多個分佈式節點擴展它們，而無需擔心對狀態的持續訪問。

有狀態的服務需要更周到的管理方法。每個應用程序實例都需要被授予訪問共享狀態的權限。這可能會施加縮放限制。例如，很少有 Kubernetes 發行版允許多個節點同時掛載具有寫訪問權限的捲。

這兩種類型的應用程序都需要主動監控，以便您在問題發生之前就知道問題。這對於有狀態的解決方案更為重要，因為您需要領先於存儲需求並確定卷安裝何時會影響容器調度選項。正常的備份策略也應該支持有狀態的部署。

該狀態還使 DevOps 過程變得複雜，難以準確地重現環境。問題可能存在於生產中，而在開發人員的機器上仍然難以捉摸。這些問題可能難以診斷。您可以通過為開發人員提供克隆環境的機制來使它們更易於管理，以便他們可以在沙箱中重現問題。

狀態總是增加複雜性和開銷。您需要配置和提供捲和數據庫等狀態管理解決方案，這使得持續集成管道更加複雜且難以維護。在大多數主要應用程序中，狀態是不可避免的，因此過於努力地保持系統無狀態可能是徒勞的。最好使用工具和培訓將有狀態的應用程序無縫集成到您的 DevOps 例程中，即使這意味著需要做更多的工作。

有狀態和無狀態應用程序之間的區別對於 DevOps 的成功非常重要。從 DevOps 的角度來看，有狀態的應用程序將更難以部署和維護，因為您需要授予每個實例對持久數據存儲的訪問權限。

無狀態應用程序與其環境完全分離，這通常使它們更容易在雲中進行容器化和擴展。然而，真正的無狀態系統相對較少，因此它們通常與有狀態數據存儲結合使用。在構建支持有狀態部署的工具的同時盡可能重構為無狀態組件通常是平衡優化的 DevOps 與系統功能需求的最有效方法。