CN113569257A - 灰度发布中的用户权限管理方法和装置 - Google Patents

Abstract

本申请公开了一种灰度发布中的用户权限管理方法和装置，所述方法包括：接收用户针对目标应用的目标菜单的访问请求，该请求中携带有用户标识和目标应用的版本标识；基于用户标识确定用户的角色标识，并基于目标应用的版本标识确定目标应用的版本；当为灰度版本时，基于预先配置的灰度角色表和所述角色标识，确定用户是否具备访问目标应用的权限；当为基础版本时，基于预先配置的基础角色表和所述角色标识，确定用户是否具备访问目标应用的权限；当用户具备访问目标应用的权限时，基于预先配置的角色菜单关系表和用户的角色标识，确定用户是否具备访问目标菜单的权限。该方法和装置可解决当前的灰度发布方案中用户权限管理系统冗余和复杂的问题。

Description

灰度发布中的用户权限管理方法和装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种灰度发布中的用户权限管理方法和装置。

背景技术

灰度发布，是一种将用户流量平滑导入新上线的业务系统的发布方式。灰度发布能在一开始就对新的功能做出验证，一旦出现问题，可以马上恢复至旧的业务系统。

目前，为了实现业务系统的灰度发布，需要根据引流策略和引流流量部署两套或者多套业务系统，并在每套业务系统中设置一套用户权限管理系统，以管理用户对业务系统中相关应用及其菜单的访问权限。如图1所示，业务系统A为改进前的业务系统，其中部署有1.0版本的应用A、应用B和应用C，业务系统B为对业务系统A的改进版，其中部署有1.1版本的应用A、应用B和应用C。在图1中，为了在业务系统A的基础上实现业务系统B的灰度发布，分别部署了业务系统A和业务系统B，并在这两套业务系统中分别设置了用户权限管理系统A和用户权限管理系统B，以实现这两套业务系统的用户权限管理，其中，来自客户端1和客户端2的用户流量，可通过引流策略导入业务系统A或业务系统B。

通过图1不难发现，当前的灰度发布方案中的用户权限管理系统显得冗余和复杂，需要改进。

发明内容

本申请实施例提供一种灰度发布中的用户权限管理方法和装置，以解决当前的灰度发布方案中用户权限管理系统冗余和复杂的问题。

第一方面，本申请实施例提供一种灰度发布中的用户权限管理方法，包括：

接收用户针对目标应用的目标菜单的访问请求，其中，所述访问请求中携带有所述用户的用户标识和所述目标应用的版本标识，所述目标应用包括本次灰度发布的灰度版本和所述灰度版本依赖的基础版本；

基于所述用户的用户标识确定所述用户的角色标识，并基于所述目标应用的版本标识确定所述目标应用的版本；

当所述目标应用的版本为所述灰度版本时，基于预先配置的灰度角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限，其中，所述灰度角色表中存储有所述灰度版本的版本标识和允许访问所述灰度版本的所述目标应用的用户角色的角色标识；

当所述目标应用的版本为所述基础版本时，基于预先配置的基础角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限，其中，所述基础角色表中存储有所述基础版本的版本标识和允许访问所述基础版本的所述目标应用的用户角色的角色标识；

当所述用户具备访问所述目标应用的权限时，基于预先配置的角色菜单关系表和所述角色标识，确定所述用户是否具备访问所述目标菜单的权限，其中，所述角色菜单关系表中存储有所述目标应用的菜单的标识和允许访问该菜单的用户角色的角色标识。

第二方面，本申请实施例还提供一种灰度发布中的用户权限管理装置，包括：

请求接收模块，用于接收用户针对目标应用的目标菜单的访问请求，其中，所述访问请求中携带有所述用户的用户标识和所述目标应用的版本标识，所述目标应用包括本次灰度发布的灰度版本和所述灰度版本依赖的基础版本；

第一确定模块，用于基于所述用户的用户标识确定所述用户的角色标识，并基于所述目标应用的版本标识确定所述目标应用的版本；

第二确定模块，用于当所述目标应用的版本为所述灰度版本时，基于预先配置的灰度角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限，其中，所述灰度角色表中存储有所述灰度版本的版本标识和允许访问所述灰度版本的所述目标应用的用户角色的角色标识；

第三确定模块，用于当所述目标应用的版本为所述基础版本时，基于预先配置的基础角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限，其中，所述基础角色表中存储有所述基础版本的版本标识和允许访问所述基础版本的所述目标应用的用户角色的角色标识；

第四确定模块，用于当所述用户具备访问所述目标应用的权限时，基于预先配置的角色菜单关系表和所述角色标识，确定所述用户是否具备访问所述目标菜单的权限，其中，所述角色菜单关系表中存储有所述目标应用的菜单的标识和允许访问该菜单的用户角色的角色标识。

第四方面，本申请实施例还提供了一种电子设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如第一方面所述的方法的步骤。

第五方面，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面所述的方法的步骤。

本申请实施例采用的上述至少一个技术方案，由于预先配置了灰度角色表、基础角色表以及角色菜单关系表，且基于预先配置的这些表即可实现灰度发布中用户访问目标应用的菜单的权限管理，因此，采用一套用户权限管理系统即可实现多个灰度版本目标应用的用户访问权限管理，无需配置多套权限管理系统，不存在用户权限管理系统冗余和复杂的问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是现有技术中的灰度发布中的用户权限管理方案的架构示意图。

图2是本申请实施例提供的灰度发布中的用户权限管理方案的架构示意图。

图3是本申请实施例提供的应用的系统架构示意图。

图4A是本申请实施例提供的应用管理界面示意图之一。

图4B是本申请实施例提供的应用管理界面示意图之二。

图4C是本申请实施例提供的应用管理界面示意图之三。

图5A是本申请实施例提供的应用的菜单管理界面示意图之一。

图5B是本申请实施例提供的应用的菜单管理界面示意图之二。

图6A是本申请实施例提供的用户角色管理界面示意图之一。

图6B是本申请实施例提供的用户角色管理界面示意图之二。

图7是本申请实施例提供的一种灰度发布中的用户权限管理方法的流程示意图。

图8是本申请实施例提供的一种灰度发布中的用户权限管理装置的结构示意图。

图9是本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

通过图1不难发现，现有技术中的用户权限管理系统与业务系统耦合在一起，有多少套业务系统就需要同步部署多少套用户权限管理系统；多套用户权限管理系统需要进行数据切分与同步，增加了系统复杂度；用户权限管理系统冗余部署，需要维护多套用户权限管理系统，在系统开发、应用部署方面带来大量冗余、重复性工作；随着业务系统中应用的灰度版本的增加，用户权限管理系统与业务系统的匹配映射关系会相当复杂，运维管理人员极容易错配业务系统权限，造成用户权限管理混乱等问题。总之，当前的灰度发布方案中的用户权限管理系统显得冗余和复杂，需要改进。

为了解决当前的灰度发布方案中的用户权限管理系统显得冗余和复杂的问题，本申请实施例提供了一种灰度发布中的用户权限管理方法和装置，该方法可由电子设备执行，如终端设备或服务器，或者，该方法可由安装在电子设备中的软件执行。其中，所述终端设备包括但不限于：智能手机、个人电脑(personalcomputer，PC)、笔记本电脑、平板电脑、电子阅读器、网络电视、可穿戴设备等智能终端设备中的任一种；其中，服务器可以是保险公司的后台服务端设备，该服务器包括但不限于：单台服务器、服务器集群、云端服务器或云端服务器集群等。

本申请实施例中所说的用户权限管理，是指用户访问业务系统中的目标应用及其菜单的权限管理，其中，目标应用可以有多个版本，这多个版本可以包括但不限于灰度版本和灰度版本依赖的基础版本，灰度版本可以有多个，且灰度版本依赖的基础版本也可以有多个。

本申请实施例提供的一种灰度发布中的用户权限管理方案，旨在通过一套用户权限管理系统实现灰度发布中不同业务系统中不同版本应用的用户访问权限管理。如图2所示，业务系统A为改进前的业务系统，其中部署有1.0版本的应用A、应用B和应用C，业务系统B为对业务系统A的改进版，其中部署有1.1版本的应用A、应用B和应用C，在进行业务系统B中各应用的灰度发布时，通过在这两套业务系统之外设置的一套用户权限管理系统3对灰度发布中的用户权限进行管理。如图2所示，通过引流策略可将来自客户端1和客户端2的用户流量导入业务系统A或业务系统B后，来自客户端1和客户端2的用户流量在访问业务系统A或业务系统B中的某一应用时，会触发本申请实施例提供的用户权限管理系统3对用户的访问权限进行管理。本申请实施例提供的一种灰度发布中的用户权限管理方法和装置应用于图2所示的用户权限管理系统3。

通过图2不难发现，本申请实施例提供的一种灰度发布中的用户权限管理方案，将用户权限管理系统与业务系统解耦，不管有多少套业务系统都对应部署一套用户权限管理系统，因此可以克服现有技术中的灰度发布中用户权限管理方案存在的缺陷。

本申请实施例提供的一种灰度发布中的用户权限管理方法，可以包括两个阶段：第一个阶段，用户权限管理过程所依赖的数据表的配置；第二阶段，基于第一阶段配置的数据表进行用户权限管理。其中，第一阶段，可以看作是灰度发布中进行用户权限管理前的准备阶段，准备阶段一般执行一次，也就是说，在执行本申请实施例提供的一种灰度发布中的用户权限管理方法时，并不需要每一次都执行第一阶段的步骤。

下面先对第一阶段——用户权限管理过程所依赖的数据表的配置过程进行说明。

(1)应用灰度管理的准备阶段——应用的版本维护表的配置

图3示出了本申请实施例提供的应用的用户权限管理系统架构示意图。参考图3可知，应用的用户权限管理系统可包括：访问层31、展现层32、业务层33、中间件34、数据层35和基础层36，其中，访问层31可包括PC端，也即用户可通过PC端访问应用；展现层32可以是web，具体可以是Html5(HyperText Markup Language 5)、CSS3(Cascading StyleSheets3，层叠样式表3)、Vue、Jquery和elementUI等方式中描述的网站；业务层33可以包括应用管理、资源管理和用户授权等模块，应用管理可以包括应用管理本身、应用的灰度版本管理和应用的灰度版本下线等内容，资源管理可以包括应用的菜单管理、用户或管理员的角色定义及配置、灰度菜单管理和灰度角色管理等内容，用户授权包括管理员授权、用户授权、用户绑定等内容；中间件34包括CMQ(Cloud Message Queue)、Redis(缓存)、Kafaka(一种开源处理平台)和COS9(一种消息队列)等；数据层35可包括南云、北云和数据库PostgreSQL等，南云和北云是分别位于南方和北方的两个云存储平台，且南云和北云各包括主和从两种部署；基础层36是物理机，包括基础云平台和devops流水线等。

为了实现通过一套用户权限管理系统对不同业务系统中不同版本的应用访问权限的管理，本申请实施例先在用户权限管理系统中配置了应用的版本维护表(svrVersion)，具体是在图3的业务层33的应用管理模块中增加了应用的版本维护表，该版本维护表中存储有本次灰度发布的目标应用的灰度版本及其依赖的基础版本的版本标识，版本标识一般是版本号或其他能够唯一标识版本的版本ID，当然还可以存储其他信息，表1为应用的版本维护表的一种示例。

表1 版本维护表

元素	释义
		版本号	本次上线版本
基础版本	依赖版本，多选
		试点日期	预计试点日期
上线日期	预计正式全国上线日期
		版本状态	灰度/已上线
有效状态	有效/无效
		版本描述	版本需求描述。

需要说明的是，在本申请实施例中，灰度版本是在正在进行灰度发布的版本，已上线版本是指已经完成发布的版本。

图4A至图4C还示出了应用管理界面的示意图。如图4A所示，在应用管理界面中可以看到业务系统中的部分或全部应用，以及这些应用的所属公司、应用名称、应用类型、有效状态、应用版本以及可对应用执行的操作等多项内容，其中，在“应用管理”这一项下，还可以通过点击“版本管理”这一按钮对应用的版本进行管理，在“操作”这一项下，可通过点击“修改”、“注销”或“查看”按钮对对应的应用执行修改、注销和查看操作。如图4B所示，还可以在应用管理界面中输入查询条件查询业务系统中的应用并显示查询结果，输入条件包括版本号、版本状态和有效状态中的一个或多个，在查询结果中也可以通过点击“操作”选项下的“修改”、“版本下线”等按钮对查询到的应用执行修改和下线操作。继续参考图4B可知，还可以通过点击“查询”按钮后面的“新增”按钮，新增新的版本的应用，点击“新增”按钮或查询结果中的“修改”按钮后会跳转至如图4C所示的页面。在图4C中，可以新增/修改应用的版本。

在实际应用中，通过图4C所示的界面维护的应用的版本信息会自动添加至上述版本维护表中，或者说，可通过在图4C所示的界面新增或修改应用的版本维护表中的信息。

(2)应用的菜单灰度管理的准备阶段——菜单表的配置

菜单灰度管理，指的是针对本次发布的灰度版本应用相对于其所依赖的基础版本应用需要调整的菜单维护灰度版本，也即在已配置的基础菜单表(smc_menu)的基础上，配置灰度菜单表(smc_menugrayrelease)，该灰度菜单表中存储有灰度版本的应用相对于基础版本的应用发生变化的菜单信息，不同灰度版本下的同一菜单可维护多条数据。可选地，灰度菜单表中留存灰度版本的版本标识以及该灰度版本所依赖的基础菜单表的主键。表2和表3分别示出了基础菜单表和灰度菜单表的一种表结构。

表2 基础菜单表

表3 灰度菜单表

可以理解，基础菜单表包括如表2所示的菜单信息，表2中的一行代表菜单的一个属性(可以是基础菜单表的列名)，一个应用的基础版本有多少菜单，在基础菜单表中对应存在相应数目的记录。同理，灰度菜单表包括如表3所示的菜单信息，表3中的一行代表菜单的一个属性(可以是基础菜单表的列名)，一个应用的灰度版本中的菜单相对于基础版本中的菜单发生了多少变化(新增/修改了多少个菜单)，在灰度菜单表中对应存在相应数目的记录。

图5A和图5B示出了菜单管理界面的示意图。如图5A所示，可以通过点击菜单管理界面中菜单层级列表中的“用户管理”这一菜单，可在其下方展示该菜单的已上线版本的相关信息，同时会展示“增加灰度版本”按钮，点击这一按钮可跳转至如图5B所示的该菜单的灰度信息编辑界面，在该界面中可编辑该菜单的灰度版本，点击保存后即可在灰度菜单表中增加一条记录。

(3)用户角色配置管理

用户角色配置管理指的是在基础角色表和角色菜单关系表的基础上维护灰度版本，也即在已配置的基础角色表(saa_grade)的基础上配置灰度角色表(saa_gradegrayrelease)，以及在已配置的角色菜单关系表(saa_grademenu)中增加灰度角色菜单关系。其中，基础角色表中存储有应用的基础版本的版本标识和允许访问该基础版本的应用的用户角色的角色标识；灰度角色表中存储有应用的灰度版本的版本标识和允许访问该灰度版本的应用的用户角色的角色标识，此外，在灰度角色表中，对于同一用户角色，可维护多个灰度版本信息，也即同一用户角色的用户可访问多个灰度版本的同一应用；角色菜单关系表中存储有应用的菜单的标识和允许访问该菜单的用户角色的角色标识。灰度角色表中还存储有应用的灰度版本的版本标识以及对应的基础角色表的主键。当然，基础角色表、灰度角色表和角色菜单关系表中还可以根据需要存储其他信息，本文对此不做限制。表4、表5和表6分别示出了基础角色表、灰度角色表和增加了灰度角色菜单关系的角色菜单关系表的一种表结构。

表4 基础角色表

表5 灰度角色表

表6 角色菜单关系表

图6A和图6B示出了用户角色管理界面的示意图。如图6A所示，点击用户角色管理界面中的“增加灰度版本”按钮这一按钮后，可展示出用户角色的灰度信息编辑界面，在该界面中可编辑该用户角色的灰度版本，点击保存后即可在灰度角色表中增加一条记录。图6B示出了用户角色管理内容的层级列表，具体内容请参见图6B。

以上介绍了本申请实施例提供的一种灰度发布中的用户权限管理方法的第一阶段，下面对第二阶段进行说明。

如图7所示，本申请实施例提供的一种灰度发布中的用户权限管理方法，可包括：

步骤701、接收用户针对目标应用的目标菜单的访问请求，其中，所述访问请求中携带有所述用户的用户标识和所述目标应用的版本标识，所述目标应用包括本次灰度发布的灰度版本和所述灰度版本依赖的基础版本。

目标应用可以业务系统中的任一应用。目标菜单可以是目标应用的任一菜单。用户在目标应用客户端(如PC端)上的展示界面(如web页面)中对目标应用的目标菜单操作一次(如点击一次)即可认为接收到用户针对目标应用的目标菜单的访问请求。由于用户一般是登录目标应用的客户端以后，再对目标应用中的菜单进行操作，因此，用户标识可以是用户的账户ID，或者是用户所使用的设备的ID。目标应用的版本标识可以是引流系统在引流时赋予的。

步骤702、基于所述用户的用户标识确定所述用户的角色标识，并基于所述目标应用的版本标识确定所述目标应用的版本。

具体的，可以基于预先配置的用户标识角色表和所述用户的用户标识，确定所述用户的角色标识，基于目标应用的版本标识和目标应用的版本维护表，确定所述目标应用的版本。

可选地，在步骤702之前，可以响应于管理员的第二配置请求，以完成所述目标应用的版本维护表的配置，其中，所述版本维护表中存储有所述灰度版本和所述基础版本的版本标识，具体配置过程可参见上文，此处不做赘述。

可选地，在步骤702之前，还可以响应于管理员的第三配置请求，以完成用户标识角色表的配置，其中，所述用户标识角色表中存储有用户标识和角色标识的对应关系。

步骤703、当所述目标应用的版本为所述灰度版本时，基于预先配置的灰度角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限。若具备则转入步骤705，否则转入步骤707。

其中，所述灰度角色表中存储有所述灰度版本的版本标识和允许访问所述灰度版本的所述目标应用的用户角色的角色标识。

可以理解，如果灰度角色表中存储的允许访问灰度版本的角色标识中包含所述用户，则确定所述用户具备访问所述目标应用的权限，反之，则确定所述用户不具备访问所述目标应用的权限。

步骤704、当所述目标应用的版本为所述基础版本时，基于预先配置的基础角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限。若具备则转入步骤705，否则转入步骤707。

其中，所述基础角色表中存储有所述基础版本的版本标识和允许访问所述基础版本的所述目标应用的用户角色的角色标识。

同样可以理解，如果基础角色表中存储的允许访问基础版本的角色标识中包含所述用户，则确定所述用户具备访问所述目标应用的权限，反之，则确定所述用户不具备访问所述目标应用的权限。

步骤705、基于预先配置的角色菜单关系表和所述角色标识，确定所述用户是否具备访问所述目标菜单的权限。若具备则转入步骤706，否则转入步骤707。

其中，所述角色菜单关系表中存储有所述目标应用的菜单的标识和允许访问该菜单的用户角色的角色标识。

可选地，在步骤701之前，图7所示的方法还可以包括：响应于管理员的第一配置请求，以完成所述灰度角色表、所述基础角色表和所述角色菜单关系表的配置。具体配置过程可参见上文所述的第一阶段，此处不做重复描述。

步骤706、允许所述用户访问所述目标菜单。

步骤707、拦截所述用户访问对所述目标菜单的访问。

本申请实施例提供的一种灰度发布中的用户权限管理方法，由于预先配置了灰度角色表、基础角色表以及角色菜单关系表，且基于预先配置的这些表即可实现灰度发布中用户访问目标应用的菜单的权限管理，因此，采用一套用户权限管理系统即可实现多个灰度版本目标应用的用户访问权限管理，无需配置多套权限管理系统，不存在用户权限管理系统冗余和复杂的问题。

可选地，图7所示的方法，在步骤701之前还可以包括：响应于第四配置请求，以完成所述目标应用的基础菜单表和灰度菜单表的配置，其中，所述基础菜单表存储有所述基础版本的所述目标应用的菜单信息，所述灰度菜单表中存储有所述灰度版本的所述目标应用相对于所述基础版本的所述目标应用发生变化的菜单信息。具体配置过程，请参见上文对第一阶段的描述。

相应的，在确定所述用户具备访问所述目标菜单的权限后，在步骤706之后，图7所示的方法还可以包括：当所述目标应用的版本为所述灰度版本时，通过查询所述基础菜单表和所述灰度菜单表获取所述目标菜单的信息；当所述目标应用的版本为所述基础版本时，通过查询所述基础菜单表获取所述目标菜单的信息。同理，业务系统在获取目标应用的菜单信息时，通过传入目标应用的版本标识，用户权限管理系统(参见图2)可通过版本标识先获取此版本的依赖版本号，依据此版本和依赖版本获取用户可访问的菜单信息。

可以理解，之所以在基础菜单表的基础上，针对灰度版本中相对于基础版本发生变化的菜单维护灰度菜单表，而不是针对所有菜单维护灰度菜单表，一方面可以避免相同菜单信息的重复存储，另一方面由于减少了菜单数据，因此可以提升菜单信息的检索效率。

可选地，查询到相应的菜单信息以后可以展示给用户。

可选地，在灰度发布结束后，灰度版本正式上线时，将灰度菜单表和灰度角色表中的灰度状态修改为已上线，依据灰度菜单表和灰度角色表中的数据更新基础菜单表和基础角色表中的数据并记录上一版本号。灰度版本正式上线后，如果出现问题时需将该版本下线时，根据基础菜单表、基础角色表中记录的上一版本号在灰度菜单表和灰度角色表中找到相应记录，并更新到灰度菜单表和灰度角色表，下线该版本，恢复到灰度状态。

可选地，在给用户配置角色时，可通过查询基础角色表和灰度角色表，给待授权用户配置角色。

相应于上述方法实施例，本申请实施例还提供了一种灰度发布中的用户权限管理装置，下面进行介绍。

如图8所示，本申请实施例提供的一种灰度发布中的用户权限管理装800，可以包括：请求接收模块801、第一确定模块802、第二确定模块803、第三确定模块804和第四确定模块805。

请求接收模块801，用于接收用户针对目标应用的目标菜单的访问请求，其中，所述访问请求中携带有所述用户的用户标识和所述目标应用的版本标识，所述目标应用包括本次灰度发布的灰度版本和所述灰度版本依赖的基础版本。

第一确定模块802，用于基于所述用户的用户标识确定所述用户的角色标识，并基于所述目标应用的版本标识确定所述目标应用的版本。

第二确定模块803，用于当所述目标应用的版本为所述灰度版本时，基于预先配置的灰度角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限，其中，所述灰度角色表中存储有所述灰度版本的版本标识和允许访问所述灰度版本的所述目标应用的用户角色的角色标识。

第三确定模块804，用于当所述目标应用的版本为所述基础版本时，基于预先配置的基础角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限，其中，所述基础角色表中存储有所述基础版本的版本标识和允许访问所述基础版本的所述目标应用的用户角色的角色标识。

第四确定模块805，用于当所述用户具备访问所述目标应用的权限时，基于预先配置的角色菜单关系表和所述角色标识，确定所述用户是否具备访问所述目标菜单的权限，其中，所述角色菜单关系表中存储有所述目标应用的菜单的标识和允许访问该菜单的用户角色的角色标识。

本申请实施例提供的一种灰度发布中的用户权限管理装置，由于预先配置了灰度角色表、基础角色表以及角色菜单关系表，且基于预先配置的这些表即可实现灰度发布中用户访问目标应用的菜单的权限管理，因此，采用一套用户权限管理系统即可实现多个灰度版本目标应用的用户访问权限管理，无需配置多套权限管理系统，不存在用户权限管理系统冗余和复杂的问题。

可选地，图8所示的装置还可以包括：放行模块和拦截模块。其中，放行模块，用于允许所述用户访问所述目标菜单。拦截模块，用于拦截所述用户访问对所述目标菜单的访问。

可选地，图8所示的装置还可以包括：第一配置响应模块，用于在接收用户针对目标应用的目标菜单的访问请求前，响应于第一配置请求，以完成所述灰度角色表、所述基础角色表和所述角色菜单关系表的配置。

可选地，图8所示的装置还可以包括：第二配置响应模块，用于在接收用户针对目标应用的目标菜单的访问请求前，响应于第二配置请求，以完成所述目标应用的版本维护表的配置，其中，所述版本维护表中存储有所述灰度版本和所述基础版本的版本标识。相应的，第一确定模块802，可用于基于所述目标应用的版本标识和所述版本维护表，确定所述目标应用的版本。

可选地，图8所示的装置还可以包括：第三配置响应模块，用于在接收用户针对目标应用的目标菜单的访问请求前，响应于第三配置请求，以完成用户标识角色表的配置，其中，所述用户标识角色表中存储有用户标识和角色标识的对应关系。相应的，第一确定模块802，可用于基于所述用户的用户标识和所述用户标识角色表，确定所述用户的角色标识。

可选地，图8所示的装置还可以包括：第四配置响应模块，用于在接收用户针对目标应用的目标菜单的访问请求前，响应于第四配置请求，以完成所述目标应用的基础菜单表和灰度菜单表的配置，其中，所述基础菜单表存储有所述基础版本的所述目标应用的菜单信息，所述灰度菜单表中存储有所述灰度版本的所述目标应用相对于所述基础版本的所述目标应用发生变化的菜单信息；第一菜单信息获取模块，用于当所述目标应用的版本为所述灰度版本时，通过查询所述基础菜单表和所述灰度菜单表获取所述目标菜单的信息；第二菜单信息获取模块，用于当所述目标应用的版本为所述基础版本时，通过查询所述基础菜单表获取所述目标菜单的信息。

需要说明的是，由于装置实施例执行的内容与方法实施例类似，因此，本文对装置实施例部分描述的较为简略，相关之处请参见方法实施例部分。

图9示出了是本申请实施例提供的一种电子设备的结构示意图。请参考图9，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成灰度发布中的用户权限管理装置。处理器，执行存储器所存放的程序，并具体用于执行本申请实施例提供的灰度发布中的用户权限管理方法。

上述如本申请图7所示实施例揭示的灰度发布中的用户权限管理装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(CentralProcessing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific IntegratedCircuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图9所示实施例中灰度发布中的用户权限管理装置执行的方法，并具体用于执行本申请实施例提供的灰度发布中的用户权限管理方法。

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

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

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

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

需要说明的是，本申请中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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

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

Claims (12)

1.一种灰度发布中的用户权限管理方法，其特征在于，所述方法包括：

接收用户针对目标应用的目标菜单的访问请求，其中，所述访问请求中携带有所述用户的用户标识和所述目标应用的版本标识，所述目标应用包括本次灰度发布的灰度版本和所述灰度版本依赖的基础版本；

基于所述用户的用户标识确定所述用户的角色标识，并基于所述目标应用的版本标识确定所述目标应用的版本；

当所述目标应用的版本为所述灰度版本时，基于预先配置的灰度角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限，其中，所述灰度角色表中存储有所述灰度版本的版本标识和允许访问所述灰度版本的所述目标应用的用户角色的角色标识；

当所述目标应用的版本为所述基础版本时，基于预先配置的基础角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限，其中，所述基础角色表中存储有所述基础版本的版本标识和允许访问所述基础版本的所述目标应用的用户角色的角色标识；

当所述用户具备访问所述目标应用的权限时，基于预先配置的角色菜单关系表和所述角色标识，确定所述用户是否具备访问所述目标菜单的权限，其中，所述角色菜单关系表中存储有所述目标应用的菜单的标识和允许访问该菜单的用户角色的角色标识。

2.根据权利要求1所述的方法，其特征在于，在接收用户针对目标应用的目标菜单的访问请求前，所述方法还包括：

响应于第一配置请求，以完成所述灰度角色表、所述基础角色表和所述角色菜单关系表的配置。

3.根据权利要求1所述的方法，其特征在于，在接收用户针对目标应用的目标菜单的访问请求前，所述方法还包括：

响应于第二配置请求，以完成所述目标应用的版本维护表的配置，其中，所述版本维护表中存储有所述灰度版本和所述基础版本的版本标识；

其中，所述基于所述目标应用的版本标识确定所述目标应用的版本，包括：

基于所述目标应用的版本标识和所述版本维护表，确定所述目标应用的版本。

4.根据权利要求1所述的方法，其特征在于，在接收用户针对目标应用的目标菜单的访问请求前，所述方法还包括：

响应于第三配置请求，以完成用户标识角色表的配置，其中，所述用户标识角色表中存储有用户标识和角色标识的对应关系；

其中，所述基于所述用户的用户标识确定所述用户的角色标识，包括：

基于所述用户的用户标识和所述用户标识角色表，确定所述用户的角色标识。

5.根据权利要求1-4任一项所述的方法，其特征在于，在接收用户针对目标应用的目标菜单的访问请求前，所述方法还包括：

响应于第四配置请求，以完成所述目标应用的基础菜单表和灰度菜单表的配置，其中，所述基础菜单表存储有所述基础版本的所述目标应用的菜单信息，所述灰度菜单表中存储有所述灰度版本的所述目标应用相对于所述基础版本的所述目标应用发生变化的菜单信息；

在确定所述用户具备访问所述目标菜单的权限后，所述方法还包括：

当所述目标应用的版本为所述灰度版本时，通过查询所述基础菜单表和所述灰度菜单表获取所述目标菜单的信息；

当所述目标应用的版本为所述基础版本时，通过查询所述基础菜单表获取所述目标菜单的信息。

6.一种灰度发布中的用户权限管理装置，其特征在于，所述装置包括：

请求接收模块，用于接收用户针对目标应用的目标菜单的访问请求，其中，所述访问请求中携带有所述用户的用户标识和所述目标应用的版本标识，所述目标应用包括本次灰度发布的灰度版本和所述灰度版本依赖的基础版本；

第一确定模块，用于基于所述用户的用户标识确定所述用户的角色标识，并基于所述目标应用的版本标识确定所述目标应用的版本；

第二确定模块，用于当所述目标应用的版本为所述灰度版本时，基于预先配置的灰度角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限，其中，所述灰度角色表中存储有所述灰度版本的版本标识和允许访问所述灰度版本的所述目标应用的用户角色的角色标识；

第三确定模块，用于当所述目标应用的版本为所述基础版本时，基于预先配置的基础角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限，其中，所述基础角色表中存储有所述基础版本的版本标识和允许访问所述基础版本的所述目标应用的用户角色的角色标识；

第四确定模块，用于当所述用户具备访问所述目标应用的权限时，基于预先配置的角色菜单关系表和所述角色标识，确定所述用户是否具备访问所述目标菜单的权限，其中，所述角色菜单关系表中存储有所述目标应用的菜单的标识和允许访问该菜单的用户角色的角色标识。

7.根据权利要求6所述的装置，其特征在于，所述装置还包括：

第一配置响应模块，用于在接收用户针对目标应用的目标菜单的访问请求前，响应于第一配置请求，以完成所述灰度角色表、所述基础角色表和所述角色菜单关系表的配置。

8.根据权利要求6所述的装置，其特征在于，所述装置还包括：

第二配置响应模块，用于在接收用户针对目标应用的目标菜单的访问请求前，响应于第二配置请求，以完成所述目标应用的版本维护表的配置，其中，所述版本维护表中存储有所述灰度版本和所述基础版本的版本标识；

其中，所述第一确定模块，用于基于所述目标应用的版本标识和所述版本维护表，确定所述目标应用的版本。

9.根据权利要求6所述的装置，其特征在于，所述装置还包括：

第三配置响应模块，用于在接收用户针对目标应用的目标菜单的访问请求前，响应于第三配置请求，以完成用户标识角色表的配置，其中，所述用户标识角色表中存储有用户标识和角色标识的对应关系；

其中，所述第一确定模块，用于基于所述用户的用户标识和所述用户标识角色表，确定所述用户的角色标识。

10.根据权利要求6-9任一项所述的装置，其特征在于，所述装置还包括：

第四配置响应模块，用于在接收用户针对目标应用的目标菜单的访问请求前，响应于第四配置请求，以完成所述目标应用的基础菜单表和灰度菜单表的配置，其中，所述基础菜单表存储有所述基础版本的所述目标应用的菜单信息，所述灰度菜单表中存储有所述灰度版本的所述目标应用相对于所述基础版本的所述目标应用发生变化的菜单信息；

第一菜单信息获取模块，用于当所述目标应用的版本为所述灰度版本时，通过查询所述基础菜单表和所述灰度菜单表获取所述目标菜单的信息；

第二菜单信息获取模块，用于当所述目标应用的版本为所述基础版本时，通过查询所述基础菜单表获取所述目标菜单的信息。

11.一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：

接收用户针对目标应用的目标菜单的访问请求，其中，所述访问请求中携带有所述用户的用户标识和所述目标应用的版本标识，所述目标应用包括本次灰度发布的灰度版本和所述灰度版本依赖的基础版本；

基于所述用户的用户标识确定所述用户的角色标识，并基于所述目标应用的版本标识确定所述目标应用的版本；

当所述目标应用的版本为所述灰度版本时，基于预先配置的灰度角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限，其中，所述灰度角色表中存储有所述灰度版本的版本标识和允许访问所述灰度版本的所述目标应用的用户角色的角色标识；

当所述目标应用的版本为所述基础版本时，基于预先配置的基础角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限，其中，所述基础角色表中存储有所述基础版本的版本标识和允许访问所述基础版本的所述目标应用的用户角色的角色标识；

当所述用户具备访问所述目标应用的权限时，基于预先配置的角色菜单关系表和所述角色标识，确定所述用户是否具备访问所述目标菜单的权限，其中，所述角色菜单关系表中存储有所述目标应用的菜单的标识和允许访问该菜单的用户角色的角色标识。

12.一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下操作：

接收用户针对目标应用的目标菜单的访问请求，其中，所述访问请求中携带有所述用户的用户标识和所述目标应用的版本标识，所述目标应用包括本次灰度发布的灰度版本和所述灰度版本依赖的基础版本；

基于所述用户的用户标识确定所述用户的角色标识，并基于所述目标应用的版本标识确定所述目标应用的版本；

当所述目标应用的版本为所述灰度版本时，基于预先配置的灰度角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限，其中，所述灰度角色表中存储有所述灰度版本的版本标识和允许访问所述灰度版本的所述目标应用的用户角色的角色标识；

当所述目标应用的版本为所述基础版本时，基于预先配置的基础角色表和所述角色标识，确定所述用户是否具备访问所述目标应用的权限，其中，所述基础角色表中存储有所述基础版本的版本标识和允许访问所述基础版本的所述目标应用的用户角色的角色标识；

当所述用户具备访问所述目标应用的权限时，基于预先配置的角色菜单关系表和所述角色标识，确定所述用户是否具备访问所述目标菜单的权限，其中，所述角色菜单关系表中存储有所述目标应用的菜单的标识和允许访问该菜单的用户角色的角色标识。

Images