一种前端微服务聚合技术解决方法

技术领域

本发明涉及前端技术领域，尤其涉及一种前端微服务聚合技术解决方法。

背景技术

目前，很多公司前端都会面临着如下业务窘境：

1老旧项目重构优化和新需求并行开发冲突；

2很难快速复用基于不同技术栈的现有模块，功能，或能力聚合成一个完整的全量系统；

3即使能做到2，但是也很难打通和统一各个子系统的权限；

4，各个子业务系统(或者说模块)的开发人员，很难做到分支，版本控制，协作困难；

5，各个子业务系统(或者说模块)的数据通信，方式方法混乱很难统一；

6，公共业务组件的没有一个合理有效的复用方式；

7，以及一些所有巨量系统中都存在的，在开发阶段各个系统之间，如何合理有效的进行调试，开发，以及测试工作；

8，在开发toB项目尤其是中后台项目时，以往的趋势都是搭建一个功能强大且完善的单页应用程序。但是中后台项目生命周期较长(一般3年+)，这期间由于参与的人员、团队的增多、变迁，单页应用就会从一个普通应用演变成一个巨石应用。随之而来就导致项目无法维护尾大不掉。这类问题在企业级Web应用中尤其常见。

在与以上这些困扰着前端开发人员的问题或者说现象博弈中，如何在这些困境中，找到一套适合自己团队的开发理论，总结沉淀出一套符合现代敏捷开发模式的，科学有效的方式方法，技术理论，甚至说系统，将成为前端开发的一个新方向和新思潮。

目前流行的前端方案有：

1、基于iframes沙箱的服务器的路由来重定向多个应用；

2、基于nginx内容分发；

3、基于webpack5的模块联邦微前端方案；

4、基于singalSpan的微前端方案

以上几个方案都有各自的优缺点：

1、方案1iframe的兼容性，以及样式错乱，刷新新页面的影响，以及需要手动维护一套复杂的系统模块之间的数据交互，心智负担比较重；

2、nginx的内容分发，需要跨部门的协作，再者对前端来说，也不太擅长这块的内容。

3、Webpack 5的联邦模块系统是一个高效的加载体系，但它也有一些潜在的缺点。首先，它可能会导致代码的复杂度增加，因为您需要对不同的模块进行分组和管理。其次，联邦模块可能会影响代码的性能，因为它们需要加载大量的模块。最后，联邦模块系统可能会增加开发人员的学习曲线，因为它们需要深入了解如何使用该系统

4、基于singalSpan的微前端方案，api接口虽然丰富便于扩展，但本身的css沙箱实现并不是特别好，再加上较于qianqun来说，接口配置复杂，不够聚合，使用配置起来比较麻烦

5、以上方案开发调试比较麻烦，没有一个便利化的解决方案。

发明内容

鉴于上述问题，提出了本发明以便提供克服上述问题或者至少部分地解决上述问题的一种前端微服务聚合技术解决方法。

根据本发明的一个方面，提供了一种前端微服务聚合技术解决方法，所述解决方法包括：

采用基于qiankun的基座方式，通过主应用分发路由，匹配定位不同子应用的技术方案，实现整套微服务整体架构；包括：路由注册配置中心，角色权限认证配置，主子应用菜单配置注册中心，主子应用通信方案，通用公共方法共享方案，公共业务组件。

可选的，所述基座由vue+qiankun开发实现，是一个轻量级，可插拔式，可配置化的前端微服务聚合解决方案，包括：微应用注册配置、角色权限配置中心以及应用菜单配置、主子应用的通信方案、通用公共方法共享方案、公共业务组件抽离、便利化开发调试、主子应用单开仓库，独立部署。

可选的，所述微应用注册配置具体包括：

当主应用通过url访问对应的子应用进行交互时，需要路由到任意一个微应用，就需要，有一个可视化的配置注册平台来在主应用中注册子应用的激活路由，在本系统中，通过页面可视化的配置路由规则，配备不同环境而且支持多种不同的路由规则，调用乾坤的registerMicroApps注册，在不同的路由被激活时，在主应用指定的dom节点，加载不同的子应用的umd包，实现路由转发。

可选的，所述角色权限配置中心以及应用菜单配置具体包括：

主子应用的角色权限，会有一个专门的系统管理的子应用去做权限角色的配置和分发，统一授权合理划分，将权限角色做统一处理，有助于统一收敛权责不一致的矛盾，结合菜单配置，做到页面以及button级别的细微控制，统一的授权的菜单再由主应用统一下发管理。

可选的，所述主子应用的通信方案具体包括：

使用qiankun提供的api-initGlobalState进行通信，通过在主、微应用中定义状态管理类的方式进行通信；

主应用作为中转，进行状态承接与派发，各个微应用不仅能获取主应用的状态变更，还能同步自身状态到主应用，微应用能独立运行。

可选的，所述通用公共方法共享方案具体包括：

主子应用之间会有很多重复的公共的方法，都是一些常用的工具函数，没有必要同时加载多份，采用在registerMicroApps注册的时候，通过props属性暴露给子应用，子应用在路Z由激活时，通过initGlobalState的onGlobalStateChange的入参，存在全局的以key-value的形式存在util对象上，在应用存活时随用随取，在应用卸载时调用unmount，remove掉utils对象上的方法。

可选的，所述公共业务组件抽离具体包括：

基于业务开发角度，在开发过程成可能遇到很多业务组件相似度很高，需要模块复用的场景，采用的方案是建立一个公共业务组件库的子应用，利用子应用嵌套微应用的原理，通过url匹配对应模块路由的，手动调用loadMicroApp，按需加载公共模块的方式实现复用逻辑；

基于相同组件库等第三方依赖，考虑将elemnent-ui，lodash的第三方依赖，直接使用cdn资源完全抽离，挂在到全局对象上，复用相同依赖。

可选的，便利化开发调试具体包括：

利用结合locoalstorage，判断当前资源的访问路径，判断当前资源访问环境，通过可是化页面配置，选择访问资源的地址；

劫持替换当前资源地址前缀，做到本地子应用访问线上主应用，应用之间的单开服务，聚焦本身自己的业务开发。

可选的，所述主子应用单开仓库，独立部署具体包括：

主子应用的仓库各自维护，有各自的分支策略，项目模块之间项目解耦，不存在一个特性上线，所有项目重新打包，重新发布，阻塞业务主流程的现象，团队协作接入方案后不会影响，当前子应用的固有功能。

本发明提供的一种前端微服务聚合技术解决方法，所述解决方法包括：采用基于qiankun的基座方式，通过主应用分发路由，匹配定位不同子应用的技术方案，实现整套微服务整体架构；包括：路由注册配置中心，角色权限认证配置，主子应用菜单配置注册中心，主子应用通信方案，通用公共方法共享方案，公共业务组件。独立开发、独立部署，增量升级，独立运行，便于开发调试的微前端聚合解决方案。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

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

图1为本发明实施例提供的前端微服务聚合的整体架构图；

图2为本发明实施例提供的微前端通信模型示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明的说明书实施例和权利要求书及附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元。

下面结合附图和实施例，对本发明的技术方案做进一步的详细描述。

如图1所示，本系统使用基于qiankun的基座方式，通过主应用分发路由，匹配定位不同子应用的技术方案，实现整套微服务整体架构，包含路由注册配置中心，角色权限认证配置，主子应用菜单配置注册中心，主子应用通信方案，通用公共方法共享方案，公共业务组件等。结合目前行内前端技术方向，主应用的基座是由vue+qiankun开发实现，是一个轻量级，可插拔式，可配置化的前端微服务聚合解决方案，包含但不限于以下能力

微应用注册配置，具体包括：

当主应用通过url访问对应的子应用进行交互时，需要路由到任意一个微应用，就需要，有一个可视化的配置注册平台来在主应用中注册子应用的激活路由，在本系统中，通过页面可视化的配置路由规则，配备不同环境而且支持多种不同的路由规则，调用乾坤的registerMicroApps注册，在不同的路由被激活时，在主应用指定的dom节点，加载不同的子应用的umd包，实现路由转发。

角色权限配置中心以及应用菜单配置，具体包括：

主子应用的角色权限，会有一个专门的系统管理的子应用去做权限角色的配置和分发，统一授权合理划分，将权限角色做统一处理，有助于统一收敛权责不一致的矛盾，结合菜单配置，可以做到页面以及button级别的细微控制，统一的授权的菜单再由主应用统一下发管理。

主子应用的通信方案，具体包括：

使用qiankun提供的api-initGlobalState进行通信，通过在主、微应用中定义状态管理类的方式进行通信。主应用作为中转，进行状态承接与派发，各个微应用不仅能获取主应用的状态变更，还能同步自身状态到主应用，微应用能独立运行。

通用公共方法共享方案，如图2所示。

主子应用之间可能会有很多重复的公共的方法，这些方法基本都是一些常用的工具函数，没有必要同时加载多份，这边采用在registerMicroApps注册的时候，通过props属性暴露给子应用，子应用在路Z由激活时，通过initGlobalState的onGlobalStateChange的入参，拿到方法，存在全局的以key-value的形式存在util对象上，在应用存活时随用随取，在应用卸载时调用unmount，remove掉utils对象上的方法。

公共业务组件抽离，具体包括：

基于业务开发角度，在开发过程成可能遇到很多业务组件相似度很高，需要模块复用的场景，这里采用的方案是建立一个公共业务组件库的子应用，利用子应用可以嵌套微应用的原理，通过url匹配对应模块路由的，手动调用loadMicroApp，按需加载公共模块的方式实现复用逻辑；

基于相同组件库等第三方依赖，可以考虑将elemnent-ui，lodash等这样的第三方依赖，可以直接使用cdn资源完全抽离，挂在到全局对象上，复用这些相同依赖，减少包体大小，提高打包速度，提升fcp。

便利化开发调试，包括：

在通常的开发过程中，经常会涉及主子应用的之间的联调和测试，一般情况下会起两个服务，一个主应用一个子应用，这样非常不利于正常开发协作，我们在除线上正式环境外，利用结合locoalstorage，判断当前资源的访问路径，判断当前资源访问环境，通过可是化页面配置，选择访问资源的地址(是对应环境的线上资源的访问地址，还是本地资源)。劫持替换当前资源地址前缀，这样就可以做到本地子应用访问线上主应用，反之亦然，应用之间的可以单开服务，聚焦本身自己的业务开发，大大的提升开发效率。

主子应用单开仓库，独立部署，包括：

主子应用的仓库各自维护，有各自的分支策略，项目模块之间项目解耦，不存在一个特性上线，所有项目重新打包，重新发布，阻塞业务主流程的现象，团队协作接入方案后不会影响，当前子应用的固有功能，做到完全技术栈无关，独立开发、独立部署，增量升级，独立运行。

有益效果：一套完全技术栈无关，独立开发、独立部署，增量升级，独立运行，便于开发调试的微前端聚合解决方案。

以上的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。