使用Web服务器作为前端，为应用程序提供在线访问，并不是一个新主意。网页与托管流程的紧密集成也不是新想法-通用网关接口(CGI)已经使用了数十年。但是，为云计算设计前端创建了一个模型：其中演示文稿或GUI功能托管在云资源上，以实现可扩展性、弹性和性能改进，而应用程序后端则可以位于任何地方。
企业仍然可以通过传统的Web服务器和CGI方法部署此混合模型，但是现代云技术提供了更好的选择。通过部署云前端，依靠无服务器技术和微服务，IT团队可以减少开销并削减成本，同时还可以为其应用程序增加灵活性和可扩展性。
现代化的压力
典型的现代应用程序前端集中在API网关或代理上。该代理元素提供一系列API，可从网页或移动应用程序调用，这些API可以连接到Web服务器，也可以通过编程语言(例如JavaScript)直接从网页调用。API的背后是应用程序本身的软件组件，托管在云或数据中心中。
尽管这种前端云计算模型仅在过去两年中才开始流行，但已经存在现代化压力。在应用程序前端设计中，前沿做法是使用微服务，微服务是逻辑的小型无状态组件，可以动态扩展或替换。无服务器是一种应用程序架构，仅在执行代码(例如这些微服务)时才消耗资源。
微服务和无服务器方法使前端完全可扩展，并能够灵活应对故障。通过使用这种类型的策略，无需服务器管理，云客户端只需为主动托管付费—低活动级别的成本比不上永远在线的云托管应用程序。
事务和事件
微服务和无服务器设计是关于事件的，而其他应用程序设计是围绕事务构建。在为微服务和无服务器设计云前端时，开发人员必须考虑与事件相关的事务。
在典型的应用程序中，用户通过多步骤过程创建事务。事务的步骤对应于事件。每个事件都必须进入事务性背景中。微服务和无服务器开发人员通常将事务分解为来源(即移动设备或Web服务器)的事件。
API网关模型适合无服务器部署。基于来自前端Web服务器或移动应用程序的调用，网关可以调用适当的无服务器代码。前端也可以访问在线数据库。然后，此访问将触发无服务器工作流。例如，基于此模型构建的应用程序访问数据库以创建订单，然后触发无服务器工作流，以将已处理的订单转移到后端应用程序以进行库存管理。
有些应用程序前端很丰富，更像是分布式处理功能，而不是简单的事件处理程序。在这些设计中，云开发人员可以使用工作流编排工具(例如AWsstepFunctions或MicrosoftAzure的DurableFunctions)来构建复杂的多无服务器功能工作流。这些工作流程类似于传统的应用程序逻辑，只是它们被分解为微服务以最大化云价值。
微服务、无服务器和容器
主要云供应商提供一种方法，使用户可在微服务到无服务器部署和始终可用的容器部署之间轻松切换。微软更直接地侧重于微服务部署，尽管AWS和谷歌也启用了它。
应用程序团队应从微服务角度思考，而不是无服务器计算。微服务架构直接解决了围绕无服务器计算的常见问题之一：当节约使用时，无服务器很具成本效益。无服务器的客户只需为使用付费，因此，随着使用的增加，无服务器激活的成本可能超过专用始终在线的容器的成本—托管相同应用程序代码。
状态控制是构建无服务器应用程序的重要考虑因素，特别是在应用程序可能切换到更传统的云原生容器托管时。微服务或无服务器功能是无状态的。在激活之间无法存储信息，这使得它适合按需激活、缩放和替换。因此，当应用程序涉及多个步骤且具有必须记住的背景信息时，必须提供状态控制。
对于云前端的API网关模型，我们有多种方法可以控制状态。当移动设备或Web服务器访问应用程序时，可提供状态作为其在应用程序中生成的事件的一部分。微服务或功能需要的所有信息都通过连接用户界面的状态信息传递给它。API网关可以部署用于记住背景信息，使其成为状态源。或者，微服务或功能可以从后端数据库获取状态信息，该数据库维护每个用户事务的背景信息。
编排是一种在内部流程或工作流图中维护状态的方法。为了使用这种方法，首先要调查你所选的云提供商能否提供这种映射，对于已托管在容器中的微服务。如果你正在考虑将一些无服务器微服务过渡到持久性容器中，那么，重点是，在提交给特定的云提供商和业务流程模型之前，了解如何做到这一点。
同时，仔细观察无服务器工作流程。云提供商必须按需加载和运行无服务器组件，这些组件处于非活动状态，因此执行时会有延迟。工作流中太多的无服务器元素可能导致响应时间显着增加。如果将相同的组件部署在常规容器中，则不会发生此问题。
微服务和无状态执行定义了云前端的架构，而非无服务器。无服务器托管模型适用于很多应用程序，但是当以其他方式执行它们时，很多应用程序更具成本效益，甚至表现更好。如果提前规划工作流，则可以发现无服务器托管可能会影响成本和性能的应用程序。不要盲目追求最新的做法，最新做法不一定是最好做法。
