CN110633157A

CN110633157A - 菜单动态管理方法、服务器、系统和计算机可读存储介质

Info

Publication number: CN110633157A
Application number: CN201810665814.5A
Authority: CN
Inventors: 黄媛媛; 付迎春; 刘学生
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2018-06-25
Filing date: 2018-06-25
Publication date: 2019-12-31
Also published as: US11169863B2; EP3812893A4; WO2020001391A1; US20210216381A1; EP3812893A1

Abstract

本发明实施例公开了一种菜单动态管理方法、服务器、系统和计算机可读存储介质，该方法包括：采集各个独立部署功能单元上功能变化时生成的菜单变化消息；通过集群方式部署的消息中间文件接收菜单变化消息，并对菜单变化消息进行广播通知；在门户单元监听菜单变化消息，并对菜单变化信息进行解析处理，更新界面显示的菜单。本发明的实施例通过消息中间件集群对菜单变化消息的转发和暂存，消息中间件的集群部署模式，从而形成了去中心化架构，各个功能模块的启动顺序上相互独立，使得系统更加具有健壮性。

Description

菜单动态管理方法、服务器、系统和计算机可读存储介质

技术领域

本申请涉及计算机网络技术领域，尤其涉及一种菜单动态管理方法、服务器、系统和计算机可读存储介质。

背景技术

在动态管理的系统中，比如微服务架构的系统，其功能拆分为独立的微服务，微服务可以独立运行、部署、升级、卸载。动态管理的系统通常要求菜单也能够跟随功能的变化动态改变，即功能部署时能够动态增加或更新该功能的菜单，功能卸载时能够动态卸载该功能对应的菜单。另外，独立部署的功能可以独立提供服务能力，这些服务能力可以灵活组合，对不同的场景暴露不同的功能集合，只提供在功能集合内的菜单。典型的应用场景是多租户场景，多租户场景下，后台部署的是功能全集，然后根据租户对服务的购买情况，对这些服务能力进行组装，在这个租户的门户上所能看到的菜单只有已经购买的功能的对应菜单。对菜单进行动态管理的需求，可以分为两个层次：第一，根据功能的安装卸载情况，实现动态的菜单管理；第二，根据需要把系统中的能力组装成功能集，不同的功能集暴露不同的门户，门户上的菜单也要求和功能集匹配，能够灵活的提供与功能集对应的菜单集合。

现有的动态菜单管理方法是当各个独立功能部署时，向菜单管理模块发送菜单注册消息，或者是菜单管理模块主动向各个功能收集菜单，菜单管理模块对这些菜单进行合并处理，然后由菜单显示模块对菜单进行展示。但是，菜单管理是由一个菜单管理模块来负责，菜单管理模块是专门用于菜单处理的中心节点，菜单管理模块可能成为瓶颈，比如该模块自身存在问题或者没有部署时，会导致菜单无法正常注册、合并和显示，导致整个系统不可用，从而缺乏健壮性。

发明内容

本申请提出的一种菜单动态管理方法、服务器、系统和计算机可读存储介质，旨在解决单一菜单管理模块进行菜单注册、合并和显示时，系统缺乏健壮性的问题。

为实现上述目的，根据本发明实施例的第一个方面，提供了一种菜单动态管理方法，包括：

当独立部署功能单元上的功能变化时，采集功能变化生成的菜单变化消息；

通过集群方式部署的消息中间文件接收所述菜单变化消息，并对所述菜单变化消息进行广播通知；

在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，更新界面显示的菜单。

根据本发明实施例的第二个方面，提供了一种服务器，具有包括处理器、存储器及数据总线；

所述数据总线用于实现处理器和存储器之间的连接通信；

所述处理器用于执行存储器中存储的内存模型计算程序，以实现以下步骤：

在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，获得菜单显示文件。

根据本发明实施例的第三个方面，提供了一种菜单动态管理系统，所述系统包括至少一服务器以及若干客户端，所述服务器中设置有若干功能单元和若干门户单元，所述客户端对应所述门户单元分别设置有显示界面；在所述系统中实现以下步骤：

在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，获得菜单显示文件；

将所述菜单显示文件发送到对应的显示界面，更新所述显示界面的菜单。

根据本发明实施例的第四个方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，一个或者多个程序可被一个或者多个处理器执行，以实现如上述菜单动态管理方法的步骤。

根据以上技术方案，可知本发明实施例提供的菜单动态管理方法、服务器、系统和计算机可读存储介质，通过消息中间件集群对菜单变化消息的转发和暂存，不再需要有一个专门用于菜单处理的中心节点，没有写入存储的菜单信息都保存在消息中间件上，一旦有可以进行菜单处理的单元启动或正常运行，就可以进行菜单消息处理、存储、合并等；消息中间件的集群部署模式，即使某个消息中间件实例不正常，也不会影响系统中的菜单注册、卸载。系统采用了去中心化架构，在各个模块的启动顺序上没有依赖关系，菜单变化处理模块、菜单合并模块即使在菜单注册之后再启动，也能在启动之后获取到已经注册的菜单。

另外，通过创建菜单统一模型，使得菜单定义更加规范、一致，保证菜单注册及后续合并逻辑的正确性。菜单合并时，根据所在门户单元定义的功能子集，对系统中现有的菜单集合进行定制，使菜单处理更加灵活。功能的所有变化，都可以灵活的进行菜单的修改，使得菜单与功能一致。

附图说明

图1是根据本发明实施例的一种菜单动态管理方法流程框图；

图2是根据本发明实施例的第二种覆盖级别更新处理方法流程框图；

图3是根据本发明实施例的第三种覆盖级别更新处理方法流程框图；

图4是本发明实施例的一种服务器结构框图；

图5是根据本发明实施例的一种菜单动态管理系统结构框图；

图6是根据本发明实施例的一种菜单动态管理系统模块划分结构框图；

图7是根据本发明实施例的菜单动态管理方法工作流程框图；

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

具体实施方式

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

在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身没有特有的意义。因此，“模块”、“部件”或“单元”可以混合地使用。

现有的菜单动态管理方法，当各个独立功能单元部署时，向菜单管理模块发送菜单注册消息，或者是菜单管理模块主动向各个功能单元收集菜单，菜单管理模块对这些菜单进行合并处理，然后由菜单显示模块对菜单进行展示。现有的菜单动态管理方案是以菜单管理模块作为系统中心节点，前述已经说明现有菜单动态管理放哪缺乏健壮性(鲁棒性)，存在中心节点故障时系统瘫痪的风险。由于采用中心化架构，对独立部署功能的启动次序有要求：菜单管理和展示都是由一个菜单管理模块来负责，各个独立功能要进行菜单注册，就需要该模块先启动，其他功能才能进行菜单注册。

基于上述现有技术方案的缺陷，具体提出了以下实施例。

实施例1

如图1所示，本发明实施例提供了一种菜单动态管理方法，包括：

S101、当独立部署功能单元上的功能变化时，采集功能变化生成的菜单变化消息；

通常系统由1-n个可以独立部署功能单元构成(独立部署单元可以是微服务或者插件)，当功能卸载或者部署时，触发生成菜单变化消息，菜单变化消息包括菜单注册消息和菜单卸载消息。

S102、通过集群方式部署的消息中间文件接收所述菜单变化消息，并对所述菜单变化消息进行广播通知；

没有写入存储的菜单变化信息都保存在消息中间件上，对系统中所有的菜单变化消息消费者进行广播通知，一旦有可以进行菜单处理的单元启动或正常运行，就可以进行菜单消息处理、入库、合并等；消息中间件的集群部署模式，即使某个消息中间件实例不正常，也不会影响系统中的菜单注册、卸载；本实施例选用kafka作为消息中间件，kafka接收到的消息会在硬盘持久化，即使消息中间件整个重启，消息也不会丢失；菜单的变动处理、合并等，可以由多个门户来分别处理，不会依赖一个集中的菜单处理模块。从而使得菜单动态管理方案具有健壮性。

S103、在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，更新界面显示的菜单。

针对菜单变化消息是在功能卸载和部署时，对应的是菜单注册和菜单删除，具体的，如图2所示，所述对所述菜单变化信息进行解析处理包括：

S201、当监听到所述菜单注册消息时，解析消息中的菜单信息，新增或修改菜单集合；

S203、当监听到所述菜单卸载消息时，解析消息中的菜单标识ID(identification的缩写)信息，删除菜单集合中的对应菜单。

其中，所述采集功能变化生成的菜单变化消息之前，所述方法还包括：创建一统一菜单模型，根据所述统一菜单模型分别定义每一功能单元的菜单，并生成对应的菜单定义文件。

表1菜单模型定义结构表

如表1所示，本发明实施例提供的一种菜单模型定义结构表，具体的，该菜单模型包括：

ID：菜单的标识，是菜单的唯一标示；

Name：

name_zh：菜单中文名；

name_en：菜单英文名；

Page ID：菜单对应的功能页面标识；

Position：

Parent：菜单的父亲菜单标识，菜单是允许有层级关系的，这里用子菜单关联父菜单；

Order：顺序，同一个父菜单下有多个子菜单时，用order表示显示顺序；

Group：分组，同一个父菜单下多个子菜单可以分组，group相同的排在一起；

display-attr：

icon：菜单图标

Display：是否显示，false则菜单隐藏；

right：

Operation：为菜单对应的鉴权操作码，在界面显示时，判断此操作码是否有权限，有权限则显示，无权限，该菜单删除；

License：为该菜单对应的license授权项，在界面显示时，判断此授权项是否有授权，有授权则显示，无授权，该菜单删除。

上述菜单模型的定义可以广泛应用于所有的菜单管理场景，不限于需要动态管理菜单的场景。其他部分可以广泛用于系统中的功能可以独立安装、卸载、升级的场景或领域。比如：

(1)采用微服务架构的系统，由于功能都是以微服务的方式独立提供，微服务可以独立部署、卸载、升级，在这种场景下，菜单的动态管理能够非常好的适配微服务架构的灵活性；

(2)对系统中的功能采用插件架构的系统，也存在和微服务架构相同的特点，因此，本专利所述的菜单动态管理可以非常好的适配动态管理系统的灵活性；

(3)分布式系统，系统中的功能分布式、独立部署，在这种场景下，菜单的动态管理能够非常好的适配分布式系统的灵活性。

其中，所述当独立部署功能单元上的功能变化时，采集功能变化生成的菜单变化消息之前，利用分布式数据库或分布式缓存对每一功能单元对应的菜单信息进行持久化处理，生成菜单集合。持久化就是对菜单消息进行保存或者删除，以及提供查询。

其中，所述在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，更新界面显示的菜单之后，所述方法还包括：

S301、当所述门户单元需要提供部分功能集合时，获取所述门户单元所需要展示菜单对应的菜单标识信息与所述菜单集合，所述菜单标识信息和所述菜单集合取交集后得到菜单合并集合；

S302、将所述菜单合并集合组织形成菜单树结构，按照显示格式对菜单树节点进行转换，在显示界面生成菜单。

具体的，合并时，根据配置的parentID，来组织菜单树结构，把parentID相同的菜单放到一层，并且根据order配置进行同一层的菜单排序，同层的菜单如果group相同，则认为是一组，同一组的菜单放到一起。菜单树结构生成之后，再按照显示的格式，对菜单树节点进行转换，转换为界面显示需要的格式。本实施例中转换为浏览器可以直接解析的html片段。

实施例2

本发明实施例提供了一种服务器，具体地，如图4所示，所述服务器40至少包括处理器41、存储器42以及数据总线43。数据总线43用于实现处理器41和存储器42之间的连接通信，存储器42作为一种计算机可读存储介质，可以存储至少一个计算机程序，这些计算机程序可供处理器41读取、编译并执行，从而实现对应的处理流程。在本实施例中，存储器42作为一种计算机可读存储介质，其中存储有识别下载文件类型程序，该程序可供处理器31执行，从而实现如下的菜单动态管理方法的步骤：

实施例3

如图5所示，本发明实施例还提供了一种菜单动态管理系统，所述系统包括至少一服务器40以及若干客户端50，所述服务器40中设置有若干功能单元和若干门户单元，所述客户端50对应所述门户单元分别设置有显示界面；在所述系统中实现以下步骤：

如图6所示，所述系统40可以划分为多个功能模块，具体包括：

菜单代理模块41，设置在服务器40中的每一功能单元中，用于采集各个独立部署功能单元上功能变化时生成的菜单变化消息；

以代理形式在各个独立部署功能单元上，在该单元部署时，菜单代理模块负责收集本单元的菜单定义文件，发送注册消息，功能卸载时，获取本单元的所有注册过的菜单标识，发送菜单卸载消息。

消息中间件集群42，用于通过集群方式部署的消息中间文件接收所述菜单变化消息，并对所述菜单变化消息进行广播通知；

以集群方式部署的消息中间件，负责接收菜单相关的消息，并通知监听菜单变化的消息消费者。本实施例中使用kafka集群，kafka是一种高吞吐量的分布式发布订阅消息系统，对接收到的消息会持久化到本地硬盘。集群部署方式，即使某个kafka实例不正常，也不会影响系统中的菜单注册、卸载；消息在硬盘持久化，即使kafka整个重启，消息也不会丢失。保证了动态菜单管理系统的健壮性。使用kafka来做消息转发，使得整个系统中不再需要有一个专门用户菜单处理的中心节点，没有写入存储的菜单信息都保存在kafka上，一旦有可以进行菜单处理的单元启动或正常运行，就可以进行菜单消息处理、入库、合并等。

菜单变化管理模块43，设置在各个门户单元中，用于监听所述菜单变化消息，并对所述菜单变化信息进行解析处理；

菜单管理模块部署在门户单元上，根据系统的需求，会有1-n个门户单元，这些门户单元上的菜单管理模块负责监听消息中间件上的菜单消息，对菜单进行持久化处理，若监听到菜单注册消息，则将解析消息中的菜单信息，新增或修改菜单存储；若监听到菜单卸载消息，则解析消息中的菜单标识信息，删除菜单存储中的对应菜单。

菜单定义模块44，设置在每一功能单元中，用于根据统一菜单模型分别定义每一功能单元的菜单，并生成对应的菜单定义文件。

按照统一菜单模型定义开发菜单实例文件，一个菜单实例文件中可以有1-n个菜单，同一个独立部署功能单元(可以是微服务、插件等)可以多有个菜单文件。这些文件为json格式，放置在微服务的固定文件夹下。

菜单存储模块45，用于利用分布式数据库或分布式缓存对各个功能单元对应的菜单信息进行持久化处理，生成菜单集合。

菜单合并模块46，检测所述门户单元是否提供部分功能集合，当只需要提供部分功能时，读取所述门户单元所需要展示的菜单标识信息与所述菜单集合，所述菜单标识信息和所述菜单集合取交集后得到菜单合并集合；将所述菜单合并集合组织形成菜单树结构，按照显示格式对菜单树节点进行转换，生成菜单显示文件。

菜单合并模块部署在门户单元上，负责菜单存储中读取菜单，进行合并。合并前，会判断本门户单元是否只需要提供部分功能的集合，若是，会取得本门户单元需要的菜单和系统中已经存在的菜单的交集作为菜单合并集合。合并时，根据配置的parent ID，来组织菜单树结构，把parent ID相同的菜单放到一层，并且根据order配置进行同一层的菜单排序，同层的菜单如果group相同，则认为是一组，同一组的菜单放到一起。树结构生成之后，再按照显示的格式，对菜单树节点进行转换，转换为界面显示需要的格式。本实施例中转换为浏览器可以直接解析的html片段。

菜单显示模块51，设置在客户端50上，用于更新显示各个门户单元通过的功能菜单。客户端50可以是浏览器等应用程序，集成安装在移动终端产品上。

具体的，系统由1-n个可以独立部署功能单元构成(独立部署功能单元可以是微服务或者插件)，每个独立部署的功能单元上有菜单定义模块和菜单代理模块，负责本单元的菜单定义和注册；消息中间件负责系统中的消息传递，以集群方式部署，本身具备健壮性；系统中部署有1-n个门户单元(是一种用于展示系统入口的独立部署单元)，这些门户单元上包含菜单的变动处理模块和菜单合并模块，负责菜单的集成；菜单存储模块负责菜单的持久化(存储或者删除)；菜单显示模块负责菜单的展示。

上述动态菜单处理系统是一种去中心化的架构，系统中不需要一个集中的菜单处理模块来集中做菜单变化监听、菜单变化处理、菜单合并处理。在各个模块的启动顺序上，也没有限制，菜单变化处理模块、菜单合并模块即使在菜单注册之后再启动，也能在启动之后获取到已经注册的菜单。

实施例4

本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，一个或者多个程序可被一个或者多个处理器执行，以实现如上述菜单动态管理方法的步骤。

如图7所示，该一个或者多个程序具体执行具体如下：

步骤S601，判断当前是功能部署还是卸载；

步骤S602，卸载则获取本微服务相关的菜单标识，发送菜单卸载消息到消息中间件(本实施例中使用消息中间件kafka)；或者S603，部署则查找本微服务指定文件夹下的菜单文件，进行文件解析，将解析后的信息发送菜单注册消息到消息中间件；

步骤S604，菜单代理模块监听消息中间件的菜单变化消息，读取消息；

步骤S605，判断是菜单注册消息还是菜单卸载消息；

步骤S606，若是菜单卸载消息，则取出需要删除的菜单标识，在存储中将对应菜单删除；(本实施例中使用的存储装置为PostGre分布式缓存)；S607，若是菜单注册消息，则取出菜单内容，进行校验，把校验后的菜单信息存储起来；

步骤S608，读取存储中的所有菜单；

步骤S609，判断是否需要进行菜单定制(在门户单元只需要展示部分功能集合场景下，需要展示的菜单不是全集)；

步骤S610，若需要进行菜单定制，则获取本门户单元中需要展示的菜单标识与所有菜单取交集，作为待合并的菜单合并集合；

步骤S611，把菜单合并集合进行去重，按照层次关系定义，组织成有序的菜单树状结构，再根据展示的需要将其转换为可以直接显示的菜单结构，持久化为菜单显示文件；(本实施例中将其转换为可以直接在浏览器显示的html片段)

步骤S612，将转换后的菜单显示文件进行显示。(本实施例中是浏览器发起对合并后的菜单文件的访问，将菜单文件读取到浏览器后，加载到页面中)。

根据以上技术方案，可知本发明实施例提供的菜单动态管理方法、系统和计算机可读存储介质，通过消息中间件集群对菜单变化消息的转发和暂存，不再需要有一个专门用于菜单处理的中心节点，没有写入存储的菜单信息都保存在消息中间件上，一旦有可以进行菜单处理的单元启动或正常运行，就可以进行菜单消息处理、存储、合并等；消息中间件的集群部署模式，即使某个消息中间件实例不正常，也不会影响系统中的菜单注册、卸载。系统采用了去中心化架构，在各个模块的启动顺序上没有依赖关系，菜单变化处理模块、菜单合并模块即使在菜单注册之后再启动，也能在启动之后获取到已经注册的菜单。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。

Claims

1.一种菜单动态管理方法，其特征在于，所述方法包括：

2.根据权利要求1所述的菜单动态管理方法，其特征在于，所述采集功能变化生成的菜单变化消息之前，还包括：

创建一统一菜单模型，根据所述统一菜单模型分别定义每一功能单元的菜单，并生成对应的菜单定义文件。

3.根据权利要求1所述的菜单动态管理方法，其特征在于，所述菜单变化消息包括菜单注册消息和菜单卸载消息。

4.根据权利要求3所述的菜单动态管理方法，其特征在于，对所述菜单变化信息进行解析处理包括：

当监听到所述菜单注册消息时，解析消息中的菜单信息，新增或修改菜单集合；

当监听到所述菜单卸载消息时，解析消息中的菜单标识信息，删除菜单集合中的对应菜单。

5.根据权利要求1所述的菜单动态管理方法，其特征在于，所述采集功能变化生成的菜单变化消息之前，还包括：

利用分布式数据库或分布式缓存对每一功能单元对应的菜单信息进行保存，生成菜单集合。

6.根据权利要求5所述的菜单动态管理方法，其特征在于，所述在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，更新界面显示的菜单之后，还包括：

当所述门户单元提供部分功能集合时，获取所述门户单元所展示菜单对应的菜单标识信息与所述菜单集合，所述菜单标识信息和所述菜单集合取交集后得到菜单合并集合；

将所述菜单合并集合组织形成菜单树结构，按照显示格式对菜单树节点进行转换，生成菜单显示文件。

7.根据权利要求6所述的菜单动态管理方法，其特征在于，所述生成菜单显示文件之后，所述方法包括：将所述菜单显示文件发送到对应的显示界面，更新显示界面的菜单。

8.一种服务器，其特征在于，所述服务器包括处理器、存储器及数据总线；

所述数据总线用于实现处理器和存储器之间的连接通信；

9.一种菜单动态管理系统，其特征在于，所述系统包括至少一服务器以及若干客户端，所述服务器中设置有若干功能单元和若干门户单元，所述客户端对应所述门户单元分别设置有显示界面；在所述系统中实现以下步骤：

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，一个或者多个程序可被一个或者多个处理器执行，以实现如权利要求1-7任意一项所述的菜单动态管理方法的步骤。