企業(yè)可以選擇為現(xiàn)有應(yīng)用程序構(gòu)建云前端計算元素，而無需將整個應(yīng)用程序遷移到云端。而為了實現(xiàn)該操作，他們可以選擇多種技術(shù)，包括無服務(wù)器計算和容器。

使用Web服務(wù)器作為前端，為應(yīng)用程序提供在線訪問，并不是一個新主意。網(wǎng)頁與托管流程的緊密集成也不是新想法-通用網(wǎng)關(guān)接口(CGI)已經(jīng)使用了數(shù)十年。但是，為云計算設(shè)計前端創(chuàng)建了一個模型：其中演示文稿或GUI功能托管在云資源上，以實現(xiàn)可擴展性、彈性和性能改進，而應(yīng)用程序后端則可以位于任何地方。

企業(yè)仍然可以通過傳統(tǒng)的Web服務(wù)器和CGI方法部署此混合模型，但是現(xiàn)代云技術(shù)提供了更好的選擇。通過部署云前端，依靠無服務(wù)器技術(shù)和微服務(wù)，IT團隊可以減少開銷并削減成本，同時還可以為其應(yīng)用程序增加靈活性和可擴展性。

[[330054]]

現(xiàn)代化的壓力

典型的現(xiàn)代應(yīng)用程序前端集中在API網(wǎng)關(guān)或代理上。該代理元素提供一系列API，可從網(wǎng)頁或移動應(yīng)用程序調(diào)用，這些API可以連接到Web服務(wù)器，也可以通過編程語言(例如JavaScript)直接從網(wǎng)頁調(diào)用。API的背后是應(yīng)用程序本身的軟件組件，托管在云或數(shù)據(jù)中心中。

盡管這種前端云計算模型僅在過去兩年中才開始流行，但已經(jīng)存在現(xiàn)代化壓力。在應(yīng)用程序前端設(shè)計中，前沿做法是使用微服務(wù)，微服務(wù)是邏輯的小型無狀態(tài)組件，可以動態(tài)擴展或替換。無服務(wù)器是一種應(yīng)用程序架構(gòu)，僅在執(zhí)行代碼(例如這些微服務(wù))時才消耗資源。

微服務(wù)和無服務(wù)器方法使前端完全可擴展，并能夠靈活應(yīng)對故障。通過使用這種類型的策略，無需服務(wù)器管理，云客戶端只需為主動托管付費—低活動級別的成本比不上永遠在線的云托管應(yīng)用程序。

事務(wù)和事件

微服務(wù)和無服務(wù)器設(shè)計是關(guān)于事件的，而其他應(yīng)用程序設(shè)計是圍繞事務(wù)構(gòu)建。在為微服務(wù)和無服務(wù)器設(shè)計云前端時，開發(fā)人員必須考慮與事件相關(guān)的事務(wù)。

在典型的應(yīng)用程序中，用戶通過多步驟過程創(chuàng)建事務(wù)。事務(wù)的步驟對應(yīng)于事件。每個事件都必須進入事務(wù)性背景中。微服務(wù)和無服務(wù)器開發(fā)人員通常將事務(wù)分解為來源(即移動設(shè)備或Web服務(wù)器)的事件。

API網(wǎng)關(guān)模型適合無服務(wù)器部署。基于來自前端Web服務(wù)器或移動應(yīng)用程序的調(diào)用，網(wǎng)關(guān)可以調(diào)用適當(dāng)?shù)臒o服務(wù)器代碼。前端也可以訪問在線數(shù)據(jù)庫。然后，此訪問將觸發(fā)無服務(wù)器工作流。例如，基于此模型構(gòu)建的應(yīng)用程序訪問數(shù)據(jù)庫以創(chuàng)建訂單，然后觸發(fā)無服務(wù)器工作流，以將已處理的訂單轉(zhuǎn)移到后端應(yīng)用程序以進行庫存管理。

有些應(yīng)用程序前端很豐富，更像是分布式處理功能，而不是簡單的事件處理程序。在這些設(shè)計中，云開發(fā)人員可以使用工作流編排工具(例如AWs step Functions或Microsoft Azure的Durable Functions)來構(gòu)建復(fù)雜的多無服務(wù)器功能工作流。這些工作流程類似于傳統(tǒng)的應(yīng)用程序邏輯，只是它們被分解為微服務(wù)以最大化云價值。

微服務(wù)、無服務(wù)器和容器

主要云供應(yīng)商提供一種方法，使用戶可在微服務(wù)到無服務(wù)器部署和始終可用的容器部署之間輕松切換。微軟更直接地側(cè)重于微服務(wù)部署，盡管AWS和谷歌也啟用了它。

應(yīng)用程序團隊應(yīng)從微服務(wù)角度思考，而不是無服務(wù)器計算。微服務(wù)架構(gòu)直接解決了圍繞無服務(wù)器計算的常見問題之一：當(dāng)節(jié)約使用時，無服務(wù)器很具成本效益。無服務(wù)器的客戶只需為使用付費，因此，隨著使用的增加，無服務(wù)器激活的成本可能超過專用始終在線的容器的成本—托管相同應(yīng)用程序代碼。

狀態(tài)控制是構(gòu)建無服務(wù)器應(yīng)用程序的重要考慮因素，特別是在應(yīng)用程序可能切換到更傳統(tǒng)的云原生容器托管時。微服務(wù)或無服務(wù)器功能是無狀態(tài)的。在激活之間無法存儲信息，這使得它適合按需激活、縮放和替換。因此，當(dāng)應(yīng)用程序涉及多個步驟且具有必須記住的背景信息時，必須提供狀態(tài)控制。

對于云前端的API網(wǎng)關(guān)模型，我們有多種方法可以控制狀態(tài)。當(dāng)移動設(shè)備或Web服務(wù)器訪問應(yīng)用程序時，可提供狀態(tài)作為其在應(yīng)用程序中生成的事件的一部分。微服務(wù)或功能需要的所有信息都通過連接用戶界面的狀態(tài)信息傳遞給它。API網(wǎng)關(guān)可以部署用于記住背景信息，使其成為狀態(tài)源。或者，微服務(wù)或功能可以從后端數(shù)據(jù)庫獲取狀態(tài)信息，該數(shù)據(jù)庫維護每個用戶事務(wù)的背景信息。

編排是一種在內(nèi)部流程或工作流圖中維護狀態(tài)的方法。為了使用這種方法，首先要調(diào)查你所選的云提供商能否提供這種映射，對于已托管在容器中的微服務(wù)。如果你正在考慮將一些無服務(wù)器微服務(wù)過渡到持久性容器中，那么，重點是，在提交給特定的云提供商和業(yè)務(wù)流程模型之前，了解如何做到這一點。

同時，仔細觀察無服務(wù)器工作流程。云提供商必須按需加載和運行無服務(wù)器組件，這些組件處于非活動狀態(tài)，因此執(zhí)行時會有延遲。工作流中太多的無服務(wù)器元素可能導(dǎo)致響應(yīng)時間顯著增加。如果將相同的組件部署在常規(guī)容器中，則不會發(fā)生此問題。

微服務(wù)和無狀態(tài)執(zhí)行定義了云前端的架構(gòu)，而非無服務(wù)器。無服務(wù)器托管模型適用于很多應(yīng)用程序，但是當(dāng)以其他方式執(zhí)行它們時，很多應(yīng)用程序更具成本效益，甚至表現(xiàn)更好。如果提前規(guī)劃工作流，則可以發(fā)現(xiàn)無服務(wù)器托管可能會影響成本和性能的應(yīng)用程序。不要盲目追求最新的做法，最新做法不一定是最好做法。