CN112804224B - 一种基于微服务的认证鉴权方法、装置、介质及电子设备 - Google Patents

Abstract

本发明实施例公开了一种基于微服务的认证鉴权方法、装置、介质及电子设备。该方法包括：若接收到业务请求，根据业务请求的请求路径，确定业务请求的认证鉴权类型；若为第一类型，则解析业务请求中的请求参数，采用认证聚合微服务对业务请求进行认证，和采用强鉴权聚合微服务对业务请求进行鉴权，得到强鉴权结果；若为第二类型，则根据业务请求中的请求参数，采用弱鉴权聚合微服务对业务请求进行鉴权，得到弱鉴权结果；对强鉴权结果或者弱鉴权结果进行聚合处理，得到与业务请求对应的业务请求结果返回至客户端。通过采用本申请所提供的技术方案，可以针对不同的业务，采用不同的认证和鉴权的逻辑，实现针对不同途径访问时都能够准确反馈的目的。

Description

一种基于微服务的认证鉴权方法、装置、介质及电子设备

技术领域

本发明实施例涉及互联网技术领域，尤其涉及一种基于微服务的认证鉴权方法、装置、介质及电子设备。

背景技术

随着科学技术的发展，用户通过不同途径访问服务器***已经是极为常见的情况。而为了应对用户通过不同途径访问时，反馈的信息的一致性的要求，现有技术的做法是将认证和鉴权强耦合在服务器***的底层架构中。这样设置的好处是可以采用固定的方式进行认证和鉴权的操作，确保了不同途径访问的情况下，信息的一致性。而问题在于，将认证和鉴权耦合来进行业务的处理，难以应对一些只需要鉴权不需要认证的业务，造成部分业务没有办法正常处理。

发明内容

本发明实施例提供一种基于微服务的认证鉴权方法、装置、介质及电子设备，可以针对不同的业务，采用不同的认证和鉴权的逻辑，实现针对不同途径访问时都能够准确反馈的目的。

第一方面，本发明实施例提供了一种基于微服务的认证鉴权方法，该方法包括：

若接收到业务请求，根据所述业务请求的请求路径，确定所述业务请求的认证鉴权类型；

若所述认证鉴权类型为第一类型，则解析所述业务请求中的请求参数，采用认证聚合微服务对所述业务请求进行认证，和采用强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果；若所述认证鉴权类型为第二类型，则根据所述业务请求中的请求参数，采用弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果；

对所述强鉴权结果或者所述弱鉴权结果进行聚合处理，得到与所述业务请求对应的业务请求结果返回至客户端。

进一步的，若接收到业务请求，根据所述业务请求的请求路径，确定所述业务请求的认证鉴权类型，包括：

若接收到业务请求，解析所述业务请求的请求参数；

根据所述请求参数确定请求路径；若所述请求路径对应认证接口，则确定所述业务请求的认证鉴权类型为第一类型；若所述请求路径对应弱鉴权接口，则确定所述业务请求的认证鉴权类型为第二类型。

进一步的，确定所述请求路径对应的认证方式，包括：

根据请求参数确定所述业务请求所对应的配置文件中的URL地址；

根据所述配置文件中的URL地址，以及与所述URL地址对应的认证方式代码，确定认证方式。

进一步的，所述方法还包括：

根据所述配置文件中的URL地址，确定与所述业务请求的URL地址对应的验证字段。

进一步的，解析所述业务请求中的请求参数，采用认证聚合微服务对所述业务请求进行认证，和采用强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果，包括：

通过网关接收所述业务请求的认证请求，并将所述认证请求转发至认证聚合微服务；

通过所述认证聚合微服务校验所述业务请求中的认证信息，若通过校验，则向客户端返回Token；其中，所述认证聚合微服务包括手机号认证、微信认证、QQ认证、小程序认证以及账号认证中的至少一种认证基础服务；

若通过网关接收所述客户端发出的业务请求中携带所述Token，则确定所述业务请求为强鉴权请求；

若验证所述Token有效，则向强鉴权聚合微服务转发所述业务请求，以使所述强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果。

进一步的，根据所述业务请求中的请求参数，采用弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果，包括：

通过网关接收所述客户端发出的业务请求中的用户信息，若所述用户信息校验通过，则将业务请求中的弱鉴权请求发送至弱鉴权聚合微服务；

通过所述弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果。

进一步的，所述方法还包括：

确定当前业务请求负载量是否达到负载门限值；

若是，则关闭认证鉴权类型为第二类型的接口。

第二方面，本发明实施例还提供了一种基于微服务的认证鉴权装置，包括：

认证鉴权类型确定模块，用于若接收到业务请求，根据所述业务请求的请求路径，确定所述业务请求的认证鉴权类型；

鉴权结果获取模块，用于若所述认证鉴权类型为第一类型，则解析所述业务请求中的请求参数，采用认证聚合微服务对所述业务请求进行认证，和采用强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果；若所述认证鉴权类型为第二类型，则根据所述业务请求中的请求参数，采用弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果；

业务处理模块，用于对所述强鉴权结果或者所述弱鉴权结果进行聚合处理，得到与所述业务请求对应的业务请求结果返回至客户端。

第三方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请实施例所述的基于微服务的认证鉴权方法。

第四方面，本申请实施例提供了一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器运行的计算机程序，所述处理器执行所述计算机程序时实现如本申请实施例所述的基于微服务的认证鉴权方法。

本申请实施例所提供的技术方案，若接收到业务请求，根据所述业务请求的请求路径，确定所述业务请求的认证鉴权类型；若所述认证鉴权类型为第一类型，则解析所述业务请求中的请求参数，采用认证聚合微服务对所述业务请求进行认证，和采用强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果；若所述认证鉴权类型为第二类型，则根据所述业务请求中的请求参数，采用弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果；对所述强鉴权结果或者所述弱鉴权结果进行聚合处理，得到与所述业务请求对应的业务请求结果返回至客户端。本申请所提供的技术方案，可以针对不同的业务，采用不同的认证和鉴权的逻辑，实现针对不同途径访问时都能够准确反馈的目的。

附图说明

图1是本发明实施例一提供的基于微服务的认证鉴权方法的流程图；

图2是本发明实施例一提供的认证服务的示意图；

图3是本发明实施例一提供的强鉴权服务的示意图；

图4是本发明实施例一提供的弱鉴权服务的示意图；

图5是本发明实施例二提供的基于微服务的认证鉴权装置的结构示意图；

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

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各步骤描述成顺序的处理，但是其中的许多步骤可以被并行地、并发地或者同时实施。此外，各步骤的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

微服务架构目前已经成为服务端主流架构，是一种新的软件架构风格。在微服务***中，所有的模块功能不再像单体应用那样，将每个单体的所有功能都集中部署在一个包内。而是由多个微服务组成，每个微服务都能独立设计、开发、部署，负责不同的业务功能，极大提高***的灵活性。但由于服务众多，基于微服务的安全访问越来越重要。

现有的认证鉴权方法中，一种是基于Session+Cookie的模式，一种是基于令牌(Token)的模式。

Session+Cookie的模式：即当一个已注册用户通过登录操作请求后，Web服务器向数据库进行校验用户名和密码，通过后就会向Session中添加一条记录，然后返回给浏览器。在返回给浏览器的报文中，会将sessionId放在Cookie里头。

基于令牌(Token)的模式：Token一般会包含用户的相关信息，通过验证Token就可以完成身份校验。Token是在认证服务端(也就是网关)产生的。如果客户端使用用户名/密码向认证服务端请求认证，认证服务端认证成功，那么认证服务端会返回用户令牌Token给客户端。客户端可以在每次业务请求的时候带上Token，通过网关进行认证鉴权，认证主要校验用户信息是否合法等。鉴权是校验Token是否有效、是否过期等。如果认证鉴权通过，则网关会把业务请求转发给底层服务进行业务处理。

Session+Cookie的模式的问题在于：用户会话绑定到某个服务器上，如果需要对这个服务器进行一些升级或改造，或者服务器延迟或宕机，那么此服务器上的一波认证用户信息就会瞬间消失，用户必须重新登录。

基于令牌(Token)的模式的问题在于：现有技术中认证和鉴权耦合在一起，即客户端调用服务端的请求时，要么是认证并鉴权，要么是不认证且不鉴权。此时实现业务服务将是非常复杂的，会出现大量冗余代码。

实施例一

图1是本发明实施例一提供的基于微服务的认证鉴权方法的流程图，本实施例可适用于对不同途径的业务请求采用不同方式进行处理的情况，该方法可以由本发明实施例所提供的基于微服务的认证鉴权装置来执行，该装置可以由软件和/或硬件的方式来实现，并可集成于服务***的电子设备中。

如图1所示，所述方法包括：

S110、若接收到业务请求，根据所述业务请求的请求路径，确定所述业务请求的认证鉴权类型。

其中，业务请求可以是客户端发出的，具体的，可以是客户端在应用程序(APP)上面发出，也可以是在客户端页面中发出，如在PC端的页面中发出业务请求，还可以是在小程序中发出或者H5原生页面发出。

本方案中，业务请求的请求路径可以包括业务请求调用的接口类型，例如，可以包括认证接口，也可以是只包括鉴权接口。可以理解的，请求路径不是仅仅只有接口能够体现，任何能够体现请求路径不同的，如调用者不同，调用对象不同等等，都可以用来区分不同的业务请求。可以根据请求路径，确定业务请求的认证鉴权类型。

本方案在，业务鉴权类型可以分为同时需要认证和鉴权的类型，即为强鉴权类型，和只需要进行鉴权的类型，即为弱鉴权类型。

本实施例中，可选的，

若接收到业务请求，根据所述业务请求的请求路径，确定所述业务请求的认证鉴权类型，包括：

若接收到业务请求，解析所述业务请求的请求参数；

根据所述请求参数确定请求路径；若所述请求路径对应认证接口，则确定所述业务请求的认证鉴权类型为第一类型；若所述请求路径对应弱鉴权接口，则确定所述业务请求的认证鉴权类型为第二类型。

其中，请求参数可以是与该业务请求相关的参数，如请求的内容，请求所需要的响应对象，以及请求所需要使用的接口，等等。在得到请求参数之后，可以根据其确定请求路径，结合前面的介绍，此处如果能够确定业务请求所需要的端口，就可以确定其请求路径。在确定请求路径之后，可以根据所需要调用接口的不同，确定为不同的认证鉴权类型。

本方案这样设置的好处是可以根据业务请求的请求参数来确定请求路径，从而确定业务请求的认证鉴权类型。通过这样的设置，可以让服务***同时兼容不同类型的认证鉴权类型，无需为强鉴权和弱鉴权分别设计不同的认证和鉴权逻辑，而是将多种鉴权方式融为一体，同时也针对不同路径发出的业务请求提供了更好的兼容性。

本方案中，可选的，

进一步的，确定所述请求路径对应的认证方式，包括：

根据请求参数确定所述业务请求所对应的配置文件中的URL地址；

根据所述配置文件中的URL地址，以及与所述URL地址对应的认证方式代码，确定认证方式。

进一步的，所述方法还包括：

根据所述配置文件中的URL地址，确定与所述业务请求的URL地址对应的验证字段。

下表为配置文件的部分示例，其中，url为地址，即发出请求的请求路径。url_filed为需要进行验证的字段，如果为空，则说明该路径不需要进行验证。gateway_type取1时，意思为存在敏感信息，例如手机号，需要在传输过程中对敏感信息进行加密处理，相应的，在取值为2时则说明不需要进行加密处理，同时也可以确定为直接进行弱鉴权即可。source_system为业务层的工程名称，可以是微服务的工程名称。

另外，下述代码提供了认证的具体调用方式：

本方案中，在得到请求参数之后，可以读取业务***中的配置文件，确定该配置文件中的接口配置项，确定与请求参数相关联的接口，从而可以根据请求参数确定业务请求的接口，实现对业务请求的接口可配置化，达到对业务请求的请求路径进行管控的目的。

上述方案中，具体的，所述方法还包括：

响应于配置文件中的接口配置项的变更操作，确定变更后的接口配置项的调用接口信息。

可以理解的，如果针对同一内容的请求，在不同的时期该内容的认证和鉴权的策略发生了变化，则可以通过工作人员修改配置文件的方式，实现对其调用接口的调整，从而可以实现接口配置项的变更。本方案通过这样的设置可以灵活的对业务请求所述的认证鉴权类型进行调整，可以根据业务的实际需求，进行灵活处理。

S120、若所述认证鉴权类型为第一类型，则解析所述业务请求中的请求参数，采用认证聚合微服务对所述业务请求进行认证，和采用强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果；若所述认证鉴权类型为第二类型，则根据所述业务请求中的请求参数，采用弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果。

其中，如果认证鉴权类型为第一类型，则可以优先进行认证，认证通过后在进行强鉴权。如果认证鉴权类型为第二类型，则无需通过认证，可以直接进行鉴权。

认证聚合微服务可以是聚合多整认证服务的微服务***，以针对不同需求进行不同的认证服务。强鉴权聚合微服务可以是聚合有多种鉴权的微服务。弱鉴权聚合微服务可以是对用户的信息进行鉴权的微服务。

S130、对所述强鉴权结果或者所述弱鉴权结果进行聚合处理，得到与所述业务请求对应的业务请求结果返回至客户端。

本方案中，具体的，解析所述业务请求中的请求参数，采用认证聚合微服务对所述业务请求进行认证，和采用强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果，包括：

通过网关接收所述业务请求的认证请求，并将所述认证请求转发至认证聚合微服务；

通过所述认证聚合微服务校验所述业务请求中的认证信息，若通过校验，则向客户端返回Token；其中，所述认证聚合微服务包括手机号认证、微信认证、QQ认证、小程序认证以及账号认证中的至少一种认证基础服务；

若通过网关接收所述客户端发出的业务请求中携带所述Token，则确定所述业务请求为强鉴权请求；

若验证所述Token有效，则向强鉴权聚合微服务转发所述业务请求，以使所述强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果。

以下为针对认证和强鉴权的具体的调用方法：

/>

其中，打印日志可以用来后续排除错误，打印日志之后，可以通过getToken()；函数来从请求中取出Token，并且可以依据此Token来从当前的微服务所对应的数据库中获取缓存的用户信息，如UserID等。在确定用户信息之后，可以将用户信息添加到Token的相应字段，便于后续直接获取用户信息。

在本方案中，可选的，如果发现当前的微服务所对应的数据库中不存在与Token对应的用户信息，则可以通过调用其他微服务对应的数据库来查找与Token关联的用户信息，从而保证用户信息能够被获取到。

图2是本发明实施例一提供的认证服务的示意图，如图2所示，客户端调用认证服务，网关接到认证请求，将认证请求转发给认证聚合微服务。认证聚合微服务将认证请求参数进行解析，调用某一个具体的认证微服务。认证微服务校验认证详细信息，对认证详细信息进行校验，校验通过则生成Token，并将Token信息记录到缓存中，设置合理有效期，最后将Token返回给客户端。

可以理解的，此处多个认证微服务(手机号，微信，QQ，小程序，账号)之间没有直接关系，可以插拔的方式进行使用。聚合后，需要解决不同认证类型账号的绑定、解绑与注销等之间的逻辑关系。

例如，目前有手机号A和微信号B的情况下：

手机号A和微信号B均可以单独登录***进行认证。此时注销手机号不影响微信号，注销微信号也不影响手机号；

若手机号和微信号都单独登录过***进行认证，则此两个账号之间不可以进行绑定；

若手机号登录过***进行认证，微信号未单独登录过***进行认证，此时手机号可以绑定微信号，绑定后，手机号登录和微信号登录视为同一个账号。此时注销，则手机号和微信号将同时注销；

手机号A和微信号B进行过绑定之后，可以进行解绑操作，解绑微信后，手机号认证信息不变。微信再次认证将被作为新号处理；

手机号认证与小程序认证的关系等同于手机号认证与微信认证的关系；

手机号认证与QQ认证的关系等同于手机号认证与微信认证的关系。

图3是本发明实施例一提供的强鉴权服务的示意图，如图3所示，客户端携带Token请求服务端的强鉴权业务服务，网关鉴权校验Token有效性，Token有效，并解析Token，识别用户信息，并将用户信息作为新增参数，传递给鉴权聚合微服务。

强鉴权聚合微服务，接收用户请求。将用户请求分解为多个强鉴权基础微服务请求。并把基础微服务返回的响应信息进行聚合，将业务结果返回给客户端。

以上为采用认证和强鉴权方式，得到强鉴权结果的过程。而针对一些无需用户登录就显示的信息，如果采用强鉴权的方式就需要强制用户先登录或者先注册才能查看该信息，对于类似于小程序的访问来说，这样的业务逻辑显然是不合理的。因此，可以单独设计一种弱鉴权的机制。

本方案中，具体的，根据所述业务请求中的请求参数，采用弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果，包括：

通过网关接收所述客户端发出的业务请求中的用户信息，若所述用户信息校验通过，则将业务请求中的弱鉴权请求发送至弱鉴权聚合微服务；

通过所述弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果。

/>

此处，如果确定为弱鉴权，则可以直接调用***的chain.filter()；函数来放行。

图4是本发明实施例一提供的弱鉴权服务的示意图，如图4所示，客户端不携带Token，只携带弱鉴权信息，请求服务端的弱鉴权业务服务，网关获取弱鉴权用户信息，并确认小程序请求的服务为弱鉴权服务，则网关开始校验弱鉴权用户信息，若校验通过，则将弱鉴权信息作为新增参数，传递给弱鉴权聚合微服务。

弱鉴权聚合微服务，接收用户请求。将用户请求分解为多个弱鉴权基础微服务请求。并把基础微服务返回的响应信息进行聚合，将业务结果返回给客户端。

经过比较可以发现，认证、强鉴权、弱鉴权三个过程在技术方案上有什么关系如下：

认证即获取Token，用于后续强鉴权使用；

强鉴权接口调用时需要验证Token(认证获取)；

弱鉴权接口调用时无需验证Token。

本申请的方案通过将认证与鉴权的分离，可以使服务更内聚，更专一。业务扩展更加容易。可直接作为中台使用。也可作为中间件直接复用。

服务端提供强鉴权和弱鉴权两种鉴权方式，可以满足不同客户端的业务应用场景。基础微服务只需要完成一套即可，达到一套基础业务***可以同时为多端提供服务。极大的提高研发效率，加快研发速度。成倍减少测试工作量，更充分的进行***测试研发。极大程度提高软件质量。

面对业务调整与需求变更，可以用最少的工作量，最快的速度，最好的质量来完成交付。做到游刃有余而不是牵一发而动全身。

本申请实施例所提供的技术方案，若接收到业务请求，根据所述业务请求的请求路径，确定所述业务请求的认证鉴权类型；若所述认证鉴权类型为第一类型，则解析所述业务请求中的请求参数，采用认证聚合微服务对所述业务请求进行认证，和采用强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果；若所述认证鉴权类型为第二类型，则根据所述业务请求中的请求参数，采用弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果；对所述强鉴权结果或者所述弱鉴权结果进行聚合处理，得到与所述业务请求对应的业务请求结果返回至客户端。本申请所提供的技术方案，可以针对不同的业务，采用不同的认证和鉴权的逻辑，实现针对不同途径访问时都能够准确反馈的目的。

在上述各技术方案的基础上，可选的，所述方法还包括：

确定当前业务请求负载量是否达到负载门限值；

若是，则关闭认证鉴权类型为第二类型的接口。

可以理解的，在业务***处理的业务请求负载量超过一定负载门限值之后，可以关闭弱鉴权接口，以支持强鉴权接口的正常运行，从而保证强鉴权的业务请求能够进行正常的处理。通过这样的设置，可以确保强鉴权的业务请求正常处理的同时，避免由于业务请求量过大造成的业务***处理速度的下降，甚至业务***的崩溃，确保了业务***的服务过程的稳定性。

实施例二

图5是本发明实施例二提供的基于微服务的认证鉴权装置的结构示意图。如图5所示，所述基于微服务的认证鉴权装置包括：

认证鉴权类型确定模块510，用于若接收到业务请求，根据所述业务请求的请求路径，确定所述业务请求的认证鉴权类型；

鉴权结果获取模块520，用于若所述认证鉴权类型为第一类型，则解析所述业务请求中的请求参数，采用认证聚合微服务对所述业务请求进行认证，和采用强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果；若所述认证鉴权类型为第二类型，则根据所述业务请求中的请求参数，采用弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果；

业务处理模块530，用于对所述强鉴权结果或者所述弱鉴权结果进行聚合处理，得到与所述业务请求对应的业务请求结果返回至客户端。

上述产品可执行本发明实施例一所提供的方法，具备执行方法相应的功能模块和有益效果。

实施例三

本申请实施例还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种基于微服务的认证鉴权方法，该方法包括：

若接收到业务请求，根据所述业务请求的请求路径，确定所述业务请求的认证鉴权类型；

若所述认证鉴权类型为第一类型，则解析所述业务请求中的请求参数，采用认证聚合微服务对所述业务请求进行认证，和采用强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果；若所述认证鉴权类型为第二类型，则根据所述业务请求中的请求参数，采用弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果；

对所述强鉴权结果或者所述弱鉴权结果进行聚合处理，得到与所述业务请求对应的业务请求结果返回至客户端。

存储介质——任何的各种类型的存储器电子设备或存储电子设备。术语“存储介质”旨在包括：安装介质，例如CD-ROM、软盘或磁带装置；计算机***存储器或随机存取存储器，诸如DRAM、DDR RAM、SRAM、EDO RAM，兰巴斯(Rambus)RAM等；非易失性存储器，诸如闪存、磁介质(例如硬盘或光存储)；寄存器或其它相似类型的存储器元件等。存储介质可以还包括其它类型的存储器或其组合。另外，存储介质可以位于程序在其中被执行的计算机***中，或者可以位于不同的第二计算机***中，第二计算机***通过网络(诸如因特网)连接到计算机***。第二计算机***可以提供程序指令给计算机用于执行。术语“存储介质”可以包括可以驻留在不同位置中(例如在通过网络连接的不同计算机***中)的两个或更多存储介质。存储介质可以存储可由一个或多个处理器执行的程序指令(例如具体实现为计算机程序)。

当然，本申请实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的基于微服务的认证鉴权操作，还可以执行本申请任意实施例所提供的基于微服务的认证鉴权方法中的相关操作。

实施例四

本申请实施例提供了一种电子设备。图6是本申请实施例四提供的一种电子设备的结构示意图。如图6所示，本实施例提供了一种电子设备600，其包括：一个或多个处理器620；存储装置610，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器620运行，使得所述一个或多个处理器620实现本申请实施例所提供的基于微服务的认证鉴权方法，该方法包括：

若接收到业务请求，根据所述业务请求的请求路径，确定所述业务请求的认证鉴权类型；

若所述认证鉴权类型为第一类型，则解析所述业务请求中的请求参数，采用认证聚合微服务对所述业务请求进行认证，和采用强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果；若所述认证鉴权类型为第二类型，则根据所述业务请求中的请求参数，采用弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果；

对所述强鉴权结果或者所述弱鉴权结果进行聚合处理，得到与所述业务请求对应的业务请求结果返回至客户端。

图6显示的电子设备600仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图6所示，该电子设备600包括处理器620、存储装置610、输入装置630和输出装置640；电子设备中处理器620的数量可以是一个或多个，图6中以一个处理器620为例；电子设备中的处理器620、存储装置610、输入装置630和输出装置640可以通过总线或其他方式连接，图6中以通过总线650连接为例。

存储装置610作为一种计算机可读存储介质，可用于存储软件程序、计算机可运行程序以及模块单元，如本申请实施例中的基于微服务的认证鉴权方法对应的程序指令。

存储装置610可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储装置610可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储装置610可进一步包括相对于处理器620远程设置的存储器，这些远程存储器可以通过网络连接。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置630可用于接收输入的数字、字符信息或语音信息，以及产生与电子设备的用户设置以及功能控制有关的键信号输入。输出装置640可包括显示屏、扬声器等电子设备。

本申请实施例提供的电子设备，可以针对不同的业务，采用不同的认证和鉴权的逻辑，实现针对不同途径访问时都能够准确反馈的目的。

上述实施例中提供的基于微服务的认证鉴权装置、介质及电子设备可运行本申请任意实施例所提供的基于微服务的认证鉴权方法，具备运行该方法相应的功能模块和有益效果。未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的基于微服务的认证鉴权方法。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (6)

1.一种基于微服务的认证鉴权方法，其特征在于，所述方法包括：

若接收到业务请求，根据所述业务请求的请求路径，确定所述业务请求的认证鉴权类型；其中，所述业务请求的请求路径包括业务请求调用的接口类型，所述接口类型包括认证接口，或者所述接口类型只包括鉴权接口；

若所述认证鉴权类型为第一类型，则解析所述业务请求中的请求参数，采用认证聚合微服务对所述业务请求进行认证，和采用强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果；若所述认证鉴权类型为第二类型，则根据所述业务请求中的请求参数，采用弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果；其中，所述第一类型对应于所述接口类型包括认证接口，所述第二类型对应于所述接口类型只包括鉴权接口；

其中，解析所述业务请求中的请求参数，采用认证聚合微服务对所述业务请求进行认证，和采用强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果，包括：

通过网关接收所述业务请求的认证请求，并将所述认证请求转发至认证聚合微服务；

通过所述认证聚合微服务校验所述业务请求中的认证信息，若通过校验，则向客户端返回Token；其中，所述认证聚合微服务包括手机号认证、微信认证、QQ认证、小程序认证以及账号认证中的至少一种认证基础服务；

若通过网关接收所述客户端发出的业务请求中携带所述Token，则确定所述业务请求为强鉴权请求；

若验证所述Token有效，则解析Token，识别用户信息，并将用户信息作为新增参数，传递给强鉴权聚合微服务；强鉴权聚合微服务，接收用户请求；将用户请求分解为多个强鉴权基础微服务请求；并把基础微服务返回的响应信息进行聚合，将业务结果返回给客户端；

其中，根据所述业务请求中的请求参数，采用弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果，包括：

通过网关接收所述客户端发出的业务请求中的用户信息，若所述用户信息校验通过，则将用户信息作为新增参数，传递给弱鉴权聚合微服务；弱鉴权聚合微服务，接收用户请求；将用户请求分解为多个弱鉴权基础微服务请求；并将基础微服务返回的响应信息进行聚合，将业务结果返回给客户端；

其中，所述方法还包括：

确定当前业务请求负载量是否达到负载门限值；

若是，则关闭认证鉴权类型为第二类型的接口。

2.根据权利要求1所述的方法，其特征在于，确定所述请求路径对应的认证方式，包括：

根据请求参数确定所述业务请求所对应的配置文件中的URL地址；

根据所述配置文件中的URL地址，以及与所述URL地址对应的认证方式代码，确定认证方式。

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

根据所述配置文件中的URL地址，确定与所述业务请求的URL地址对应的验证字段。

4.一种基于微服务的认证鉴权装置，其特征在于，所述装置包括：

认证鉴权类型确定模块，用于若接收到业务请求，根据所述业务请求的请求路径，确定所述业务请求的认证鉴权类型；其中，所述业务请求的请求路径包括业务请求调用的接口类型，所述接口类型包括认证接口，或者所述接口类型只包括鉴权接口；

鉴权结果获取模块，用于若所述认证鉴权类型为第一类型，则解析所述业务请求中的请求参数，采用认证聚合微服务对所述业务请求进行认证，和采用强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果；若所述认证鉴权类型为第二类型，则根据所述业务请求中的请求参数，采用弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果；其中，所述第一类型对应于所述接口类型包括认证接口，所述第二类型对应于所述接口类型只包括鉴权接口；

其中，解析所述业务请求中的请求参数，采用认证聚合微服务对所述业务请求进行认证，和采用强鉴权聚合微服务对所述业务请求进行鉴权，得到强鉴权结果，包括：

通过网关接收所述业务请求的认证请求，并将所述认证请求转发至认证聚合微服务；

通过所述认证聚合微服务校验所述业务请求中的认证信息，若通过校验，则向客户端返回Token；其中，所述认证聚合微服务包括手机号认证、微信认证、QQ认证、小程序认证以及账号认证中的至少一种认证基础服务；

若通过网关接收所述客户端发出的业务请求中携带所述Token，则确定所述业务请求为强鉴权请求；

若验证所述Token有效，则解析Token，识别用户信息，并将用户信息作为新增参数，传递给强鉴权聚合微服务；强鉴权聚合微服务，接收用户请求；将用户请求分解为多个强鉴权基础微服务请求；并把基础微服务返回的响应信息进行聚合，将业务结果返回给客户端；

其中，根据所述业务请求中的请求参数，采用弱鉴权聚合微服务对所述业务请求进行鉴权，得到弱鉴权结果，包括：

通过网关接收所述客户端发出的业务请求中的用户信息，若所述用户信息校验通过，则将用户信息作为新增参数，传递给弱鉴权聚合微服务；弱鉴权聚合微服务，接收用户请求；将用户请求分解为多个弱鉴权基础微服务请求；并将基础微服务返回的响应信息进行聚合，将业务结果返回给客户端；

其中，所述装置还被配置为：

确定当前业务请求负载量是否达到负载门限值；

若是，则关闭认证鉴权类型为第二类型的接口。

5.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-3中任一所述的基于微服务的认证鉴权方法。

6.一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1-3中任一所述的基于微服务的认证鉴权方法。

Images