CN113626220A - 微服务控制方法及系统 - Google Patents

Abstract

本申请实施例涉及计算机技术领域，提供了一种微服务控制方法及系统。该微服务控制方法包括：预配置的用户与任务角色的对应关系，以及任务角色与控制权限的对应关系。进一步的，在接收第一用户对第一微服务的控制请求之后，所述第一微服务对应第一任务；确定第一用户对应第一任务的目标任务角色，第一任务与第一微服务对应。之后，确定目标任务角色对第一任务是否具备控制请求对应的控制权限；若目标任务角色对第一任务具备控制请求对应的控制权限，对第一微服务执行控制请求对应的控制操作。可见，本申请实施例的技术方案，通过用户在群组中的任务角色隔离微服务，从而进一步细化了隔离的颗粒度，进而，能够提高各个微服务中的信息的安全性。

Description

微服务控制方法及系统

技术领域

本申请实施例涉及计算机技术领域，尤其涉及一种微服务控制方法及系统。

背景技术

在服务划分场景中，单体应用程序可以被拆分为多个高内聚低耦合的小型服务，这些小型服务被称为微服务。其中，每个微服务可以独立提供服务，各个微服务之间可以采用轻量级通信机制进行通信。为了避免微服务之间相互影响，以及确保各微服务中信息的安全性，不同的微服务之间需要隔离。

一种常规的微服务隔离机制是：按照租户(tenant)将不同微服务进行隔离。其中，“租户”可以理解为根据业务场景定义的群组，该群组可以包含若干个用户，例如，公司的一个部门可以作为一个租户，该部门的若干员工即为该租户包含的用户。

通常，按照租户进行微服务隔离的场景中，该租户中每个用户均可以控制该租户对应的任一微服务。可见，这样的微服务隔离机制，隔离的颗粒度相对较大，从而使得各个微服务相互之间的影响依然较大，并且各个微服务中的信息依然存在较大的安全风险。

发明内容

本申请实施例提供了一种微服务控制方法及系统，以解决现有方法由于微服务隔离的颗粒度相对较大导致的问题。

第一方面，本申请实施例提供了一种微服务控制方法，该方法包括：

接收第一用户对第一微服务的控制请求，第一微服务对应第一任务；

根据预配置的用户与任务角色的对应关系，确定第一用户对应第一任务的目标任务角色；

根据预配置的任务角色与控制权限的对应关系，确定目标任务角色对第一任务是否具备控制请求对应的控制权限；

若目标任务角色对第一任务具备控制请求对应的控制权限，对第一微服务执行控制请求对应的控制操作。

第二方面，本申请实施例提供了一种微服务控制装置，该装置包括：

接收模块，用于接收第一用户对第一微服务的控制请求，第一微服务对应第一任务；

确定模块，用于根据预配置的用户与任务角色的对应关系，确定第一用户对应第一任务的目标任务角色；

确定模块，还用于根据预配置的任务角色与控制权限的对应关系，确定目标任务角色对第一任务是否具备控制请求对应的控制权限；

控制模块，用于若目标任务角色对第一任务具备控制请求对应的控制权限，对第一微服务执行控制请求对应的控制操作。

第三方面，本申请实施例提供了一种微服务控制系统，该微服务控制系统包括存储器和一个或多个处理器；其中，所述存储器用于存储计算机程序；当所述计算机程序被所述处理器执行时，使得微服务控制系统执行第一方面所述的微服务控制方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，该计算机存储介质中存储有指令，当所述指令在计算机上运行时，使得计算机执行第一方面所述的微服务控制方法的部分或全部步骤。

第五方面，本申请实施例提供了一种计算机程序产品，计算机程序产品中包括计算机程序代码，当计算机程序代码在计算机上运行时，使得计算机实现第一方面所述的微服务控制方法。

为解决现有方案存在的技术问题，本申请实施例预配置任务角色与控制权限的对应关系。任务角色用于指示用户在执行一项任务的群组中所执行的具体任务内容，任一项任务对应若干微服务。控制权限包括每个任务角色对相应任务所具备的控制权限，也即，每个任务角色对相应任务所对应全部微服务所具备的控制权限。进而，当接收到第一用户对第一微服务的控制请求之后，根据用户与任务角色的对应关系，确定第一用户对应第一任务的目标任务角色。之后，根据任务角色与控制权限的对应关系，确定目标任务角色对第一微服务所属的第一任务是否具备控制请求对应的控制权限，若具备，对第一微服务执行该控制请求对应的控制操作。可见，本申请实施例的技术方案，通过用户在群组中的任务角色隔离微服务，从而进一步细化了隔离的颗粒度，进而，能够提高各个微服务中的信息的安全性。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍。应理解，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的微服务控制方法100的示例性方法流程图；

图2为本申请实施例提供的微服务控制装置的示例性组成示意图；

图3为本申请实施例提供的微服务控制系统的示例性结构示意图。

具体实施方式

下面结合本申请实施例中的附图，对本申请实施例的技术方案进行描述。

本申请以下实施例中所使用的术语是为了描述特定实施例的目的，而并非旨在作为对本申请技术方案的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括复数表达形式，除非其上下文中明确地有相反指示。还应当理解，尽管在以下实施例中可能采用术语第一、第二等来描述某一类对象，但所述对象不应限于这些术语。这些术语用来将该类对象的具体实现对象进行区分。例如，以下实施例中采用术语第一、第二等来描述微服务，但微服务不限于这些术语。这些术语仅用来区分不同的微服务。以下实施例中可能采用术语第一、第二等来描述的其他类对象同理，此处不再赘述。

下面对本申请实施例涉及的技术术语进行解释。

微服务：是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块(Small Building Blocks)为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关(Language-Independent/Language agnostic)的API(ApplicationProgramming Interface，应用程序接口)集相互通信。实际实施场景中，若干个微服务相互配合可以完成一项任务，该任务可以是实现一个应用程序的完整功能等。

云容器平台：用于支撑微服务的搭建、开发、测试，以及微服务运行期的数据处理和微服务的管理监控的软件平台。

服务网格(Service Mesh)：适用于云容器平台，用于为微服务提供通信、监控、控制权限授权和信息同步等控制功能。

RBAC(Role-Based Access Control，基于角色的访问控制)：用于提供一种基于用户的角色(Role)来确定用户对应用控制权限的逻辑。其中，用户的角色包括指示用户所属的群组的角色和指示用户在所属群组中所执行的任务相关的角色，用户所属的群组例如是用户所属的部门，用户在所属群组中所执行的任务例如是用户在部门项目组中的任务。一个群组例如包括至少两个任务角色。本申请实施例中，对微服务的控制权限例如包括以下至少一项：创建权限、更新权限、删除权限、查看权限。

本申请实施例提供了一种微服务控制方法及系统，该系统中预先部署任务角色与控制权限的对应关系，进而，在搭建微服务的过程中，建立微服务与任务的对应关系，在添加用户的过程中，确定用户的任务角色。之后，若用户对一个微服务发起控制请求，该系统可以确定用户的任务角色，然后，根据相应任务角色与控制权限的对应关系，确定相应用户对于相应微服务所属任务的控制权限，进而，响应相应控制请求。可见，本申请实施例的技术方案，通过用户在群组中的任务角色隔离微服务，从而进一步细化了隔离的颗粒度，进而，能够提高各个微服务中的信息的安全性。

下面通过对示例性实施方式的描述，对本申请实施例的技术方案以及本申请的技术方案产生的技术效果进行说明。

请参考图1，图1示意了一种示例性微服务控制方法100(以下简称方法100)。本实现方式以微服务控制系统执行方法100为例进行说明，微服务控制系统例如可以基于服务网格技术执行方法100。方法100包括如下步骤：

步骤S101，接收第一用户对第一微服务的控制请求。

其中，第一用户和第一微服务是预先部署的，第一用户可以通过任务使用端向微服务控制系统发送控制第一微服务的控制请求。该任务使用端是指部署微服务以使用所部署的微服务执行某项任务的平台。第一微服务例如对应第一任务，第一用户例如是执行该第一任务中部分任务的用户。

可选的，第一任务可以对应至少两个微服务，第一微服务是该至少两个微服务中的任一微服务。第一任务与该至少两个微服务的对应关系，可以是部署微服务过程中建立的。示例性的，响应于对应第一任务创建第二微服务的指令，微服务控制系统创建第二微服务，进而，微服务控制系统通过为第二微服务添加第一任务的标识，建立第二微服务与第一任务的对应关系。任务的标识例如可以实现为appID(Application identity，应用标识)。

步骤S102，根据预配置的用户与任务角色的对应关系，确定第一用户对应第一任务的目标任务角色。

其中，任务角色是根据任务所需要的执行角色预先设定的，例如，一个项目开发任务中，需要开发人员和测试人员两种执行角色，那么，该项目开发任务包括开发人员和测试人员两类任务角色。相应的，在添加用户的过程，可以基于所添加用户待执行的具体任务内容，建立该用户与相匹配的任务角色的对应关系。例如，微服务控制系统接收添加第二用户的请求之后，若第二用户执行前述项目开发任务的开发工作，建立该第二用户与开发人员这一任务角色的对应关系，若第二用户执行前述项目开发任务的测试工作，建立该第二用户与测试人员这一任务角色的对应关系。

示例性的，任务角色和用户的对应关系采用表格的方式呈现，例如如表1所示。

表1

其中，表1示意的任务角色包括任务角色1和任务角色2，与任务角色1对应的用户包括用户A、用户C、用户D、用户E和用户G，与任务角色2对应的用户包括用户B、用户F和用户Z。即，用户A、用户C、用户D、用户E和用户G的任务角色是任务角色1，用户B、用户F和用户Z的任务角色是任务角色2。

可以理解的是，表1仅是示意性描述，对本申请实施例的技术方案不构成限制。实际实现中，一项任务可以包含更多的任务角色，且每个任务角色可以包括更多或者更少与之对应的用户。

可选的，一个用户可以参与多个任务的执行，相应的，该用户在其所参与的任务中均对应一个任务角色。一些实施方式中，该用户在各个任务中对应的任务角色均相同，另一些实施方式中，该用户在各个任务中对应的任务角色均不同或者部分不同。此处不限制。

可选的，在获得如表1所示的对应关系之后，微服务控制系统可以将该对应关系存储在数据库中，进而，在接收到来自第一用户的控制请求之后，可以基于如表1所示是对应关系，确定第一用户对应第一任务的目标任务角色。

步骤S103，根据预配置的任务角色与控制权限的对应关系，确定目标任务角色对第一任务是否具备控制请求对应的控制权限。

本申请实施例中，针对任务部署任务角色的目的在于，按照任务角色确定对任务的控制权限。基于此，在确定任务角色之后，还可以配置任务角色与控制权限的对应关系，该任务角色与控制权限的对应关系可以存储在微服务控制系统的数据库中。

需要指出的是，根据前述任务与微服务的关系，一个任务角色对应一项任务具备一种控制权限，那么，在实现过程中，该任务角色对应相应任务包含的所有微服务，均具备该控制权限。基于此，任务角色与控制权限的对应关系可以表达为，任务角色对任务的控制权限。

结合前述描述，本申请实施例中，对微服务的控制权限可以包括至少一项，例如包括以下至少一项：创建权限、更新权限、删除权限和查看权限。在实际实施场景中，为了指示各项控制权限，可以为每项控制权限设置标识。一些实施方式中，对应每一项控制权限可以设置ID(identity，身份标识)，例如，创建权限的ID是01、更新权限的ID是02、删除权限的ID是03，查看权限的ID是04。另一些实施方式中，对应每一项控制权限可以设置字符串标识，该字符串标识例如是name(名称)的缩写，例如，创建权限的字符串标识是CRE(create)、更新权限的字符串标识是UPA(update)、删除权限的字符串标识是DEL(delete)，查看权限的字符串标识是VIE(view)。其他一些实施方式中，对应每一项控制权限还可以设置ID和字符串组合的标识，例如，创建权限的标识是01-CRE、更新权限的标识是02-UPA、删除权限的标识是03-DEL，查看权限的标识是04-VIE。

进一步的，为了维护至少一个任务角色与至少一个控制权限的对应关系，微服务控制系统中可以将每个任务角色与该任务角色允许的控制权限(permission)对应存储。任务角色与控制权限对应关系的呈现方式采用表格形式表示，例如如表2所示。

表2

其中，表2示意了两个任务对应的任务角色，以及每个任务角色对应的控制权限，其中，任务1包括任务角色1、任务角色2和任务角色2，任务角色1对任务1具备创建权限和更新权限，任务角色2对任务1具备删除权限，任务角色3对任务1具备查看权限。任务2包括任务角色4和任务角色5，任务角色4对任务2具备创建权限、更新权限和删除权限，任务角色5对任务2具备查看权限。

可以理解的是，表2仅是示意性描述，对本申请实施例的技术方案不构成限制。实际实现中，每个任务角色可以对应与表2不同数量的控制权限，且每个任务角色对应的控制权限也可以不同于表2所示。

此外，虽然表2通过每个任务角色与该任务角色允许的控制权限，呈现任务角色与控制权限的对应关系，但是，本申请实施例的技术方案不限于此。另一些实施场景中，还可以通过每个任务角色与该任务角色不允许的控制权限，呈现任务角色与控制权限的对应关系。再一些实施场景中，还可以通过每个任务角色与该任务角色允许的控制权限以及不允许的控制权限，呈现任务角色与控制权限的对应关系。

进一步的，在确定第一用户对应第一任务的目标任务角色之后，微服务控制系统可以从预存储的如表2所示的对应关系中，确定目标任务角色对应的允许的控制权限中是否包含控制请求对应的控制权限，若目标任务角色对应的允许的控制权限中包含控制请求对应的控制权限，确定目标任务角色具备执行控制请求对应的控制权限，也即，第一用户具备执行控制请求对应的控制权限。若目标任务角色对应的允许的控制权限中不包含控制请求对应的控制权限，确定目标任务角色不具备执行控制请求对应的控制权限，也即，第一用户不具备执行控制请求对应的控制权限。

步骤S104，若目标任务角色对第一任务具备控制请求对应的控制权限，对第一微服务执行控制请求对应的控制操作。

其中，根据前述对任务与微服务关系的说明，若目标任务角色对第一任务具备一项控制权限，那么，该目标任务角色对第一任务对应的全部微服务具备该项控制权限。基于此，第一任务包括第一微服务，若目标任务角色对第一任务具备控制请求对应的控制权限，目标任务角色对第一微服务具备控制请求对应的控制权限。进而，微服务控制系统对第一微服务执行控制请求对应的控制操作。示例性的，微服务控制系统可以向第一用户返回第一微服务的相关数据，第一微服务的相关数据例如负载数据。

另一些实施方式中，若目标任务角色对第一任务不具备控制请求对应的控制权限，相应的，目标任务角色对第一微服务不具备控制请求对应的控制权限。进而，微服务控制系统可以向第一用户返回无控制权限的提醒信息。

需要指出的是，上述方法100中，用户、任务角色和任务均可以以标识的方式呈现，例如，用户以用户标识(user-ID)的方式呈现、任务角色以(group-ID)的方式呈现，任务以(app-ID)的方式呈现。微服务控制系统可以根据相应标识确定相应的内容。

本申请实施例的实现方式中，微服务控制系统预先维护任务角色与控制权限的对应关系。任务角色用于指示用户在执行一项任务的群组中所执行的具体任务内容，任一项任务对应若干微服务。控制权限包括每个任务角色对相应任务所具备的控制权限，也即，每个任务角色对相应任务所对应全部微服务所具备的控制权限。进而，当接收到第一用户对第一微服务的控制请求之后，根据用户与任务角色的对应关系，确定第一用户对应第一任务的目标任务角色。之后，根据任务角色与控制权限的对应关系，确定目标任务角色对第一微服务所属的第一任务是否具备控制请求对应的控制权限，若具备，对第一微服务执行该控制请求对应的控制操作。可见，本申请实施例的技术方案，通过用户在群组中的任务角色隔离微服务，从而进一步细化了隔离的颗粒度，进而，能够提高各个微服务中的信息的安全性。

以下结合示例对本申请实施例的技术方案进行说明。

以公司的一个部门为例，该部门包含多个项目组，项目组例如对应前述任务，每个项目组例如包含多个项目角色(也即前述任务角色)。示例性的，每个用户例如包括部门角色和项目角色两类，部门角色例如包括管理员和普通成员。当用户是普通成员时，用户对应一个项目角色，其中，项目角色例如包括负责人、开发人员和测试人员三类。本示例中，任务(项目组)标识例如通过app-ID表示，用户标识例如通过user-ID表示，任务角色(项目角色)例如通过group-ID表示，例如，项目角色负责人的标识是group-m，项目角色开发人员的标识是group-c和项目角色测试人员的标识是group-t，每项控制权限例如采用permissionID表示。permission ID详见前述实施例的描述，此处不详述。

在确定前述部门角色和项目角色之后，部署app-ID、group-ID和permission ID的对应关系，该对应关系的实现可以如表2所示，此处不赘述。

进一步的，可以基于云容器平台对应每个项目组部署微服务。以一个项目组为例，该项目组的app-ID例如是A00，对应该项目组可以部署多个微服务，每部署一个微服务，云容器平台可以对应相应项目组，为该服务添加标签“app-ID：A00”，以建立该微服务与项目组A00的对应关系。

需要指出的是，云容器平台还可以为该微服务添加部门名称、容器标识以及微服务版本(version)等其他标签。此处不详述。

进一步的，还可以基于云容器平台添加用户。以user-ID是Z01的用户为例，在添加user-ID：Z01之后，按照需求建立user-ID：Z01与部门角色和部门内相应项目角色的对应关系。其中，user-ID：Z01与项目角色的对应关系可以如表1所示，此处不赘述。

其中，在部署前述对应关系之后，云容器平台可以将前述对应关系均存储在数据库中。

在部署前述各个微服务以及各用户之后，云容器平台可以基于服务网格技术接收并响应各用户控制微服务的请求。本申请实施例中，将基于服务网格技术接收并响应控制请求的功能的主体，称为微服务控制系统。

示例性的，用户标识为user-ID：Z02的用户，在项目执行端登录时，项目执行端例如根据user-ID：Z02生成令牌(Token)，进而，将该令牌携带在对微服务M的更新请求中，发送到微服务控制系统。

微服务控制系统解析该更新请求，得到令牌和更新请求对应的permission ID：02，且，微服务控制系统根据微服务M的标签确定微服务M对应项目B00。

进一步的，微服务控制系统根据前述对应关系确定，user-ID：Z02在项目B00中对应的项目角色例如是group-m。进一步的，微服务控制系统根据前述对应关系确定，项目角色group-m对应的permission ID包括01、02、03和04。那么，微服务控制系统可以确定项目角色group-m对项目B00具备permission ID：02对应的控制权限，即，微服务控制系统可以确定user-ID：Z02对微服务M具备更新权限。进而，微服务控制系统响应该更新请求对微服务M执行更新操作。

当然，若user-ID：Z02在项目B00中对应的项目角色是group-t，且项目角色group-t对应的permission ID仅包括04，那么，微服务控制系统可以确定项目角色group-t对项目B00不具备permission ID：02对应的控制权限，即，微服务控制系统可以确定user-ID：Z02对微服务M不具备更新权限。进而，微服务控制系统向相应的项目执行端返回无权限的提醒信息。

综上，本申请实施例的实现方式中，微服务控制系统预先维护任务角色与控制权限的对应关系。任务角色用于指示用户在执行一项任务的群组中所执行的具体任务内容，任一项任务对应若干微服务。控制权限包括每个任务角色对相应任务所具备的控制权限，也即，每个任务角色对相应任务所对应全部微服务所具备的控制权限。进而，当接收到第一用户对第一微服务的控制请求之后，根据用户与任务角色的对应关系，确定第一用户对应第一任务的目标任务角色。之后，根据任务角色与控制权限的对应关系，确定目标任务角色对第一微服务所属的第一任务是否具备控制请求对应的控制权限，若具备，则对第一微服务执行该控制请求对应的控制操作。可见，本申请实施例的技术方案，通过用户在群组中的任务角色隔离微服务，从而进一步细化了隔离的颗粒度，进而，能够提高各个微服务中的信息的安全性。

上述实施例从第一用户对应的目标任务角色的确定、控制请求对应的控制权限的确定等设备所执行的动作的角度，对本申请实施例提供的微服务控制方法的各实施方式进行了介绍。应理解，对应第一用户对应的目标任务角色的确定、控制请求对应的控制权限的确定等的处理步骤，本申请实施例可以以硬件或硬件和计算机软件的结合形式来实现上述功能。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

例如，若上述实现步骤通过软件模块来实现相应的功能，如图2所示，本申请实施例提供了一种微服务控制装置。该微服务控制装置可以包括接收模块201、确定模块202和控制模块203。该微服务控制装置可用于执行上述方法100中的部分或全部操作。

例如：接收模块201可以用于接收第一用户对第一微服务的控制请求，第一微服务对应第一任务。确定模块202可以用于根据预配置的用户与任务角色的对应关系，确定第一用户对应第一任务的目标任务角色。确定模块202还可以用于根据预配置的任务角色与控制权限的对应关系，确定目标任务角色对第一任务是否具备控制请求对应的控制权限。控制模块203可以用于若目标任务角色对第一任务具备控制请求对应的控制权限，对第一微服务执行控制请求对应的控制操作。

由此可见，本申请实施例提供的微服务控制装置，预先维护任务角色与控制权限的对应关系。任务角色用于指示用户在执行一项任务的群组中所执行的具体任务内容，任一项任务对应若干微服务。控制权限包括每个任务角色对相应任务所具备的控制权限，也即，每个任务角色对相应任务所对应全部微服务所具备的控制权限。进而，当接收到第一用户对第一微服务的控制请求之后，根据用户与任务角色的对应关系，确定第一用户对应第一任务的目标任务角色。之后，根据任务角色与控制权限的对应关系，确定目标任务角色对第一微服务所属的第一任务是否具备控制请求对应的控制权限，若具备，则对第一微服务执行该控制请求对应的控制操作。可见，本申请实施例的技术方案，通过用户在群组中的任务角色隔离微服务，从而进一步细化了隔离的颗粒度，进而，能够提高各个微服务中的信息的安全性。

可选的，预配置的任务角色与控制权限的对应关系，包括：至少两个任务角色，以及每个任务角色对应的至少一个允许控制权限，允许控制权限指示相应任务角色具备的控制权限。

可选的，确定模块202还用于确定目标任务角色对应的至少一项允许控制权限中是否包含控制请求对应的控制权限；以及若目标任务角色对应的至少一项允许控制权限中包含控制请求对应的控制权限，确定目标任务角色具备执行控制请求对应的控制权限。

可选的，控制模块203还用于若目标任务角色对应的至少一项允许控制权限中不包含控制请求对应的控制权限，向第一用户反馈无控制权限的提示信息。

可选的，控制请求对应的控制权限是以下任一项：创建权限、更新权限、删除权限。

可选的，该微服务控制装置还包括建立模块。本实施方式中，接收模块201还用于响应于对应第一任务创建第二微服务的指令，创建第二微服务。建立模块用于通过为第二微服务添加第一任务的标识，建立第二微服务与第一任务的对应关系。

可选的，接收模块201还用于接收添加第二用户的请求，第二用户对应第一任务。建立模块还用于建立第二用户与第一任务相应任务角色的对应关系。

可以理解的是，以上各个模块/单元的划分仅仅是一种逻辑功能的划分，实际实现时，该以上各模块的功能可以集成到硬件实体实现，例如，确定模块202的功能和控制模块203的功能可以集成到处理器实现，接收模块201的功能可以集成到收发器实现，实现上述各模块功能的程序和指令，可以维护在存储器中。

如图3所示，图3示意了一种微服务控制系统，微服务控制系统可以用作前述服务器或者终端。图3所示的微服务控制系统包括：处理器4001和存储器4003。其中，处理器4001和存储器4003相连，如通过总线4002相连。可选地，微服务控制系统还可以包括收发器4004。需要说明的是，实际应用中收发器4004不限于一个，该微服务控制系统的结构并不构成对本申请实施例的限定。

处理器4001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器4001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线4002可包括一通路，在上述组件之间传送信息。总线4002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线4002可以分为地址总线、数据总线、控制总线等。为便于表示，图3中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器4003可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器4003用于存储执行本申请方案的应用程序代码，并由处理器4001来控制执行。处理器4001用于执行存储器4003中存储的应用程序代码，以实现前述方法实施例所示的内容。本申请实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有本技术方案相关的指令，当其在计算机上运行时，使得计算机执行如前述方法100所示实施例描述的方法中的部分或全部步骤。

本申请实施例中还提供一种计算机程序产品，当其在计算机上运行时，使得计算机执行如前述方法100所示实施例描述的方法中的部分或全部步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，游戏的控制装置，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。

Claims (10)

1.一种微服务控制方法，其特征在于，所述方法包括：

接收第一用户对第一微服务的控制请求，所述第一微服务对应第一任务；

根据预配置的用户与任务角色的对应关系，确定所述第一用户对应所述第一任务的目标任务角色；

根据预配置的任务角色与控制权限的对应关系，确定所述目标任务角色对所述第一任务是否具备所述控制请求对应的控制权限；

若所述目标任务角色对所述第一任务具备所述控制请求对应的控制权限，对所述第一微服务执行所述控制请求对应的控制操作。

2.根据权利要求1所述的方法，其特征在于，所述预配置的任务角色与控制权限的对应关系，包括：

至少两个任务角色，以及每个任务角色对应的至少一个允许控制权限，所述允许控制权限指示相应任务角色具备的控制权限。

3.根据权利要求2所述的方法，其特征在于，根据预配置的任务角色与控制权限的对应关系，确定所述目标任务角色对所述第一任务是否具备所述控制请求对应的控制权限，包括：

确定所述目标任务角色对应的至少一项允许控制权限中是否包含所述控制请求对应的控制权限；

若所述目标任务角色对应的至少一项允许控制权限中包含所述控制请求对应的控制权限，确定所述目标任务角色具备执行所述控制请求对应的控制权限。

4.根据权利要求3所述的方法，其特征在于，还包括：

若所述目标任务角色对应的至少一项允许控制权限中不包含所述控制请求对应的控制权限，向所述第一用户反馈无控制权限的提示信息。

5.根据权利要求1至4中任一项所述的方法，其特征在于，所述控制请求对应的控制权限是以下任一项：创建权限、更新权限、删除权限。

6.根据权利要求1所述的方法，其特征在于，还包括：

响应于对应所述第一任务创建第二微服务的指令，创建所述第二微服务；

通过为所述第二微服务添加所述第一任务的标识，建立所述第二微服务与所述第一任务的对应关系。

7.根据权利要求1所述的方法，其特征在于，还包括：

接收添加第二用户的请求，所述第二用户对应所述第一任务；

建立所述第二用户与所述第一任务相应任务角色的对应关系。

8.一种微服务控制装置，其特征在于，所述装置包括：

接收模块，用于接收第一用户对第一微服务的控制请求，所述第一微服务对应第一任务；

确定模块，用于根据预配置的用户与任务角色的对应关系，确定所述第一用户对应所述第一任务的目标任务角色；

所述确定模块，还用于根据预配置的任务角色与控制权限的对应关系，确定所述目标任务角色对所述第一任务是否具备所述控制请求对应的控制权限；

控制模块，用于若所述目标任务角色对所述第一任务具备所述控制请求对应的控制权限，对所述第一微服务执行所述控制请求对应的控制操作。

9.一种微服务控制系统，其特征在于，所述微服务控制系统包括存储器和一个或多个处理器；其中，所述存储器用于存储计算机程序；当所述计算机程序被所述处理器执行时，使得所述电子设备执行如权利要求1至7中任一项所述的微服务控制方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行如权利要求1至7中任一项所述的微服务控制方法。

Images