CN111324346A - 一种基于Serverless的前端应用构建方法和系统 - Google Patents

Abstract

本发明涉及一种基于Serverless的前端应用构建方法和系统，能够实现前端应用的动态迭代更新。本发明将Serverless的概念向前端进行延伸，将前端应用的运行时和前端UI的定义分离，以无状态函数构成的函数包的形式定义前端UI组件，并以远程服务的形式提供，形成前端容器应用和后端函数包服务两部分，以服务的形式提供组件代码并在前端动态加载。在开发过程中，开发人员并行开发组件，并通过管理接口向函数包服务添加代码即可实现部署，从而形成一个可横向扩展的、动态的、细粒度的、持续的迭代开发的过程，并降低前端系统迭代升级的技术门槛与潜在风险。

Description

一种基于Serverless的前端应用构建方法和系统

技术领域

本发明涉及一种基于Serverless架构的，可动态迭代更新的前端应用构建方法和系统，属于计算机技术应用领域。

背景技术

随着Web技术的不断发展，Web应用的功能逐渐丰富，界面复杂度也随之增加。传统的网站架构采用单体应用的架构，前后端代码位于一个代码库内，使用MVC模式，将后端代码嵌入前端模板中，每次访问时由后端根据模板生成前端页面。这种模式下，前端功能较为单一，可交互性不强，而开发者也没有明确区分前后端的概念，当系统规模逐渐增长后，开发和维护成本将迅速增长。

为此，业界提出了前后端分离的开发模式，将前端独立，使用AJAX技术动态地从后端请求数据，在约定前后端接口的情况下，前端开发人员可以独立迭代前端子系统，而不必关心后端的实现，从而实现解耦。此后，前端领域提出了工程化的概念，前端由前端页面转向前端应用，前端结构越来越复杂，所承载的功能也越来越强大。然而，虽然设计模式不断优化，前端应用从后端独立后，本身却仍基于单体应用模式。随着时间推移，前端本身越来越臃肿，维护的成本越来越高，出现了“前端巨无霸”的情况，使得前端应用在开发维护等方面出现了一系列问题。

一个Web应用的前端的落地涉及开发部署维护等多个环节，目前存在的问题有：

1)单体应用阻断并行开发，修改任何模块都需要重新打包、停机部署整个应用；

2)模块耦合，单一模块崩溃容易引起整个应用失效；

3)代码可读性差，修改单一模块需要从入口开始花费大量精力阅读业务无关代码；

4)代码全部位于一个代码库中，版本管理中容易出现代码冲突和覆盖的问题。

目前，存在一些技术和方法用于解决部分问题。为解决代码可维护性、可读性差的问题，前端框架方面，出现了诸如React、Vue.js等库，组件化地构建前端，对前端代码模块进行了良好的划分，使得各组件可以较为独立地并行开发，从而降低了代码的耦合度。此外，Redux借鉴了有限状态机的思想，对前端状态和行为进行了更严格的控制，从而提高前端的可控性，避免前端状态失控，降低开发难度。然而，上述技术仅在开发模式上进行了优化，其应用仍基于单体应用架构，在打包构建方面依然存在问题。并且，由于引入了更复杂的技术栈，反而增加了应用在部署时的难度。

在后端领域，近年来出现了微服务的概念，以服务为基本单位将后端分解为了更细粒度的独立单元，模块化地组合形成后端系统。每个微服务都能够独立地运行和维护，对于单个服务不仅降低了开发难度，而且提高了系统的弹性和灵活性，有助于更好地进行分工和协作。但由于微服务单元完全独立，因此需要部署多套子系统，这增加了系统部署和系统环境配置的难度。

为此，Serverless架构(无服务器架构)将微服务中的运行时从子系统中剥离，采用“函数即服务”的理念，一个函数即是一个服务，仅在需要时运行，返回结果后即结束，而从硬件到运行时等各种环境则由Serverless平台自动化地维护，从而使得开发人员只需关心业务逻辑的实现。由于运行时的分离，业务模块的维护变得十分简单，只需上传函数代码即可实现服务的部署。同时，由于函数仅按需启动，而非传统微服务需要程序持续运行，因此也避免了服务更新需要停机造成的服务不可用问题。

而在前端领域，为了解决前端的架构问题，借鉴于微服务架构，微前端将此概念向前端进行了延伸，以服务为基本单元将整个Web应用分解为贯通前后端的子应用，每个前端子应用对应于后端的一个微服务，因此也被称为前端微服务化或垂直系统的前端一体化。每一个子应用都可由一个独立的团队端到端、全栈式开发部署。然而，同微服务一样，由于系统被分解为独立的子系统，应用部署的难度也随之增加。

在现实条件下，特别是一些外包场景下，开发者与系统的实际部署使用方角色分离，且使用方的系统管理员缺乏足够计算机专业知识，系统的升级维护是个非常麻烦的问题，系统的迭代需要开发方频繁派驻人员协助部署，效率低下，且访问生产环境始终存在风险。

发明内容

本发明解决的技术问题：克服现有技术的不足，将Serverless的概念向前端延伸，提供一种Serverless化的Web前端应用构建方法，具有动态迭代升级、无需管理系统环境的优点，不同团队仅使用纯函数并行、独立地开发前端UI组件，并通过管理接口上传组件代码即可实现升级。各项服务在一次部署后便无需修改，从而降低前端迭代升级的门槛和成本。

本发明解决其技术问题所采用的技术方案是：

一种基于Serverless的前端应用构建方法，包括以下步骤：

在前端建立容器应用；

所述容器应用从后端的函数包服务中获取函数包并构建所需的组件，实现页面的加载。

进一步地，所述函数包服务采用以下方式建立：

在后端设置函数包服务的管理接口；

设计并规划页面样式和布局，并构建一个入口组件函数包，该入口组件函数包的渲染方法包含对页面中所需的其他组件对应的函数包的引用，构建此入口组件函数包后，将其通过管理接口添加至函数包服务中；

并行开发入口组件引用的函数包，通过云函数添加组件所需的后端服务，并在开发完成后通过管理接口将函数包添加至函数包服务中。

进一步地，通过各组件团队并行、独立地开发由函数包定义的组件，部署时只需将函数包添加到函数包服务中，前端应用与后端服务运行时无需修改，从而实现前端应用的动态迭代更新。

进一步地，所述前端采用集中化的状态管理机制，包括：前端应用的所有状态均保存在状态容器内；通过函数包构建组件时，生成的状态合并入前端总状态，由容器应用维护；状态更新的时机和方式、函数包函数的调用，由容器应用控制。

进一步地，使用无状态函数定义前端的组件，前端的组件共享容器应用的运行时和底层接口。

进一步地，本发明方法采用一种基于无状态函数插件的前端应用架构，包括以下部分：

1)容器应用，作为前端入口和前端应用的运行时，其定义为：

设：

·Q：前端应用所有可能的状态；

·∑：前端应用所有可能产生的活动；

·I：UI(用户界面)；

·null：一个表示空的值，表示函数没有返回值。

则容器应用包含：

(1)状态对象q∈Q：储存当前状态；

(2)规约函数δ：Q×∑→Q：给定当前状态和活动，更新当前状态；

(3)渲染函数γ：Q→I：给定当前状态，生成UI；

(4)进入钩子函数λ：Q→∑∪{null}：给定当前状态，产生活动ε∈∑，或什么也不做；

(5)退出钩子函数

Q→∑∪{null}：给定当前状态，产生活动ε∈∑，或什么也不做。

2)函数包，作为前端组件的构建单元，用于定义UI，其定义为一个五元组

p＝(f_init，f_reducer，f_render，f_inhook，f_outhook)

f_init：C→Q_sub

f_reducer：Q×∑×C→Q_sub

f_render：Q×C→I

f_inhook：Q×C→∑∪{null}

f_outhook：Q×C→∑∪{null}

其中：

·p：函数包；

·f_init：初始化函数；

·f_reducer：规约函数；

·f_render：渲染函数；

·f_inhook：进入钩子函数；

·f_outhook：退出钩子函数；

·Q_sub：函数包所构建的组件所有可能的状态；

·C：传递给函数包的参数；

3)函数包服务，其定义为一个五元组

S＝(P，A，D，E，r)

其中：

·P：函数包服务提供的所有函数包；

·A：服务包含的所有远程地址；

·D：服务可接受的参数；

·E：错误信息集合；

·r：A×D→P∪E：r是路由函数，其接收访问地址和提供的参数，返回函数包或错误信息。

4)使用包含参数c∈C的函数包构建组件的流程

触发条件：容器应用的渲染函数γ中渲染了一个尚未加载的组件；

(1)容器应用向函数服务地址a∈A请求函数包，并提供参数d∈D；

(2)对于后端函数服务，响应p＝r(a，d)；

(3)对于容器应用，如果响应p∈E，结束流程，否则继续；

(4)容器应用调用f_init，生成状态q_sub＝f_init(C)；

(5)容器应用将f_reducer、f_render、f_inhook和f_outhook加入到δ、γ、λ和

形成新的规约函数、渲染函数、进入钩子函数、退出钩子函数δ′、γ′、λ′和

使：

·调用δ′(q，ε)时，等效于同时调用δ(q，ε)和f_reducer(q，ε，c)，返回合并后的值；

·调用γ′(q)时，等效于同时调用γ(q)和f_render(q，c)，返回合并后的返回值；

·调用λ′(q)时，等效于同时调用λ(q)和f_inhook(q，c)；

·调用

时，等效于同时调用

和f_outhook(q，c)；

(6)容器应用将q_sub加入到当前状态q中，形成新的状态q′，使q′＝q∪q_sub；

(7)当前状态改变，重绘页面，方法参见前端架构定义的第5)部分。

5)前端运行流程

触发条件：浏览器访问页面；

(1)浏览器加载含有容器应用代码的空页面，加载并运行容器应用；

(2)容器应用的γ初始渲染一个作为入口的函数包；

(3)容器应用的γ渲染未加载的函数包，使用前端架构定义第4)部分的流程，更新状态q，以及δ和γ函数；

(4)前端状态q发生改变；

(5)容器应用调用λ执行渲染前操作，如果产生了活动，对于每个活动，跳转到第(9)步执行一次流程，否则继续；

(6)容器应用调用γ重绘前端界面，如果γ中需要渲染尚未加载的函数包，跳转到第(3)步，否则继续；

(7)容器应用调用

执行渲染后操作，如果产生了活动，对于每个活动，跳转到第(9)步执行一次流程，否则继续；

(8)界面重绘完成，如果用户在界面上进行操作，将生成一个活动ε∈∑，否则等待，直至用户关闭浏览器，或因程序行为产生活动跳转到(9)步；

(9)活动ε被分发至容器应用，容器应用调用δ处理活动，生成新的状态，跳转到第(4)步。

基于如上定义的Web应用构建方法，包括以下步骤：

第一步，实现前端容器应用和后端函数包服务及管理接口，并部署运行；

第二步，设计并规划页面样式和布局，并构建一个入口组件函数包，作为用户加载页面时第一个生成的组件；该函数包的渲染方法包含对页面中所需的其他组件对应的函数包的引用，在加载页面时触发请求函数包构建组件的流程；构建此函数包后，将其通过管理接口添加至函数包服务中；

第三步，各组件开发团队并行开发第二步中引用的函数包，通过云函数添加组件所需的后端服务，并在开发完成后通过管理接口将函数包添加至函数包服务中，每个组件被添加后，该组件即完成迭代；

第四步，重复第二步至第三步，对前端进行迭代开发。

基于同一发明构思，本发明还提供一种基于Serverless的前端应用构建系统，其包括部署在前端的容器应用，以及部署在后端的函数包服务模块；所述容器应用从所述函数包服务中获取函数包并构建所需的组件，实现页面的加载。

与现有技术方案相比，本发明的有益效果是：

(1)UI组件之间解耦，独立构建，良好地支持并行开发；

(2)使用函数包定义UI，只需实现对应的五个无状态函数，开发模式得到规范，组件开发难度降低；

(3)前端运行时与UI定义解耦，更新函数包即完成UI修改，实现动态迭代更新，无需管理服务器环境；应用迭代开发由各组件团队并行、独立地开发由函数包定义的组件，部署时只需将函数包添加到函数包服务中，前端应用与后端服务运行时无需修改，从而实现前端应用的动态迭代更新；

(4)UI升级无需停机，用户浏览器中网页持续可用，体验更好。

附图说明

图1为传统方法的迭代流程示意图。

图2为本发明方法的迭代流程示意图。

图3所示为基于微服务的Web系统架构示意图；

图4所示为基于微前端的Web系统架构示意图；

图5所示为基于本发明方法的Web系统架构示意图；

图6所示为页面加载方法示意图；

图7所示为页面加载的活动图；

图8本发明方法的前端架构示意图；

图9所示为本发明方法应用场景示例中传统方法的示意图；

图10所示为本发明方法应用场景示例中本发明方法的示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清晰明了，以下结合附图说明，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

本发明的基本思路在于，将原本作为前端应用一部分的组件，改为以服务的方式动态提供和加载，同时为了简化开发模式，使用函数构建组件。传统方法的总体迭代流程如图1所示，开发者在本地开发完成整个前端应用后，需要运维人员访问服务器生产环境，使服务器停机，更新相应程序，最后重启服务。而在停机到重启服务期间，服务不可用，用户无法访问。一方面，操作生产环境存在风险，且具备一定门槛，而另一方面，由于停机维护期间不可访问，因此用户体验也会因此受到严重影响。

本发明方法的总体迭代流程如图2所示，开发者以函数包的形式并行开发组件，在完成工作后将代码提交给管理人员，管理人员只需要通过固定的管理接口向函数包服务添加函数包即可，无需访问和操作生产环境，添加函数包只需固定操作，无需具备计算机专业知识，从而降低了操作门槛和操作风险。在此过程中，前端和后端始终保持正常运行，服务没有任何修改或停机，用户可以在任意时刻成功访问。

如图3所示为基于微服务架构的Web系统架构图。为了更好地维护组织后端服务，微服务架构在前后端分离的基础上将后端分解为了以服务为基本单位的，可独立运行的子系统。前端通过API路由定位并使用具体的某个子系统的服务。这种架构使得后端各项服务可以独立维护，系统的可维护性，可扩展性更高，且单一服务的不可用并不会影响全局，提高系统的鲁棒性。但微服务仅为后端的架构设计，并没有考虑前端。通常，微服务架构下的前端由单一的团队进行开发，而随着时间的推移，前端将越来越臃肿，被称为“前端巨无霸”，维护成本高，且不利于并行开发。

为此，如图4所示的微前端架构将微服务中的子系统向前端进行了延伸。将前端进行组件化，每个组件成为一个相对独立的子应用，对应于后端一组特定的微服务。开发中，由不同的团队独立地、全栈式地完成从前端到后端存储的完整开发。这种方法可以提高系统的横向扩展能力，但仍未解决更新迭代过程中的停机维护以及技术门槛高的问题。

本发明方法的Web系统架构图如图5所示，该方法借鉴了Serverless的思想，将Serverless的概念成功向前端进行了延伸，包括：使用无状态函数定义前端组件；前端组件共享容器应用运行时和底层接口。核心思想是将前端运行和前端定义进行分离，前端仅保留一个最基本的容器应用提供底层支持，其他组件均为动态加载并组装，因此对UI的更新并不需要对前端应用的运行环境进行任何修改，从而实现了动态的迭代更新。相对于微前端，本发明方法中的组件并不包含完整运行时，而是共享容器底层接口，因此更加轻量，开发者只需实现函数包中定义的函数即可快速构建组件，从而有效降低了开发门槛和运维工作量。

如图6所示为本发明方法构建的Web系统的页面加载示意图，用户浏览器访问页面后，首先加载的是一个包含容器应用的空页面。加载完成后，由容器应用从服务器的函数包服务中获取一个入口组件的函数包(即从服务器获取页面布局)，并在此之后获取具体所需的组件并加载，最终完成整个页面的加载。其活动图如图7所示。

如图8所示为前端应用的架构与工作流程，容器应用内保存着整个前端应用的总状态，总状态由各个组件的子状态组合而成，组件由从函数包服务中获取的函数包构建而来。首次加载时，函数包的初始化函数生成组件的子状态，并合并入容器应用的总状态中。每当总状态改变时，容器应用将调用函数包的渲染函数渲染各个组件，而在渲染前后将分别调用进入钩子函数和退出钩子函数用以执行必要的自动化操作。当用户或钩子函数执行操作时，将产生的活动分发至应用容器，应用容器将当前状态和活动作为输入，调用函数包的规约函数处理各个组件的状态变化，每个规约函数生成当前组件的子状态，并组合而成新的总状态。总状态改变后，引发重绘，从而形成循环。

如图9、10所示为本发明方法所适用场景的示例。在真实场景下，特别是在外包开发的场景下，开发者与系统的实际部署使用方并不相同，且系统的部署使用方缺乏具备足够计算机专业知识的人员。如图9所示，组织A为专业的计算机团队，负责系统的开发，组织B为系统的实际使用和部署方，系统部署和运行于组织B内，且多数情况下不便从外部网络直接访问。由于后端多为数据查询服务，因此主要业务在前端实现，系统的快速迭代升级也多为从用户体验角度出发的对前端的修改。在这种场景下，系统迭代升级时，需要组织A的相关开发人员频繁地前往组织B协助部署，耗费大量人力物力。

本发明方法有效地解决了上述问题。如图10所示，首先将系统完整部署于组织B并正常上线运行，当前端界面中某处需要修改时，对应组件的开发团队可在组织A内自行迭代相应组件。在开发完毕后，该组件代码文件可通过邮件、通讯软件等各种方式远程发送给组织B的系统管理人员，其通过组件服务后台提供的管理界面可直接添加组件代码，由于操作管理界面无需计算机专业知识，经过简单培训即可，因此技术门槛极低。在添加完毕后，前端即完成迭代更新，浏览器再次访问将显示最新的内容。

与现有常用架构相比，本发明的技术方案的优势如表1所示。

表1.本发明与现有常用架构的比较

架构	本方法	微前端	前后端分离	前后端一体
					模块解耦	是	是	仅前后端	否
并行开发	是	是	——	——
					无需管理系统运行时	是	否	否	否
动态迭代更新	是	否	否	否

以上实施例仅用以说明本发明的技术方案而非对其进行限制，本领域的普通技术人员可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明的原理和范围，本发明的保护范围应以权利要求书所述为准。

Claims (10)

1.一种基于Serverless的前端应用构建方法，其特征在于，包括以下步骤：

在前端建立容器应用；

所述容器应用从后端的函数包服务中获取函数包并构建所需的组件，实现页面的加载。

2.根据权利要求1所述的方法，其特征在于，所述函数包服务采用以下方式建立：

在后端设置函数包服务的管理接口；

设计并规划页面样式和布局，并构建一个入口组件函数包，该入口组件函数包的渲染方法包含对页面中所需的其他组件对应的函数包的引用，构建此入口组件函数包后，将其通过管理接口添加至函数包服务中；

并行开发入口组件引用的函数包，通过云函数添加组件所需的后端服务，并在开发完成后通过管理接口将函数包添加至函数包服务中。

3.根据权利要求1所述的方法，其特征在于，通过各组件团队并行、独立地开发由函数包定义的组件，部署时只需将函数包添加到函数包服务中，前端应用与后端服务运行时无需修改，从而实现前端应用的动态迭代更新。

4.根据权利要求1所述的方法，其特征在于，所述前端采用集中化的状态管理机制，包括：前端应用的所有状态均保存在状态容器内；通过函数包构建组件时，生成的状态合并入前端总状态，由容器应用维护；状态更新的时机和方式、函数包函数的调用，由容器应用控制。

5.根据权利要求1所述的方法，其特征在于，使用无状态函数定义前端的组件，前端的组件共享容器应用的运行时和底层接口。

6.根据权利要求1所述的方法，其特征在于，所述容器应用包含：

状态对象q∈Q：储存当前状态；

规约函数δ:Q×∑→Q：给定当前状态和活动，更新当前状态；

渲染函数γ:Q→I：给定当前状态，生成UI；

进入钩子函数λ:Q→∑∪{null}：给定当前状态，产生活动ε∈∑，或什么也不做；

退出钩子函数

给定当前状态，产生活动ε∈∑，或什么也不做。

其中，Q为前端应用所有可能的状态；∑为前端应用所有可能产生的活动；I为UI即用户界面；null是一个表示空的值，表示函数没有返回值。

7.根据权利要求6所述的方法，其特征在于，所述函数包定义为一个五元组：

p＝(f_init,f_reducer,f_render,f_inhook,f_outhook)

f_init：C→Q_sub

f_reducer：Q×∑×C→Q_sub

f_render：Q×C→I

f_inhook：Q×C→∑∪{null}

f_outhook：Q×C→∑∪{null}

其中，p表示函数包；f_init表示初始化函数；f_reducer表示规约函数；f_render表示渲染函数；f_inhook表示进入钩子函数；f_outhook表示退出钩子函数；Q_sub表示函数包所构建的组件所有可能的状态；C表示传递给函数包的参数。

所述函数包服务定义为一个五元组：

S＝(P,A,D,E,r)

其中，P表示函数包服务提供的所有函数包；A表示服务包含的所有远程地址；D表示服务可接受的参数；E表示错误信息集合；r:A×D→P∪E，其中r表示路由函数，其接收访问地址和提供的参数，返回函数包或错误信息。

8.根据权利要求7所述的方法，其特征在于，所述容器应用采用以下步骤构建组件：

容器应用向函数服务地址a∈A请求函数包，并提供参数d∈D；

对于后端函数服务，响应p＝r(a,d)；

对于容器应用，如果响应p∈E，结束流程，否则继续；

容器应用调用f_init，生成状态q_sub＝f_init(C)；

容器应用将f_reducer、f_render、f_inhook和f_outhook加入到δ、γ、λ和

形成新的规约函数、渲染函数、进入钩子函数、退出钩子函数δ′、γ′、λ′和

使：

调用δ′(q,ε)时，等效于同时调用δ(q,ε)和f_reducer(q,ε,c)，返回合并后的值；

调用γ′(q)时，等效于同时调用γ(q)和f_render(q,c)，返回合并后的返回值；

调用λ＇(q)时，等效于同时调用λ(q)和f_inhook(q,c)；

调用

时，等效于同时调用

和f_outhook(q,c)；

容器应用将q_sub加入到当前状态q中，形成新的状态q′，使q′＝q∪q_sub；

当前状态改变，重绘页面。

9.根据权利要求8所述的方法，其特征在于，所述前端在访问页面时的运行过程包括：

(1)浏览器加载含有容器应用代码的空页面，加载并运行容器应用；

(2)容器应用的γ初始渲染一个作为入口的函数包；

(3)容器应用的γ渲染未加载的函数包，更新状态q，以及δ和γ函数；

(4)前端状态q发生改变；

(5)容器应用调用λ执行渲染前操作，如果产生了活动，对于每个活动，跳转到第(9)步执行一次流程，否则继续；

(6)容器应用调用γ重绘前端界面，如果γ中需要渲染尚未加载的函数包，跳转到第(3)步，否则继续；

(7)容器应用调用

执行渲染后操作，如果产生了活动，对于每个活动，跳转到第(9)步执行一次流程，否则继续；

(8)界面重绘完成，如果用户在界面上进行操作，将生成一个活动ε∈∑，否则等待，直至用户关闭浏览器，或因程序行为产生活动跳转到(9)步；

(9)活动ε被分发至容器应用，容器应用调用δ处理活动，生成新的状态，跳转到第(4)步。

10.一种基于Serverless的前端应用构建系统，其特征在于，包括部署在前端的容器应用，以及部署在后端的函数包服务模块；所述容器应用从所述函数包服务中获取函数包并构建所需的组件，实现页面的加载。

Images