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

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

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

現(xiàn)代化的壓力

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

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

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

事務(wù)和事件

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

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

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

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

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

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

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

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

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

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

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

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