使用Web服務器作為前端，為應用程序提供在線訪問，并不是一個新主意。網頁與托管流程的緊密集成也不是新想法-通用網關接口(CGI)已經使用了數十年。但是，為云計算設計前端創建了一個模型：其中演示文稿或GUI功能托管在云資源上，以實現可擴展性、彈性和性能改進，而應用程序后端則可以位于任何地方。
企業仍然可以通過傳統的Web服務器和CGI方法部署此混合模型，但是現代云技術提供了更好的選擇。通過部署云前端，依靠無服務器技術和微服務，IT團隊可以減少開銷并削減成本，同時還可以為其應用程序增加靈活性和可擴展性。
現代化的壓力
典型的現代應用程序前端集中在API網關或代理上。該代理元素提供一系列API，可從網頁或移動應用程序調用，這些API可以連接到Web服務器，也可以通過編程語言(例如JavaScript)直接從網頁調用。API的背后是應用程序本身的軟件組件，托管在云或數據中心中。
盡管這種前端云計算模型僅在過去兩年中才開始流行，但已經存在現代化壓力。在應用程序前端設計中，前沿做法是使用微服務，微服務是邏輯的小型無狀態組件，可以動態擴展或替換。無服務器是一種應用程序架構，僅在執行代碼(例如這些微服務)時才消耗資源。
微服務和無服務器方法使前端完全可擴展，并能夠靈活應對故障。通過使用這種類型的策略，無需服務器管理，云客戶端只需為主動托管付費—低活動級別的成本比不上永遠在線的云托管應用程序。
事務和事件
微服務和無服務器設計是關于事件的，而其他應用程序設計是圍繞事務構建。在為微服務和無服務器設計云前端時，開發人員必須考慮與事件相關的事務。
在典型的應用程序中，用戶通過多步驟過程創建事務。事務的步驟對應于事件。每個事件都必須進入事務性背景中。微服務和無服務器開發人員通常將事務分解為來源(即移動設備或Web服務器)的事件。
API網關模型適合無服務器部署。基于來自前端Web服務器或移動應用程序的調用，網關可以調用適當的無服務器代碼。前端也可以訪問在線數據庫。然后，此訪問將觸發無服務器工作流。例如，基于此模型構建的應用程序訪問數據庫以創建訂單，然后觸發無服務器工作流，以將已處理的訂單轉移到后端應用程序以進行庫存管理。
有些應用程序前端很豐富，更像是分布式處理功能，而不是簡單的事件處理程序。在這些設計中，云開發人員可以使用工作流編排工具(例如AWsstepFunctions或MicrosoftAzure的DurableFunctions)來構建復雜的多無服務器功能工作流。這些工作流程類似于傳統的應用程序邏輯，只是它們被分解為微服務以最大化云價值。
微服務、無服務器和容器
主要云供應商提供一種方法，使用戶可在微服務到無服務器部署和始終可用的容器部署之間輕松切換。微軟更直接地側重于微服務部署，盡管AWS和谷歌也啟用了它。
應用程序團隊應從微服務角度思考，而不是無服務器計算。微服務架構直接解決了圍繞無服務器計算的常見問題之一：當節約使用時，無服務器很具成本效益。無服務器的客戶只需為使用付費，因此，隨著使用的增加，無服務器激活的成本可能超過專用始終在線的容器的成本—托管相同應用程序代碼。
狀態控制是構建無服務器應用程序的重要考慮因素，特別是在應用程序可能切換到更傳統的云原生容器托管時。微服務或無服務器功能是無狀態的。在激活之間無法存儲信息，這使得它適合按需激活、縮放和替換。因此，當應用程序涉及多個步驟且具有必須記住的背景信息時，必須提供狀態控制。
對于云前端的API網關模型，我們有多種方法可以控制狀態。當移動設備或Web服務器訪問應用程序時，可提供狀態作為其在應用程序中生成的事件的一部分。微服務或功能需要的所有信息都通過連接用戶界面的狀態信息傳遞給它。API網關可以部署用于記住背景信息，使其成為狀態源。或者，微服務或功能可以從后端數據庫獲取狀態信息，該數據庫維護每個用戶事務的背景信息。
編排是一種在內部流程或工作流圖中維護狀態的方法。為了使用這種方法，首先要調查你所選的云提供商能否提供這種映射，對于已托管在容器中的微服務。如果你正在考慮將一些無服務器微服務過渡到持久性容器中，那么，重點是，在提交給特定的云提供商和業務流程模型之前，了解如何做到這一點。
同時，仔細觀察無服務器工作流程。云提供商必須按需加載和運行無服務器組件，這些組件處于非活動狀態，因此執行時會有延遲。工作流中太多的無服務器元素可能導致響應時間顯著增加。如果將相同的組件部署在常規容器中，則不會發生此問題。
微服務和無狀態執行定義了云前端的架構，而非無服務器。無服務器托管模型適用于很多應用程序，但是當以其他方式執行它們時，很多應用程序更具成本效益，甚至表現更好。如果提前規劃工作流，則可以發現無服務器托管可能會影響成本和性能的應用程序。不要盲目追求最新的做法，最新做法不一定是最好做法。
