一种微前端的应用构建方法、装置及计算机存储介质

技术领域

本申请涉及计算机科学与技术领域，尤其涉及一种微前端的应用构建方法、装置及计算机存储介质。

背景技术

微前端借鉴了微服务的架构理念，将一个庞大的应用拆分为多个小应用，这些小应用都可以独立开发、测试和部署，同时也可以聚合成一个产品。

但是，当前微前端封装的公共业务组件，难以在主应用和子应用之间共享，只能在主应用和子应用项目中重复引入，存在主应用、子应用重复配置公共业务组件的问题，导致公共业务组件维护成本加大。

发明内容

本申请提供了一种微前端的应用构建方法、装置及计算机存储介质，用于降低公共业务组件的维护成本。

本申请第一方面提供了一种微前端的应用构建方法，包括：

根据用户指令加载主应用，获取所述主应用的第一公共业务组件及所述主应用所包含的子应用的业务路由及主应用路由；

合并所述主应用路由及所述子应用的业务路由，生成全局路由；

根据所述全局路由生成目标路由列表及菜单列表；

接收所述用户在所述菜单列表上输入的选择指令，根据所述选择指令确定所述用户选择的目标子应用；

通过所述目标路由列表获取所述目标子应用的目标业务路由；

根据所述目标业务路由确定所述目标子应用的第二公共业务组件；

判断所述第一公共业务组件与所述第二公共业务组件是否相同；

若相同，则控制所述目标子应用复用所述第一公共业务组件，生成目标子应用页面；

若不相同，则控制所述目标子应用获取所述第二公共业务组件，生成目标子应用页面。

可选地，在所述合并所述主应用路由及所述子应用的业务路由，生成全局路由之前，所述应用构建方法还包括：

向后台服务器发送所述用户的用户信息；

接收所述后台服务器返回的用户权限，并根据所述用户权限，生成用户路由；

所述合并所述主应用路由及所述子应用的业务路由，生成全局路由包括：

合并所述主应用路由、所述子应用的业务理由及所述用户路由，生成全局路由。

可选地，在所述根据用户指令加载主应用之后，所述应用构建方法还包括：

获取所述主应用的第三方依赖包，所述第三方依赖包部署于CDN服务器上。

可选地，所述获取所述主应用的第三方依赖包包括：

通过webpack打包，将所述第三方依赖包注入至入口文件；

当所述主应用加载时，通过所述入口文件获取所述主应用的第三方依赖包。

可选地，所述获取所述主应用的第一公共业务组件包括：

在核心库中根据所述主应用加载第一公共业务组件的第一资源配置文件；

根据所述第一资源配置文件获取所述第一公共业务组件的第一路由路径；

根据所述第一路由路径加载所述第一公共业务组件。

可选地，所述获取所述主应用所包含的子应用的业务路由包括：

加载主应用包含的子应用的公共业务组件的第三资源配置文件；

根据所述第三资源配置文件获取所述子应用的公共业务组件的第三路由路径；

根据所述第三路由路径获取所述子应用的业务路由。

可选地，所述控制所述目标子应用获取所述第二公共业务组件，生成目标子应用页面包括：

控制目标子应用获取第二公共业务组件；

将所述第二公共业务组件对应的第二资源配置文件注册至所述目标子应用中；

当所述目标子应用加载时，通过所述第二资源配置文件懒加载所述第二公共业务组件，生成目标子应用页面。

本申请第二方面提供了一种微前端的应用构建装置，包括：

第一获取单元，用于根据用户指令加载主应用，获取所述主应用的公共业务组件及所述主应用所包含的子应用的业务路由及主应用路由；

合并单元，用于合并所述主应用路由及所述子应用的业务路由，生成全局路由；

生成单元，用于根据所述全局路由生成目标路由列表及菜单列表；

第一确定单元，用于接收所述用户在菜单列表上输入的选择指令，根据所述选择指令确定所述用户选择的目标子应用；

第二获取单元，用于通过所述目标路由列表获取所述目标子应用的目标业务路由；

第二确定单元，用于根据所述目标业务路由确定所述目标子应用的第二公共业务组件；

判断单元，用于判断所述第一公共业务组件与所述第二公共业务组件是否相同；

复用单元，用于若相同，则所述目标子应用复用所述第一公共业务组件，生成目标子应用页面；

第三获取单元，用于若不相同，则所述目标子应用获取所述第二公共业务组件，生成目标子应用页面。

可选地，所述应用构建装置还包括：

发送单元，用于向后台服务器发送所述用户的用户信息；

接收单元，用于接收所述后台服务器返回的用户权限并根据所述用户权限，生成用户路由；

所述合并单元具体用于：

合并所述主应用路由、所述子应用的业务理由及所述用户路由，生成全局路由。

可选地，所述获取单元具体用于：获取所述主应用的第三方依赖包、所述主应用的第一公共业务组件及所述主应用所包含的子应用的业务路由及主应用路由，所述第三方依赖包部署于CDN服务器上。

可选地，所述第一获取单元具体用于：

通过webpack打包，将所述第三方依赖包注入至入口文件；

当所述主应用加载时，通过所述入口文件获取所述主应用的第三方依赖包。

可选地，所述第一获取单元具体用于：

在核心库中根据所述主应用加载第一公共业务组件的第一资源配置文件；

根据所述第一资源配置文件获取所述第一公共业务组件的第一路由路径；

根据所述第一路由路径加载所述第一公共业务组件。

可选地，所述第一获取单元具体用于：

加载所述主应用包含的子应用的公共业务组件的第三资源配置文件；

根据所述第三资源配置文件获取所述子应用的公共业务组件的第三路由路径；

根据所述第三路由路径获取所述子应用的业务路由。

可选地，所述第三获取单元具体用于：

控制所述目标子应用获取第二公共业务组件；

将所述第二公共业务组件对应的第二资源配置文件注册至所述目标子应用中；

当所述目标子应用加载时，通过所述目标资源配置文件懒加载所述第二公共业务组件，生成目标子应用页面。

本申请第三方面提供了一种微前端的应用构建装置，所述装置包括：

处理器、存储器、输入输出单元以及总线；

所述处理器与所述存储器、所述输入输出单元以及所述总线相连；

所述存储器保存有程序，所述处理器调用所述程序以执行第一方面以及第一方面中任一项可选的微前端的应用构建方法。

本申请第四方面提供了一种计算机可读存储介质，所述计算机可读存储介质上保存有程序，所述程序在计算机上执行时执行第一方面以及第一方面中任一项可选的微前端的应用构建方法。

从以上技术方案可以看出，本申请具有以下优点：本申请通过目标子应用的目标业务路由确定目标子应用引用的第二公共业务组件，并判断所述第二公共业务组件与主应用引用的第一公共业务组件是否相同；若相同，则控制目标子应用复用所述第一公共业务组件，生成目标子应用页面；若不相同，则控制目标子应用获取第二公共业务组件，生成目标子应用页面；通过上述步骤，解决了公共业务组件在主应用和子应用间重复配置的问题，只需要在主应用里统一配置公共业务组件的路由，实现主应用配置一次，其余子应用便可直接通过主应用复用该公共业务组件，大大降低了公共业务组件的维护成本。

附图说明

为了更清楚地说明本申请中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请提供的一种微前端的应用构建方法一个实施例流程示意图；

图2为本申请提供的一种微前端的应用构建方法另一个实施例流程示意图；

图3为本申请提供的一种微前端的应用构建装置一个实施例结构示意图；

图4为本申请提供的一种微前端的应用构建装置另一个实施例结构示意图；

图5为本申请提供的一种微前端的应该构建装置另一个实施例结构示意图。

具体实施方式

本申请提供了一种微前端的应用构建方法、装置及计算机存储介质，用于降低公共业务组件的维护成本。

需要说明的是，本申请提供的一种微前端的应用构建方法，可以应用于终端，还可以应用于服务器上，例如终端可以是智能手机或电脑、平板电脑、智能电视、智能手表、便携计算机终端也可以是台式计算机等固定终端。为方便阐述，本申请中以终端为执行主体进行举例说明。

请参阅图1，图1为本申请提供的一种微前端的应用构建方法的一个实施例，该应用构建方法包括：

101、终端根据用户指令加载主应用，获取主应用的第一公共业务组件及主应用所包含的子应用的业务路由及主应用路由；

在本实施例中，主应用作为系统的入口，主要负责部分业务模块实现和子应用管理，在运行主应用时，按需加载公共组件或方法，子应用主要负责具体业务模块的实现，主应用包含多个子应用，可以按需加载子应用；将应用间的公共业务组件和方法抽离到核心库中进行维护，按需加载公共业务组件；当终端接收到用户指令时，例如，当用户在浏览器中打开系统，加载主应用时，终端查找核心库，获取第一公共业务组件、子应用的业务路由及主应用路由，并根据子应用的业务路由加载子应用的业务路由文件。

102、终端合并主应用路由及子应用的业务路由，生成全局路由；

在本实施例中，在主应用中，将子应用返回的业务路由和主应用路由保存到变量中，生成全局路由。

103、终端根据全局路由生成目标路由列表及菜单列表；

在本实施例中，终端根据全局路由生成目标路由列表及菜单列表，并根据菜单列表生成展示页面，以使得用户通过展示页面的菜单按钮选择访问子应用的具体业务页面。

104、终端接收用户在菜单列表上输入的选择指令，根据选择指令确定用户选择的目标子应用；

在本实施例中，用户点击菜单列表，访问目标子应用的具体页面，终端接收用户在菜单列表上输入的选择指令，根据选择指令确定用户选择的目标子应用。

105、终端通过目标路由列表获取目标子应用的目标业务路由；

在本实施例中，终端通过目标路由列表查找目标子应用对应的目标业务路由。

106、终端根据目标业务路由确定目标子应用的第二公共业务组件；

在本实施例中，终端根据目标业务路查找核心库由确定目标子应用引用的第二公共业务组件。

107、终端判断第一公共业务组件与第二公共业务组件是否相同；

在本实施例中，判断主应用所引用的第一公共业务组件与子应用所引用的第二公共业务组件是否相同，若是，则执行步骤108；若否，则执行步骤109。

108、若相同，则终端控制目标子应用复用第一公共业务组件，生成目标子应用页面；

在本实施例中，若第一公共业务组件与第二公共业务组件相同，即第一公共业务组件在主应用和目标子应用中同时被引用，则终端控制目标子应用直接通过主应用复用第一公共业务组件，生成目标子应用页面。

109、若不相同，则终端控制目标子应用获取第二公共业务组件，生成目标子应用页面；

在本实施例中，若第一公共业务组件与第二公共业务组件不相同，即主应用未引用第二公共业务组件，则终端控制目标子应用根据目标业务路由获取第二公共业务组件对应的第二路由路径，获取第二公共业务组件，生成目标子应用页面。

本申请实施例通过目标子应用的目标业务路由确定目标子应用引用的第二公共业务组件，并判断所述第二公共业务组件与主应用引用的第一公共业务组件是否相同；若相同，则控制目标子应用复用所述第一公共业务组件，生成目标子应用页面；若不相同，则控制目标子应用获取第二公共业务组件，生成目标子应用页面；通过上述步骤，解决了公共业务组件在主应用和子应用间重复配置的问题，只需要在主应用里统一配置公共业务组件的路由，实现主应用配置一次，其余子应用便可直接通过主应用复用该公共业务组件，大大降低了公共业务组件的维护成本。

请参阅图2，图2为本申请提供的一种微前端的应用构建方法的另一个实施例，包括：

201、终端根据用户指令加载主应用，获取主应用的第三方依赖包、主应用的公共业务组件及主应用所包含的子应用的业务路由及主应用路由，该第三方依赖包部署于CDN服务器上；

在本实施例中，终端获取主应用的第三方依赖包包括：通过webpack打包，将第三方依赖包注入至入口文件；当主应用加载时，通过入口文件获取主应用的第三方依赖包；第三方依赖包部署于CDN服务器上，不仅加快了第三方依赖包的访问速度，还解决了第三方依赖包重复引入的问题，微前端应用在CDN服务器上加载对应第三方依赖包，能有效控制前端的资源接入，且通过CDN服务器加载资源可提升用户的访问速度并节省服务器消耗；终端获取主应用的公共业务组件包括：终端在核心库中根据主应用加载公共业务组件的第一资源配置文件；终端根据第一资源配置文件获取公共业务组件的第一路由路径；终端根据第一路由路径加载公共业务组件；基于webpack的Module Federration功能，生成公共业务组件的第一资源配置文件resource.js，在第一资源配置文件resource.js中记录核心库对外暴露的方法名及方法对应的路径，方便根据该第一资源配置文件resource.js按需加载公共业务组件；终端获取主应用所包含的子应用的业务路由包括：终端加载主应用包含的子应用的公共业务组件的第三资源配置文件；终端根据第三资源配置文件获取子应用的公共业务组件的第三路由路径；终端根据第三路由路径获取子应用的业务路由；终端通过配置exposes属性，在第三资源配置文件resource.js文件中按业务模块记录路由文件路径索引，获取子应用的业务路由，方便主应用根据业务路由按需加载子应用。

202、终端向后台服务器发送用户的用户信息；

在本实施例中，终端向后台服务器发送用户的用户信息，请求后台服务器根据用户信息返回用户权限。

203、终端接收后台服务器返回的用户权限，并根据用户权限，生成用户路由；

在本实施例中，终端接收后台服务器返回的用户权限，并根据用户权限，生成用户路由，实现动态路由。

204、终端合并主应用路由、子应用的业务路由及用户路由，生成全局路由；

在本实施例中，终端合并主应用路由、子应用路由及用户路由，生成全局路由，实现动态路由，确保用户可以且仅可以访问无需授权或已经得到授权的网站资源，提高了安全性。

205、终端根据全局路由生成目标路由列表及菜单列表；

206、终端接收用户在菜单列表上输入的选择指令，根据选择指令确定用户选择的目标子应用；

207、终端通过目标路由列表获取目标子应用的目标业务路由；

208、终端根据目标业务路由确定目标子应用的第二公共业务组件；

209、终端判断第一公共业务组件与第二公共业务组件是否相同；210、若相同，则控制目标子应用复用第一公共业务组件，生成目标子应用页面；

上述步骤205至210与前述图1实施例中的步骤103至108类似，具体此处不再赘述。

211、若不相同，则控制目标子应用获取第二公共业务组件，生成目标子应用页面；

在本实施例中，若第一公共业务组件与第二公共业务组件不相同，则终端控制目标子应用获取第二公共组件，其中，终端控制目标子应用获取第二公共业务组件，生成目标子应用页面包括：终端控制目标子应用获取第二公共业务组件，通过Module Federation的remotes属性将第二公共业务组件对应的第二资源配置文件resource.js注册至目标子应用中；当目标子应用被加载时，通过第二资源配置文件懒加载第二公共业务组件，生成目标子应用页面，当前所有的应用的公共业务组件都会在用过访问时被加载，导致应用加载时间过长，通过懒加载公共业务组件能够有效降低应用加载时间，提升用户体验。

请参阅图3，图3为本申请提供的一种微前端的应用构建装置一个实施例，该应用构建装置包括：

第一获取单元301，用于根据用户指令加载主应用，获取主应用的第一公共业务组件、主应用所包含的子应用的业务路由及主应用路由；

合并单元302，用于合并主应用路由及子应用的业务路由，生成全局路由；

生成单元303，用于根据全局路由生成目标路由列表及菜单列表；

第一确定单元304，用于接收用户在菜单列表上输入的选择指令，根据选择指令确定用户选择的目标子应用；

第二获取单元305，用于通过目标路由列表获取目标子应用的目标业务路由；

第二确定单元306，用于根据目标业务路由确定目标子应用的第二公共业务组件；

判断单元307，用于判断第一公共业务组件与第二公共业务组件是否相同；

复用单元308，用于若相同，则控制目标子应用复用第一公共业务组件，生成目标子应用页面；

第三获取单元309，用于若不相同，则控制目标子应用获取第二公共业务组件，生成目标子应用页面。

本实施例系统中，各单元的功能与前述图1所示方法实施例中的步骤对应，此处不再赘述。

下面对本申请提供的一种微前端的应用构建装置进行详细说明，请参阅图4，图4为本申请提供的一种微前端的应用构建装置另一个实施例，该应用构建装置包括：

第一获取单元401，用于根据用户指令加载主应用，获取主应用的第三方依赖包、主应用的公共业务组件、主应用所包含的子应用的业务路由及主应用路由；

合并单元402，用于合并主应用路由及子应用的业务路由，生成全局路由；

生成单元403，用于根据全局路由生成目标路由列表及菜单列表；

第一确定单元404，用于接收用户在菜单列表上输入的选择指令，根据选择指令确定用户选择的目标子应用；

第二获取单元405，用于通过目标路由列表获取目标子应用的目标业务路由；

第二确定单元406，用于根据目标业务路由确定目标子应用的第二公共业务组件；

判断单元407，用于判断第一公共业务组件与第二公共业务组件是否相同；

复用单元408，用于若相同，则目标子应用复用第二公共业务组件，生成目标子应用页面；

第三获取单元409，用于若不相同，则目标子应用获取第二公共业务组件，生成目标子应用页面。

可选地，应用构建装置还包括：

发送单元410，用于向后台服务器发送用户的用户信息；

接收单元411，用于接收后台服务器返回的用户权限并根据用户权限，生成用户路由；

合并单元402具体用于：

合并主应用路由、子应用的业务理由及用户路由，生成全局路由。

可选地，所述第一获取单元具体用于：

获取所述主应用的第三方依赖包、所述主应用的第一公共业务组件及所述主应用所包含的子应用的业务路由及主应用路由，所述第三方依赖包部署于CDN服务器上。

可选地，第一获取单元401具体用于：

通过webpack打包，将第三方依赖包注入至入口文件；

当主应用加载时，通过入口文件获取主应用的第三方依赖包。

可选地，第一获取单元401具体用于：

在核心库中根据主应用加载公共业务组件的第一资源配置文件；

根据第一资源配置文件获取公共业务组件的第一路由路径；

根据第一路由路径加载公共业务组件。

可选地，第一获取单元401具体用于：

加载主应用包含的子应用的公共业务组件的第三资源配置文件；

根据第三资源配置文件获取子应用的公共业务组件的第三路由路径；

根据第三路由路径获取子应用的业务路由。

可选地，第三获取单元409具体用于：

控制目标子应用获取第二公共业务组件；

将第二公共业务组件对应的第二资源配置文件注册至目标子应用中；

当目标子应用加载时，通过目标资源配置文件懒加载第二公共业务组件，生成目标子应用页面。

本实施例系统中，各单元的功能与前述图2所示方法实施例中的步骤对应，此处不再赘述。

本申请还提供了一种微前端的应用构建装置，请参阅图5，图5为本申请提供的一种微前端的应用构建装置一个实施例，该应用构建装置包括：

处理器501、存储器502、输入输出单元503、总线504；

处理器501与存储器502、输入输出单元503以及总线504相连；

存储器502保存有程序，处理器501调用程序以执行如上任一一种微前端的应用构建方法。

本申请还涉及一种计算机可读存储介质，计算机可读存储介质上保存有程序，当程序在计算机上运行时，使得计算机执行如上任一一种应用构建方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，read-onlymemory)、随机存取存储器(RAM，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。