為什麼微軟、AWS都選擇無服務器架構？3分鍾讀懂其優勢和用例

在傳統的客戶端-服務器應用程序中，基於數據的所有API和端點都需要由開發人員實現。

無服務器架構（server less）是指依賴第三方服務運行的企業IT基礎架構，而不是使用內部部署架構。

但這並不意味著不需要服務器，而是企業無需購買、租用或配置物理服務器，從而無需預配置或管理服務器即可運行代碼（由服務商提供基礎設施）。

無服務器基礎結構不必獨立於基於服務器的基礎結構運行，某些代碼可以在服務器上運行。Web應用程序就是一個很好的例子，它結合了微服務和無服務器代碼來使它們運行。

無服務器基礎架構可以分為兩個單獨的類別：後端即服務（BaaS）和功能即服務（FaaS）。

BaaS最初是作為移動架構（移動後端即服務或MBaaS），但已經發展為支持桌麵程序，而不僅僅是移動應用程序。

BaaS提供完整的在線服務，管理代碼的每個部分。通常，代碼將在觸發後不斷運行，因此向提供商支付訂閱。

BaaS使用相同的後端服務在各種應用程序的共享基礎架構上運行。提供BaaS基礎設施的供應商的例子有Parse，Kinvey，Buddy，Appcelerator和StackMob。

FaaS與BaaS不同，因為它僅提供執行開發人員設計的代碼的工具。

FaaS通過按需觸發代碼來工作，例如當某個事件發生時。這意味著你不必擔心管理操作，因為它們都是自動發生的，並且運行起來非常便宜，隻需支付在該觸發器上消耗的內容，在幾分之一秒內，測量內存和CPU使用率。

FaaS基礎結構的示例包括AWS Lambda、Azure Functions、IBM OpenWhisk和Google Cloud Functions。它們都支持大多數編程語言和運行時，包括Node.js、Python、.NET Core和Java。

無服務器基礎架構不適用於每個應用程序或服務，特別是FaaS設置的情況。

因為它專為快速查詢而設計，所以它最適合實時應用程序，例如數據分析、推送通知（如遊戲應用程序、傳輸更新應用程序和社交網絡或消息程序）以及其他不運行的應用程序經常，但在事件驅動的時間間隔，如數據庫清理。

由於無服務器基礎架構可以與微服務一起使用，因此還有其他應用程序可以使用此功能，包括API引導的SaaS應用程序或依賴第三方源數據的應用程序。

除了較低的前期成本以及通常基於消費的支付模式之外，無服務器基礎架構可以更容易維護，提供商管理維護確保它們按需啟動和運行。

這意味著你不必聘請工程師來管理服務器，開發人員可以專注於編寫代碼和創新。這也意味著企業可以更好地響應不斷變化的市場條件，調整代碼而不必考慮它將駐留在何處。

FaaS特別提供了進一步的好處。例如，用戶不必等待HTTP請求或API調用，因為代碼僅在需要時執行。提供商管理包括擴展在內的所有其他內容，使其成為管理資源的更簡單方法。

一旦執行了任務，容器就會被提供者停止服務，因此你不會為休眠容器付費。

因為基礎架構的管理依賴於提供者而不是開發人員，所以存在一些缺點。

最大的問題之一是開發人員或程序員不會像管理基礎架構那樣擁有相同的應用程序可見性。因此，如果代碼出現中斷或問題，他們可能無法立即解決問題。

供應商鎖定也是一個很大的挑戰。如果在一個服務上設置所有內容，那麼在提供商之間切換是很棘手的，有時候，實施的複雜性可能意味著在提供支持和切換時在經濟上不可行。

無服務器架構的其他限製是因為它使用共享基礎架構，在初始服務器請求期間可能會出現一些級別的延遲，這可能會使應用程序顯得遲緩。

無服務器功能都是無狀態的(stateless )，狀態信息不能從一個函數的調用傳遞給下一個。有些應用程序不適合無服務器體係結構，例如長時間運行的進程，因為FaaS被設計為在代碼啟動後銷毀容器。

雖然無服務器平台也許可以輕鬆滿足初始部署和縮放等需求，但依然無法完全省略基礎架構運維。

歡迎關注“芯享家科技”，一起來聊有價值的科技知識！