CN112306755A - 一种基于微前端架构的高可用性实现方法和系统 - Google Patents

Abstract

本发明提供一种基于微前端架构的高可用性的实现方法和系统，其中，高可用性实现方法用于包括主体容器和子服务的微前端项目；该方法包括：建立对应于主体容器及子服务的主体备份和子服务备份；根据主体备份的地址信息监控主体备份的运行状态并更新其内部数据，根据子服务的地址信息监控子服务备份的运行状态并更新其内部数据；判断主体容器是否发生系统灾难；若是，则将主体容器切换为运行状态正常且内部数据已更新的主体备份；判断子服务是否发生系统灾难；若是，则将子服务切换至运行状态正常且内部数据已更新的子服务备份。本发明的技术方案能解决现有技术中微前端架构整合的系统也是单点系统，无法通过统一入口访问不同子系统的问题。

Description

一种基于微前端架构的高可用性实现方法和系统

技术领域

本发明涉及网络技术领域，尤其涉及一种基于微前端架构的高可用性实现方法和系统。

背景技术

当今市场，前端架构层出不穷，但以Angular、React和Vue为首的三大JavaScript框架已经成为了绝大多数企业进行前端架构的首选方案。很多企业伴随着自身的发展和壮大，业务的覆盖面和复杂程度也越来越高，然而，各个部门之间因业务情况的不一致，可能会选取不同的框架进行架构。而Angular、React和Vue框架却并不是相同的设计理念，不同框架之间的技术栈和封装模式相互之间是完全独立的，且每个框架都具有只属于自己的唯一生态。用户经常会出现对不同部门之间业务进行查看和跟踪的需要，然而因为各个部门之间架构的独立性，这就需要在多个技术栈系统(即通过框架搭建的系统)之间来回切换。另外，两个或者更多技术栈系统需要进行业务交互时，因为架构之间相互独立，导致技术栈系统之间的连接也成为了麻烦的问题。

目前针对架构相互独立的问题，有一种流行的解决方案是使用微前端架构将不同的技术栈系统整合在一起。但是，这么做却存在着巨大的问题：我们虽然将不同的技术栈系统整合到了一起，形成新的系统，但是整合起来的系统自身却也变成了一个新的单点系统；而当这个单点系统出现系统灾难等现象时，我们同样无法通过统一的入口访问不同的技术栈系统，这就导致系统整体与各个子服务遇到灾难容易崩溃。

发明内容

本发明提供了一种基于微前端架构的高可用性实现方法和系统，旨在解决现有技术中，通过微前端架构将不同技术栈系统整合形成的系统自身也是单点系统，导致系统出现故障容易崩溃的问题。

为解决上述问题，根据本发明的第一方面，本发明提供了一种基于微前端架构的高可用性实现方法，该方法用于微前端项目，微前端项目包括主体容器和子服务；高可用性实现方法包括：

分别建立对应于主体容器的主体备份，以及对应于子服务的子服务备份；

根据主体备份的地址信息实时监控主体备份的运行状态并更新主体备份的内部数据，以及，根据子服务的地址信息实时监控子服务备份的运行状态并更新子服务的内部数据；

判断主体容器是否发生系统灾难；

若判定主体容器发生系统灾难，则将主体容器切换为运行状态正常且内部数据已更新的主体备份，以提供主体服务功能；

判断子服务是否发生系统灾难；

若判定子服务发生系统灾难，则将子服务切换至运行状态正常且内部数据已更新的子服务备份，以提供子服务功能。

优选地，上述根据主体备份的地址信息实时监控主体备份的运行状态并更新主体备份的内部数据的步骤，包括：

通过主体备份的地址信息，按预定时间间隔依次向主体备份发送信息请求；

判断第一预定时间内是否接收到主体备份对信息请求的响应信息；

若判定第一预定时间内接收到响应信息，则确定主体备份的运行状态正常；

以及，

实时监听主体容器生成的系统数据；

通过主体备份的地址信息，将系统数据同步至主体备份。

优选地，上述判断主体容器是否发生系统灾难的步骤，包括：

使用拦截器拦截主体容器的外部操作指令；

当拦截器拦截到外部操作指令时，向主体容器发送预请求；

判断第二预定时间内是否接收到主体容器对预请求的响应信息；

若判定第二预定时间内未接收到响应信息，则确定主体容器发生系统灾难。

优选地，上述将主体容器切换为运行状态正常且内部数据已更新的主体备份的步骤，包括：

记录系统灾难发生时，微前端项目对主体容器的必要配置信息；

通过主体备份的地址信息，将主体容器切换为主体备份；

使用必要配置信息配置主体备份，以使微前端项目恢复至系统灾难发生前的状态。

优选地，上述将子服务切换至运行状态正常且内部数据已更新的子服务备份的步骤，包括：

记录系统灾难发生时，微前端项目对子服务的必要配置信息；

通过子服务备份的地址信息，将子服务切换为子服务备份；

使用必要配置信息配置子服务备份；

将配置后的子服务备份输出至主体容器或主体备份中进行展示。

优选地，上述高可用性实现方法，在分别建立对应于主体容器的主体备份，以及对应于子服务的子服务备份的步骤之后还包括：

分别设置用于部署主体容器、主体备份、子服务和子服务备份的多台代理服务器；

启动多台代理服务器，并建立每台代理服务器之间的通信连接。

根据本发明的第二方面，本发明还提供了一种基于微前端架构的高可用性实现系统，该系统用于微前端项目，微前端项目包括主体容器和子服务；该高可用性实现系统包括：

备份建立模块，用于分别建立对应于主体容器的主体备份，以及对应于子服务的子服务备份；

监控更新模块，用于根据主体备份的地址信息实时监控主体备份的运行状态并更新主体备份的内部数据，以及，根据子服务的地址信息实时监控子服务备份的运行状态并更新子服务的内部数据；

第一灾难判断模块，用于判断主体容器是否发生系统灾难；

第一备份切换模块，用于当第一灾难判断模块判定主体容器发生系统灾难时，将主体容器切换为运行状态正常且内部数据已更新的主体备份，以提供主体服务功能；

第二灾难判断模块，用于判断子服务是否发生系统灾难；

第二备份切换模块，用于当判定子服务发生系统灾难时，将子服务切换至运行状态正常且内部数据已更新的子服务备份，以提供子服务功能。

优选地，上述监控更新模块包括：

第一请求发送子模块，用于通过主体备份的地址信息，按预定时间间隔依次向主体备份发送信息请求；

第一接收判断子模块，用于判断第一预定时间内是否接收到主体备份对信息请求的响应信息；

状态确定子模块，用于当接收判断子模块判定第一预定时间内接收到响应信息时，确定主体备份的运行状态正常；

以及，

数据监听子模块，用于实时监听主体容器生成的系统数据；

数据同步子模块，用于通过主体备份的地址信息，将系统数据同步至主体备份。

优选地，上述第一灾难判断模块包括：

指令拦截子模块，用于使用拦截器拦截主体容器的外部操作指令；

第二请求发送子模块，用于当拦截器拦截到外部操作指令时，向主体容器发送预请求；

第二接收判断子模块，用于判断第二预定时间内是否接收到主体容器对预请求的响应信息；

灾难确定子模块，用于当第二接收判断子模块判定第二预定时间内未接收到响应信息时，确定主体容器发生系统灾难。

优选地，上述第一备份切换模块包括：

第一配置记录子模块，用于记录系统灾难发生时，微前端项目对主体容器的必要配置信息；

主体切换子模块，用于通过主体备份的地址信息，将主体容器切换为主体备份；

第一备份配置子模块，用于使用必要配置信息配置主体备份，以使微前端项目恢复至系统灾难发生前的状态。

优选地，上述第二备份切换模块包括：

第二配置记录子模块，用于记录系统灾难发生时，微前端项目对子服务的必要配置信息；

子服务切换子模块，用于通过子服务备份的地址信息，将子服务切换为子服务备份；

第二备份配置子模块，用于使用必要配置信息配置子服务备份；

展示输出子模块，用于将配置后的子服务备份输出至主体容器或主体备份中进行展示。

优选地，本申请提供的高可用性实现系统，除了上述模块外还包括：

服务器设置模块，用于分别设置用于部署主体容器、主体备份、子服务和子服务备份的多台代理服务器；

服务器启动模块，用于启动多台代理服务器，并建立每台代理服务器之间的通信连接。

本申请技术方案提供的基于微前端架构的高可用性实现方案，首先，建立对应于主体容器及子服务器的主体备份和子服务备份，从而在主体容器或子服务发生系统灾难时迅速切换到相关备份；然后根据主体备份的地址信息监控主体备份的运行状态并更新其内部数据，这样就能够确定主体备份是否可用并使得主体备份与主体容器的内部数据相同，同理，也需要根据子服务器的地址信息监控子服务备份的运行状态并更新子服务器备份的内部数据。当主体容器发生系统灾难时，就可以将主体容器切换到运行状态正常且内部数据已更新的主体备份，使用该主体备份为微前端架构提供主体服务，另外子服务是通过主体容器或主体备份进行展示的，这样通过主体容器或主体备份也能够访问不同的子服务；另外当子服务发生系统灾难时，可以将子服务切换到运行状态正常且内部数据已更新的子服务备份，从而使用该子服务备份提供原子服务的功能。通过上述过程本申请技术方案能够实现微前端架构的高可用性，通过采用高可用的处理方式，将不同服务分开部署并提供容灾处理方案，从而能够解决现有技术中微前端架构将多个子服务集合起来形成的新的单点系统以及各子服务同样为单点系统而造成的遇到灾难系统容易崩溃的问题，最终确保系统在碰到灾难时仍能够稳定运行。

附图说明

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

图1是本发明实施例提供的一种应用环境示意图；

图2是本发明实施例提供的第一种基于微前端架构的高可用性实现方法的流程示意图；

图3是图2所示实施例提供的一种状态监控和数据更新方法的流程示意图；

图4是图2所示实施例提供的一种系统灾难发生判断方法的流程示意图；

图5是图2所示实施例提供的一种主体备份切换方法的流程示意图；

图6是图2所示实施例提供的一种子服务备份切换方法的流程示意图；

图7是本发明实施例提供的第二种基于微前端架构的高可用性实现方法的流程示意图；

图8是本发明实施例提供的第三种基于微前端架构的高可用性实现方法的流程示意图；

图9是本发明实施例提供的第一种基于微前端架构的高可用性实现系统的结构示意图；

图10是本发明实施例提供的一种监控更新模块的结构示意图；

图11是图9所示实施例提供的一种第一灾难判断模块的结构示意图；

图12是图9所示实施例提供的一种第一备份切换模块的结构示意图；

图13是图9所示实施例提供的一种第二备份切换模块的结构示意图；

图14是本发明实施例提供的一种高可用性实现系统的结构示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例的主要技术问题如下：

现有的微前端架构生成的微前端项目中，是通过微前端架构件不同的技术栈系统整合在一起的，这样原有的技术栈系统就成为了整合后系统的子服务，但是这样做存在具体的问题，虽然将不同的技术栈系统整合在一起形成了新的系统，但是整合起来的系统自身也变成了一个新的单点系统，而这个单点系统出现系统灾难等问题时，同样无法通过统一的入口访问不同的技术栈系统，这样就导致系统整体与各个子服务任一项遇到灾难就容易崩溃的问题。

为解决上述问题，参见图1，图1是本发明实施例提供的一种应用环境示意图。该应用环境包括用于展示和协调各个子服务的主体容器1，以及提供具体服务的子服务2。在这个系统中，再建立与主体容器1对应的主体备份3，以及与子服务2对应的子服务备份4，这样就能够通过主体备份3和子服务备份4的地址信息，对主体备份3和子服务备份4进行运行状态的监控以及内部数据的更新。其中，主体备份3即图1中的主体容器(备份)1和主体容器(备份)2，子服务备份4即图1中的子服务(备份)1和子服务(备份)2。当主体容器1或子服务2出现系统灾难时，就可以使用主体备份3或子服务备份4对主体容器1或子服务2进行进行切换替代，以替代其功能。通过该方式能够提高整个系统的高可用性，将不同服务分开部署并提供容灾处理方案，从而解决现有技术中微前端架构将多个子服务集合在一起形成的单点系统以及各子服务同样为单点系统而造成的遇到系统灾难容易崩溃的问题。

为实现上述目的，参见图2，图2为发明实施例提供的第一种基于微前端架构的高可用性实现方法的流程示意图。该方法用于微前端项目，微前端项目包括主体容器和子服务；其中高可用性是指通过设计减少系统不能提供服务的时间。架设系统一直能够提供服务，则系统的可用性为100％。

具体如图2所示，该基于微前端架构的高可用性实现方法包括以下步骤：

S110：分别建立对应于主体容器的主体备份，以及对应于子服务的子服务备份。主体备份与主体容器相对应，两者内部数据一致；对应的，子服务器备份与子服务相对应，两者内部数据一致。构建高可用微前端的过程中，为了避免单点系统遇到灾难崩溃的问题，最好的办法是一个系统内设置多个备份。同时，这多个备份为该系统服务。

S120：根据主体备份的地址信息实时监控主体备份的运行状态并更新主体备份的内部数据。

具体地，可以在微前端项目的静态资源文件夹中创建存储有主体备份的地址信息的信息配置文件，该信息配置文件为避免单点系统问题提供了依据。并且，该信息配置文件中保存有键值对数组类型的名称和URL地址，用于标明每个备份的相关资源信息。另外，为了能够满足系统的高可用性要求，必须考虑如何能够掌握每个备份当前的运行状态并确保每个备份中数据的一致性，避免系统崩溃后不知道是否有备份可用以及数据错乱的问题。

其中，如图3所示，该根据主体备份的地址信息实时监控主体备份的运行状态并更新主体备份的内部数据的步骤，包括：

S121：通过主体备份的地址信息，按预定时间间隔依次向主体备份发送信息请求。主体备份的地址信息标明了主体备份的存储位置，此时向主体备份发送信息请求能够返回得到响应信息。

S122：判断第一预定时间内是否接收到主体备份对信息请求的响应信息。该第一预定时间是从上述发送信息请求开始计算。

S123：若判定第一预定时间内接收到响应信息，则确定主体备份的运行状态正常。若第一预定时间内接收到该响应信息，说明主体备份能够对信息请求做出反应，进而能够确定该主体备份的运行状态正常。

具体地，需要在微架构项目创建文件夹A，在该文件夹A内创建用于存放心跳发送相关的JavaScript逻辑文件。该JavaScript逻辑文件实现的功能包括：根据上述静态资源文件夹内的备份的地址信息，例如主体备份的地址信息，在每隔预定时间间隔通过每一个备份的地址信息向备份发送信息请求。若请求成功，则说明通信的该备份运行状态健康，然后对对该备份进行健康状态标注，以备发生问题时进行灾难处理提供依据。

另外，本申请还需要的主体容器和主体备份进行数据同步，从而保证两者数据的一致性，以便在发生系统灾难时能够使用主体备份进行准确地处理，实现主体的无缝切换。

S124：实时监听主体容器生成的系统数据。

S125：通过主体备份的地址信息，将系统数据同步至主体备份。

具体地，在微前端项目下创建文件夹B，在该文件夹B中创建用于进行数据一致性的相关JavaScript逻辑文件。该逻辑文件的主要作用是存储系统数据，该系统数据通常为系统，例如主体容器为响应客户操作或外部系统产生的数据，另外该逻辑文件还需要监听该系统数据。当每次发生数据处理时启用监听。在监听过程中，需要根据配置文件中的备份地址将当前变更的数据发往各个备份。各个备份在接收到变更的数据后需要将这些数据存储到自身文件中，为后续发生系统灾难时切换备份提供依据。

本申请实施例，在项目初始化阶段，启用心跳发送和数据一致性监听，从而监控主体备份的运行状态并更新主体服务的内部数据，使得各备份的运行状态并确保每个备份的数据一致性，为后续灾难处理打下基础。

另外，在构建高可用的主体备份后，还需要对微前端架构的子服务进行备份，从而构建高可用子服务。因为微前端项目本身是将多个子服务汇集到一起而产生的。而每一个子服务本身都属于一个单点系统，那么子服务也同样会面临着灾难问题。此时，我们需要像微前端项目的主体容器一样，将各个子服务进行高可用，(即使用多个子服务备份共同维护一个子服务的正常运行)。当发生灾难时也进行相同的容灾处理。以此来避免灾难而造成的崩溃问题。具体如下：

S130：根据子服务的地址信息实时监控子服务备份的运行状态并更新子服务的内部数据。

根据子服务的地址信息监控子服务备份的运行状态以及更新子服务的内部数据的方法与监控和更新主体容器的方法一致。两者都需要在微前端项目下创建相关文件夹，以在创建的文件夹下创建用于进行心跳发送和数据一致性的相关JavaScript文件。具体地，在子服务的项目静态资源目录下创建一个文件。该文件用于存储子服务备份的地址信息，该地址信息采用键值对标明每个备份相关资源信息，在子服务的项目目录下创建一个文件夹，用于存放心跳发送、数据一致性通信和容灾处理的JavaScript逻辑文件。这些文件的内容与主体容器本身对心跳发送、数据一致性通信和容灾处理内容的逻辑思路一致，主要都是负责监控各个备份的状态、保证数据一致性和应对灾难处理等操作。

在创建和更新主体容器和子服务的备份后，就需要构建容灾处理逻辑。因为微前端项目作为单点系统，其最致命的问题是当灾难发生时只能重启服务才能够解决问题，这就给用户使用造成了巨大不便。而本申请技术方案提供的高可用性实现方法能够在系统灾难发生时自动启动容灾处理逻辑，保证系统的正常运行。这是因为本申请实施例提供的高可用性实现方案是多个备份同时维护一个服务；当系统发生灾难时，通过容灾处理可以切换到运行良好的备份下继续服务，这样就成功避免了灾难。具体地：

S140：判断主体容器是否发生系统灾难。

具体地，如图4所示，该判断主体容器是否发生系统灾难的步骤具体包括：

S141：使用拦截器拦截主体容器的外部操作指令。

S142：当拦截器拦截到外部操作指令时，向主体容器发送预请求。

S143：判断第二预定时间内是否接收到主体容器对预请求的响应信息。

S144：若判定第二预定时间内未接收到响应信息，则确定主体容器发生系统灾难。

本申请实施例提供的技术方案，需要在微前端项目下创建一个文件夹，再在这个文件夹下创建容灾处理的JavaScript逻辑文件。该JavaScript逻辑文件的作用如下：创建一个拦截器，通过该拦截器拦截用户的每次操作。因为前端文件属于静态文件。因此在浏览器访问过后，所有静态文件均已缓存下来，而系统灾难造成的问题主要发生在发送数据请求时，因此每次拦截用户请求后先发送预请求。如果预请求成功，则允许正常操作。如果预请求失败，则说明此时已经发生系统灾难。

当发生系统灾难时，使用之前存储的高可用性信息进行备份的切换，例如备份地址信息、创建的用于监听运行状态以及数据备份的逻辑文件等。具体可通过存储的各备份的地址信息查询状态良好的备份的地址，并将微前端项目的配置文件中提供服务功能的主体容器地址切换到对应备份的地址下。具体方法如下：

S150：若判定主体容器发生系统灾难，则将主体容器切换为运行状态正常且内部数据已更新的主体备份，以提供主体服务功能。

具体如图5所示，该将主体容器切换为运行状态正常且内部数据已更新的主体备份的步骤具体包括：

S151：记录系统灾难发生时，微前端项目对主体容器的必要配置信息；

S152：通过主体备份的地址信息，将主体容器切换为主体备份；因为主体备份可能存在多个，因此可设计专门的选举机制以将主体容器切换到对应的主体备份。

S153：使用必要配置信息配置主体备份，以使微前端项目恢复至系统灾难发生前的状态。

本申请实施例提供的技术方案中，在切换备份的过程中，需要将灾难的必要配置信息(例如系统IP、配置文件信息和缓存数据等)存储到本地或浏览器的全局对象中。在通过主体备份的地址信息，将主体容器切换为上述运行状态正常且内部数据已更新的主体备份中，使用上述必要配置信息来配置主体备份以进行相关操作，以将当前使用主体备份的微前端项目恢复到灾难发生前的状态，从而保证切换的无缝连接。

S160：判断子服务是否发生系统灾难。判断子服务是否发生系统灾难的方法与上述判断主体容器发生系统灾难的方法大体一致，在此不再赘述。

S170：若判定子服务发生系统灾难，则将子服务切换至运行状态正常且内部数据已更新的子服务备份，以提供子服务功能。

具体如图6所示，该将子服务切换至运行状态正常且内部数据已更新的子服务备份的步骤，包括：

S171：记录系统灾难发生时，微前端项目对子服务的必要配置信息；

S172：通过子服务备份的地址信息，将子服务切换为子服务备份；因为子备份可能存在多个，因此可设计专门的选举机制以将子服务切换到对应的子服务备份。

S173：使用必要配置信息配置子服务备份；

S174：将配置后的子服务备份输出至主体容器或主体备份中进行展示。

在记录系统灾难发生时微前端项目对子服务的必要配置信息后，可以通过该必要配置信息配置子服务备份，从而还原系统灾难发生前一刻子服务的对外状态，保证子服务备份切换的无缝连接。另外因为子服务和子服务备份需要在主体容器中进行展示，因此需要将配置后的子服务备份输出值主体容器或切换后的主体备份进行展示。

综上，本申请技术方案提供的基于微前端架构的高可用性实现方法，首先，建立对应于主体容器及子服务器的主体备份和子服务备份，从而在主体容器或子服务发生系统灾难时迅速切换到相关备份；然后根据主体备份的地址信息监控主体备份的运行状态并更新其内部数据，这样就能够确定主体备份是否可用并使得主体备份与主体容器的内部数据相同，同理，也需要根据子服务器的地址信息监控子服务备份的运行状态并更新子服务器备份的内部数据。当主体容器发生系统灾难时，就可以将主体容器切换到运行状态正常且内部数据已更新的主体备份，使用该主体备份为微前端架构提供主体服务，另外子服务是通过主体容器或主体备份进行展示的，这样通过主体容器或主体备份也能够访问不同的子服务；另外当子服务发生系统灾难时，可以将子服务切换到运行状态正常且内部数据已更新的子服务备份，从而使用该子服务备份提供原子服务的功能。通过上述过程本申请技术方案能够实现微前端架构的高可用性，通过采用高可用的处理方式，将不同服务分开部署并提供容灾处理方案，从而能够解决现有技术中微前端架构将多个子服务集合起来形成的新的单点系统以及各子服务同样为单点系统而造成的遇到灾难系统容易崩溃的问题，最终确保系统在碰到灾难时仍能够稳定运行。

在微前端项目中构建系统发生故障是进行灾难处理的逻辑文件后，还需要对微前端项目的主体容器以及子服务进行高可用性的部署实现物理层的容灾处理，具体如图7所示，作为一种优选的实施例，该高可用性实现方法，在分别建立对应于主体容器的主体备份，以及对应于子服务的子服务备份的步骤之后还包括：

S210：分别设置用于部署主体容器、主体备份、子服务和子服务备份的多台代理服务器；

S220：启动多台代理服务器，并建立每台代理服务器之间的通信连接。

具体地，在多台服务器下分别搭建代理服务器，并部署主体容器、多个主体备份、子服务以及多个子服务备份。然后代理服务器配置的配置请求超时时，切换到其他对应的服务器，例如当部署有主体容器的代理服务器请求超时时，切换到主体备份所在的代理服务器。当代理服务器存在灾难时，无需启用微前端项目的整体容灾处理机制，代理服务器即可通过上述图2所示实施例提供的容灾处理方法进行灾难处理。在设置多台代理服务器后，还需要启动上述代理服务器，建立每台代理服务器之间的通信连接，以保证服务器之间的网络通畅。

另外，作为一种优选的实施例，如图8所示，本发明还提供了一种基于微前端架构的高可用性实现方法，该方法包括：

S301：主体容器初始化，进行心跳、数据通信及容灾处理等方法。

S302：每个主体备份初始化。

S303：子服务初始化，进行心跳检测、数据通信及容灾处理等方法。

S304：子服务备份初始化。

S305：判断主体容器预请求是否成功；若失败，则执行步骤S306；若成功，则执行步骤S307。

S306：调用容灾处理的程序。

S307：判断子服务预请求是否成功；若成功，则执行步骤S308；若失败，则执行步骤S311。

S308：使用子服务，继续执行操作。

S309：切换到主体备份。

S310：使用主体备份，继续执行操作。

S311：调用容灾处理的程序。

S312：切换到子服务备份。

S313：使用子服务备份，继续执行操作。

另外，基于上述方法实施例的同一构思，本发明实施例还提供了基于微前端架构的高可用性实现系统，用于实现本发明的上述方法，由于该系统实施例解决问题的原理与上述方法相似，因此至少具有上述实施例的技术方案所带来的所有有益效果，在此不再一一赘述。

参见图9，图9为本发明实施例提供的第一种基于微前端架构的高可用性实现系统的结构示意图。如图9所示，该高可用性实现系统用于微前端项目，微前端项目包括主体容器和子服务；该高可用性实现系统包括：

备份建立模块110，用于分别建立对应于主体容器的主体备份，以及对应于子服务的子服务备份；

监控更新模块120，用于根据主体备份的地址信息实时监控主体备份的运行状态并更新主体备份的内部数据，以及，根据子服务的地址信息实时监控子服务备份的运行状态并更新子服务的内部数据；

第一灾难判断模块130，用于判断主体容器是否发生系统灾难；

第一备份切换模块140，用于当第一灾难判断模块判定主体容器发生系统灾难时，将主体容器切换为运行状态正常且内部数据已更新的主体备份，以提供主体服务功能；

第二灾难判断模块150，用于判断子服务是否发生系统灾难；

第二备份切换模块160，用于当判定子服务发生系统灾难时，将子服务切换至运行状态正常且内部数据已更新的子服务备份，以提供子服务功能。

综上，本申请实施例提供的基于微前端架构的高可用性实现系统，首先，备份建立模块110建立对应于主体容器及子服务器的主体备份和子服务备份，从而在主体容器或子服务发生系统灾难时迅速切换到相关备份；然后监控更新模块120根据主体备份的地址信息监控主体备份的运行状态并更新其内部数据，这样就能够确定主体备份是否可用并使得主体备份与主体容器的内部数据相同，同理，也需要根据子服务器的地址信息监控子服务备份的运行状态并更新子服务器备份的内部数据。当第一灾难判断模块130判定主体容器发生系统灾难时，第一备份切换模块140就可以将主体容器切换到运行状态正常且内部数据已更新的主体备份，使用该主体备份为微前端架构提供主体服务，另外子服务是通过主体容器或主体备份进行展示的，这样通过主体容器或主体备份也能够访问不同的子服务；另外当第二灾难判断模块150判定子服务发生系统灾难时，第二备份切换模块160可以将子服务切换到运行状态正常且内部数据已更新的子服务备份，从而使用该子服务备份提供原子服务的功能。通过上述过程本申请技术方案能够实现微前端架构的高可用性，通过采用高可用的处理方式，将不同服务分开部署并提供容灾处理方案，从而能够解决现有技术中微前端架构将多个子服务集合起来形成的新的单点系统以及各子服务同样为单点系统而造成的遇到灾难系统容易崩溃的问题，最终确保系统在碰到灾难时仍能够稳定运行。

其中，如图10所示，上述监控更新模块120包括：

第一请求发送子模块121，用于通过主体备份的地址信息，按预定时间间隔依次向主体备份发送信息请求；

第一接收判断子模块122，用于判断第一预定时间内是否接收到主体备份对信息请求的响应信息；

状态确定子模块123，用于当接收判断子模块判定第一预定时间内接收到响应信息时，确定主体备份的运行状态正常；

以及，

数据监听子模块124，用于实时监听主体容器生成的系统数据；

数据同步子模块125，用于通过主体备份的地址信息，将系统数据同步至主体备份。

其中，作为一种优选的实施例，如图11所示，上述第一灾难判断模块130包括：

指令拦截子模块131，用于使用拦截器拦截主体容器的外部操作指令；

第二请求发送子模块132，用于当拦截器拦截到外部操作指令时，向主体容器发送预请求；

第二接收判断子模块133，用于判断第二预定时间内是否接收到主体容器对预请求的响应信息；

灾难确定子模块134，用于当第二接收判断子模块判定第二预定时间内未接收到响应信息时，确定主体容器发生系统灾难。

其中，作为一种优选的实施例，如图12所示，上述第一备份切换模块140包括：

第一配置记录子模块141，用于记录系统灾难发生时，微前端项目对主体容器的必要配置信息；

主体切换子模块142，用于通过主体备份的地址信息，将主体容器切换为主体备份；

第一备份配置子模块143，用于使用必要配置信息配置主体备份，以使微前端项目恢复至系统灾难发生前的状态。

其中，作为一种优选的实施例，如图13所示，上述第二备份切换模块160包括：

第二配置记录子模块161，用于记录系统灾难发生时，微前端项目对子服务的必要配置信息；

子服务切换子模块162，用于通过子服务备份的地址信息，将子服务切换为子服务备份；

第二备份配置子模块163，用于使用必要配置信息配置子服务备份；

展示输出子模块164，用于将配置后的子服务备份输出至主体容器或主体备份中进行展示。

另外，作为一种优选的实施例，如图14所示，本申请实施例还提供了一种高可用性实现系统，该高可用性实现系统除了上述模块外还包括：

服务器设置模块170，用于分别设置用于部署主体容器、主体备份、子服务和子服务备份的多台代理服务器；

服务器启动模块180，用于启动多台代理服务器，并建立每台代理服务器之间的通信连接。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

应当注意的是，在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的部件或步骤。位于部件之前的单词“一”或“一个”不排除存在多个这样的部件。本发明可以借助于包括有若干不同部件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种基于微前端架构的高可用性实现方法，其特征在于，用于微前端项目，所述微前端项目包括主体容器和子服务；所述高可用性实现方法包括：

分别建立对应于所述主体容器的主体备份，以及对应于所述子服务的子服务备份；

根据所述主体备份的地址信息实时监控所述主体备份的运行状态并更新所述主体备份的内部数据，以及，根据所述子服务的地址信息实时监控所述子服务备份的运行状态并更新所述子服务的内部数据；

判断所述主体容器是否发生系统灾难；

若判定所述主体容器发生系统灾难，则将所述主体容器切换为运行状态正常且内部数据已更新的所述主体备份，以提供主体服务功能；

判断所述子服务是否发生系统灾难；

若判定所述子服务发生系统灾难，则将所述子服务切换至运行状态正常且内部数据已更新的所述子服务备份，以提供子服务功能。

2.根据权利要求1所述的高可用性实现方法，其特征在于，所述根据主体备份的地址信息实时监控主体备份的运行状态并更新所述主体备份的内部数据的步骤，包括：

通过所述主体备份的地址信息，按预定时间间隔依次向所述主体备份发送信息请求；

判断第一预定时间内是否接收到所述主体备份对所述信息请求的响应信息；

若判定所述第一预定时间内接收到所述响应信息，则确定所述主体备份的运行状态正常；

以及，

实时监听所述主体容器生成的系统数据；

通过所述主体备份的地址信息，将所述系统数据同步至所述主体备份。

3.根据权利要求1所述的高可用性实现方法，其特征在于，所述判断所述主体容器是否发生系统灾难的步骤，包括：

使用拦截器拦截所述主体容器的外部操作指令；

当所述拦截器拦截到所述外部操作指令时，向所述主体容器发送预请求；

判断第二预定时间内是否接收到所述主体容器对所述预请求的响应信息；

若判定所述第二预定时间内未接收到所述响应信息，则确定所述主体容器发生系统灾难。

4.根据权利要求1所述的高可用性实现方法，其特征在于，所述将主体容器切换为运行状态正常且内部数据已更新的主体备份的步骤，包括：

记录所述系统灾难发生时，所述微前端项目对所述主体容器的必要配置信息；

通过所述主体备份的地址信息，将所述主体容器切换为所述主体备份；

使用所述必要配置信息配置所述主体备份，以使所述微前端项目恢复至所述系统灾难发生前的状态。

5.根据权利要求4所述的高可用性实现方法，其特征在于，所述将所述子服务切换至运行状态正常且内部数据已更新的所述子服务备份的步骤，包括：

记录所述系统灾难发生时，所述微前端项目对所述子服务的必要配置信息；

通过所述子服务备份的地址信息，将所述子服务切换为所述子服务备份；

使用所述必要配置信息配置所述子服务备份；

将配置后的所述子服务备份输出至所述主体容器或主体备份中进行展示。

6.根据权利要求1所述的高可用性实现方法，其特征在于，在分别建立对应于所述主体容器的主体备份，以及对应于所述子服务的子服务备份的步骤之后，所述方法还包括：

分别设置用于部署所述主体容器、所述主体备份、所述子服务、所述子服务备份的多台代理服务器；

启动所述多台代理服务器，并建立每台代理服务器之间的通信连接。

7.一种基于微前端架构的高可用性实现系统，其特征在于，用于微前端项目，所述微前端项目包括主体容器和子服务；所述高可用性实现系统包括：

备份建立模块，用于分别建立对应于所述主体容器的主体备份，以及对应于所述子服务的子服务备份；

监控更新模块，用于根据所述主体备份的地址信息实时监控所述主体备份的运行状态并更新所述主体备份的内部数据，以及，根据所述子服务的地址信息实时监控所述子服务备份的运行状态并更新所述子服务的内部数据；

第一灾难判断模块，用于判断所述主体容器是否发生系统灾难；

第一备份切换模块，用于当所述第一灾难判断模块判定所述主体容器发生系统灾难时，将所述主体容器切换为运行状态正常且内部数据已更新的所述主体备份，以提供主体服务功能；

第二灾难判断模块，用于判断所述子服务是否发生系统灾难；

第二备份切换模块，用于当判定所述子服务发生系统灾难时，将所述子服务切换至运行状态正常且内部数据已更新的所述子服务备份，以提供子服务功能。

8.根据权利要求7所述的高可用性实现系统，其特征在于，所述监控更新模块，包括：

第一请求发送子模块，用于通过所述主体备份的地址信息，按预定时间间隔依次向所述主体备份发送信息请求；

第一接收判断子模块，用于判断第一预定时间内是否接收到所述主体备份对所述信息请求的响应信息；

状态确定子模块，用于当所述接收判断子模块判定所述第一预定时间内接收到所述响应信息时，确定所述主体备份的运行状态正常；

以及，

数据监听子模块，用于实时监听所述主体容器生成的系统数据；

数据同步子模块，用于通过所述主体备份的地址信息，将所述系统数据同步至所述主体备份。

9.根据权利要求7所述的高可用性实现系统，其特征在于，所述第一灾难判断模块，包括：

指令拦截子模块，用于使用拦截器拦截所述主体容器的外部操作指令；

第二请求发送子模块，用于当所述拦截器拦截到所述外部操作指令时，向所述主体容器发送预请求；

第二接收判断子模块，用于判断第二预定时间内是否接收到所述主体容器对所述预请求的响应信息；

灾难确定子模块，用于当所述第二接收判断子模块判定所述第二预定时间内未接收到所述响应信息时，确定所述主体容器发生系统灾难。

10.根据权利要求7所述的高可用性实现系统，其特征在于，所述第一备份切换模块，包括：

第一配置记录子模块，用于记录所述系统灾难发生时，所述微前端项目对所述主体容器的必要配置信息；

主体切换子模块，用于通过所述主体备份的地址信息，将所述主体容器切换为所述主体备份；

第一备份配置子模块，用于使用所述必要配置信息配置所述主体备份，以使所述微前端项目恢复至所述系统灾难发生前的状态。

Images