基于用户权限的业务处理方法、系统及电子设备和介质

摘要

本申请公开了一种基于用户权限的业务处理方法、系统及电子设备和介质，方法包括：获取当前登录用户的当前职责类型；职责类型为根据用户角色类型和数据访问维度预先为当前登录用户分配的职责，用户角色类型用于定义功能模块使用权限和功能模块操作权限；根据当前职责类型，向权限中心服务获取对应的当前权限信息；接收到当前登录用户通过用户终端发起的业务操作后，根据当前权限信息判断是否允许对业务操作进行响应。本申请通过增加职责、用户角色的权限管理维度，提供精细化的权限管理方式，满足用户具备不同职责类型时的权限控制需求，提高了系统整体的安全性。利用权限中心服务现权限信息共享，避免各系统重复建设权限中心导致的资源浪费问题。

说明书

技术领域

本申请涉及权限管理技术领域，更具体地说，涉及一种基于用户权限的业务处理方法、系统及一种电子设备和一种计算机可读存储介质。

背景技术

随着现代社会的信息化发展，公司普遍存在使用一个或多个信息化系统的情况，一方面系统均有权限控制需求，另一方面，公司不同部门不同职位的人员对权限也有不同的要求。例如，若为每个系统单独设置一套权限体系，则当入职一位新人或人员岗位存在调动时，人资或信息化部门同事需要进入多个系统进行设置，工作量大、出错概率高、系统数据的管控难度大。又例如，若职工A为采购主管，其可导出所有供应商的信息，职工B为采购专员，其仅具备新增采购订单的权限，若不做权限设置，职工B也可导出所有供应商的信息，则可能存在数据泄露的安全隐患。

由于公司可能涉及多个不同部门，不同的部门具备不同的权限，如研发部门可以有项目立项的功能权限，但人资部门无项目立项的功能权限。而同一个部门内，不同岗位人员也有着不同的权限要求，如采购主管与采购专员，采购主管可以查看采购部门所有人员的系统操作数据，不同采购专员的权限控制可能也不同。为此，如何进行统一精细化的权限设置，以供业务管控使用是本领域技术人员需要解决的问题。

发明内容

本申请的目的在于提供一种基于用户权限的业务处理方法、系统及一种电子设备和一种计算机可读存储介质，能够提供统一精细化的权限管理方式。

为实现上述目的，本申请提供了一种基于用户权限的业务处理方法，包括：

获取当前登录用户的当前职责类型；所述职责类型为根据用户角色类型和数据访问维度预先为所述当前登录用户分配的职责，所述用户角色类型用于定义功能模块使用权限和功能模块操作权限；

根据所述当前职责类型，向权限中心服务获取对应的当前权限信息；

当接收到所述当前登录用户通过用户终端发起的业务操作后，根据所述当前权限信息判断是否允许对所述业务操作进行响应。

可选的，还包括：

接收所述用户终端发起的职责切换请求，获取为所述当前登录用户预先分配的所有职责类型；

将所述所有职责类型通过可视化界面进行显示，以接收所述用户终端针对目标职责类型下发的选择指令；

根据所述目标职责类型，向所述权限中心服务获取对应的目标权限信息，以便后续根据所述目标权限信息进行业务操作的响应控制或禁止控制。

可选的，所述权限中心服务用于保存预先配置的所有权限信息，所述权限信息的配置过程包括：

通过可视化界面对所有功能模块、针对功能模块的具体操作类型以及所有数据访问维度进行显示；

获取针对所述功能模块和所述具体操作类型的选择指令，根据所述功能模块和所述具体操作类型的不同组合方式生成对应不同的用户角色类型；

获取针对所述用户角色类型和所述数据访问维度的选择指令，根据所述用户角色类型和所述数据访问维度的不同组合方式生成对应不同的职责类型；

根据业务需求为已注册用户分配所述职责类型，以使用户具备所述职责类型对应的功能模块使用权限、功能模块操作权限以及数据访问权限。

可选的，还包括：

生成用户角色类型列表和职责类型列表；

接收针对所述用户角色类型列表和/或所述职责类型列表的更新指令，以根据所述更新指令进行新增/删除/修改操作。

可选的，所述当接收到所述当前登录用户通过用户终端发起的业务操作后，根据所述当前权限信息判断是否允许对所述业务操作进行响应，包括：

当接收到所述当前登录用户通过用户终端发起的业务操作后，判断当前所述业务操作是否处于所述当前权限信息允许的范围内；

如果是，则允许对所述业务操作进行响应；

如果否，则返回权限不足的提示信息，并记录所述当前登录用户的非法次数，在所述非法次数大于预设阈值后生成告警信息并发送至管理终端。

可选的，所述根据所述当前职责类型，向权限中心服务获取对应的当前权限信息之后，还包括：

根据所述当前权限信息，确定第一类信息和第二类信息；其中，所述第一类信息包括所述当前登录用户在所述当前职责类型下允许访问的功能模块和数据库、允许执行的操作类型，所述第二类信息包括所述当前登录用户在所述当前职责类型下禁止访问的功能模块和数据库、禁止执行的操作类型；

在可视化界面对所述第一类信息进行显示，对所述第二类信息进行隐藏处理或灰化处理。

为实现上述目的，本申请提供了一种基于用户权限的业务处理系统，包括：

职责类型获取模块，用于获取当前登录用户的当前职责类型；所述职责类型为根据用户角色类型和数据访问维度预先为所述当前登录用户分配的职责，所述用户角色类型用于定义功能模块使用权限和功能模块操作权限；

权限信息获取模块，用于根据所述当前职责类型，向权限中心服务获取对应的当前权限信息；

业务操作控制模块，用于当接收到所述当前登录用户通过用户终端发起的业务操作后，根据所述当前权限信息判断是否允许对所述业务操作进行响应。

可选的，所述权限中心服务用于保存预先配置的所有权限信息，所述权限信息的配置系统包括：

显示模块，用于通过可视化界面对所有功能模块、针对功能模块的具体操作类型以及所有数据访问维度进行显示；

角色类型生成模块，用于获取针对所述功能模块和所述具体操作类型的选择指令，根据所述功能模块和所述具体操作类型的不同组合方式生成对应不同的用户角色类型；

职责类型生成模块，用于获取针对所述用户角色类型和所述数据访问维度的选择指令，根据所述用户角色类型和所述数据访问维度的不同组合方式生成对应不同的职责类型；

职责类型分配模块，用于根据业务需求为已注册用户分配所述职责类型，以使用户具备所述职责类型对应的功能模块使用权限、功能模块操作权限以及数据访问权限。

为实现上述目的，本申请提供了一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现前述公开的任一种基于用户权限的业务处理方法的步骤。

为实现上述目的，本申请提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现前述公开的任一种基于用户权限的业务处理方法的步骤。

通过以上方案可知，本申请提供的一种基于用户权限的业务处理方法，包括：获取当前登录用户的当前职责类型；所述职责类型为根据用户角色类型和数据访问维度预先为所述当前登录用户分配的职责，所述用户角色类型用于定义功能模块使用权限和功能模块操作权限；根据所述当前职责类型，向权限中心服务获取对应的当前权限信息；当接收到所述当前登录用户通过用户终端发起的业务操作后，根据所述当前权限信息判断是否允许对所述业务操作进行响应。

由上可知，本申请可预先根据用户角色类型和数据访问维度为用户分配职责类型，其中，用户角色类型用于定义功能模块使用权限和功能模块操作权限，也即，将职责类型分配至用户，用户即可具备对应的功能模块使用权限、功能模块操作权限和数据访问权限，当用户登录后，可以根据当前职责类型向权限中心服务请求对应的权限信息，以便根据权限信息进行业务操作管控。通过增加职责类型、用户角色类型的权限管理维度，能够提供更加精细化的权限管理方式，可满足一个用户具备不同职责类型时的权限控制需求，并提高了系统整体的安全性。另外，可向权限中心服务请求权限信息，利用权限中心服务进行统一的权限信息管控，实现权限信息共享，避免各系统重复建设权限中心导致的资源浪费问题。

本申请还公开了一种基于用户权限的业务处理系统及一种电子设备和一种计算机可读存储介质，同样能实现上述技术效果。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请。

附图说明

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

图1为本申请实施例公开的一种基于用户权限的业务处理方法的流程图；

图2为本申请实施例公开的另一种基于用户权限的业务处理方法的流程图；

图3为本申请实施例公开的权限信息配置过程的流程图；

图4为本申请实施例公开的权限模型层级关系示意图；

图5为本申请实施例公开的一种基于用户权限的业务处理系统的结构图；

图6为本申请实施例公开的一种电子设备的结构图；

图7为本申请实施例公开的另一种电子设备的结构图。

具体实施方式

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

参见图1所示，本申请实施例公开的一种基于用户权限的业务处理方法包括：

S101：获取当前登录用户的当前职责类型；所述职责类型为根据用户角色类型和数据访问维度预先为所述当前登录用户分配的职责，所述用户角色类型用于定义功能模块使用权限和功能模块操作权限；

本申请实施例中，用户可通过终端登录业务系统。当用户登录后，系统可获取当前登录用户所选择的当前职责类型。具体地，可由用户角色类型和数据访问维度的不同组合方式组合得到不同的职责类型，并可由功能模块使用权限和功能模块操作权限的不同组合方式组合得到不同的用户角色类型。

可以理解的是，本申请实施例将功能模块使用权限、功能模块操作权限和数据访问维度对应的不同数据访问权限作为最底层的权限层级。考虑到虽然每一个用户不同，但多个用户可能会拥有相同的操作权限和使用权限，本实施例通过功能模块使用权限和功能模块操作权限进行自由组合生成多种用户角色类型。考虑到虽然每一个用户不同，但多个用户可能会拥有相同的操作权限、使用权限和数据访问权限，本实施例通过用户角色类型和数据访问维度进行自由组合生成多种职责类型。由此，通过新增两个层级的权限管理维度，即用户角色类型和职责类型，适用于多个用户具有相同权限时的权限分配场景，可以直接将生成好的职责类型分配给用户，无需为每个用户从最底层的权限层级中选择权限进行分配。

作为一种可行的实施方式，上述职责类型可以通过不同的标识字段或标识号进行表示，因此可通过获取当前登录用户的登录状态信息中对应的标识字段或标识号等识别当前登录用户的当前职责类型。

S102：根据所述当前职责类型，向权限中心服务获取对应的当前权限信息；

当确定当前登录用户的当前职责类型之后，即可向权限中心服务发起信息获取请求，以获取对应的当前权限信息。本步骤中，可以根据当前职责类型对应的标识号或标识字段在权限中心服务中读取对应的权限信息。

上述权限中心服务具体用于保存预先配置的所有权限信息，即每种职责类型所具备的权限。优选的，权限中心服务可采用无状态化的缓存管理技术提供服务，从而满足快速获取权限信息，以实现提升系统访问速度的高性能要求。

S103：当接收到所述当前登录用户通过用户终端发起的业务操作后，根据所述当前权限信息判断是否允许对所述业务操作进行响应。

在具体实施中，当读取到当前用户职责类型对应的权限信息之后，即可对后续业务操作进行相应的管控。具体地，当接收到当前登录用户通过用户终端发起的业务操作后，即可通过当前权限信息判断当前业务操作是否处于当前权限信息允许的范围内。如果是，则允许对当前业务操作进行响应；如果否，则禁止对当前业务操作进行响应。

可以理解的是，本实施例在判定当前业务操作不属于当前权限信息允许的范围内后，除了禁止响应之外，还可返回权限不足的提示信息，并记录当前登录用户的非法次数，在非法次数大于预设阈值后可生成告警信息并发送至管理终端。由此，可以方便管理终端管理非法用户，以进一步提升系统的安全性。其中，上述预设阈值可以在具体实施中根据实际情况进行设定，本实施例不对其数值进行限定。

作为一种优选的实施方式，本申请实施例还可以在根据当前职责类型向权限中心服务获取对应的当前权限信息之后，直接对当前用户无法访问的模块或数据等进行处理，以避免用户发起权限不允许的操作。具体地，可根据当前权限信息，确定第一类信息和第二类信息。其中，第一类信息包括当前登录用户在所述当前职责类型下允许访问的功能模块和数据库、允许执行的操作类型，第二类信息包括当前登录用户在当前职责类型下禁止访问的功能模块和数据库、禁止执行的操作类型。进而在可视化界面对第一类信息进行显示，对第二类信息进行隐藏处理或灰化处理，由此，可直接避免用户发起权限外的业务操作。

由上可知，本申请可预先根据用户角色类型和数据访问维度为用户分配职责类型，其中，用户角色类型用于定义功能模块使用权限和功能模块操作权限，也即，将职责类型分配至用户，用户即可具备对应的功能模块使用权限、功能模块操作权限和数据访问权限，当用户登录后，可以根据当前职责类型向权限中心服务请求对应的权限信息，以便根据权限信息进行业务操作管控。通过增加职责类型、用户角色类型的权限管理维度，能够提供更加精细化的权限管理方式，可满足一个用户具备不同职责类型时的权限控制需求，并提高了系统整体的安全性。另外，可向权限中心服务请求权限信息，利用权限中心服务进行统一的权限信息管控，实现权限信息共享，避免各系统重复建设权限中心导致的资源浪费问题。

本申请实施例公开了另一种基于用户权限的业务处理方法，相对于上一实施例，本实施例对技术方案作了进一步的说明和优化。参见图2所示，具体的：

S201：接收所述用户终端发起的职责切换请求，获取为所述当前登录用户预先分配的所有职责类型；

S202：将所述所有职责类型通过可视化界面进行显示，以接收所述用户终端针对目标职责类型下发的选择指令；

本申请实施例中，考虑到一个用户可以具备多种职责类型，可预先根据其岗位要求为用户分配不同的指责类型。用户在使用业务系统时，可快速切换不同的职责类型进行业务处理，实现在不同工作场景中拥有不同系统权限的要求。

具体地，可通过系统接收用户终端发起的职责切换请求，即可获取预先为当前登录用户分配的所有职责类型。进而可通过可视化界面显示所有职责类型，用户可针对其中的目标职责类型下发选择指令，即完成职责类型的切换。

S203：根据所述目标职责类型，向所述权限中心服务获取对应的目标权限信息，以便后续根据所述目标权限信息进行业务操作的响应控制或禁止控制。

当用户终端切换职责类型之后，即可根据新的目标职责类型重新向权限中心服务请求新的权限信息，后续即可根据目标职责类型对应的权限信息控制用户的业务处理过程。

下面对本申请实施例中权限信息的配置过程进行介绍，具体地，参见图3所示，可包括：

S301：通过可视化界面对所有功能模块、针对功能模块的具体操作类型以及所有数据访问维度进行显示；

本申请实施例中，在管理员进行权限配置时，系统可通过可视化界面显示系统中的所有功能模块、针对功能模块的具体操作类型，以及所有的数据访问维度。

S302：获取针对所述功能模块和所述具体操作类型的选择指令，根据所述功能模块和所述具体操作类型的不同组合方式生成对应不同的用户角色类型；

可以理解的是，管理员可根据功能模块和具体操作类型的不同组合方式，勾选相应的功能模块和具体操作类型，组合生成对应的不同用户角色类型，每个用户角色类型具备自身对应的功能模块使用权限和功能模块操作权限。

S303：获取针对所述用户角色类型和所述数据访问维度的选择指令，根据所述用户角色类型和所述数据访问维度的不同组合方式生成对应不同的职责类型；

在组合生成用户角色类型之后，管理员可根据用户角色类型和数据访问维度的不同组合方式，勾选相应的用户角色类型和数据访问维度，以组合生成不同的职责类型，每种职责类型具备自身对应的功能模块使用权限、功能模块操作权限和数据访问权限。

S304：根据业务需求为已注册用户分配所述职责类型，以使用户具备所述职责类型对应的功能模块使用权限、功能模块操作权限以及数据访问权限。

当生成职责类型之后，管理员可根据实际的业务需求和岗位要求，为系统中的已注册用户分配职责类型，用户即可具备相应的功能模块使用权限、功能模块操作权限以及数据访问权限。

作为一种可行的实施方式，本申请实施例还可在生成不同的用户角色类型以及生成不同的职责类型之后，对应生成用户角色类型列表和职责类型列表。其中，用户角色类型列表和职责类型列表中可具体保存类型名称和对应的权限。管理员可以对用户角色类型列表和职责类型列表进行更新。具体地，系统可接收管理员下发的针对用户角色类型列表和/或职责类型列表的更新指令，即可根据更新指令对列表进行新增/删除/修改操作。

下面通过一种具体的实施场景对本申请实施例提供的基于用户权限的业务处理方法进行介绍。参见图4所示，本实施例主要定义了资源、功能、角色、Profile、职责和用户六个模型，形成了四级权限层级。其中，资源模型中具体定义用户可以使用的系统功能模块中的具体操作权限，功能模型中具体定义用户可以使用的系统功能模块权限，Profile模型中具体定义用户可以查询到的数据权限。

在权限设置系统的最底层可将系统权限分为功能权限、资源权限、数据权限。考虑到虽然每一个用户是不同的，但多个用户可以拥有相同的操作和功能模块访问权限，在分配给每一个用户具体权限前，增加一个由功能和资源组合生成的角色权限模型。进一步地，考虑到多个用户可以拥有一样的操作、功能模块访问、数据访问权限，在分配给每一个用户具体权限前，增加一个由角色和Profile组合生成的职责权限模型。进而，即可将职责分配给用户，每个用户将拥有自己的操作、功能和数据访问权限。

下面分别对上述六种权限模型进行举例说明。如下表1为一种资源模型的部分示例，资源模型可具体定义新增、删除、导出、查询、静态的页面展示等同一个功能模块的不同操作与逻辑控制。

表1

表2为一种功能模型的部分示例，功能模型具体定义用户所拥有的固定资产管理、市场活动管理、会议室管理、质量投诉管理等不同功能模块。

表2

表3为一种角色模型的部分示例，角色模型具体定义员工可以操作哪些功能与资源。如职能员工角色，包含固定资产管理的新增、查询，会议室管理的新增、查询的功能和资源；职能主管角色，固定资产管理的新增、查询、导出、删除，会议室管理的新增、查询、导出、删除的功能和资源；业务员工角色，包含市场活动的新增、查询的功能和资源；业务主管角色，包含市场活动的新增、查询、报表展示的功能和资源。

表3

表4为一种Profile模型的部分示例，Profile模型具体定义特定的数据管理维度，比如渠道、库存组织、财务科目组等管理维度的切分，主要用于数据范围的管控。Profile可以是单个值，也可以对应多个值，可以具体通过SQL或接口的方式进行配置以加入新的管理维度。

表4

表5为一种职责模型的部分示例，职责模型具体结合角色和Profile信息进行设置，以定义不同的职责，可实现不同人员对功能模块、操作、数据权限的区分。

表5

表6为一种用户模型的部分示例，用于模型具体定义人员账号与用户类型等信息，并将职责分配给用户。

表6

本申请实施例中，在配置好用户权限之后，可以通过无状态化技术存放至权限中心服务，各个前端应用均可通过调取权限中心服务完成权限的认证及获取，在服务中心化架构的基础上实现高性能的权限管控。

另外，本申请实施例还可通过代码定义，将业务和权限管控进行分离，即先进行权限认证，再执行具体的业务逻辑，使得各部分的耦合度降低，提高了程序的可重用性。

下面对本申请实施例提供的一种基于用户权限的业务处理系统进行介绍，下文描述的一种基于用户权限的业务处理系统与上文描述的一种基于用户权限的业务处理方法可以相互参照。

参见图5所示，本申请实施例提供的一种基于用户权限的业务处理系统包括：

职责类型获取模块401，用于获取当前登录用户的当前职责类型；所述职责类型为根据用户角色类型和数据访问维度预先为所述当前登录用户分配的职责，所述用户角色类型用于定义功能模块使用权限和功能模块操作权限；

权限信息获取模块402，用于根据所述当前职责类型，向权限中心服务获取对应的当前权限信息；

业务操作控制模块403，用于当接收到所述当前登录用户通过用户终端发起的业务操作后，根据所述当前权限信息判断是否允许对所述业务操作进行响应。

关于上述模块401至403的具体实施过程可参考前述实施例公开的相应内容，在此不再进行赘述。

在上述实施例的基础上，作为一种优选实施方式，所述权限中心服务用于保存预先配置的所有权限信息，所述权限信息的配置系统包括：

显示模块，用于通过可视化界面对所有功能模块、针对功能模块的具体操作类型以及所有数据访问维度进行显示；

角色类型生成模块，用于获取针对所述功能模块和所述具体操作类型的选择指令，根据所述功能模块和所述具体操作类型的不同组合方式生成对应不同的用户角色类型；

职责类型生成模块，用于获取针对所述用户角色类型和所述数据访问维度的选择指令，根据所述用户角色类型和所述数据访问维度的不同组合方式生成对应不同的职责类型；

职责类型分配模块，用于根据业务需求为已注册用户分配所述职责类型，以使用户具备所述职责类型对应的功能模块使用权限、功能模块操作权限以及数据访问权限。

本申请还提供了一种电子设备，参见图6所示，本申请实施例提供的一种电子设备包括：

存储器100，用于存储计算机程序；

处理器200，用于执行所述计算机程序时可以实现上述实施例所提供的步骤。

具体的，存储器100包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机可读指令，该内存储器为非易失性存储介质中的操作系统和计算机可读指令的运行提供环境。处理器200在一些实施例中可以是一中央处理器(CentralProcessing Unit，CPU)、控制器、微控制器、微处理器或其他数据处理芯片，为电子设备提供计算和控制能力，执行所述存储器100中保存的计算机程序时，可以实现前述任一实施例公开的基于用户权限的业务处理方法。

在上述实施例的基础上，作为优选实施方式，参见图7所示，所述电子设备还包括：

输入接口300，与处理器200相连，用于获取外部导入的计算机程序、参数和指令，经处理器200控制保存至存储器100中。该输入接口300可以与输入装置相连，接收用户手动输入的参数或指令。该输入装置可以是显示屏上覆盖的触摸层，也可以是终端外壳上设置的按键、轨迹球或触控板，也可以是键盘、触控板或鼠标等。

显示单元400，与处理器200相连，用于显示处理器200处理的数据以及用于显示可视化的用户界面。该显示单元400可以为LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。

网络端口500，与处理器200相连，用于与外部各终端设备进行通信连接。该通信连接所采用的通信技术可以为有线通信技术或无线通信技术，如移动高清链接技术(MHL)、通用串行总线(USB)、高清多媒体接口(HDMI)、无线保真技术(WiFi)、蓝牙通信技术、低功耗蓝牙通信技术、基于IEEE802.11s的通信技术等。

图7仅示出了具有组件100-500的电子设备，本领域技术人员可以理解的是，图7示出的结构并不构成对电子设备的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。

本申请还提供了一种计算机可读存储介质，该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。该存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现前述任一实施例公开的基于用户权限的业务处理方法。

本申请通过增加职责类型、用户角色类型的权限管理维度，能够提供更加精细化的权限管理方式，可满足一个用户具备不同职责类型时的权限控制需求，并提高了系统整体的安全性。另外，可向权限中心服务请求权限信息，利用权限中心服务进行统一的权限信息管控，实现权限信息共享，避免各系统重复建设权限中心导致的资源浪费问题。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。