為什麼選擇無伺服器模型？

　　無伺服器計算是一種執行模型，其中雲服務提供商將資源動態分配給負責執行的部分程式碼。在此模型中，客戶只需為實際使用的資源付費。

　　程式碼通常執行在無狀態容器中，可以由各種事件觸發，如 HTTP 請求、資料庫事件、佇列服務、監控警報、檔案上傳等。

　　 那麼為什麼選擇無伺服器模型呢？

　　無伺服器模型也稱為“函式即服務（FaaS）”，可以為 IT 團隊解決遇到的幾個傳統問題。當應用程式執行在公司專有伺服器上，並且公司需要負責提供和管理底層資源時，公司會發現：

　　必須為伺服器的運維付費，即使實際上沒有服務時也如此。

　　負責伺服器和所有底層資源的正常執行和維護。

　　必須維護伺服器安全和更新。

　　隨著使用量的增加或減少，必須相應地調整伺服器的規模。

　　在沒有專門管理伺服器的小公司中以及在擁有專用資源的大公司中，這些運維工作都需要花費很多時間，並佔用構建和維護應用程式等核心活動的資源。解決這些問題正是無伺服器計算誕生的意義所在。

　　 選擇無伺服器架構的好處

　　無伺服器架構正變得越來越流行。事實上，根據 MarketsandMarkets 的研究，該行業的收入預計將從 2020 年的約 76 億美元增加到 2025 年的約 211 億美元，複合年增長率（CAGR）為 22.7%。無伺服器架構採用率的增長歸因於新開發模式帶來的一系列優勢。

　　 即付即用

　　與基礎設施即服務（IaaS）模型（無論其實際使用情況如何，都需要租用硬體資源）不同，函式即服務（FaaS）模型基於“即用即付”：當事件呼叫函式時，只在執行函式所必要的嚴格時間內支付資源使用費。

　　只為實際使用的服務價值付費，可以讓團隊專注於產品及其獨特功能的開發，而非服務成本或實現。事實上，這些服務只是為了支援主要功能而整合的。

　　 可擴充套件性

　　可擴充套件性是公司快速發展的一個關鍵因素，因為它們需要垂直或水平地擴充套件基礎設施。這是一項頗具挑戰性的任務，通常需要大量的時間和精力，同時運維成本也會相應增加。

　　無伺服器環境消除了這些限制，允許公司以較小的規模啟動，然後隨著時間的推移支援其增長，期間不會中斷服務，計劃變更時也無需付出高昂的代價。

　　 靈活性和適應性

　　計算資源的供應和管理職責轉移到了雲廠商身上，公司就能夠快速採用新技術，使其可以快速、有效地響應業務和市場需求，而不必擔心基礎設施升級問題和所有相關成本。

　　 高可用性和容錯性

　　眾所周知，當今的公司業務嚴重依賴 IT，這也為什麼是 IT 服務必須保證高可用性。雲廠商提供了精心設計的全球基礎架構，能夠保證客戶負載的可用性和彈性。

　　 業務連續性和災難恢復

　　如今，業務連續性是公司關心的一個關鍵方面，因此各項活動必須有可靠的災難恢復戰略和計劃支援。提供無伺服器解決方案的雲廠商提供了很多高階功能，有助於自動恢復應用程式和底層系統應對任何型別的災難（自然災害、網路攻擊、硬體缺陷等）。

　　 無伺服器架構：需要考慮的關鍵方面

　　儘管採用無伺服器架構的優勢眾多，但仍有一些問題需要考慮。我們來看看在決定採用這種新的開發模式時要牢記的關鍵挑戰。

　　 供應商鎖定

　　對於無伺服器架構，在設計和遷移階段必須考慮供應商鎖定問題。通常，這些型別的架構在各個供應商的“花園圍牆”中更容易開發。

　　這正是為什麼公司必須從一開始就清楚地瞭解從一個供應商過渡到另一個供應商時可能出現的關鍵問題：

　　並非所有供應商的執行時和程式語言支援都是統一的，他們還會慢慢調整這些內容。

　　業界缺乏用於描述觸發無伺服器程式碼執行的事件的標準化格式。

　　一些平臺使用專有或內部開發的工具進行打包和部署。

　　為了緩解這些問題，負責促進雲原生實施開放標準傳播的雲原生計算基金會（CNCF）維護了一個觀察站，來跟蹤這些按組織分類的無伺服器產品。CNCF 支援開發、開放標準和解決方案，例如用於在雲端和本地實施 FaaS 服務的 CloudEvents（事件資料的標準化格式）和 Knative 等。

　　 估算成本的挑戰

　　由於 FaaS 服務的定價模式是按使用付費，因此很難估算成本。在沒有固定費用的情況下，公司需要在必要時支付資源使用費，因此當應用程式實施到生產環境中時，公司經常會遇到令人討厭的意外。

　　分析不同供應商的報價是一個好主意。公司實際上可能會發現，不同廠商在成本、免費可用資源等方面有著顯著的差異。

　　這裡有一個有趣的估算工具是無伺服器成本計算器，它可以模擬計算一些最流行平臺的使用成本，例如 AWS Lambda、Azure Functions、Google Cloud Functions 和 IBM OpenWhisk。

　　 冷啟動

　　在無伺服器正規化中，資源只有在實際使用時才會被計費。出於經濟性考慮，在企業實際不使用資源時，雲廠商便會將資源停掉。如此一來，有時可能會出現啟用延遲（冷啟動）。冷啟動是指從呼叫函式到例項啟用和響應請求所需的時間之間的延遲。以下為會影響冷啟動問題的三個因素：

　　使用的程式語言

　　已分配和可用的資源

　　依賴項的數量和整體應用程式的複雜性

　　因此，處理設計到的每個引數、優化函式啟動時間是非常重要的。企業可以採用雲廠商推薦的特定技術，例如 AWS 用於 Lambda 函式的技術，或 Google Cloud Platform 用於 Cloud Run 函式的技術。

　　 安全風險

　　雖然所有云廠商都提供了先進的安全系統，但要知道，為多個客戶提供服務的伺服器自然比專用本地伺服器更容易受到安全問題的影響。這是由於存在更大的事件源集，同時也增加了潛在的攻擊面。一些常見的風險是由於依賴從第三方軟體（如開源包和庫）獲得的無伺服器函式和分散式拒絕服務（DDoS）攻擊導致的。

　　 總結

　　儘管在採用無伺服器架構時可能會遇到各種挑戰，但在大多數情況下，使用帶來的收益超過了關鍵問題帶來的風險。此外，謹慎選擇供應商以避免被鎖定、實施前文描述的各種措施來減輕冷啟動等，可以很容易地發現和解決一些問題。