Service request processing method and device, equipment and storage medium

Abstract

The invention discloses a business request processing method and device, equipment and a storage medium, and relates to the field of request processing, and the method comprises the steps: a gateway obtains a token obtaining request, forwards the token obtaining request to an authorization service, so that the authorization service carries out the identity verification of a client, and forwards a token to the client after the identity verification succeeds; acquiring a service request sent by the client based on the token, matching the service request with the assertion, determining a target micro-service according to a matching result, and judging whether the token meets a preset access condition; if the token meets a preset access condition, routing the service request to a target micro-service based on a target service registration center, so that the target micro-service obtains and processes the service request, and returns a processing result to the gateway; and forwarding the processing result to the client, and recording the processing logic of the service request by using the filter to complete the processing of the service request, thereby realizing the processing of the service request sent by the client.

Description

Technical Field

[0001] The present invention relates to the field of request processing, and in particular to a service request processing method, device, equipment and storage medium. Background Art

[0002] Microservices (or microservice architecture) is a cloud-native architecture approach that includes many small, loosely coupled and independently deployable components or services in a single application, as opposed to the monolithic approach of large, tightly coupled applications. Microservices usually have their own technology stack, including databases and data management models. Currently, when a client accesses a microservice, it sends a request to the gateway, then finds a route that matches the request in the Gateway Handler Mapping, sends it to the Gateway Web Handler, and then sends the request to the target microservice through a specified filter chain, and finally returns the processing result of the target microservice. Among them, route forwarding is usually performed by Nginx (engine x, a high-performance HTTP (Hypertext Transfer Protocol) and reverse proxy web server) for reverse proxy, logging, etc. Each service needs to authenticate and authorize the client independently, and the access efficiency is low. Therefore, how to perform comprehensive authentication and authorization on the client accessing the microservice to avoid multiple identity authentication when the client accesses different microservices through the same gateway is an urgent problem to be solved. Summary of the invention

[0003] In view of this, the purpose of the present invention is to provide a service request processing method, device, equipment and storage medium, which can avoid multiple identity authentication when the client accesses different microservices through the same gateway. The specific scheme is as follows:

[0004] In a first aspect, the present application discloses a service request processing method, which is applied to a gateway, comprising:

[0005] Obtain a token acquisition request sent by the client, and forward the token acquisition request to the authorization service so that the authorization service can authenticate the client based on the client identity information in the token acquisition request, and forward the corresponding token to the client based on a preset token bucket algorithm after the identity authentication is successful;

[0006] Obtain the service request sent by the client based on the token, match the service request with the assertion built into the gateway, determine the target microservice corresponding to the service request according to the corresponding matching result, and determine whether the token meets the preset access condition of the target microservice;

[0007] If the token meets the preset access condition of the target microservice, the service request is routed to the target microservice based on the target service registration center, so that the target microservice obtains and processes the service request, and returns the corresponding processing result to the gateway;

[0008] The processing result is forwarded to the client, and the processing logic corresponding to the business request is recorded using the filter corresponding to the gateway to complete the processing of the business request.

[0009] Optionally, before obtaining the token acquisition request sent by the client, the method further includes:

[0010] The gateway and all microservices are registered with the target service registration center, and the gateway and all microservices are uniformly managed through the target service registration center, so as to determine the path address of the target microservice corresponding to the business request based on the target service registration center, and route the business request through the path address.

[0011] Optionally, forwarding the token acquisition request to an authorization service so that the authorization service authenticates the client based on the client identity information in the token acquisition request, and forwarding a corresponding token to the client based on a preset token bucket algorithm after successful authentication, includes:

[0012] Forwarding the token acquisition request to the authorization service;

[0013] The authorization service authenticates the client based on the user name and password of the client in the token acquisition request. If the client identity authentication is successful, a corresponding token is generated, and the token and the corresponding expiration information of the token are saved to the redis database, and the token is forwarded to the client through the gateway based on the preset token bucket algorithm.

[0014] Optionally, the determining whether the token satisfies a preset access condition of the target microservice includes:

[0015] Determine whether the signature and validity period of the token are valid based on the validity information corresponding to the token in the redis database;

[0016] If the signature and the validity period of the token are valid, it is determined whether the access rights of the token overlap with the access rights corresponding to the target microservice.

[0017] Optionally, after determining whether the access rights of the token overlap with the access rights corresponding to the target microservice, the method further includes:

[0018] If the access rights of the token intersect with the access rights corresponding to the target microservice, it is determined that the token meets the preset access conditions of the target microservice;

[0019] If the access rights of the token do not overlap with the access rights corresponding to the target microservice, it is determined that the token does not meet the preset access conditions of the target microservice, and a prompt message indicating that there is no permission is sent.

[0020] Optionally, the service request processing method further includes:

[0021] If the gateway itself has an exception or an exception occurs during the business request processing, the target method is inherited and overridden through the ErrorWebExceptionHandler class of the gateway, and the exception is processed through the target method, and the status code and data structure returned to the client are customized.

[0022] Optionally, the using the filter corresponding to the gateway to record the processing logic corresponding to the service request includes:

[0023] Using the first type filter corresponding to the gateway to record the request parameters, request header and uniform resource identifier of the service request;

[0024] The request status, response time and processing result of the service request are recorded using the second type filter corresponding to the gateway.

[0025] In a second aspect, the present application discloses a service request processing device, which is applied to a gateway, comprising:

[0026] A token forwarding module, used to obtain a token acquisition request sent by a client, forward the token acquisition request to an authorization service, so that the authorization service can authenticate the client based on the client identity information in the token acquisition request, and forward a corresponding token to the client based on a preset token bucket algorithm after successful authentication;

[0027] A condition judgment module is used to obtain a service request sent by the client based on the token, match the service request with the assertion built into the gateway, determine the target microservice corresponding to the service request according to the corresponding matching result, and judge whether the token meets the preset access condition of the target microservice;

[0028] A processing result acquisition module, used for routing the business request to the target microservice based on the target service registration center if the token meets the preset access condition of the target microservice, so that the target microservice obtains and processes the business request, and returns the corresponding processing result to the gateway;

[0029] The processing logic recording module is used to forward the processing result to the client and use the filter corresponding to the gateway to record the processing logic corresponding to the business request to complete the processing of the business request.

[0030] In a third aspect, the present application discloses an electronic device, comprising:

[0031] Memory, used to store computer programs;

[0032] The processor is used to execute the computer program to implement the aforementioned service request processing method.

[0033] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the aforementioned service request processing method is implemented.

[0034] In this application, when processing the customer's business request, the gateway first obtains the token acquisition request sent by the client, and forwards the token acquisition request to the authorization service so that the authorization service can authenticate the client based on the client identity information in the token acquisition request, and forward the corresponding token to the client based on the preset token bucket algorithm after the identity authentication is successful; then obtain the business request sent by the client based on the token, match the business request with the built-in assertion of the gateway, determine the target microservice corresponding to the business request according to the corresponding matching result, and judge whether the token meets the preset access conditions of the target microservice; if the token meets the preset access conditions of the target microservice, the target microservice and the target service registration center are used to route the business request so that the target microservice obtains and processes the business request, and returns the corresponding processing result to the gateway; finally, the processing result is forwarded to the client, and the corresponding filter of the gateway is used to record the processing logic corresponding to the business request to complete the processing of the business request. It can be seen that in this application, the gateway first obtains the client's token acquisition request and forwards it to the authorization service so that the authorization service can authenticate the client based on the client identity information in the token acquisition request. After the client identity authentication is passed, the authorization service sends the corresponding token to the client based on the preset token bucket algorithm, thereby realizing service traffic control. When the client needs to access the microservice, it sends a business request containing the token to the gateway. The gateway matches the business request with the built-in assertion of the gateway, determines the target microservice corresponding to the business request based on the corresponding matching result, and then verifies the token for the business request. If the token meets the preset access conditions of the target microservice, the client can use the token to access the target microservice, so that the client only needs to access the gateway without having to pay attention to how the service is implemented, avoiding multiple identity authentication when the client accesses different microservices through the same gateway. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0036] Figure 1 A flow chart of a business request processing method disclosed in this application;

[0037] Figure 2 A schematic diagram of a basic architecture of a gateway disclosed in this application;

[0038] Figure 3 A schematic diagram of a load balancing configuration disclosed in this application;

[0039] Figure 4 A token bucket algorithm flow chart disclosed in this application;

[0040] Figure 5 A schematic diagram of a gateway current limiting configuration disclosed in this application;

[0041] Figure 6 A schematic diagram of a service fuse configuration disclosed in this application;

[0042] Figure 7 A schematic diagram of a service fuse implementation disclosed in this application;

[0043] Figure 8 A schematic diagram of a global exception handling disclosed in this application;

[0044] Fig. 9 A schematic diagram of a global exception handling disclosed in this application;

[0045] Fig.10 A signaling diagram of a specific service request processing method disclosed in this application;

[0046] Fig.11 A schematic diagram of the structure of a service request processing device disclosed in this application;

[0047] Fig.12 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0048] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0049] At present, when a client accesses a microservice, it sends a request to the gateway, then finds a route that matches the request in the Gateway HandlerMapping, sends it to the Gateway Web Handler, and then sends the request to the target microservice through the specified filter chain, and finally returns the processing result of the target microservice. The gateway Web processor is usually reverse-proxyed by Nginx, and each service needs to authenticate and authorize the client independently, resulting in low access efficiency. In order to solve the above technical problems, the present application discloses a business request processing method, device, equipment and storage medium, which can avoid multiple identity authentication when the client accesses different microservices through the same gateway.

[0050] See also Figure 1 As shown, an embodiment of the present invention discloses a service request processing method, which is applied to a gateway, including:

[0051] Step S11, obtain the token acquisition request sent by the client, and forward the token acquisition request to the authorization service, so that the authorization service can authenticate the client based on the client identity information in the token acquisition request, and forward the corresponding token to the client based on the preset token bucket algorithm after the identity authentication is successful.

[0052] In this embodiment, the basic architecture of the gateway is as follows Figure 2As shown, the client includes a computer terminal, a mobile terminal and other external interfaces. In order to achieve load balancing, the gateway needs to register the gateway and all microservices to the target service registration center before obtaining the token acquisition request sent by the client. The gateway and all microservices are uniformly managed through the target service registration center, so as to determine the path address of the target microservice corresponding to the business request based on the target service registration center, and route the business request through the path address. It can be known that load balancing refers to distributing network requests to multiple servers to improve the response speed of network services and improve the concurrency of network services. It is one of the important optimization methods in the microservice network architecture. In a microservice architecture, services are usually deployed on multiple servers to improve the availability and stability of services. However, if multiple service instances receive a large number of requests at the same time, some service instances may be overloaded, affecting the response speed and stability of the service. Load balancing can effectively distribute requests to multiple service instances so that the load of each service instance does not exceed its processing capacity, thereby improving the response speed and stability of the service. In a specific implementation, such as Figure 3 As shown, nacos can be used as the target service registration center, and the gateway and all microservices can be registered on nacos. Nacos will manage the gateway and all microservices in a unified manner, and introduce the spring-cloud-loadbalance (a dependency for load balancing) dependency. In this way, when configuring routing for the client, you only need to use the lb (Load balance) protocol and the service name registered on nacos to achieve load balanced access to downstream microservices.

[0053] In this embodiment, after registering the gateway and all microservices with the target service registration center, the gateway obtains the token acquisition request sent by the client, and then forwards the token acquisition request to the authorization service. The authorization service authenticates the client based on the client identity information in the token acquisition request, and forwards the corresponding token to the client based on the preset token bucket algorithm after the identity authentication is successful. Specifically, it may include: the gateway forwards the token acquisition request to the authorization service; the authorization service authenticates the client based on the client's username and password in the token acquisition request. If the client identity authentication is successful, a corresponding token is generated, and the token and the corresponding time information of the token are saved to the redis database, and the token is forwarded to the client through the gateway based on the preset token bucket algorithm.

[0054] In this embodiment, the flow control of the service can be achieved by forwarding the token to the client through the gateway based on the preset token bucket algorithm. Among them, flow control refers to the management and control of the flow of network transmission data to improve network transmission efficiency and ensure the quality of network services. It is one of the important optimization methods in the microservice network architecture. In the microservice architecture, communication between services is usually affected by factors such as network latency and bandwidth limitations. Flow control can effectively manage and control the flow of network transmission data, thereby improving network transmission efficiency and ensuring the quality of network services. The token bucket algorithm is a bucket that stores fixed-capacity tokens, and tokens are added to the bucket at a fixed rate. The specific description is as follows: Figure 4 As shown in the figure, if the average rate configured by the user is r, a token is added to the bucket every 1 / r seconds, assuming that the bucket can store up to b tokens. If the token bucket is full when the token arrives, the token will be discarded; when a data packet of n bytes arrives, n tokens will be deleted from the bucket and the request will be processed. If there are less than n tokens in the token bucket, the token will not be deleted, and the data packet is considered to be outside the flow limit; the token bucket algorithm allows a maximum of b bytes to arrive each time, but from the long-term operation results, the rate of data packets is limited to a constant r. Data packets outside the flow limit can be processed in different ways. In one specific implementation, the data packets outside the flow limit can be discarded; in another specific implementation, the data packets outside the flow limit can be stored in a queue and transmitted when enough tokens are accumulated in the token bucket; in addition, these data packets outside the flow limit can continue to be sent, but special marks need to be added to these data packets outside the flow limit, and these specially marked data packets will be discarded when the network is overloaded. Figure 5 This is a schematic diagram of a gateway current limiting configuration disclosed in this application. Current limiting can be achieved by configuring the gateway.

[0055] Step S12: Obtain a business request sent by the client based on the token, match the business request with the assertion built into the gateway, determine the target microservice corresponding to the business request according to the corresponding matching result, and determine whether the token meets the preset access condition of the target microservice.

[0056] In this embodiment, after obtaining the token, the client can send a service request to the gateway. After the gateway obtains the service request sent by the client based on the token, it matches the service request with the built-in assertion of the gateway, thereby determining the target microservice corresponding to the service request according to the matching result of the assertion being true, and then judging whether the token meets the preset access conditions of the target microservice, wherein the preset access conditions are to verify (authenticate) and authenticate the token, which may specifically include: judging whether the signature and the life span of the token are valid based on the timeliness information corresponding to the token in the redis database; if the signature and the life span of the token are valid, that is, the token passes the verification, then judging whether the access rights of the token and the access rights corresponding to the target microservice have an intersection. If the access rights of the token and the access rights corresponding to the target microservice have an intersection, that is, the authentication is passed, then the token is judged to meet the preset access conditions of the target microservice; if the access rights of the token and the access rights corresponding to the target microservice do not intersect, then the token is judged to not meet the preset access conditions of the target microservice, and a prompt message of no authority is sent. It can be known that Predicate is used to match all content in the HTTP request (such as request header, request parameters), and routing is performed if the request matches the assertion. Authentication is to confirm the identity of the user, while authorization is to confirm whether the user has the authority to access a resource or perform an operation. In the microservice network architecture, authentication and authorization can effectively protect the security of services and the integrity of data, while also improving the availability and stability of services.

[0057] Step S13: If the token meets the preset access condition of the target microservice, the business request is routed to the target microservice based on the target service registration center, so that the target microservice obtains and processes the business request, and returns the corresponding processing result to the gateway.

[0058] In this embodiment, if the token meets the preset access conditions of the target microservice, that is, the token passes verification and authentication, the gateway obtains the specific address corresponding to the target microservice from the target service registration center, such as ip (Internet Protocol) + port number, and then routes the business request to the target microservice. Routing is the basic module for building a gateway, which consists of ID (Identity document), target URI (Uniform Resource Identifier), a series of assertions and filters. If the assertion is true, the route is matched. After obtaining the business request, the target microservice processes the business request based on the corresponding processing logic and returns the processing result to the gateway.

[0059] After the gateway forwards the business request to the target microservice, if it detects that the target microservice has an exception, or the failure rate of calling the target microservice meets a certain threshold condition, such as 20 failed calls within 5 seconds, the target microservice can be downgraded based on the fuse mechanism, thereby fusing the call to the target microservice and quickly returning the corresponding error information to prevent the entire system from crashing and ensure the stability of the entire system. In addition, if it is detected that the target microservice can respond normally, the call link before the target microservice was blown can be restored. Figure 6 and Figure 7 As shown, the present application discloses a schematic diagram of a service fusing configuration and service fusing implementation based on Hystrix (a library for handling delays and fault tolerance in distributed systems), thereby ensuring that other microservices can work normally by fusing the call link of the target microservice with an error. Service fusing means that in a microservice architecture, when a service is abnormal or times out, a fusing mechanism is used to protect the service and prevent the entire system from crashing. It is one of the important fault-tolerance means in a microservice network architecture. In a microservice architecture, the dependencies between services are usually complex. Problems with a service may cause multiple services to fail to work properly, thereby affecting the stability of the entire system.

[0060] Step S14: forward the processing result to the client, and use the filter corresponding to the gateway to record the processing logic corresponding to the business request to complete the processing of the business request.

[0061] In this embodiment, the gateway forwards the acquired processing result to the corresponding client, and then uses different types of filters to record the processing logic of the business request, thereby completing the processing of the business request. The specific process of the gateway recording the processing logic of the business request may include: using the first type filter corresponding to the gateway to record the request parameters, request header and uniform resource identifier of the business request; using the second type filter corresponding to the gateway to record the request status, response time and processing results of the business request. Among them, the first type of filter is a "pre" type filter, and the second type of filter is a "post" type filter. The "pre" type filter will execute logic before the service processes the request, and the "post" type filter will execute logic after the service processes the request. Based on these two types of filters, a very complete logging function can be achieved. The "pre" type can record log information such as parameters, request headers, url (uniform resource locator, uniform resource locator) of each request, and the "post" type can record log information such as request status, response time, and processing results of the business request. Through log monitoring, the communication logs between services can be effectively collected and analyzed, so as to discover and solve potential problems and ensure the stability and reliability of the service.

[0062] In this embodiment, Figure 8 and Fig. 9 As shown, if the gateway itself has an exception or there is an exception in the business request processing process, the target method is inherited and overridden by the ErrorWebExceptionHandler class of the gateway, and the exception is processed by the target method, and the status code and data structure returned to the client are customized, so that the gateway can uniformly handle all forwarding calls and the gateway's own exceptions, and customize the status code and data structure returned to the client.

[0063] To summarize, in this application, the gateway first obtains the client's token acquisition request and forwards it to the authorization service so that the authorization service can authenticate the client based on the client identity information in the token acquisition request. After the client identity authentication is passed, the authorization service sends the corresponding token to the client based on the preset token bucket algorithm, thereby realizing service traffic control. When the client needs to access the microservice, it sends a business request containing the token to the gateway. The gateway matches the business request with the built-in assertion of the gateway, determines the target microservice corresponding to the business request based on the corresponding matching result, and then verifies the token for the business request. If the token meets the preset access conditions of the target microservice, the client can use the token to access the target microservice, so that the client only needs to access the gateway without having to pay attention to how the service is implemented, avoiding multiple identity authentication when the client accesses different microservices through the same gateway.

[0064] Based on the above embodiment, the present application discloses a service request processing method, which can avoid multiple identity authentications when a client accesses different microservices through the same gateway. Next, a specific service request processing process will be described in detail.

[0065] like Fig.10As shown, the front end (i.e., the client) carries a series of identity information such as username and password to initiate a login request (i.e., a token acquisition request) to log in to the gateway to obtain a token. After receiving the login request from the front end, the gateway forwards the login request to the OAuth (Open Authorization) 2.0 authentication service (i.e., the authorization service). The OAuth2.0 authentication service authenticates the front end based on the identity information in the login request. If the front end passes the identity authentication, the OAuth2.0 authentication service sends the corresponding token to the gateway based on the preset token bucket algorithm, and saves the token and the corresponding time information to the redis database. The gateway then forwards the token to the front end so that the front end can initiate a business request to the gateway based on the token. In one embodiment, the authentication and authorization scheme can be spring security (a security management framework), which is highly compatible with spring cloud gateway (a gateway); in another embodiment, sa-token (an identity authentication and authorization framework) can be selected as the authentication and authorization scheme to replace spring security, thereby building a lightweight program.

[0066] After receiving the business request sent by the front end, the gateway matches the business request with the built-in assertion of the gateway, determines the target microservice corresponding to the business request based on the corresponding matching result, and determines whether the token meets the preset access conditions of the target microservice. The specific process of determining whether the token meets the preset access conditions of the target microservice may include: verifying the signature and expiration date of the token sent by the front end based on the token stored in the redis database. If the signature and expiration date of the token are both valid, then determining whether the access rights of the token have an intersection with the access rights corresponding to the target microservice. If the access rights of the token have an intersection with the access rights corresponding to the target microservice, then determining that the token meets the preset access conditions of the target microservice; if the access rights of the token have no intersection with the access rights corresponding to the target microservice, then determining that the token does not meet the preset access conditions of the target microservice, and sending a prompt message of no authority to the front end.

[0067] Before the gateway obtains the token acquisition request from the front end, the gateway and all microservices have been registered with the target service registration center, and the gateway and all microservices are uniformly managed through the target service registration center. Therefore, the gateway can determine the path address of the target microservice corresponding to the business request based on the target service registration center, and route the business request through the path address. If the token meets the preset access conditions, the gateway routes the business request to the target microservice based on the target service registration center, so that the target microservice obtains and processes the business request, and returns the corresponding processing result to the gateway. The gateway forwards the processing result to the client and uses the filter corresponding to the gateway to record the processing logic corresponding to the business request to complete the processing of the business request. If nacos is used as the target service registration center, the gateway and all microservices are registered on nacos and uniformly managed by nacos. At the same time, the spring-cloud-loadbalance dependency is introduced, so that when configuring the route, you only need to use the lb protocol and the service name registered on nacos to achieve load balancing access to microservices. In addition, spring cloud's native eruka can also be used as a target service registration center, without the need for additional construction.

[0068] When recording the processing logic of business requests, the "pre" type filter of the gateway will execute the logic before the target microservice processes the business request, and can record the parameters, request headers, URL and other log information of each business request. The "post" type filter will execute the logic after the target microservice processes the business request, and can record the business request status, response time, returned processing results and other log information. Based on these two types of filters, a very complete logging function can be implemented. In addition, the "pre" type filter can also implement parameter verification, permission verification, traffic monitoring, log output, protocol conversion and other functions. The "post" type filter can modify the response content, response header and log output, which plays a very important role in traffic monitoring and other aspects.

[0069] In addition, after the gateway forwards the business request to the target microservice, if it detects that the target microservice has an exception, or the failure rate of calling the target microservice meets a certain threshold condition, such as 20 failed calls within 5 seconds, the target microservice can be downgraded based on the fuse mechanism (such as Hystrix), thereby fusing the call to the target microservice and quickly returning the corresponding error information to prevent the entire system from crashing and ensure the stability of the entire system. In addition, if it is detected that the target microservice can respond normally, the call link before the target microservice is fusing can be restored. If there is an exception in the gateway itself or in the process of processing the business request, the target method is inherited and rewritten through the gateway's ErrorWebExceptionHandler class, and the exception is handled through the target method, and the status code and data structure returned to the front end are customized.

[0070] It can be seen that this application draws on the idea of ​​the mediator pattern in the software design pattern. The front end only needs to access the gateway layer and does not need to care about the implementation of microservices. The gateway layer will forward and call them uniformly. This application selects spring cloudgateway as the basic framework and uses the react mode of its webflux (a responsive framework) to improve the efficiency of service requests. At the same time, it integrates multiple components or middleware such as spring security, redis, nacos, Hystrix, etc. to create a practical multi-functional gateway, which extracts authentication and authorization, global exception handling, request log collection, current limiting, load balancing and service fuse functions from microservices and integrates them into an independent gateway layer to achieve decoupling. Most functions follow the principle of convention over configuration. Customized content can also be implemented through simple configuration, so that microservices only need to care about their own business, which improves the efficiency of accessing microservices.

[0071] See also Fig.11 As shown, the embodiment of the present application discloses a service request processing device, which is applied to a gateway, including:

[0072] The token forwarding module 11 is used to obtain a token acquisition request sent by a client, and forward the token acquisition request to an authorization service so that the authorization service can authenticate the client based on the client identity information in the token acquisition request, and forward the corresponding token to the client based on a preset token bucket algorithm after the identity authentication is successful;

[0073] The condition judgment module 12 is used to obtain the service request sent by the client based on the token, match the service request with the assertion built into the gateway, determine the target microservice corresponding to the service request according to the corresponding matching result, and judge whether the token meets the preset access condition of the target microservice;

[0074] A processing result acquisition module 13 is used to route the business request to the target microservice based on the target service registration center if the token meets the preset access condition of the target microservice, so that the target microservice obtains and processes the business request, and returns the corresponding processing result to the gateway;

[0075] The processing logic recording module 14 is used to forward the processing result to the client, and use the filter corresponding to the gateway to record the processing logic corresponding to the business request to complete the processing of the business request.

[0076] It can be seen that in this application, the gateway first obtains the client's token acquisition request and forwards it to the authorization service so that the authorization service can authenticate the client based on the client identity information in the token acquisition request. After the client identity authentication is passed, the authorization service sends the corresponding token to the client based on the preset token bucket algorithm, thereby realizing service traffic control. When the client needs to access the microservice, it sends a business request containing the token to the gateway. The gateway matches the business request with the built-in assertion of the gateway, determines the target microservice corresponding to the business request based on the corresponding matching result, and then verifies the token for the business request. If the token meets the preset access conditions of the target microservice, the client can use the token to access the target microservice, so that the client only needs to access the gateway without having to pay attention to how the service is implemented, avoiding multiple identity authentication when the client accesses different microservices through the same gateway.

[0077] In a specific embodiment, the device may further include:

[0078] A registration management module is used to register the gateway and all microservices to the target service registration center, and uniformly manage the gateway and all microservices through the target service registration center, so as to determine the path address of the target microservice corresponding to the business request based on the target service registration center, and route the business request through the path address.

[0079] In a specific embodiment, the token forwarding module 11 may specifically include:

[0080] A request forwarding unit, used to forward the token acquisition request to an authorization service;

[0081] A token forwarding unit is used to authenticate the client through the authorization service based on the user name and password of the client in the token acquisition request. If the client identity authentication is successful, a corresponding token is generated, the token and the corresponding time information of the token are saved in the redis database, and the token is forwarded to the client through the gateway based on the preset token bucket algorithm.

[0082] In a specific embodiment, the condition judgment module 12 may specifically include:

[0083] A validity judgment unit, used to judge whether the signature and the validity period of the token are valid based on the validity information corresponding to the token in the redis database;

[0084] The permission judgment unit is used to judge whether the access rights of the token and the access rights corresponding to the target microservice have an intersection if the signature and the validity period of the token are valid.

[0085] In a specific embodiment, the device may further include:

[0086] A first judgment result execution module, configured to determine that the token satisfies a preset access condition of the target microservice if the access rights of the token and the access rights corresponding to the target microservice have an intersection;

[0087] The second judgment result execution module is used to determine that the token does not meet the preset access conditions of the target microservice if the access rights of the token have no intersection with the access rights corresponding to the target microservice, and send a prompt message indicating that there is no permission.

[0088] In a specific embodiment, the device may further include:

[0089] The exception handling module is used to inherit and rewrite the target method through the ErrorWebExceptionHandler class of the gateway if there is an exception in the gateway itself or in the business request processing process, and to handle the exception through the target method and customize the status code and data structure returned to the client.

[0090] In a specific embodiment, the processing logic recording module 14 may specifically include:

[0091] A first recording unit, configured to record the request parameters, request header and uniform resource identifier of the service request by using a first type filter corresponding to the gateway;

[0092] The second recording unit is used to record the request status, response time and processing result of the service request by using the second type filter corresponding to the gateway.

[0093] Furthermore, the present application also discloses an electronic device. Fig.12 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content in the diagram cannot be regarded as any limitation on the scope of use of the present application.

[0094] Fig.12 A schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the service request processing method disclosed in any of the aforementioned embodiments. In addition, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0095] In this embodiment, the power supply 23 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0096] In addition, the memory 22 as a carrier for resource storage may be a read-only memory, a random access memory, a disk or an optical disk, etc. The resources stored thereon may include an operating system 221, a computer program 222, etc., and the storage method may be temporary storage or permanent storage.

[0097] The operating system 221 is used to manage and control the hardware devices on the electronic device 20 and the computer program 222, which can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program that can be used to complete the service request processing method performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program that can be used to complete other specific tasks.

[0098] Furthermore, the present application also discloses a computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the aforementioned disclosed service request processing method. For the specific steps of the method, reference may be made to the corresponding contents disclosed in the aforementioned embodiments, and no further description will be given here.

[0099] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0100] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0101] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0102] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0103] The technical solution provided by the present application is introduced in detail above. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for general technicians in this field, according to the idea of ​​the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A method for processing a business request, characterized in that: Applied to gateways, including: Obtain a token acquisition request sent by the client, and forward the token acquisition request to the authorization service so that the authorization service can authenticate the client based on the client identity information in the token acquisition request, and forward the corresponding token to the client based on a preset token bucket algorithm after the identity authentication is successful; Obtain the service request sent by the client based on the token, match the service request with the assertion built into the gateway, determine the target microservice corresponding to the service request according to the corresponding matching result, and determine whether the token meets the preset access condition of the target microservice; If the token meets the preset access condition of the target microservice, the service request is routed to the target microservice based on the target service registration center, so that the target microservice obtains and processes the service request, and returns the corresponding processing result to the gateway; The processing result is forwarded to the client, and the processing logic corresponding to the business request is recorded using the filter corresponding to the gateway to complete the processing of the business request.

2. The service request processing method according to claim 1, characterized in that: Before obtaining the token acquisition request sent by the client, the method further includes: The gateway and all microservices are registered with the target service registration center, and the gateway and all microservices are uniformly managed through the target service registration center, so as to determine the path address of the target microservice corresponding to the business request based on the target service registration center, and route the business request through the path address.

3. The service request processing method according to claim 1, characterized in that: The forwarding of the token acquisition request to the authorization service so that the authorization service authenticates the client based on the client identity information in the token acquisition request, and forwards the corresponding token to the client based on a preset token bucket algorithm after successful authentication, including: Forwarding the token acquisition request to the authorization service; The authorization service authenticates the client based on the user name and password of the client in the token acquisition request. If the client identity authentication is successful, a corresponding token is generated, and the token and the corresponding expiration information of the token are saved to the redis database, and the token is forwarded to the client through the gateway based on the preset token bucket algorithm.

4. The service request processing method according to claim 3, characterized in that: The determining whether the token satisfies a preset access condition of the target microservice includes: Determine whether the signature and validity period of the token are valid based on the validity information corresponding to the token in the redis database; If the signature and the validity period of the token are valid, it is determined whether the access rights of the token overlap with the access rights corresponding to the target microservice.

5. The service request processing method according to claim 4, characterized in that: After determining whether the access rights of the token and the access rights corresponding to the target microservice have an intersection, the method further includes: If the access rights of the token intersect with the access rights corresponding to the target microservice, it is determined that the token meets the preset access conditions of the target microservice; If the access rights of the token do not overlap with the access rights corresponding to the target microservice, it is determined that the token does not meet the preset access conditions of the target microservice, and a prompt message indicating that there is no permission is sent.

6. The service request processing method according to claim 1, characterized in that: Also includes: If the gateway itself has an exception or an exception occurs during the business request processing, the target method is inherited and overridden through the ErrorWebExceptionHandler class of the gateway, and the exception is processed through the target method, and the status code and data structure returned to the client are customized.

7. The service request processing method according to any one of claims 1 to 6, characterized in that: The recording of the processing logic corresponding to the service request by using the filter corresponding to the gateway includes: Using the first type filter corresponding to the gateway to record the request parameters, request header and uniform resource identifier of the service request; The request status, response time and processing result of the service request are recorded using the second type filter corresponding to the gateway.

8. A service request processing device, characterized in that: Applied to gateways, including: A token forwarding module, used to obtain a token acquisition request sent by a client, forward the token acquisition request to an authorization service, so that the authorization service can authenticate the client based on the client identity information in the token acquisition request, and forward a corresponding token to the client based on a preset token bucket algorithm after successful authentication; A condition judgment module is used to obtain a service request sent by the client based on the token, match the service request with the assertion built into the gateway, determine the target microservice corresponding to the service request according to the corresponding matching result, and judge whether the token meets the preset access condition of the target microservice; A processing result acquisition module, used for routing the business request to the target microservice based on the target service registration center if the token meets the preset access condition of the target microservice, so that the target microservice obtains and processes the business request, and returns the corresponding processing result to the gateway; The processing logic recording module is used to forward the processing result to the client and use the filter corresponding to the gateway to record the processing logic corresponding to the business request to complete the processing of the business request.

9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the service request processing method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: Used to store a computer program, wherein when the computer program is executed by a processor, the service request processing method according to any one of claims 1 to 7 is implemented.

Images