深析無服務架構利弊「無服務架構的優勢有哪些」

雲計算，容器，API和自動化技術的進步以及後端即服務（backend-as-a-service）產品的日益複雜，為雲提供商提供了無伺服器架構（Serverless）雲產品的機會。但這並不意味著伺服器不再需要，這只是意味著開發人員不再需要擔心基礎設施，因為一切都由雲提供商負責。使用這種方法，開發人員只需部署適當的代碼，其他一切由雲提供商自動管理。看上去真的不錯。

無伺服器架構如何工作

在傳統的Web應用程序架構中，你必須管理基礎架構，並確保其滿足可擴展性和安全性需求。例如，客戶端在一邊，伺服器在另一邊。客戶端發送一個「請求」，伺服器回復「響應」。但是，如果無法滿足應用程序需求，則很快就要擴展伺服器端了。

現在，這可以通過多種方式完成。一種方法是通過擴展伺服器，通過使用更強性能的伺服器增加容量。另一種方法是橫向擴展伺服器，添加額外的伺服器來處理負載。在這種情況下，還必須部署負載平衡，以便「決定」如何平衡兩台或多台伺服器之間的負載。這意味著你必須管理此設置，對其中一個伺服器發生故障或負載平衡發生故障時採取預防措施。

在成本方面，即使沒有充分利用，也必須支付所有這些組件的分配，包括虛擬機、負載平衡，存儲等。這需要對這些資源進行適當規劃和管理的投資。雖然一些雲提供商提供「按需付費」模式和「彈性定價」，但仍然需要決定如何實施架構。對於Web應用程序開發人員來說，通常是後者。

無伺服器模型提供了完全不同的方法。與傳統架構不同，無服務架構在無狀態計算容器中運行，這些容器是事件觸發的，短暫的（只能持續一次調用），並由第三方完全管理。就像一個「黑盒子」，這個服務你只需上傳代碼並實時自動處理。當一個請求進來時，就會運行你的Lambda功能的容器。

在成本方面，使用無伺服器模型，通常僅支付服務請求和運行代碼所需的計算時間。計費以100毫秒為單位進行計量，使其具有成本效益，並且易於自動從每天幾個請求到每秒數千次都可以。

使用無伺服器架構的優點

•降低運營成本 – 如果你考慮這個問題，無服務架構本質上是一個外包解決方案。基礎設施不會消失。然而，與常規雲服務相比，事實上，只需要根據流量規模和形式支付需要的計算量，這可能會大大節省運營成本，特別是對於具有不同變化的早期和動態應用負載要求。

•無限可擴展性 – 極高的可擴展性在雲服務領域並不新鮮，但無服務架構將其提升到一個全新的水平。無服務架構的縮放功能不僅可以降低計算成本，還可以減少運行管理，因為縮放是自動的。使用無伺服器，無需明確添加和刪除實例到伺服器陣列，並讓供應商為你擴展應用程序。由於雲計算提供商根據每個請求執行擴展，所以甚至不需要考慮在內存不足之前可以處理多少並發請求的問題。

•分離問題 – 無伺服器幾乎迫使你實施關注模型的分離，通過該分離將應用程序分成不同的部分，以使每個部分都解決一個單獨的問題。

•隔離進程 – 在無伺服器環境中，每個Lambda函數都完全隔離。如果其中一個功能關閉，它不影響其他功能，它不會導致伺服器崩潰。

使用無伺服器架構的缺點

•缺乏控制權 – 通過任何外包策略，你都可以將某些系統的控制權給第三方供應商。由於系統停機，意外的限制，成本的變化，功能的喪失，強制的API升級等，這種缺乏控制可能會顯現出來。此外，如果需要專門的伺服器進行專門的流程，那麼必須自己運行這個專門的伺服器。一個無伺服器架構，在大多數情況下，提供商業化的基礎設施，將以廣義的方式運行你的流程。

•長時間運行流程的高成本 – 如果你的進程持續運行很長時間，則可能會需要運行自己的伺服器。因為這不僅涉及到成本，還涉及到擁有的技能或者想要投入運行自己的伺服器的專註；在評估這些解決方案時，請考慮所有這些方面。

•供應商鎖定將基礎架構管理完全外包給無伺服器提供商，無疑將自己鎖定到該供應商。每個供應商都有自己的標準和編程框架，不容易改變。在幾乎每一種情況下，無論從供應商使用的無伺服器功能，將由另一個供應商進行不同的實現。如果要切換供應商，幾乎肯定需要更新操作工具（部署，監控等），可能還需要更改代碼。

如果你將應用程序分解成微服務，則無伺服器架構是一個很好的選擇。它不太適合運行專門過程的長時間運行的應用程序。雖然無服務架構還流於趨勢，但是由於更多的開發者採用它並將其帶入主流，所以這個市場的所有玩家都期望有重要的創新和新功能。