基于微前端的数据处理方法、介质、装置和计算设备与流程

1.本公开的实施方式涉及数据处理技术领域，更具体地，本公开的实施方式涉及一种基于微前端的数据处理方法、介质、装置和计算设备。


背景技术：

2.本部分旨在为权利要求书中陈述的本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
3.微前端技术以前端应用为核心，在用户的浏览器上，将多个不同前端应用同时运行在了一起，又保证相互独立，互不影响。用户可以在同一个浏览器界面上浏览不同的应用，提升了用户体验，提高了用户的使用效率。
4.目前，在微前端技术下，通常使用nginx作为代理，通过统一资源定位(uniform resource locator，url)路径或域名的方式将前端应用请求对应到不同的应用服务器。但是，nginx缺乏业务上的统一管理能力，因此，往往需要应用服务器重复地开发登录和权限控制等通用功能，增加了开发成本。


技术实现要素：

5.本公开提供一种基于微前端的数据处理方法、介质、装置和计算设备，以降低开发成本。
6.在本公开实施方式的第一方面中，提供了一种基于微前端的数据处理方法，应用于主应用网关，该基于微前端的数据处理方法包括：
7.接收客户端发送的数据请求消息，数据请求消息携带有数据请求消息对应的来源标记、目标服务标记和用户信息，来源标记用于表征数据请求消息的来源，目标服务标记用于表征数据请求消息对应的目标后端服务；
8.根据来源标记、用户信息和数据请求消息对应的请求地址，进行权限鉴定；
9.若确定客户端有权限访问请求地址，则根据目标服务标记以及预设后端服务配置，将数据请求消息发送给目标服务标记对应的目标后端服务，预设后端服务配置用于表征服务标记和后端服务的对应关系，预设后端服务配置是由应用平台所配置的；
10.将目标后端服务发送的数据请求消息对应的响应消息，发送给客户端。
11.第二方面，本公开实施例提供一种基于微前端的数据处理方法，应用于客户端，该基于微前端的数据处理方法包括：
12.响应于前端应用的打开操作，从应用平台获取前端应用对应的前端静态资源；
13.根据前端静态资源，渲染对应的前端应用页面；
14.响应于目标业务服务页面的请求操作，基于微前端沙箱技术，向主应用网关发送数据请求消息，数据请求消息携带有数据请求消息对应的来源标记、目标服务标记和用户信息；
15.接收主应用网关发送的数据请求消息对应的响应消息；
16.根据响应消息，渲染目标业务服务页面。
17.第三方面，本公开实施例提供一种基于微前端的数据处理方法，应用于应用平台，该基于微前端的数据处理方法包括：
18.接收前端应用的开发者通过上传工具上传的前端应用对应的版本文件，版本文件至少包含前端应用对应的前端静态资源和代码；
19.根据版本文件，生成对应版本号的资源包，并将资源包发布到各个部署环境，部署环境包括开发部署环境、测试部署环境和运维部署环境；
20.存储资源包对应的信息，以对各个部署环境的资源包进行相应版本的切换，信息至少包括资源包对应的前端应用标识、资源包的版本号、资源包对应的部署环境。
21.第四方面，本公开实施例提供一种基于微前端的数据处理装置，应用于主应用网关，该基于微前端的数据处理装置包括：
22.接收模块，用于接收客户端发送的数据请求消息，数据请求消息携带有数据请求消息对应的来源标记、目标服务标记和用户信息，来源标记用于表征数据请求消息的来源，目标服务标记用于表征数据请求消息对应的目标后端服务；
23.鉴定模块，用于根据来源标记、用户信息和数据请求消息对应的请求地址，进行权限鉴定；
24.发送模块，用于若确定客户端有权限访问请求地址，则根据目标服务标记以及预设后端服务配置，将数据请求消息发送给目标服务标记对应的目标后端服务，预设后端服务配置用于表征服务标记和后端服务的对应关系，预设后端服务配置是由应用平台所配置的；以及将目标后端服务发送的数据请求消息对应的响应消息，发送给客户端。
25.第五方面，本公开实施例提供一种基于微前端的数据处理装置，应用于客户端，该基于微前端的数据处理装置包括：
26.获取模块，用于响应于前端应用的打开操作，从应用平台获取前端应用对应的前端静态资源；
27.第一渲染模块，用于根据前端静态资源，渲染对应的前端应用页面；
28.发送模块，用于响应于目标业务服务页面的请求操作，基于微前端沙箱技术，向主应用网关发送数据请求消息，数据请求消息携带有数据请求消息对应的来源标记、目标服务标记和用户信息；
29.接收模块，用于接收主应用网关发送的数据请求消息对应的响应消息；
30.第二渲染模块，用于根据响应消息，渲染目标业务服务页面。
31.第六方面，本公开实施例提供一种基于微前端的数据处理装置，应用于应用平台，该基于微前端的数据处理装置包括：
32.接收模块，用于接收前端应用的开发者通过上传工具上传的前端应用对应的版本文件，版本文件至少包含前端应用对应的前端静态资源和代码；
33.处理模块，用于根据版本文件，生成对应版本号的资源包，并将资源包发布到各个部署环境，部署环境包括开发部署环境、测试部署环境和运维部署环境；
34.存储模块，用于存储资源包对应的信息，以对各个平台的资源包进行相应版本的切换，信息至少包括资源包对应的前端应用标识、资源包的版本号、资源包对应的部署环境。
35.第七方面，本公开实施例提供一种计算设备，包括：处理器，以及与处理器通信连接的存储器；
36.存储器存储计算机执行指令；
37.处理器执行存储器存储的计算机执行指令，以实现如本公开第一方面所述的基于微前端的数据处理方法。
38.第八方面，本公开实施例提供一种计算设备，包括：处理器，以及与处理器通信连接的存储器；
39.存储器存储计算机执行指令；
40.处理器执行存储器存储的计算机执行指令，以实现如本公开第二方面所述的基于微前端的数据处理方法。
41.第九方面，本公开实施例提供一种计算设备，包括：处理器，以及与处理器通信连接的存储器；
42.存储器存储计算机执行指令；
43.处理器执行存储器存储的计算机执行指令，以实现如本公开第三方面所述的基于微前端的数据处理方法。
44.第十方面，本公开实施例提供一种存储介质，存储介质中存储有计算机程序指令，计算机程序指令被执行时，实现如本公开第一方面所述的基于微前端的数据处理方法。
45.第十一方面，本公开实施例提供一种存储介质，存储介质中存储有计算机程序指令，计算机程序指令被执行时，实现如本公开第二方面所述的基于微前端的数据处理方法。
46.第十二方面，本公开实施例提供一种存储介质，存储介质中存储有计算机程序指令，计算机程序指令被执行时，实现如本公开第三方面所述的基于微前端的数据处理方法。
47.第十三方面，本公开实施例提供一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现如本公开第一方面所述的基于微前端的数据处理方法。
48.第十四方面，本公开实施例提供一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现如本公开第二方面所述的基于微前端的数据处理方法。
49.第十五方面，本公开实施例提供一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现如本公开第三方面所述的基于微前端的数据处理方法。
50.本公开实施例提供的基于微前端的数据处理方法、介质、装置和计算设备，通过应用平台接收前端应用的开发者通过上传工具上传的前端应用对应的版本文件，生成对应版本号的资源包，并将资源包发布到各个部署环境，存储资源包对应的信息；客户端响应于前端应用的打开操作，从应用平台获取前端应用对应的前端静态资源，并渲染对应的前端应用页面；客户端响应于目标业务服务页面的请求操作，基于微前端沙箱技术，向主应用网关发送数据请求消息，数据请求消息携带有数据请求消息对应的来源标记、目标服务标记和用户信息；主应用网关根据来源标记、用户信息和数据请求消息对应的请求地址，进行权限鉴定；若确定客户端有权限访问请求地址，则主应用网关根据目标服务标记以及预设后端服务配置，将数据请求消息发送给目标后端服务，将接收到的目标后端服务发送的响应消息发送给客户端，客户端渲染目标业务服务页面。由于本公开实施例通过主应用网关对数据请求消息进行权限鉴定，将包含用户信息的数据请求消息发送给目标后端服务，不需要各后端服务重复开发登录和权限控制功能，因此，能够降低开发成本，提升用户体验；且通
过应用平台统一管理资源包的生成和发布，能够简化前端应用的发布流程，减少前端应用的部署资源消耗；另外，通过主应用网关根据目标服务标记以及预设后端服务配置，将数据请求消息发送给目标后端服务，无需各部署环境分别修改代码配置，即可发送至正确的后端服务，能够简化开发和调试的流程。
附图说明
51.通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：
52.图1为本公开一实施例提供的应用服务器使用nginx作为代理的示意图；
53.图2为本公开实施例提供的一种应用场景示意图；
54.图3为本公开一实施例提供的基于微前端的数据处理方法的信令交互示意图；
55.图4为本公开一实施例提供的通过应用平台进行资源包版本管理的示意图；
56.图5为本公开一实施例提供的基于微前端的数据处理方法的流程图；
57.图6为本公开另一实施例提供的基于微前端的数据处理方法的流程图；
58.图7为本公开一实施例提供的基于微前端的数据处理装置的结构示意图；
59.图8为本公开另一实施例提供的基于微前端的数据处理装置的结构示意图；
60.图9为本公开又一实施例提供的基于微前端的数据处理装置的结构示意图；
61.图10为本公开一实施例提供的存储介质示意图；
62.图11为本公开一实施例提供的计算设备的结构示意图。
63.在附图中，相同或对应的标号表示相同或对应的部分。
具体实施方式
64.下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。
65.本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。
66.根据本公开的实施方式，提出了一种基于微前端的数据处理方法、介质、装置和计算设备。
67.在本文中，需要理解的是，所涉及的术语：微前端，是指将一个巨大的业务前端系统，拆分成多个垂直业务的小系统，并通过预设方式进行组合，结合成一个复杂系统的技术方案；微前端子应用，即微前端中承载单个垂直业务所有功能的载体；微前端主应用，是微前端中负责组合和调配垂直业务对应的微前端子应用的载体；微前端沙箱技术，即在浏览器上同时运行不同脚本(javascript，js)，并能保持隔离互不影响的技术，是微前端技术得以实施的关键技术；服务中间层(backend for frontend，bff)，是指前端业务和后端服务交互中，使用node.js等技术搭建的，以服务于前端业务，整合后端业务的中间层技术；主应
用网关，是指结合bff功能及微前端主应用功能搭建的网关，负责分发前端资源以及完成后端服务接口的转发，并在转发时完成登录和权限等功能；应用平台，是指对每个微前端子应用进行版本管理、服务器网际互连协议(internet protocol，ip)配置的中心化平台；cookie，是网站中为了辨别用户身份，进行跟踪而储存在用户本地终端上的数据(通常经过加密)，由用户客户端计算机暂时或永久保存的信息；nginx，一种高性能的超文本传输协议(hyper text transfer protocol，http)和反向代理万维网(world wide web，web)服务器；可扩展超文本传输请求(extensible markup language hyper text transfer protocol request，xmlhttprequest)，是指浏览器中javascript发起http请求的技术。此外，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。
68.下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。
69.发明概述
70.本发明人发现，目前，在微前端技术下，通常使用nginx作为代理，通过url地址或域名的方式将前端应用请求对应到不同的应用服务器。示例性地，图1为本公开一实施例提供的应用服务器使用nginx作为代理的示意图，如图1所示，响应于用户对前端应用的打开操作，根据对应的前端应用请求，通过nginx从前端资源服务获取前端资源，通过nginx访问后端应用程序接口(application programming interface，api)服务，或者访问其他的后端服务或其他的前端服务，以获得对应的服务信息。由于nginx缺乏业务上的统一管理能力，因此，往往需要应用服务器重复地开发登录和权限控制等通用功能，增加了开发成本。另外，在微前端技术下，由于业务上的增加，往往需要部署多个前端资源服务，而前端应用往往只需要浏览器即可运行，造成了不必要的服务器资源浪费。服务器部署流程一般比较繁琐，需要花费比较多的时间，且可能存在因服务器配置不同而导致部署失败的情况；前端服务和后端服务往往需要先通过人工口头约定的方式约定好nginx配置，同时需要人工确认该nginx配置在测试环境和线上环境等多个环境中都可用，因此，存在一定的不可控性。微前端技术以前端应用为核心，主要使用javascript代理(proxy)或者快照等方式，在用户浏览器上，把多个不同前端应用同时运行在了一起，又保证相互独立，互不影响。用户可以在同一个浏览器界面上浏览不同的应用，提升了用户体验，提高了用户的使用效率。但是，目前的微前端技术存在以下缺陷：微前端子应用配置往往需要通过修改代码实现，导致每次更新和发布微前端子应用时，都需要同时发布微前端主应用，增加了发布成本。
71.基于上述问题，本公开提供一种基于微前端的数据处理方法、介质、装置和计算设备，通过在微前端沙箱技术的基础上进行扩展，结合应用平台和主应用网关，能够提供统一的登录和权限校验，降低开发成本，且能够统一管理和发布前端应用版本，减少前端应用的部署资源消耗。
72.应用场景总览
73.首先参考图2对本公开提供的方案的应用场景进行示例说明。图2为本公开实施例提供的一种应用场景示意图，如图2所示，本应用场景中，用户在通过客户端201打开前端应用时，客户端201从应用平台202获取前端应用对应的前端静态资源，渲染对应的前端应用页面；客户端201响应于用户对目标业务服务页面的请求操作，向主应用网关203发送数据请求消息；主应用网关203将该数据请求消息发送给目标后端服务204，并将接收到的目标
后端服务204发送的响应消息发送给客户端201，以使客户端201渲染目标业务服务页面。
74.需要说明的是，图2仅是本公开实施例提供的一种应用场景的示意图，本公开实施例不对图2中包括的设备进行限定，也不对图2中设备之间的位置关系进行限定。
75.示例性方法
76.下面结合图2的应用场景，参考图3来描述根据本公开示例性实施方式的用于基于微前端的数据处理的方法。需要注意的是，上述应用场景仅是为了便于理解本公开的精神和原理而示出，本公开的实施方式在此方面不受任何限制。相反，本公开的实施方式可以应用于适用的任何场景。
77.首先，通过具体实施例介绍基于微前端的数据处理方法。
78.图3为本公开一实施例提供的基于微前端的数据处理方法的信令交互示意图。如图3所示，本公开实施例的方法包括：
79.s301、应用平台接收前端应用的开发者通过上传工具上传的前端应用对应的版本文件，版本文件至少包含前端应用对应的前端静态资源和代码。
80.本公开实施例中，示例性地，图4为本公开一实施例提供的通过应用平台进行资源包版本管理的示意图，如图4所示，前端应用的开发者在自己本地电脑上完成前端应用的开发工作，然后使用上传工具上传前端应用对应的版本文件，版本文件至少包含前端应用对应的前端静态资源和代码。相应地，应用平台接收前端应用的开发者通过上传工具上传的前端应用对应的版本文件。可以理解，前端应用对应的版本文件均会统一上传到应用平台。
81.可选的，应用平台接收前端应用的开发者通过上传工具上传的前端应用对应的版本文件之前，还可以包括：应用平台对开发者在上传工具中配置的密钥进行鉴权，以确定开发者是否有权限通过上传工具上传前端应用对应的版本文件。
82.示例性地，在前端应用的开发者通过上传工具上传前端应用对应的版本文件之前，应用平台会给每个开发者生成一个密钥，开发者将该密钥配置到上传工具中。应用平台在接收前端应用的开发者通过上传工具上传的前端应用对应的版本文件之前，对开发者在上传工具中配置的密钥进行鉴权，以确定开发者是否有权限通过上传工具上传前端应用对应的版本文件。若鉴权结果为鉴权通过，则应用平台接收前端应用的开发者通过上传工具上传的前端应用对应的版本文件；若鉴权结果为未鉴权通过，则应用平台提示开发者没有权限通过上传工具上传前端应用对应的版本文件。通过上述方式，能够保障应用平台接收版本文件的安全性。
83.s302、应用平台根据版本文件，生成对应版本号的资源包，并将资源包发布到各个部署环境，部署环境包括开发部署环境、测试部署环境和运维部署环境。
84.该步骤中，示例性地，参考图4，开发者通过上传工具上传的前端应用对应的版本文件中包含用于生成相应版本号的资源包的构建打包脚本以及用于将相应版本号的资源包发布到各个部署环境的部署脚本。因此，应用平台在接收到前端应用的开发者通过上传工具上传的前端应用对应的版本文件后，可以根据版本文件，通过版本文件中的构建打包脚本生成对应版本号的资源包，并通过版本文件中的部署脚本将资源包发布到各个部署环境，部署环境包括开发部署环境、测试部署环境和运维部署环境。可以理解，通过应用平台统一生成前端应用对应版本号的资源包，并将资源包发布到各个部署环境。
85.s303、应用平台存储资源包对应的信息，以对各个部署环境的资源包进行相应版
本的切换，信息至少包括资源包对应的前端应用标识、资源包的版本号、资源包对应的部署环境。
86.示例性地，应用平台通过数据库存储资源包对应的信息。应用平台在根据版本文件，生成对应版本号的资源包，并将资源包发布到各个部署环境后，存储资源包对应的信息，该信息至少包括资源包对应的前端应用标识、资源包的版本号、资源包对应的部署环境，其中，部署环境包括开发部署环境、测试部署环境和运维部署环境。参考图4，可以理解，基于应用平台存储的资源包的信息(包括资源包的历史版本信息)，可以对各个部署环境的资源包进行相应版本的切换。示例性地，参考图4，若开发者通过应用平台显示的资源包对应的信息，发现当前版本的资源包存在问题，可以通过应用平台存储的资源包的历史版本快速切换到正确的历史版本对应的资源包。例如，应用平台为一个前端应用a分别生成了版本1对应的资源包和版本2对应的资源包；若开发者发现前端应用a当前使用的版本2的资源包存在缺陷，需要回退到版本1的资源包，则只需要将应用平台在数据库中存储的前端应用a正在使用的版本2修改为版本1，即可完成版本切换。通过上述方式，前端应用的发布流程从复杂的【上传代码
→
各部署环境对应的服务器上分别构建、生成资源包
→
各部署环境分别发布资源包】，简化为【应用平台统一生成资源包、将资源包发布到各个部署环境
→
通过应用平台的数据库中进行版本切换】。例如，对于前端应用x，目前的发布流程是上传前端应用x的代码后，分别在开发、测试和运维环境进行构建、生成对应的资源包，并将资源包分别发布到各部署环境；而本方案是开发上传代码到应用平台，生成资源包，并发布到开发、测试和运维环境，能够简化前端应用x的发布流程，减少前端应用x的部署资源消耗。
87.另外，由于通过应用平台统一管理资源包的版本，因此，前端从每个前端应用需要两台独立服务器进行部署，简化为通过应用平台所在的两台服务器支持多个前端应用，减少了服务器资源的使用，具体地，例如，原本针对每个前端应用至少需要两台独立服务器进行部署，若有n个前端应用，则至少需要2n台独立服务器进行部署，而本公开通过应用平台所在的两台服务器支持n个前端应用的部署，使得原本针对每个前端应用所进行的应用级的服务器冗余部署转变为了针对应用平台的平台级的服务器冗余部署，从而大大减少了服务器资源的使用；同时在版本切换流程中，无需为多种部署环境重复地进行构建任务工作，从而大大降低了任务构建的工作量。
88.该步骤中，可选的，资源包包括至少一个前端静态资源，应用平台存储资源包对应的信息，包括：应用平台获取资源包中包含的各前端静态资源对应的访问地址；存储访问地址与版本号的对应关系。
89.示例性地，资源包比如包括两个前端静态资源，则应用平台会给这两个前端静态资源分别生成对应的访问地址，将两个前端静态资源分别对应的访问地址组合为当前版本的数据。具体地，将两个前端静态资源分别对应的访问地址组合为js对象简谱(javascript object notation，json)格式的字符串，应用平台将该字符串和当前版本对应的版本号存储至数据库中。
90.s304、客户端响应于前端应用的打开操作，从应用平台获取前端应用对应的前端静态资源。
91.本公开实施例中，示例性地，前端应用的打开操作比如为用户打开前端应用。客户端响应于前端应用的打开操作，从应用平台读取前端应用对应的前端静态资源。可以理解，
在用户使用某个前端应用的时候，从应用平台自动分发对应的前端静态资源。
92.s305、客户端根据前端静态资源，渲染对应的前端应用页面。
93.该步骤中，客户端在从应用平台获取到前端应用对应的前端静态资源后，可以根据前端静态资源，渲染对应的前端应用页面，将渲染后的前端应用页面呈现给用户，便于用户浏览渲染后的前端应用页面。
94.s306、客户端响应于目标业务服务页面的请求操作，基于微前端沙箱技术，向主应用网关发送数据请求消息，数据请求消息携带有数据请求消息对应的来源标记、目标服务标记和用户信息。其中，来源标记用于表征数据请求消息的来源，目标服务标记用于表征数据请求消息对应的目标后端服务。
95.相应地，主应用网关接收客户端发送的数据请求消息。
96.本公开实施例中，微前端沙箱技术是基于javascript proxy功能进行javascript代码隔离的技术，在微前端沙箱技术的基础上，增加了对浏览器中运行的前端应用代码的监控能力。xmlhttprequest是前端发起http请求的方法，微前端沙箱技术可以代理xmlhttprequest，达到拦截发送出来的http请求，并添加来源标记和目标服务标记的效果。目标业务服务页面的请求操作比如为用户对目标业务服务页面的请求操作。主应用网关比如为通过bff技术搭建的。示例性地，客户端响应于目标业务服务页面的请求操作，基于微前端沙箱技术，向主应用网关发送数据请求消息。其中，数据请求消息携带有数据请求消息对应的来源标记、目标服务标记和用户信息，用户信息比如为客户端用cookie保存的用户名、用户登录状态和用户邮箱等，该用户信息即为登录用户信息。主应用网关在接收到客户端发送的数据请求消息后，会从数据请求消息中获得数据请求消息对应的来源标记、目标服务标记和用户信息。对于客户端如何基于微前端沙箱技术，向主应用网关发送数据请求消息，可参考后续实施例，此处不再赘述。
97.s307、主应用网关根据来源标记、用户信息和数据请求消息对应的请求地址，进行权限鉴定。
98.该步骤中，主应用网关在接收到客户端发送的数据请求消息后，可以根据数据请求消息中带的来源标记、用户信息以及数据请求消息对应的请求地址，进行权限鉴定，以确定客户端是否有权限访问数据请求消息对应的请求地址。对于主应用网关如何根据来源标记、用户信息和数据请求消息对应的请求地址，进行权限鉴定，可参考后续实施例，此处不再赘述。
99.若确定客户端有权限访问数据请求消息对应的请求地址，则执行s308步骤；若确定客户端没有权限访问请求地址，则主应用网关发送提示信息给客户端，提示信息用于表征客户端没有权限访问数据请求消息对应的请求地址。相应地，客户端接收主应用网关发送的提示信息，并反馈提示信息。
100.可以理解，主应用网关若确定客户端没有权限访问请求地址，会发送提示信息给客户端，以提示客户端没有权限访问数据请求消息对应的请求地址；客户端接收并反馈该提示信息，以通知用户没有权限访问上述的目标业务服务页面。
101.s308、若确定客户端有权限访问请求地址，则主应用网关根据目标服务标记以及预设后端服务配置，将数据请求消息发送给目标服务标记对应的目标后端服务。其中，预设后端服务配置用于表征服务标记和后端服务的对应关系，预设后端服务配置是由应用平台
所配置的。
102.示例性地，在应用平台将资源包发布到各个部署环境后，可以根据各个部署环境的后端服务由应用平台配置获得预设后端服务配置。具体地，可选的，应用平台接收后端服务对应的后端服务配置，后端服务配置用于表征服务标记和后端服务的对应关系；存储后端服务配置。示例性地，人工在应用平台配置服务标记和后端服务的对应关系(即后端服务配置)，相应地，应用平台接收后端服务对应的后端服务配置，并存储后端服务配置，该后端服务配置即为上述的预设后端服务配置。该步骤中，主应用网关在确定客户端有权限访问数据请求消息对应的请求地址后，可以根据目标服务标记以及预设后端服务配置，将包含有用户信息的数据请求消息发送给目标服务标记对应的目标后端服务，目标后端服务会获取数据请求消息携带的用户信息，进行相应逻辑的处理。其中，主应用网关能够直接将登录用户信息发送给目标后端服务，而不再需要目标后端服务通过cookie重新获取登录用户信息，因此，可以避免各后端服务重复开发登录功能。
103.进一步地，目标服务标记对应至少两个后端服务，主应用网关根据目标服务标记以及预设后端服务配置，将数据请求消息发送给目标服务标记对应的目标后端服务，包括：主应用网关根据目标服务标记查询预设后端服务配置，确定目标服务标记对应的至少两个后端服务；确定至少两个后端服务中访问量较小的后端服务为目标后端服务；将数据请求消息发送给目标后端服务。
104.示例性地，假设目标服务标记对应的两个后端服务分别为后端服务a和后端服务b，主应用网关根据目标服务标记查询预设后端服务配置，确定目标服务标记对应有后端服务a和后端服务b；若后端服务a和后端服务b中后端服务a的访问量小于后端服务b的访问量，则确定后端服务a为目标后端服务；将数据请求消息发送给后端服务a。后端服务a会获取数据请求消息携带的用户信息，进行相应逻辑的处理。
105.对于该步骤，可以理解，前端应用不需要做任何额外操作，通过主应用网关就可以将数据请求消息发送给目标后端服务，即完成正确的http请求行为；且由于预设后端服务配置是由应用平台所配置的，因此，具有更好的灵活性。
106.s309、主应用网关将目标后端服务发送的数据请求消息对应的响应消息，发送给客户端。
107.相应地，客户端接收主应用网关发送的数据请求消息对应的响应消息。
108.该步骤中，主应用网关在将数据请求消息发送给目标后端服务后，会接收到目标后端服务发送的数据请求消息对应的响应消息，因此，主应用网关将该响应消息发送给客户端，客户端接收该响应消息。
109.s310、客户端根据响应消息，渲染目标业务服务页面。
110.客户端在接收到主应用网关发送的数据请求消息对应的响应消息后，可以根据响应消息，渲染目标业务服务页面。示例性地，数据请求消息比如为获取榜单信息，则对应的响应消息中包含榜单信息，客户端根据该响应消息，渲染榜单服务页面。
111.需要说明的是，客户端基于微前端沙箱技术，可以把不同的前端应用运行在同一个页面中，给用户提供一站式使用体验。
112.本公开实施例提供的基于微前端的数据处理方法，通过应用平台接收前端应用的开发者通过上传工具上传的前端应用对应的版本文件，生成对应版本号的资源包，并将资
源包发布到各个部署环境，存储资源包对应的信息；客户端响应于前端应用的打开操作，从应用平台获取前端应用对应的前端静态资源，并渲染对应的前端应用页面；客户端响应于目标业务服务页面的请求操作，基于微前端沙箱技术，向主应用网关发送数据请求消息，数据请求消息携带有数据请求消息对应的来源标记、目标服务标记和用户信息；主应用网关根据来源标记、用户信息和数据请求消息对应的请求地址，进行权限鉴定；若确定客户端有权限访问请求地址，则主应用网关根据目标服务标记以及预设后端服务配置，将数据请求消息发送给目标后端服务，将接收到的目标后端服务发送的响应消息发送给客户端，客户端渲染目标业务服务页面。由于本公开实施例通过主应用网关对数据请求消息进行权限鉴定，将包含用户信息的数据请求消息发送给目标后端服务，不需要各后端服务重复开发登录和权限控制功能，因此，能够降低开发成本，提升用户体验；且通过应用平台统一管理资源包的生成和发布，能够简化前端应用的发布流程，减少前端应用的部署资源消耗；另外，通过主应用网关根据目标服务标记以及预设后端服务配置，将数据请求消息发送给目标后端服务，无需各部署环境分别修改代码配置，即可发送至正确的后端服务，能够简化开发和调试的流程。
113.图5为本公开一实施例提供的基于微前端的数据处理方法的流程图。在上述实施例的基础上，本公开实施例对主应用网关如何基于微前端进行数据处理进行进一步说明。如图5所示，本公开实施例的方法可以包括：
114.s501、接收客户端发送的数据请求消息，数据请求消息携带有数据请求消息对应的来源标记、目标服务标记和用户信息。
115.其中，来源标记用于表征数据请求消息的来源，目标服务标记用于表征数据请求消息对应的目标后端服务。
116.该步骤的具体描述可以参见图3所示实施例中s306步骤的相关描述，此处不再赘述。
117.本公开实施例中，图3中s307步骤可以进一步包括如下的s502至s504三个步骤：
118.s502、根据来源标记、用户信息和数据请求消息对应的请求地址，在应用平台中进行查询。
119.可以理解，通过应用平台可以按需预先配置好来源标记、用户信息和数据请求消息对应的请求地址的对应关系，即确定用户的访问权限，将用户的访问权限相关信息存储至应用平台的数据库中。示例性地，用户c想要访问前端应用1的接口“/api/edit”来完成一个编辑操作，则主应用网关会接收到对应的数据请求消息，其中，来源标记为该前端应用1的标识信息，数据请求消息对应的请求地址即为该前端应用1的接口“/api/edit”，因此，可以根据来源标记、用户信息和数据请求消息对应的请求地址，在应用平台中进行查询。
120.s503、若应用平台中存在与来源标记、用户信息和数据请求消息对应的请求地址完全匹配的数据信息，则确定客户端有权限访问请求地址。
121.示例性地，基于s502步骤中的示例，通过将应用平台中存储的用户c的访问权限相关信息与根据当前数据请求消息获得的来源标记、用户信息和数据请求消息对应的请求地址进行比对，若应用平台中存在与来源标记、用户信息和数据请求消息对应的请求地址完全匹配的数据信息，则确定用户c有权限访问该请求地址，进而执行s505步骤和s506步骤。
122.需要说明的是，权限校验是跨不同的前端应用的。示例性地，比如前端应用1的接
口“/api/edit”和前端应用2的接口“/api/edit2”，可能都只需要用户c有同样的权限即可访问。通过上述方式，能够给用户的访问权限配置提供更高的灵活性和便利性。
123.s504、若应用平台中不存在与来源标记、用户信息和数据请求消息对应的请求地址完全匹配的数据信息，则确定客户端没有权限访问请求地址。
124.示例性地，基于s502步骤中的示例，通过将应用平台中存储的用户c的访问权限相关信息与根据当前数据请求消息获得的来源标记、用户信息和数据请求消息对应的请求地址进行比对，若应用平台中不存在与来源标记、用户信息和数据请求消息对应的请求地址完全匹配的数据信息，则确定用户c没有权限访问该请求地址，进而执行s507步骤。
125.通过步骤s504，可以拦截不符合用户访问权限的数据请求消息。可以理解，通过该拦截行为，可以使得数据请求消息在到达后端服务前就完成拦截。提前拦截可以保证数据请求消息实际到达后端服务的时候，都已经通过权限校验的，即用户有权限访问数据请求消息对应的请求地址，后端服务无需额外考虑用户权限相关的问题。通过上述方式，既可以简化后端服务在使用用户权限功能时对业务代码的侵入性，使开发者可以专注在业务代码的开发，又可以以在应用平台进行权限配置的方式保障用户操作的安全性。
126.s505、若确定客户端有权限访问请求地址，则根据目标服务标记以及预设后端服务配置，将数据请求消息发送给目标服务标记对应的目标后端服务，预设后端服务配置用于表征服务标记和后端服务的对应关系，预设后端服务配置是由应用平台所配置的。
127.该步骤的具体描述可以参见图3所示实施例中s308步骤中的相关描述。
128.s506、将目标后端服务发送的数据请求消息对应的响应消息，发送给客户端。
129.该步骤的具体描述可以参见图3所示实施例中s309步骤中的相关描述，此处不再赘述。
130.s507、发送提示信息给客户端，提示信息用于表征客户端没有权限访问数据请求消息对应的请求地址。
131.该步骤的具体描述可以参见图3所示实施例中s307步骤中的相关描述，此处不再赘述。
132.本公开实施例提供的基于微前端的数据处理方法，由于主应用网关根据数据请求消息携带的来源标记和用户信息以及数据请求消息对应的请求地址，在应用平台中进行查询进行权限鉴定，在确定户端有权限访问数据请求消息对应的请求地址后，将包含用户信息的数据请求消息发送给目标后端服务，不需要各后端服务重复开发登录和权限控制功能，因此，能够降低开发成本，提升用户体验；且通过主应用网关根据目标服务标记以及预设后端服务配置，将数据请求消息发送给目标后端服务，无需各部署环境分别修改代码对应的后端服务相关配置，即可发送至正确的后端服务，能够简化开发和调试的流程。
133.在上述实施例的基础上，可选的，根据来源标记、用户信息和数据请求消息对应的请求地址，进行权限鉴定之前，还包括：根据用户信息和预设加密算法，获取用户信息对应的用户认证信息；根据目标服务标记以及预设后端服务配置，将数据请求消息发送给目标服务标记对应的目标后端服务，包括：在数据请求消息中添加用户认证信息；根据目标服务标记以及预设后端服务配置，将添加了用户认证信息的数据请求消息发送给目标服务标记对应的目标后端服务，以使目标后端服务根据用户认证信息获得对应的用户信息。
134.示例性地，预设加密算法比如为rsa加密算法(以rivest、shamir、adleman三人的
名字命名的加密算法)。在用户登录前端应用后，主应用网关根据用户信息和rsa加密算法，获取用户信息对应的用户认证信息，为每个需要转发到后端服务器的数据请求消息的消息头(header)添加上用户信息认证信息。主应用网关根据目标服务标记以及预设后端服务配置，将添加了用户认证信息的数据请求消息发送给目标服务标记对应的目标后端服务，以使目标后端服务根据用户认证信息获得对应的用户信息。
135.需要说明的是，由于用户信息可以在服务器间传输，需要额外考虑一些安全性措施，因此，一种可能的实施方式中，可以只允许各服务器在局域网内建立通信连接，以保证用户信息在服务器间传输的安全性。
136.另外，还可以对用户信息进行基于rsa加密算法的认证，以保证用户信息来源的可靠性，最终保证用户信息在传输过程中的安全性。
137.图6为本公开另一实施例提供的基于微前端的数据处理方法的流程图。在上述实施例的基础上，本公开实施例对客户端如何基于微前端进行数据处理进行进一步说明。如图6所示，本公开实施例的方法可以包括：
138.s601、响应于前端应用的打开操作，从应用平台获取前端应用对应的前端静态资源。
139.该步骤的具体描述可以参见图3所示实施例中s304步骤中的相关描述，此处不再赘述。
140.s602、根据前端静态资源，渲染对应的前端应用页面。
141.该步骤的具体描述可以参见图3所示实施例中s305步骤中的相关描述，此处不再赘述。
142.本公开实施例中，图3中s306步骤可以进一步包括如下的s603至s605三个步骤：
143.s603、响应于目标业务服务页面的请求操作，通过微前端沙箱技术将前端应用的全局对象替换为代理模块的全局对象。
144.其中，前端应用包含目标业务服务页面，代理模块用于通过为不同的前端应用创建不同的全局对象，以隔离不同的前端应用。
145.示例性地，微前端沙箱技术可以代理前端应用中的xmlhttprequest对象，即将前端应用中的xmlhttprequest对象替换为代理模块的全局对象，以隔离不同的前端应用，实现对前端应用的数据请求消息的修改能力。
146.s604、基于代理模块的全局对象，在目标业务服务页面的请求操作对应的初始请求消息中添加来源标记和目标服务标记，获得数据请求消息。
147.示例性地，xmlhttprequest是前端应用中用来进行数据请求的方法，在通过微前端沙箱技术对xmlhttprequest代理的基础上，即基于代理模块的全局对象，在目标业务服务页面的请求操作对应的初始请求消息(即当前要发出的数据请求消息)中添加来源标记和目标服务标记，获得数据请求消息。例如，在前端应用1中，用户编辑数据需要给后端服务发送一个数据请求消息，数据请求消息对应的请求地址即为该前端应用1的接口“/api/edit”，通过本公开实施例提供的方法，无需修改前端应用的代码，即可在发送数据请求消息前获得数据请求消息对应的来源标记以及目标服务标记，然后通过微前端沙箱技术统一添加来源标记和目标服务标记，获得数据请求消息，以将该获得数据请求消息发送给主应用网关。
148.s605、向主应用网关发送数据请求消息，数据请求消息携带有数据请求消息对应的来源标记、目标服务标记和用户信息。
149.该步骤的具体描述可以参见图3所示实施例中s306步骤中的相关描述，此处不再赘述。
150.s606、接收主应用网关发送的数据请求消息对应的响应消息。
151.该步骤的具体描述可以参见图3所示实施例中s309步骤的相关描述，此处不再赘述。
152.s607、根据响应消息，渲染目标业务服务页面。
153.该步骤的具体描述可以参见图3所示实施例中s310步骤的相关描述，此处不再赘述。
154.本公开实施例提供的基于微前端的数据处理方法，由于客户端基于微前端沙箱技术，在目标业务服务页面的请求操作对应的初始请求消息中添加来源标记和目标服务标记，获得数据请求消息；向主应用网关发送数据请求消息，以使主应用网关根据来源标记进行权限鉴定以及根据目标服务标记将数据请求消息发送给对应的目标后端服务。因此，能够降低开发成本，提升用户体验；且无需各部署环境分别修改代码配置，即可发送至正确的后端服务，能够简化开发和调试的流程。
155.示例性装置
156.在介绍了本公开示例性实施方式的介质之后，接下来，参考图7对本公开示例性实施方式的基于微前端的数据处理装置进行说明。本公开示例性实施方式的装置，可以实现前述应用于主应用网关的基于微前端的数据处理实施例中的各个过程，并达到相同的功能和效果。
157.图7为本公开一实施例提供的基于微前端的数据处理装置的结构示意图，应用于主应用网关。如图7所示，本公开实施例的基于微前端的数据处理装置700包括：接收模块701、鉴定模块702和发送模块703。其中：
158.接收模块701，用于接收客户端发送的数据请求消息，数据请求消息携带有数据请求消息对应的来源标记、目标服务标记和用户信息，来源标记用于表征数据请求消息的来源，目标服务标记用于表征数据请求消息对应的目标后端服务。
159.鉴定模块702，用于根据来源标记、用户信息和数据请求消息对应的请求地址，进行权限鉴定。
160.发送模块703，用于若确定客户端有权限访问请求地址，则根据目标服务标记以及预设后端服务配置，将数据请求消息发送给目标服务标记对应的目标后端服务，预设后端服务配置用于表征服务标记和后端服务的对应关系，预设后端服务配置是由应用平台所配置的；以及将目标后端服务发送的数据请求消息对应的响应消息，发送给客户端。
161.在一些实施例中，鉴定模块702可以具体用于：根据来源标记、用户信息和数据请求消息对应的请求地址，在应用平台中进行查询；若应用平台中存在与来源标记、用户信息和数据请求消息对应的请求地址完全匹配的数据信息，则确定客户端有权限访问请求地址；或者，若应用平台中不存在与来源标记、用户信息和数据请求消息对应的请求地址完全匹配的数据信息，则确定客户端没有权限访问请求地址。
162.可选的，鉴定模块702还可以用于：若确定客户端没有权限访问请求地址，则发送
提示信息给客户端，提示信息用于表征客户端没有权限访问数据请求消息对应的请求地址。
163.在一些实施例中，目标服务标记对应至少两个后端服务，发送模块703可以具体用于：根据目标服务标记查询预设后端服务配置，确定目标服务标记对应的至少两个后端服务；确定至少两个后端服务中访问量较小的后端服务为目标后端服务；将数据请求消息发送给目标后端服务。
164.可选的，该基于微前端的数据处理装置700还包括获取模块704，用于在鉴定模块根据来源标记、用户信息和数据请求消息对应的请求地址，进行权限鉴定之前，根据用户信息和预设加密算法，获取用户信息对应的用户认证信息；发送模块具体用于：在数据请求消息中添加用户认证信息；根据目标服务标记以及预设后端服务配置，将添加了用户认证信息的数据请求消息发送给目标服务标记对应的目标后端服务，以使目标后端服务根据用户认证信息获得对应的用户信息。
165.本公开实施例提供的基于微前端的数据处理装置，可以用于执行上述任一方法实施例中应用于主应用网关的基于微前端的数据处理方法的方案，其实现原理和技术效果类似，此处不再赘述。
166.图8为本公开另一实施例提供的基于微前端的数据处理装置的结构示意图，应用于客户端。如图8所示，本公开实施例的基于微前端的数据处理装置800包括：获取模块801、第一渲染模块802、发送模块803、接收模块804和第二渲染模块805。其中：
167.获取模块801，用于响应于前端应用的打开操作，从应用平台获取前端应用对应的前端静态资源。
168.第一渲染模块802，用于根据前端静态资源，渲染对应的前端应用页面。
169.发送模块803，用于响应于目标业务服务页面的请求操作，基于微前端沙箱技术，向主应用网关发送数据请求消息，数据请求消息携带有数据请求消息对应的来源标记、目标服务标记和用户信息。
170.接收模块804，用于接收主应用网关发送的数据请求消息对应的响应消息。
171.第二渲染模块805，用于根据响应消息，渲染目标业务服务页面。
172.在一些实施例中，发送模块803可以具体用于：通过微前端沙箱技术将前端应用的全局对象替换为代理模块的全局对象，前端应用包含目标业务服务页面，代理模块用于通过为不同的前端应用创建不同的全局对象，以隔离不同的前端应用；基于代理模块的全局对象，在目标业务服务页面的请求操作对应的初始请求消息中添加来源标记和目标服务标记，获得数据请求消息；向主应用网关发送数据请求消息。
173.可选的，接收模块804还可以用于：接收主应用网关发送的提示信息，提示信息用于表征客户端没有权限访问数据请求消息对应的请求地址；反馈提示信息。
174.本公开实施例提供的基于微前端的数据处理装置，可以用于执行上述任一方法实施例中应用于客户端的基于微前端的数据处理方法的方案，其实现原理和技术效果类似，此处不再赘述。
175.图9为本公开又一实施例提供的基于微前端的数据处理装置的结构示意图，应用于应用平台。如图9所示，本公开实施例的基于微前端的数据处理装置900包括：接收模块901、处理模块902和存储模块903。其中：
176.接收模块901，用于接收前端应用的开发者通过上传工具上传的前端应用对应的版本文件，版本文件至少包含前端应用对应的前端静态资源和代码。
177.处理模块902，用于根据版本文件，生成对应版本号的资源包，并将资源包发布到各个部署环境，部署环境包括开发部署环境、测试部署环境和运维部署环境。
178.存储模块903，用于存储资源包对应的信息，以对各个平台的资源包进行相应版本的切换，信息至少包括资源包对应的前端应用标识、资源包的版本号、资源包对应的部署环境。
179.在一些实施例中，资源包包括至少一个前端静态资源，存储模块903可以具体用于：获取资源包中包含的各前端静态资源对应的访问地址；存储访问地址与版本号的对应关系。
180.可选的，该基于微前端的数据处理装置900还包括鉴权模块904，用于在接收模块接收前端应用的开发者通过上传工具上传的前端应用对应的版本文件之前，对开发者在上传工具中配置的密钥进行鉴权，以确定开发者是否有权限通过上传工具上传前端应用对应的版本文件。
181.在一些实施例中，接收模块901还可以用于：接收后端服务对应的后端服务配置，后端服务配置用于表征服务标记和后端服务的对应关系；存储模块903还可以用于存储后端服务配置。
182.本公开实施例提供的基于微前端的数据处理装置，可以用于执行上述任一方法实施例中应用于应用平台的基于微前端的数据处理方法的方案，其实现原理和技术效果类似，此处不再赘述。
183.示例性介质
184.在介绍了本公开示例性实施方式的方法之后，接下来，参考图10对本公开示例性实施方式的存储介质进行说明。
185.图10为本公开一实施例提供的存储介质示意图。参考图10所示，存储介质1000中存储着根据本公开的实施方式的用于实现上述方法的程序产品，其可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此。
186.所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
187.可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质。
188.可以以一种或多种程序设计语言的任意组合来编写用于执行本公开公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c 等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在
用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备。
189.示例性计算设备
190.在介绍了本公开示例性实施方式的方法、介质和装置之后，接下来，参考图11对本公开示例性实施方式的计算设备进行说明。
191.图11显示的计算设备1100仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
192.图11为本公开一实施例提供的计算设备的结构示意图，如图11所示，计算设备1100以通用计算设备的形式表现。计算设备1100的组件可以包括但不限于：上述至少一个处理单元1101、上述至少一个存储单元1102，连接不同系统组件(包括处理单元1101和存储单元1102)的总线1103。
193.总线1103包括数据总线、控制总线和地址总线。
194.存储单元1102可以包括易失性存储器形式的可读介质，例如随机存取存储器(ram)11021和/或高速缓存存储器11022，可以进一步包括非易失性存储器形式的可读介质，例如只读存储器(rom)11023。
195.存储单元1102还可以包括具有一组(至少一个)程序模块11024的程序/实用工具11025，这样的程序模块11024包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
196.计算设备1100也可以与一个或多个外部设备1104(例如键盘、指向设备等)通信。这种通信可以通过输入/输出(i/o)接口1105进行。并且，计算设备1100还可以通过网络适配器1106与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图11所示，网络适配器1106通过总线1103与计算设备1100的其它模块通信。应当理解，尽管图中未示出，可以结合计算设备1100使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
197.应当注意，尽管在上文详细描述中提及了基于微前端的数据处理装置的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。
198.此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
199.虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。