Request processing method and device based on microservice gateway, and electronic equipment

Abstract

The invention discloses a request processing method and device based on a micro-service gateway and electronic equipment, after an access request initiated by a user is received, the access request can be forwarded to a preset gateway, the preset gateway can firstly analyze the access request to determine a service required by the access request, and then the service required by the access request is processed by the preset gateway. The method comprises the following steps: receiving an access request from a remote management center, acquiring a routing rule pre-configured in the management center from the remote management center, and processing the access request according to the acquired routing rule, the routing rule being pre-configured in a routing file uniformly managed by the management center through a registration mode and being uniformly managed by the management center.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a request processing method, device and electronic device based on a microservice gateway. Background Art

[0002] With the continuous development of computer technology, a variety of business services have been deeply integrated into people's daily lives, such as online shopping, information sharing, online investment and financial management, online video browsing, etc. These business services provide many experiences for people's daily lives.

[0003] In order to further provide better services to users, distributed services came into being, which refers to decomposing an application or system into multiple services that can be deployed, run and expanded independently. These services are usually distributed on different servers or computing nodes and communicate through the network. Each service is responsible for executing specific business logic and can be developed, deployed and managed independently of other services. This architectural approach can provide higher flexibility, scalability and fault tolerance.

[0004] However, for the development of distributed services, due to business reasons, developers need to access the gateway for different services separately during the system development process. In particular, since the Dubbo service cannot directly access the gateway through routing configuration, and each time a new Dubbo service application is added, it is necessary to add corresponding Dubbo annotations to the gateway layer to implement the Application Programming Interface (API) call access between the service provider and the consumer, which increases the development cost of the gateway layer and makes it impossible for developers to uniformly manage downstream services. Summary of the invention

[0005] The embodiments of the present application provide a request processing method, device and electronic device based on a microservice gateway to partially solve the above-mentioned problems existing in the prior art.

[0006] The present application embodiment adopts the following technical solutions: The present application embodiment provides a request processing method based on a microservice gateway, including: Receive access requests initiated by users; Forwarding the access request to a preset gateway to determine the service required by the access request through the preset gateway, and obtaining a routing rule pre-configured in the management center from a remote management center, wherein the routing rule is configured in a routing file uniformly managed by the management center by registration; The access request is processed according to the routing rule.

[0007] Optionally, the access request carries an access token of the user; Before obtaining the routing rules pre-configured in the management center from the remote management center, the method further includes: Calling an authentication microservice deployed in the management center to authenticate the access token carried in the access request, wherein the authentication microservice is pre-created and configured in the management center; From a remote management center, obtain the routing rules pre-configured in the management center, including: If it is determined that the access token passes the authentication, the routing rules pre-configured in the management center are obtained from the remote management center.

[0008] Optionally, calling an authentication microservice deployed in the management center to authenticate the access token carried in the access request specifically includes: Identify the access request to determine routing information corresponding to the access request; If it is determined that authentication is required for the access request based on the routing information and the pre-acquired authentication routing list, the authentication microservice deployed in the management center is called to authenticate the access token carried in the access request. The authentication routing list is pre-written to the management center in the form of configuration information and broadcast by the management center to the preset gateway.

[0009] Optionally, the method further comprises: If it is determined, based on the routing information and the authentication routing list, that authentication is not required for the access request, the access request is forwarded based on the routing rule obtained from the management center.

[0010] Optionally, forwarding the access request according to the routing rule obtained from the management center specifically includes: The routing rules of the service corresponding to the access request in the management center are read through the preset Dubbo filter, so as to forward the access request according to the obtained routing rules.

[0011] Optionally, processing the access request according to the routing rule specifically includes: Determine whether the service required by the access request is a Dubbo service according to the identified routing information corresponding to the access request and the routing rule; If it is determined that the service required by the access request is not the Dubbo service, the access request is routed and forwarded through the preset gateway based on the routing rule.

[0012] Optionally, the method further comprises: If it is determined that the service required by the access request is the Dubbo service, the downstream Dubbo service is called through the preset gateway based on the preset generalized calling method.

[0013] The embodiment of the present application provides a request processing device based on a microservice gateway, including: A receiving module, used for receiving an access request initiated by a user; A gateway module, used to forward the access request to a preset gateway, so as to determine the service required by the access request through the preset gateway, and obtain a routing rule pre-configured in the management center from a remote management center, wherein the routing rule is configured in a routing file uniformly managed by the management center by registration; A processing module is used to process the access request according to the routing rule.

[0014] An embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the above-mentioned request processing method based on the microservice gateway is implemented.

[0015] An embodiment of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned request processing method based on a microservice gateway when executing the program.

[0016] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects: It can be seen from the above method that after receiving an access request initiated by a user, the access request can be forwarded to a preset gateway, which can first parse the access request to determine the service required for the access request, and then obtain the routing rules pre-configured in the management center from the remote management center to process the access request according to the obtained routing rules, wherein the routing rules are pre-configured in the routing file uniformly managed by the management center through registration, and are uniformly managed by the management center.

[0017] From the above content, it can be seen that since the routing files managed by the management center can be configured in advance in the management center in a registered manner, this can achieve unified, efficient and flexible management of downstream services, reduce the complexity and access cost of microservice system expansion, and thus improve the forwarding efficiency of access requests initiated by users to a certain extent. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of this specification and constitute a part of this specification. The illustrative embodiments and descriptions of this specification are used to explain this specification and do not constitute an improper limitation on this specification. In the drawings: Figure 1 A schematic diagram of a request processing method based on a microservice gateway provided in an embodiment of the present application; Figure 2 A schematic diagram of an architecture for providing microservices for a management center provided in an embodiment of the present application; Figure 3 A detailed flow chart of access request forwarding based on a microservice gateway provided in an embodiment of the present application; Figure 4 A schematic diagram of a request processing device based on a microservice gateway provided in an embodiment of the present application; Figure 5 A method corresponding to Figure 1 Schematic diagram of the structure of an electronic device. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical solutions and advantages of this application clearer, the technical solutions of this specification will be clearly and completely described below in combination with the specific embodiments of this specification and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this specification.

[0020] For the development of distributed services, due to business reasons, developers need to access the gateway for different services separately during the system development process. In particular, since the Dubbo service cannot directly access the gateway through routing configuration, and each time a new Dubbo service application is added, it is necessary to add corresponding Dubbo annotations at the gateway layer to implement the Application Programming Interface (API) call access between the service provider and the consumer, which increases the development cost of the gateway layer and makes it impossible for developers to uniformly manage downstream services.

[0021] Moreover, for services that require authentication, it is impossible to generalize them to the gateway layer, and the authentication logic will be scattered among various services, greatly reducing the readability of the code.

[0022] To this end, an embodiment of the present application provides a request processing method based on a microservice gateway. Through this method, unified, efficient and flexible management of downstream services can be achieved, reducing the complexity and access cost of microservice system expansion, thereby improving the forwarding efficiency of access requests initiated by users to a certain extent. The method provided by the embodiment of the present application will be described in detail below.

[0023] The technical solutions provided by the embodiments of this specification are described in detail below in conjunction with the accompanying drawings.

[0024] Figure 1 A schematic diagram of a request processing method based on a microservice gateway provided in an embodiment of the present application includes the following steps: S101: receiving an access request initiated by a user.

[0025] In an embodiment of the present application, the terminal device used by the user (such as electronic devices such as desktop computers, laptops, or mobile terminal devices such as smart phones and tablet computers) or the client installed in the terminal device can receive access requests initiated by the user based on the operations performed by the user in the course of executing the business.

[0026] Among them, the business executed by the user can be determined according to the actual situation. The specific business is not clearly limited in the embodiment of the present application. For example, it can be an access request for a user to visit a website when searching for information online, or it can be an access request initiated when a user visits a sub-page of a merchant when shopping online.

[0027] As mentioned above, the execution entity that receives the access request initiated by the user can be the above-mentioned terminal device or the client installed in the terminal device. For the sake of convenience of description, the following only takes the client as the execution entity to describe in detail the request processing method based on the microservice gateway provided in the embodiment of the present application.

[0028] S102: Forward the access request to a preset gateway to determine the service required by the access request through the preset gateway, and obtain the routing rules pre-configured in the management center from the remote management center. The routing rules are configured in a routing file uniformly managed by the management center through registration.

[0029] After receiving the access request, the client needs to forward it to the corresponding preset gateway for processing.

[0030] It should be pointed out that in actual applications, the gateway will not forward the received access requests at will, but will authenticate the received access requests according to actual needs. In other words, for some access requests, the gateway will forward them only if they pass the gateway's authentication, and if the access request does not pass the gateway's authentication, the gateway will not process it. Of course, there are also some access requests with certain access rights. After receiving these access requests, the gateway will not authenticate them, but will release them.

[0031] Therefore, in the embodiment of the present application, after receiving the above access request, the preset gateway needs to first call the authentication microservice deployed by the remote management center to authenticate the access token of the user carried in the access request.

[0032] The so-called microservice is actually an architecture, a method of designing software applications, which builds a single application into a set of small, independent services, each of which implements a specific business function and communicates through a well-defined API. These services are self-contained and can be independently deployed, expanded, and updated, thereby improving flexibility and maintainability.

[0033] In order to achieve efficient and flexible management of some services, the above authentication microservice can be created and configured in the above management center in advance.

[0034] Specifically, in an embodiment of the present application, the management center can be a configuration and application service management platform built based on a preset architecture (such as Nacos), which can provide basic services such as dynamic service discovery, service configuration, service sharing and management.

[0035] The management center can manage the routing rule files for various services in a unified manner. The routing rule files include application registration name, routing name, routing order, service protocol and other information. If the authentication microservices required for gateway forwarding access requests need to be added based on actual needs, they can be registered to the management center in the form of Dubbo services. In this way, the preset gateway can call these pre-configured authentication microservices from the remote management center in the subsequent process to authenticate the received access requests.

[0036] During the configuration process of the authentication microservice, an administrator with configuration authority can write a predetermined authentication routing list into the above-mentioned management center in the form of configuration information, and the management center can trigger an authentication change event to broadcast the authentication routing list to each gateway through the event.

[0037] For the above-mentioned preset gateway, once the authentication routing list is obtained, it can be saved, and in subsequent practical applications, the authentication routing list can be used to further determine which access requests need to be authenticated and which can be released.

[0038] Specifically, the client can identify the access request through the preset gateway to determine the routing information corresponding to the access request, where the routing information can be understood as indicating the object to be accessed by the access request. If it is determined that authentication is required for this access request based on the identified routing information and the authentication routing list pre-acquired by the preset gateway, the authentication microservice deployed in the management center can be called to authenticate the access token of the user carried in the access request.

[0039] Of course, if it is determined that no authentication is required for this access request based on the identified routing information and the above-mentioned authentication routing list, the access request can be forwarded based on the routing rules obtained from the management center.

[0040] It can be seen that the authentication routing list mentioned in the embodiment of the present application is equivalent to a list, which actually specifies which addresses the access request requires authentication and which addresses do not require authentication. In other words, the authentication routing list also specifies which addresses the user can access and which addresses cannot be accessed.

[0041] Furthermore, in the embodiment of the present application, the management center actually manages various routing rules in a unified manner. These routing rules can be configured in advance to the management center by an authorized administrator or user through registration. The use of these routing rules can be called by the gateway in the subsequent process according to the authentication result or the routing information corresponding to the access request.

[0042] Therefore, after forwarding the access request to the preset gateway, it is possible to determine how to retrieve the corresponding routing rules from the management center according to the specific authentication result.

[0043] Specifically, the client can read the routing rules of the service corresponding to the access request in the management center through the preset Dubbo filter, so as to forward the access request through the obtained routing rules in the subsequent process.

[0044] S103: Process the access request according to the routing rule.

[0045] As mentioned above, since various services can be pre-configured in the above-mentioned management center, in the subsequent processing of the above-mentioned access request, the access request can also be processed accordingly through the various services managed by the management center and the routing rules corresponding to different services.

[0046] Specifically, based on the routing information and routing rules corresponding to the identified access request, it can be determined whether the service required for the access request is a Dubbo service. If it is determined that the service required for the access request is not a Dubbo service, the access request can be routed and forwarded through a preset gateway based on the routing rules obtained from the above-mentioned management center.

[0047] Of course, if it is determined that the service required for the access request is a Dubbo service, the downstream Dubbo service can be called through the preset gateway based on the preset generalized calling method.

[0048] The generalized calling method mentioned here is a feature of the Dubbo framework, which allows clients to call remote services without knowing the service interface definition. Usually, service consumers using Dubbo need to rely on specific service interfaces and corresponding Java class libraries, which makes the service consumer side tightly coupled with the service provider side.

[0049] However, in some scenarios, such as dynamic calls, cross-language calls, or when the service interface changes frequently, you may not want or be able to directly depend on the service interface in the consumer's code. In this case, you can use generalized calls, which provide a more flexible way to call services.

[0050] In the embodiments of the present application, the generalized calling method may include multiple methods, and the following only lists some methods as examples: 1. Generic Reference: Create a generic service reference by setting generic=true, and then pass in the method name, parameter type, and parameter value when calling the service to implement a generic call.

[0051] 2. Generic Invoke: Directly use the org.apache.dubbo.rpc.service.GenericService interface, which has only one $invoke method and can accept any service name, method name, parameter type, and parameter value for generic invocation.

[0052] 3. Dynamic proxy: Using Java's dynamic proxy mechanism, you can implement generalized calls to services without modifying existing codes.

[0053] Of course, there may be other generalized calling methods, which will not be explained in detail here.

[0054] It should be noted that the service required for the access request can be not only the Dubbo service mentioned above, but also other services, such as Feign service. Correspondingly, if the service corresponding to the access request is Feign service, the access request can be forwarded to the downstream service for processing through load balancing according to the corresponding routing rules pre-registered and configured in the management center. For example, for the application of HTTP service, the request can also be forwarded directly to the downstream service through the routing rules obtained from the management center.

[0055] From the above content, it can be seen that since various routing rules and related microservices for authentication are pre-registered in the management center, in the subsequent request processing process, the client can call these routing rules and authentication microservices from the management center to flexibly and efficiently process access requests. The entire process does not require adding relevant annotations of new services in the gateway as in the prior art, which reduces development costs, realizes unified management of downstream services, and significantly improves the processing efficiency of access requests to a certain extent.

[0056] The process of configuring the above routing rules and authentication microservices in the management center is described in detail below from the actual configuration process, such as Figure 2 shown.

[0057] Figure 2 A schematic diagram of an architecture for providing microservices for a management center provided in an embodiment of the present application.

[0058] exist Figure 2 The architecture shown includes clients, Domain Name System (DNS), distributed microservice gateways, and distributed management centers. Since it is distributed, the distributed microservice gateway is equivalent to setting up one or more microservice gateways (i.e., the preset gateways mentioned above). The same is true for the distributed management center, which is actually equivalent to setting up one or more management centers to meet service needs.

[0059] From the above Figure 2 It can be seen that the administrator can publish permission configuration information and routing rule information in the management center. The management center can determine the access rights of each user (that is, the authentication routing list mentioned above) through the permission configuration information published by the administrator. At the same time, the routing rule information published by the administrator can be configured to manage various routing rules.

[0060] The same is true for each microservice. The microservice service registration can be performed in the management center, so that the management center can uniformly manage the registered microservices. For the microservice gateway, these microservices can be subscribed to implement the call of these microservices in the subsequent process, and the access requests can be processed through these microservices.

[0061] According to the rules of the management center, the gateway's authentication microservice can be preset to be configured as follows: Application name configuration: Set the name of the client that needs authentication to "permission" through the spring.application.name property. This configuration ensures that the client has a unique identifier in the Spring environment, which facilitates subsequent service registration and discovery.

[0062] Nacos service discovery and configuration management: Specify the address of the Nacos server through the spring.cloud.nacos.server-addr property.

[0063] Use the spring.cloud.nacos.username and spring.cloud.nacos.password properties to set the Nacos username and password respectively to ensure access to the Nacos service. In terms of Nacos service discovery, use the spring.cloud.nacos.discovery.namespace property to specify the namespace to which the client belongs as "jscl-platform". This configuration enables the client to be correctly registered with the Nacos service registry and be visible to other services in the same namespace.

[0064] Permissions are configured in the management center in a JSON structure through tenant-role-permissions, for example: [ { "tenantId": "tenant1", "tenantName": "Tenant One", "roles": [ { "roleId": "admin", "roleName": "Administrator", "permissions": [ { "permissionId": "manage_users", "permissionName": "Manage Users" } ] } ] }] Each tenant has a unique tenantId and a descriptive tenantName. Each tenant has a roles array that defines all roles within the tenant. Each role has a unique roleId and a descriptive roleName, as well as a permissions array that lists all permissions that the role has. Each permission has a unique permissionId and a descriptive permissionName. The tenants mentioned here can be understood as users who use the above client, and users who use the client can have different roles in some business scenarios. Different roles have different corresponding permissions. For example, users with higher permissions can access some page content, while users with lower permissions cannot access these page contents.

[0065] As for the required gateway service (i.e. how to use the preset gateway to process access requests), for situations where no authentication is required, some release routes that do not require authentication can be configured in the management center, for example: skip-url: - / api / ${api-module} / auth / login - / api / ${api-module} / auth / loginEncrypted / * In the above, each line represents a type of route that does not require authentication, and "*" is a wildcard for the route. At the gateway layer, you need to create a route authorization filter RouteAuthFilter, implement the GlobalFilter global interface and the Order filter sorting interface, rewrite the filter method in the GlobalFilter interface and getOrder in the Order interface, and set the processing priority of this filter to the highest level. The filter method mainly performs unified processing of client access requests to achieve load balancing and forward access requests to downstream services.

[0066] Create a Dubbo service filter, implement the GlobalFilter global interface and the Order filter sorting interface, rewrite the filter method in the GlobalFilter interface and getOrder in the Order interface, set the processing priority of this filter to the second highest level, and also rewrite the Dubbo service management filter method to uniformly process Dubbo service requests and implement generalized calls to downstream Dubbo services.

[0067] It should be noted that for some release routes that do not require authentication configured by the management center, the JSON format can be used for configuration, and the configuration of each route should be in a separate line.

[0068] For the configuration of routing rules, please refer to the following: [ { "id": "dros-ic-platform", "order": 0, "predicates": [ { "name": "Path", "args": { "pattern": " / api / app / dros-ic-platform / **" } } ] "uri": "lb: / / dros-ic-platform", "type": "Dubbo", } ] Configuration ID (id): This field is a unique identifier for the configuration item, used to distinguish different routing configurations in the system. In the above example, it represents the routing configuration for the "dros-ic-platform" service; Configuration order (order): 0. This field defines the priority of the routing configuration, the smaller the value, the higher the priority.

[0069] When multiple routing configurations match the same request, the system will select and execute them in the order of the value of the order field from small to large.

[0070] Predicates: Predicates are used to match access requests. Only access requests that meet the predicates will be processed by the routing configuration. This example contains a Path predicate with the parameter pattern set to / api / app / dros-ic-platform / **, which means that only access requests starting with / api / app / dros-ic-platform / will be matched by this configuration.

[0071] Service address (uri): This field specifies the target service address of the access request. lb stands for load balancing, indicating that the access request will be sent to an instance of the service named dros-ic-platform. The specific instance is selected by the load balancer based on the current system status.

[0072] Routing type (type): Dubbo, this field indicates the type of routing configuration, which means that the routing configuration is designed specifically for Dubbo services, ensuring the efficiency and stability of service calls.

[0073] In order to further illustrate the method provided in the embodiment of the present application, the whole process will be further introduced with a detailed flow chart as follows: Figure 3 shown.

[0074] Figure 3 A detailed flow chart of access request forwarding based on a microservice gateway provided in an embodiment of the present application.

[0075] The user initiates an access request from the client. After receiving the access request, the client may forward the access request carrying the access token to the DNS load balancing device. The DNS further forwards the access request to the gateway service, ie, the above-mentioned preset gateway.

[0076] The preset gateway identifies the access request obtained to determine whether the access request requires authentication. If it is determined that the access request requires authentication, the preset gateway authenticates the access token by remotely calling the authentication microservice and the configured permission information that are uniformly managed in the management center. When it is determined that the authentication is successful, the preset gateway can read the routing rules pre-configured in the management center for the service required for the access request. When it is determined that the authentication is not successful, the preset gateway does not process the access request, and the whole process ends. In addition, if it is determined that authentication is not required, it can be released to enter the subsequent load balancing processing.

[0077] After completing the authentication process, the preset gateway will further process the access request. Specifically, the preset gateway can determine whether the service required by the access request is a Dubbo service based on the routing information identified for the access request. If it is determined to be a Dubbo service, it will be forwarded to the downstream service through a generalized call. The downstream service will process the access request and return a response to the preset gateway. The preset gateway will then return it to the client through unified processing.

[0078] If it is determined that it is not a Dubbo service, the preset gateway can obtain the routing rules from the management center and identify the service type of the downstream service to complete the forwarding processing of the access request.

[0079] Furthermore, the embodiments of the present application can actually be understood as a rewrite of the routing filter, thereby realizing the unified processing of client access requests and the process of load balancing to forward access requests to downstream services. In addition, by rewriting the Dubbo filter, the access requests of the Dubbo service are uniformly processed, and the generalized call to the downstream Dubbo service is realized.

[0080] In an embodiment of the present application, the management center can be deployed in a distributed manner such as a k8s cluster to ensure the availability of the configuration, and can dynamically update the configuration and service status in real time and broadcast it to downstream services to ensure the real-time nature of the configuration.

[0081] In addition, through the k8s cluster, the gateways required by the microservices can be deployed in a distributed manner on multiple machines to ensure the robustness of the system. The deployed gateways complete the mapping and matching of services based on the information carried in the access request and the routing rules preset by the management center.

[0082] In an embodiment of the present application, a corresponding authentication module can be set up. On this basis, after receiving the access request sent by the client, the preset gateway can send the access request to the authentication module. The authentication module receives the access request, reads the administrator's authentication routing list, parses and identifies the token carried by the access request, and returns the authentication result to the preset gateway.

[0083] The above is one or more implementation methods of this specification. Based on the same idea, this specification also provides a corresponding request processing device based on a microservice gateway, such as Figure 4 shown.

[0084] Figure 4 A schematic diagram of a request processing device based on a microservice gateway provided in this specification includes: Receiving module 401, used to receive an access request initiated by a user; The gateway module 402 is used to forward the access request to a preset gateway, so as to determine the service required by the access request through the preset gateway, and obtain the routing rules pre-configured in the management center from the remote management center, wherein the routing rules are configured in a routing file uniformly managed by the management center by registration; The processing module 403 is used to process the access request according to the routing rule.

[0085] Optionally, the access request carries an access token of the user; The gateway module 402 is further used to call the authentication microservice deployed in the management center to authenticate the access token carried in the access request before obtaining the routing rules pre-configured in the management center from the remote management center, and the authentication microservice is pre-created and configured in the management center; The gateway module 402 is specifically configured to obtain, from a remote management center, a routing rule pre-configured in the management center if it is determined that the access token has passed the authentication.

[0086] Optionally, the gateway module 402 is specifically used to identify the access request to determine the routing information corresponding to the access request; if it is determined that the access request needs to be authenticated based on the routing information and the pre-acquired authentication routing list, the authentication microservice deployed in the management center is called to authenticate the access token carried in the access request, and the authentication routing list is pre-written to the management center in the form of configuration information and broadcast by the management center to the preset gateway.

[0087] Optionally, the gateway module 402 is further configured to forward the access request according to the routing rules obtained from the management center if it is determined that no authentication is required for the access request according to the routing information and the authentication routing list.

[0088] Optionally, the gateway module 402 is specifically used to read the routing rules of the service corresponding to the access request in the management center through a preset Dubbo filter, so as to forward the access request through the obtained routing rules.

[0089] Optionally, the processing module 403 is specifically used to determine whether the service required by the access request is a Dubbo service based on the identified routing information corresponding to the access request and the routing rules; if it is determined that the service required by the access request is not the Dubbo service, the access request is routed and forwarded through the preset gateway based on the routing rules.

[0090] Optionally, the processing module 403 is further configured to, if it is determined that the service required by the access request is the Dubbo service, call the downstream Dubbo service through the preset gateway based on a preset generalized calling method.

[0091] This specification also provides a computer-readable storage medium, which stores a computer program, which can be used to execute the above Figure 1 Provides a request processing method based on the microservice gateway.

[0092] This manual also provides Figure 5 The one shown corresponds to Figure 1 A schematic diagram of the electronic device. Figure 5 As shown, at the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, and may also include other hardware required for the business. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it to achieve the above Figure 1 The request processing method based on microservice gateway.

[0093] In the 1990s, it was very clear whether the improvement of a technology was hardware improvement (for example, improvement of the circuit structure of diodes, transistors, switches, etc.) or software improvement (improvement of the method flow). However, with the development of technology, many improvements of the method flow today can be regarded as direct improvements of the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be implemented with hardware entity modules. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask chip manufacturers to design and make dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0094] The controller may be implemented in any suitable manner, for example, the controller may take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (e.g., software or firmware) executable by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, and the memory controller may also be implemented as part of the control logic of the memory. It is also known to those skilled in the art that, in addition to implementing the controller in a purely computer-readable program code manner, the controller may be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller may be considered as a hardware component, and the devices for implementing various functions included therein may also be considered as structures within the hardware component. Or even, the devices for implementing various functions may be considered as both software modules for implementing the method and structures within the hardware component.

[0095] The systems, devices, modules or cells described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0096] For the convenience of description, the above device is described by dividing the functions into various cells. Of course, when implementing this specification, the functions of each cell can be implemented in the same or multiple software and / or hardware.

[0097] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0098] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0099] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0100] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0101] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0102] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0103] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0104] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity 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, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0105] It should be understood by those skilled in the art that the embodiments of this specification may be provided as methods, systems or computer program products. Therefore, this specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0106] This specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0107] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0108] The above description is only an embodiment of the present specification and is not intended to limit the present specification. For those skilled in the art, the present specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present specification shall be included in the scope of the claims of the present specification.

Claims

1. A request processing method based on a microservice gateway, characterized in that: include: Receive access requests initiated by users; Forwarding the access request to a preset gateway to determine the service required by the access request through the preset gateway, and obtaining a routing rule pre-configured in the management center from a remote management center, wherein the routing rule is configured in a routing file uniformly managed by the management center by registration; The access request is processed according to the routing rule.

2. The method according to claim 1, characterized in that The access request carries the access token of the user; Before obtaining the routing rules pre-configured in the management center from the remote management center, the method further includes: Calling an authentication microservice deployed in the management center to authenticate the access token carried in the access request, wherein the authentication microservice is pre-created and configured in the management center; From a remote management center, obtain the routing rules pre-configured in the management center, including: If it is determined that the access token passes the authentication, the routing rules pre-configured in the management center are obtained from the remote management center.

3. The method according to claim 2, characterized in that Calling the authentication microservice deployed in the management center to authenticate the access token carried in the access request, specifically including: Identify the access request to determine routing information corresponding to the access request; If it is determined that authentication is required for the access request based on the routing information and the pre-acquired authentication routing list, the authentication microservice deployed in the management center is called to authenticate the access token carried in the access request. The authentication routing list is pre-written to the management center in the form of configuration information and broadcast by the management center to the preset gateway.

4. The method according to claim 3, characterized in that The method further comprises: If it is determined, based on the routing information and the authentication routing list, that authentication is not required for the access request, the access request is forwarded based on the routing rule obtained from the management center.

5. The method according to claim 4, characterized in that Forwarding the access request according to the routing rules obtained from the management center specifically includes: The routing rules of the service corresponding to the access request in the management center are read through the preset Dubbo filter, so as to forward the access request according to the obtained routing rules.

6. The method according to claim 1, characterized in that Processing the access request according to the routing rule specifically includes: Determine whether the service required by the access request is a Dubbo service according to the identified routing information corresponding to the access request and the routing rule; If it is determined that the service required by the access request is not the Dubbo service, the access request is routed and forwarded through the preset gateway based on the routing rule.

7. The method according to claim 6, characterized in that The method further comprises: If it is determined that the service required by the access request is the Dubbo service, the downstream Dubbo service is called through the preset gateway based on the preset generalized calling method.

8. A request processing device based on a microservice gateway, characterized in that: include: A receiving module, used for receiving an access request initiated by a user; A gateway module, used to forward the access request to a preset gateway, so as to determine the service required by the access request through the preset gateway, and obtain a routing rule pre-configured in the management center from a remote management center, wherein the routing rule is configured in a routing file uniformly managed by the management center by registration; A processing module is used to process the access request according to the routing rule.

9. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the method described in any one of claims 1 to 7 is implemented.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the method described in any one of claims 1 to 7 is implemented.

Images