CN115277637B - 基于微前端架构的多域名项目的管理平台及高度聚合部署方法 - Google Patents

Abstract

本发明提供一种基于微前端架构的多域名项目的管理平台及高度聚合部署方法，管理平台包括：基于基座应用的第一主应用、第二主应用；其中，基座应用用于提供全局通用功能；第一主应用使用代理服务器配置有至少一个子应用；第二主应用使用代理服务器配置有至少一个子应用；第一主应用的二级域名和第二主应用的二级域名不同，第一主应用的二级域名和第二主应用的二级域名被设置成在基座应用所在代理服务器上指向同一个存储的目录位置。该管理平台可将高内聚的基座应用作为公有资源，使得不同域名的多个主应用和同框架的子应用共享基座应用所提供的所有资源，支持多域名、多项目、跨域环境下使用，极大的降低了开发成本、测试成本和维护成本。

Description

基于微前端架构的多域名项目的管理平台及高度聚合部署 方法

技术领域

本发明涉及计算机信息技术领域，尤其涉及一种基于微前端架构的多域名项目的管理平台及高度聚合部署方法。

背景技术

本部分旨在为权利要求书中陈述的本发明的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

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

由于公司项目庞大，不论是后台系统，还是前台业务系统都由几个甚至几十个前端应用构成，例如将后台系统的前端应用将所有代码都放在一个项目，随着业务的不断更新，项目逐渐臃肿，维护成本不断提高，项目打包时间变长，打包占用硬件资源变大，打包成功率变低。

前台业务系统受业务线及微服务影响，产生了几十个前端应用，后期将会继续增加。目前由于应用数量过多，维护起来变的困难，学习成本不断提高，不便于管理。

同时前台业务由多个二级域名构成，每个域名中的框架结构一致，这样的结构导致不同域名下相同结构部分的变更，都需要同步变更多个项目文件并将其更新至生产环境。不避要的更新和多次的变更带来多次的测试和不同程度的风险。

发明内容

鉴于此，本发明实施例提供了一种基于微前端架构的多域名项目的管理平台及高度聚合部署方法，以消除或改善现有技术中存在的一个或更多个缺陷。

本发明的技术方案如下：

根据本发明的一方面，本发明提供了一种基于微前端架构的多域名项目的管理平台，所述管理平台包括：基于基座应用的第一主应用、第二主应用；其中，所述基座应用为所述第一主应用和第二主应用的通用基座，用于给所述第一主应用和第二主应用提供全局通用功能；所述第一主应用使用代理服务器配置有至少一个子应用，所述第一主应用的所有的子应用注册到所述第一主应用中；所述第二主应用使用代理服务器配置有至少一个子应用，所述第二主应用的所有的子应用注册到所述第二主应用中；所述第一主应用的二级域名和所述第二主应用的二级域名不同，所述第一主应用的二级域名和所述第二主应用的二级域名被设置成在所述基座应用所在代理服务器上指向同一个存储的目录位置，所述基座应用作为所述第一主应用及其子应用、所述第二主应用及其子应用的访问入口。

在一些实施例中，所述管理平台还包括：第三主应用，其使用代理服务器配置了至少一个子应用，所述第三主应用的所有的子应用注册到所述第三主应用中，所述第三主应用的二级域名与所述第一主应用、第二主应用均不同，所述第三主应用的二级域名的根目录也指向所述基座应用。

在一些实施例中，所述第一主应用和所述第二主应用的顶级域名相同或不同。

在一些实施例中，所述第一主应用是面向企业用户的业务系统，包含多个子业务应用；所述第二主应用是面向内部人员的用户中心系统，包含多个子业务应用；在所述管理平台包括第三主应用的情况下，所述第三主应用是账户中心系统，包含多个子业务应用。

在一些实施例中，所述基座应用包括：

基本框架模块，用于给所述管理平台提供基本框架和操作页面；

全局配置模块，用于统一管理所述管理平台的各应用项目的配置信息；

应用注册模块，用于根据预设的注册应用配置信息将子应用注册到对应的主应用中，也用于将主应用注册到所述基座应用中，未注册的子应用、主应用无法通过所述基座应用进行访问；

共享axios模块，用于在所述基座应用中封装网络请求axios并将其下发至主应用和/或子应用中，以全局控制网络请求，对接口请求及相应做出统一控制；

工具类模块，用于将工具类下发至子应用，以避免各子应用各自加载和单独升级；

共享组件模块，用于将多个应用项目常用的组件封装为所述基座应用的通用组件，并能将该所述通用组件向主应用和/或子应用下发；

共享Store模块，用于管理各应用项目的共享状态，若主应用之间、主子应用之间和子应用之间存在共享状态，其中任意一个应用项目的数据状态进行变更，则其余的应用项目的对应数据均同步变更。

在一些实施例中，所述基座应用的基本框架模块提供的操作页面包括有：主应用访问入口单元、当前展示的主应用框架单元、组件展示单元；其中，所述主应用访问入口单元用于进入不同二级域名的各个主应用；所述主应用框架单元用于展示所述基座应用的框架，该框架在展示不同的主应用时，由该主应用与基座应用的通信接口决定；所述组件展示单元用于显示当前主应用的组件，主应用的组件能被其子应用作为通用组件调用。

在一些实施例中，所述基座应用的各主应用通过设置的状态管理模块与其对应的子应用进行通信，所述状态管理模块将主应用的状态管理对象暴露给对应的子应用，则该子应用与主应用能共同操作该状态管理对象来操作数据，实现主应用和子应用的通信。

根据本发明的另一方面，本发明也提供了一种多域名项目的高度聚合部署方法，该方法基于如前述的管理平台，包括如下步骤：

S10：将多个不同二级域名的主应用指向到同一代理服务器，代理服务器对多个二级域名做好绑定；

S20：将各个不同二级域名的主应用的根目录指向该代理服务器的同一个根目录，以实现基座应用的共享；

S30：将基座应用的源代码部署到各主应用在代理服务器所指向的根目录下，以实现不同域名的主应用的高度聚合部署；

在完成不同域名的主应用的高度聚合部署后，用户访问任一指定的主应用的二级域名时，代理服务器都会将资源指向基座应用所存储的目录位置。

根据本发明的又一方面，本发明也提供了一种基于多域名项目的高度聚合部署装置，包括处理器和存储器，所述存储器中存储有计算机指令，所述处理器用于执行所述存储器中存储的计算机指令，当所述计算机指令被处理器执行时，该装置实现如前述高度聚合部署方法的步骤。

根据本发明的再一方面，本发明也提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如前述高度聚合部署方法的步骤。

根据本发明实施例的基于微前端架构的多域名项目的管理平台及高度聚合部署方法，可获得的有益效果至少包括：

（1）该管理平台可将多种技术栈应用项目（如JSP项目与SPA项目）集成到一个平台中统一管理，解决了公共文件分散、各自维护、未统一管理读取的乱象。

（2）该管理平台和部署方法可将高内聚的基座应用作为公有资源，使得不同域名的多个主应用和同框架的子应用共享基座应用所提供的所有资源，支持多域名、多项目、跨域环境下使用，高度聚合部署的方式极大的降低了开发成本、测试成本和维护成本，同时使得管理平台管理的各个应用项目的扩展能力、移值能力得到极大的提高。

本发明的附加优点、目的，以及特征将在下面的描述中将部分地加以阐述，且将对于本领域普通技术人员在研究下文后部分地变得明显，或者可以根据本发明的实践而获知。本发明的目的和其它优点可以通过在书面说明及其权利要求书以及附图中具体指出的结构实现到并获得。

本领域技术人员将会理解的是，能够用本发明实现的目的和优点不限于以上具体所述，并且根据以下详细说明将更清楚地理解本发明能够实现的上述和其他目的。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。附图中的部件不是成比例绘制的，而只是为了示出本发明的原理。为了便于示出和描述本发明的一些部分，附图中对应部分可能被放大，即，相对于依据本发明实际制造的示例性装置中的其它部件可能变得更大。在附图中：

图1为本发明一实施例中的管理平台的架构框图。

图2为本发明一实施例中的基座应用的功能模块框图。

图3为本发明一实施例中的基座应用提供的操作页面的示意图。

图4为本发明一实施例中的管理平台的各子应用可使用的技术栈子的示意图。

图5为本发明一实施例中的管理平台的多域名高度聚合部署的示意图。

图6为本发明一实施例中的用户访问本申请管理平台中的应用项目的示意图。

图7为本发明一实施例中以一个主应用为例的部署架构图。

图8为本发明一实施例中的管理平台的主应用和子应用的通信示意图。

图9为本发明一实施例中的多域名项目的高度聚合部署方法的步骤示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施方式和附图，对本发明做进一步详细说明。在此，本发明的示意性实施方式及其说明用于解释本发明，但并不作为对本发明的限定。

在此，还需要说明的是，为了避免因不必要的细节而模糊了本发明，在附图中仅仅示出了与根据本发明的方案密切相关的结构和/或处理步骤，而省略了与本发明关系不大的其他细节。

应该强调，术语“包括/包含”在本文使用时指特征、要素、步骤或组件的存在，但并不排除一个或更多个其它特征、要素、步骤或组件的存在或附加。

在此，还需要说明的是，如果没有特殊说明，术语“连接”在本文不仅可以指直接连接，也可以表示存在中间物的间接连接。

在下文中，将参考附图描述本发明的实施例。在附图中，相同的附图标记代表相同或类似的部件，或者相同或类似的步骤。

本发明提供了一种基于微前端架构的多域名项目的管理平台及高度聚合部署方法，该管理平台不仅可将多种技术栈应用项目集成到一个平台中统一管理，解决了公共文件分散、各自维护、未统一管理读取的乱象；也可将高内聚的基座应用作为公有资源，使得不同域名的多个主应用和同框架的子应用共享基座应用所提供的所有资源，支持多域名、多项目、跨域环境下使用，高度聚合部署的方式极大的降低了开发成本、测试成本和维护成本，同时使得管理平台管理的各个应用项目的扩展能力、移值能力得到极大的提高。

传统微前端部署的主应用只提供给一个域名应用下使用，与传统微前端部署方式相比，本发明所述的高度聚合部署是指将高内聚的基座应用做为公共资源向子应用提供服务。高度聚合部署支持多域名、多项目、跨域环境下使用，使子应用可同时访问同一个主应用和基座应用。高度聚合部署的方式极大的降低了开发成本、测试成本、维护成本，同时扩展能力、移值能力得到极大的提高。

微前端是借鉴微服务的概念，为了解决前端在大型工程在变更、维护、扩展等方面的困难而提出。通过该架构将应用集成，把多个技术无关的应用集成到一起，实现数据、模块共享，并在运行时动态加载，避免一次过量加载过多内容。

根据本发明的一方面，本发明提供了一种基于微前端架构的多域名项目的管理平台，图1为本发明一实施例中的管理平台的架构框图，如图1示例，所述管理平台包括：基于基座应用的第一主应用、第二主应用。

其中，所述基座应用为所述第一主应用和第二主应用的通用基座（也可称为共享基座），用于给第一主应用和第二主应用提供全局通用功能。例如，全局通用功能可包括全局配置、通用组件等。

所述第一主应用使用代理服务器配置有至少一个子应用，所述第一主应用的所有的子应用注册到所述第一主应用中；所述第二主应用使用代理服务器配置有至少一个子应用，所述第二主应用的所有的子应用注册到所述第二主应用中。在该实施例中，所述第一主应用的二级域名和所述第二主应用的二级域名不同，所述第一主应用的二级域名和所述第二主应用的二级域名被设置成在所述基座应用所在代理服务器上指向同一个存储的目录位置，该目录位置也就是相当于基座应用（所存放资源的位置）。指向设置完成后，所述基座应用可作为所述第一主应用及其子应用、所述第二主应用及其子应用的访问入口。

在该实施例中，此处所述的代理服务器可使用Nginx（engine x），但不限于此，也可使用其他类型的代理服务器。Nginx 是一款轻量级的 Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，其特点是占有内存少，并发能力强。

本发明实施例的管理平台也采用了微前端架构，相对于传统微前端部署的主应用只提供给一个域名应用下使用，本发明中的主应用可集成有多个，且各个主应用的二级域名，即便各主应用的顶级域名不同，也可访问同一个基座应用，这种架构的管理平台可实现高度聚合部署，支持多域名、多项目、跨域环境下使用，极大的降低了开发成本、测试成本、维护成本，同时使得管理的各个应用项目的扩展能力、移值能力得到极大的提高。

在一些实施例中，所述管理平台还包括：第三主应用，其使用代理服务器配置了至少一个子应用，所述第三主应用的所有的子应用注册到所述第三主应用中，所述第三主应用的二级域名与所述第一主应用、第二主应用均不同，所述第三主应用的二级域名的根目录也指向所述基座应用。同理，本发明实施例的管理平台也可集成有第四主应用等，其集成数量可根据实际需求而任意设定。

在一些实施例中，所述第一主应用和所述第二主应用的顶级域名可以相同，也可以不同。可以理解的是，第三主应用与第一主应用、第二主应用的顶级域名可以相同，也可以不同。

在一些实施例中，所述第一主应用可以是面向企业用户的业务系统，包含多个子业务应用。所述第二主应用是面向内部人员的用户中心系统，包含多个子业务应用。在所述管理平台包括第三主应用的情况下，所述第三主应用是账户中心系统，包含多个子业务应用。本发明实施例的基于微前端架构的多域名项目的管理平台不仅可将前台和中后台项目统一管理、统一维护，也可支持多域名、多项目、跨域环境下使用，极大的降低了开发成本、测试成本和维护成本等。

图5为本发明一实施例中的管理平台的多域名高度聚合部署的示意图，图6为本发明一实施例中的用户访问本申请管理平台中的应用项目的示意图。如图5和图6示例，其展示了了三个二级域名（即主应用，分别为www.xxx.com、user.xxx.com、account.xxx.com），以及每个二级域名配置了一个子应用（配置多个子应用同理）。

该部署方案展示了本发明中的管理平台在管理在多域名复杂大型项目中，可通过代理服务器（Nginx）使多个二级域名使用同一个基座应用。即使非同一个顶级域名也可访问同一基座应用。图中展示了将每个二级域名的根目录都统一指向了一个目录位置【root/home/base】，这个位置相当于每个域名的主应用。也就是访问：www.xxx.com、user.xxx.com、account.xxx.com这三个地址时，Nginx会将资源都指向目录【/home/base】，也就是同时读取同一个基座应用，实现所述的高度聚合部署。当用户访问图5中的www.xxx.com/special，user.xxx.com/register，account.xxx.com/personal每个二级域名（主应用）下的子应用时，Nginx就资源分别指向了各自的私有目录【/home/webroot/www】【/home/webroot/user】【/home/webroot/account】。当我们更新主应用时只需要更新基座应用的真实目录【/home/base】即可。当我们更新子应用时，只需要更新各自私有目录下的子应用目录即可，如【/home/webroot/www/specail】【/home/webroot/user/register】【/home/webroot/account/personal】。

图7为本发明一实施例中以一个www主应用为例的部署架构图。代理服务器可以选用但不限于Nginx，例如也可采用iframe、Web Commonents和组合式应用路由等。以采用Nginx路由转发为例，通过Nginx配置反向代理来实现不同路径映射到不同应用，Nginx配置主应用和子应用api代理。例如www.xxx.com/special对应子应用1（例如云信开立应用项目），www.xxx.com/app对应子应用2（例如云信支付应用项目）,其他路径可分别指向了还款清分、ABS、云签和审单中心等子应用。可以理解的是，其他主应用同理，如user主应用、account主应用等。

本发明实施例的基座应用可以是一个前端SPA项目，主要负责应用注册，路由映射，消息下发等，而子应用是独立前端项目，这些应用项目不限于采用React、Vue、Angular或者JQuery开发，如图4所示，第一主应用的子应用和/或第二主应用的子应用所使用的技术栈包括Vue、React、Angular、JQuery、ES5语法中的一种或多种。每个子应用注册到基座应用中，由基座应用进行管理，但是如果脱离基座应用也是可以单独访问。

微前端是借鉴微服务的概念，为了解决前端在大型工程在变更、维护、扩展等方面的困难而提出。通过该架构将应用集成，把多个技术无关的应用集成到一起，实现数据、模块共享，并在运行时动态加载，避免一次过量加载过多内容。

本发明实施例的基座应用作为架构底层支架，主要提供通用组件、应用集成、配置信息，应用授权、路由、框架结构等功能。基座应用提供应用配置，根据对应用的配置通过props向子应用传递主应用内容。同时基座应用默认向子应用提供UI风格、网络请求、工具类、状态管理等内容。

图2为本发明一实施例中的基座应用的功能模块框图。如图2示例中，所述基座应用包括：基本框架模块400，用于给所述管理平台提供基本框架和操作页面；全局配置模块100，用于统一管理所述管理平台的各应用项目的配置信息；应用注册模块200，用于根据预设的注册应用配置信息将子应用注册到对应的主应用中，也用于将主应用注册到所述基座应用中，未注册的子应用、主应用无法通过所述基座应用进行访问；共享axios模块300，用于在所述基座应用中封装网络请求axios并将其下发至主应用和/或子应用中，以全局控制网络请求，对接口请求及相应做出统一控制；工具类模块500，用于将工具类下发至子应用，以避免各子应用各自加载和单独升级；共享组件模块600，用于将多个应用项目常用的组件封装为所述基座应用的通用组件，并能将该所述通用组件向主应用和/或子应用下发；共享Store模块700，用于管理各应用项目的共享状态，若主应用之间、主子应用之间和子应用之间存在共享状态，其中任意一个应用项目的数据状态进行变更，则其余的应用项目的对应数据均同步变更。

图3为本发明一实施例中的基座应用提供的操作页面的示意图。如图2和图3示例，所述基座应用的基本框架模块400提供的操作页面包括有：主应用访问入口单元410、当前展示的主应用框架单元420、组件展示单元430。其中，所述主应用访问入口单元410用于进入不同二级域名的各个主应用，如第一主应用入口、第二主应用入口等，其入口可为并列的标题形式；所述主应用框架单元420用于展示所述基座应用的框架，该框架在展示不同的主应用时，由该主应用与基座应用的通信接口决定。换言之，基座应用的框架是只有一个通用的，其具体显示的菜单可以根据不同的主应用的接口而不同。所述组件展示单元430用于显示当前主应用的组件，主应用的组件能被其子应用作为通用组件调用。例如，图3右侧的查询组件和表格组件可以被作为通用组件，根据实际需求，可以被任意的子应用调用。

在上述实施例中，主应用访问入口单元410也可以被设置为某一个主应用的各个子应用的访问入口，其具体显示内容可根据接口的不同而不同。

本发明实施例的子应用默认继承主应用传递的内容，继承后的子应用即实现了全站风格的统一、组件的统一、请求的统一。当以上内容发生变更时，只需要更新基座应用，子应用将自动继承而发生变更。避免了传统方式中需要更新N个应用的过程，也不用需要多次测试N个项目。

虽然子应用使用的技术栈各不相同，基座应用依然可以通过通用技术或封装向子应用传递，如JSON、Javascript等。

在一些实施例中，如图8所示，图8为本发明一实施例中的管理平台的主应用和子应用的通信示意图。所述基座应用的各主应用通过设置的状态管理模块与其对应的子应用进行通信，所述状态管理模块将主应用的状态管理对象暴露给对应的子应用，则该子应用与主应用能共同操作该状态管理对象来操作数据，实现主应用和子应用的通信。

在本发明实施例中，主子应用间要想通信，首先在主应用中将所有需要通过该框架显示的应用进行注册，只有经过注册的子应用才可以通过该主应用访问到其子应用，该方式可有效避免错误访问及恶意访问。只有注册的子应用才可以和主应用通信，确保访问主应用数据的安全。

主应用与子应用通过主应用中的状态管理进行通信。主应用暴露状态管理对象给子应用，主应用与子应用共同操作该对象来操作数据。由于使主应用与子应用操作同一对象，获取的数据即是最新数据，以此实现主应用与子应用的通信。

子应用与子应用之间的通信与主应用与子应用通信类似，子应用与子应用需要依赖主应用中的状态管理对象。由于子应用同一时刻只会触发一个，所以当前激活的子应用可通过状态管理对象先将数据存入主应用中，另一个子应用加载后，通过主应用状态管理对象获取即可。

本发明实施例的子应用即业务项目，子应用项目主要暴露三个接口bootstrap、mount、unmount，在不同节点触发进行相应处理。同时子应用中会接收主应用传递的Props数据，子应用通过配置及可在项目中进行访问及应用，完成子应用项目的个性化配置、开发。

高度聚合部署方法中，由于主应用对于每个域的子应用注册不同，应用之间的数据通信是在同域之间通信，所以不存在跨域风险，也不允许跨域通信，进而避免数据上的相互干扰及泄露。

本发明实施例的管理平台的微前端架构，主应用及子应用与服务间通信开发环境与生产环境有所不同。

在开发环境下，原先各应用需要在各自应用中配置不同的proxy代理。在微前端架构下所有子应用将不需要单独做proxy代理。由主应用配置好proxy代理后，子应用发送请求时，请求将由主应用的代理完成跨域请求的调用。

在生产环境下，生产环境与开发环境略有不同，生产环境下proxy代理由代理服务器完成（如Nginx）。

在高度聚合部署方法中，如果多个二级域名使用同一个nginx配置文件，则代理配置至同一个nginx文件中即可。如果二级域名配置了多个不同nginx文件，则在每个nginx配置文件中单独配置的需代理即可，因此服务间通信所需的代理设置十分灵活。

根据本发明的另一方面，本发明也提供了一种基于前述管理平台的多域名项目的高度聚合部署方法，图9为本发明一实施例中的多域名项目的高度聚合部署方法的步骤示意图。如图9所示，包括如下步骤：

S10：将多个不同二级域名的主应用指向到同一代理服务器，代理服务器对多个二级域名做好绑定；

S20：将各个不同二级域名的主应用的根目录指向该代理服务器的同一个根目录，以实现基座应用的共享；其中，该根目录为基座应用所有资源在代理服务器上的存储目录；

S30：将基座应用的源代码部署到各主应用在代理服务器所指向的根目录下，以实现不同域名的主应用的高度聚合部署；

在完成不同域名的主应用的高度聚合部署后，用户访问任一指定的主应用的二级域名时，代理服务器都会将资源指向基座应用所存储的目录位置。

可以理解的是，此处所述的S20和S30的先后次序可以前后置换，即先进行基座应用的源代码部署，后进行主应用的根目录指向，也可实现同样的技术效果。

根据本发明的又一方面，本发明也提供了一种基于多域名项目的高度聚合部署装置，包括处理器和存储器，所述存储器中存储有计算机指令，所述处理器用于执行所述存储器中存储的计算机指令，当所述计算机指令被处理器执行时，该装置实现如前述高度聚合部署方法的步骤。

根据本发明的再一方面，本发明也提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如前述高度聚合部署方法的步骤。

根据本发明实施例的基于微前端架构的多域名项目的管理平台及高度聚合部署方法，可获得的有益效果至少包括：

（1）该管理平台可将多种技术栈应用项目（如JSP项目与SPA项目）集成到一个平台中统一管理，解决了公共文件分散、各自维护、未统一管理读取的乱象。

（2）该管理平台和部署方法可将高内聚的基座应用作为公有资源，使得不同域名的多个主应用和同框架的子应用共享基座应用所提供的所有资源，支持多域名、多项目、跨域环境下使用，高度聚合部署的方式极大的降低了开发成本、测试成本和维护成本，同时使得管理平台管理的各个应用项目的扩展能力、移值能力得到极大的提高。

（3）该管理平台可实现组件共享，所有应用项目的组件均可共享，可对共享组件进行集中管理，降低维护成本。

（4）该管理平台可实现所有应用项目统一风格，提升用户体验。

本领域普通技术人员应该可以明白，结合本文中所公开的实施方式描述的各示例性的组成部分、系统和方法，能够以硬件、软件或者二者的结合来实现。具体究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。当以硬件方式实现时，其可以例如是电子电路、专用集成电路（ASIC）、适当的固件、插件、功能卡等等。当以软件方式实现时，本发明的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM（EROM）、软盘、CD-ROM、光盘、硬盘、光纤介质、射频（RF）链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本发明中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本发明不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

软件可以置于随机存储器（RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

本发明中，针对一个实施方式描述和/或例示的特征，可以在一个或更多个其它实施方式中以相同方式或以类似方式使用，和/或与其他实施方式的特征相结合或代替其他实施方式的特征。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明实施例可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种基于微前端架构的多域名项目的管理平台，其特征在于，所述管理平台包括：基于基座应用的第一主应用、第二主应用；

其中，所述基座应用为所述第一主应用和第二主应用的通用基座，用于给所述第一主应用和第二主应用提供全局通用功能；

所述第一主应用使用代理服务器配置有至少一个子应用，所述第一主应用的所有的子应用注册到所述第一主应用中；

所述第二主应用使用代理服务器配置有至少一个子应用，所述第二主应用的所有的子应用注册到所述第二主应用中；

所述第一主应用的二级域名和所述第二主应用的二级域名不同，所述第一主应用的二级域名和所述第二主应用的二级域名被设置成在所述基座应用所在代理服务器上指向同一个存储的目录位置，所述基座应用作为所述第一主应用及其子应用、所述第二主应用及其子应用的访问入口；

所述基座应用包括：

基本框架模块，用于给所述管理平台提供基本框架和操作页面；

全局配置模块，用于统一管理所述管理平台的各应用项目的配置信息；

应用注册模块，用于根据预设的注册应用配置信息将子应用注册到对应的主应用中，也用于将主应用注册到所述基座应用中，未注册的子应用、主应用无法通过所述基座应用进行访问；

共享axios模块，用于在所述基座应用中封装网络请求axios并将其下发至主应用和/或子应用中，以全局控制网络请求，对接口请求及相应做出统一控制；

工具类模块，用于将工具类下发至子应用，以避免各子应用各自加载和单独升级；

共享组件模块，用于将多个应用项目常用的组件封装为所述基座应用的通用组件，并能将该所述通用组件向主应用和/或子应用下发；

共享Store模块，用于管理各应用项目的共享状态，若主应用之间、主子应用之间和子应用之间存在共享状态，其中任意一个应用项目的数据状态进行变更，则其余的应用项目的对应数据均同步变更。

2.根据权利要求1所述的基于微前端架构的多域名项目的管理平台，其特征在于，所述管理平台还包括：

第三主应用，其使用代理服务器配置了至少一个子应用，所述第三主应用的所有的子应用注册到所述第三主应用中，所述第三主应用的二级域名与所述第一主应用、第二主应用均不同，所述第三主应用的二级域名的根目录也指向所述基座应用。

3.根据权利要求1所述的基于微前端架构的多域名项目的管理平台，其特征在于，所述第一主应用和所述第二主应用的顶级域名相同或不同。

4.根据权利要求1所述的基于微前端架构的多域名项目的管理平台，其特征在于，

所述第一主应用是面向企业用户的业务系统，包含多个子业务应用；

所述第二主应用是面向内部人员的用户中心系统，包含多个子业务应用；

在所述管理平台包括第三主应用的情况下，所述第三主应用是账户中心系统，包含多个子业务应用。

5.根据权利要求1所述的基于微前端架构的多域名项目的管理平台，其特征在于，所述基座应用的基本框架模块提供的操作页面包括有：主应用访问入口单元、当前展示的主应用框架单元、组件展示单元；

其中，所述主应用访问入口单元用于进入不同二级域名的各个主应用；

所述主应用框架单元用于展示所述基座应用的框架，该框架在展示不同的主应用时，由该主应用与基座应用的通信接口决定；

所述组件展示单元用于显示当前主应用的组件，主应用的组件能被其子应用作为通用组件调用。

6.根据权利要求1所述的基于微前端架构的多域名项目的管理平台，其特征在于，所述基座应用的各主应用通过设置的状态管理模块与其对应的子应用进行通信，所述状态管理模块将主应用的状态管理对象暴露给对应的子应用，则该子应用与主应用能共同操作该状态管理对象来操作数据，实现主应用和子应用的通信。

7.一种多域名项目的高度聚合部署方法，其特征在于，该方法基于如权利要求1至6中任一项所述的管理平台，包括如下步骤：

S10：将多个不同二级域名的主应用指向到同一代理服务器，代理服务器对多个二级域名做好绑定；

S20：将各个不同二级域名的主应用的根目录指向该代理服务器的同一个根目录，以实现基座应用的共享；

S30：将基座应用的源代码部署到各主应用在代理服务器所指向的根目录下，以实现不同域名的主应用的高度聚合部署；

在完成不同域名的主应用的高度聚合部署后，用户访问任一指定的主应用的二级域名时，代理服务器都会将资源指向基座应用所存储的目录位置。

8.一种基于多域名项目的高度聚合部署装置，包括处理器和存储器，其特征在于，所述存储器中存储有计算机指令，所述处理器用于执行所述存储器中存储的计算机指令，当所述计算机指令被处理器执行时，该装置实现如权利要求7所述方法的步骤。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求7所述方法的步骤。

Images