Micro-service access method and system, service gateway and micro-service basic platform

Abstract

The invention discloses a micro-service access method and system, a service gateway and a micro-service basic platform, and relates to the technical field of gateway development, and the method comprises the steps: creating a service instance corresponding to each micro-service, and storing a first corresponding relation between each micro-service and each service instance; in the service access information corresponding to each micro-service, extracting a first route corresponding to each micro-service, and storing a second corresponding relationship between each micro-service and each first route; extracting a second route in the external request, and determining a target micro-service corresponding to the second route in each micro-service based on the second corresponding relationship; and determining a target service instance corresponding to the target micro-service based on the first corresponding relationship, and responding to the external request through the target service instance. The invention aims to solve the technical problem of how to access the stock micro-service to the service gateway and realize the unified management of the stock micro-service and the increment micro-service.

Description

Technical Field

[0001] The present application relates to the field of gateway technology, and in particular to a microservice access method, system, service gateway, and microservice basic platform. Background Art

[0002] With the rapid adoption of microservices architectures, the importance of service gateways as unified traffic entry points and governance hubs has become increasingly prominent. As businesses grow, enterprises continue to introduce incremental microservices based on new technology architectures. These microservices are designed from the outset to be compatible with the technical specifications and communication protocols of service gateways, enabling quick and smooth integration and management. However, existing microservices built earlier face a distinct dilemma: due to the rapid evolution of technology stacks, with the coexistence of multiple technologies, from early Dubbo (Distributed Unified Business Basic Operations) to modern gRPC (gRPC Remote Procedure Calls), the communication protocols and interface specifications of existing microservices differ significantly from those of service gateways. Forcibly modifying existing microservice code to adapt to service gateways not only requires significant manpower and time, but also risks disrupting the stable operation of existing services. This gap between new and old technologies and the risks of this transformation make gateway integration of existing microservices a major bottleneck in microservices governance.

[0003] Therefore, how to connect existing microservices to the service gateway and achieve unified management of existing microservices and incremental microservices is a technical problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] The main purpose of this application is to provide a microservice access method, system, service gateway and microservice basic platform, aiming to solve the technical problem of how to connect existing microservices to the service gateway and realize unified management of existing microservices and incremental microservices.

[0005] To achieve the above objectives, this application proposes a microservice access method, which includes:

[0006] Create a service instance corresponding to each microservice, and store a first correspondence between each microservice and each service instance, wherein the microservice includes an incremental microservice and an existing microservice. When the microservice is an existing microservice, the service instance corresponding to the existing microservice includes an IP address and a port, and the IP address and port are the IP address and service port of the server where the existing microservice is deployed;

[0007] Extracting the first routes corresponding to the microservices from the service access information corresponding to the microservices, and storing the second correspondences between the microservices and the first routes;

[0008] Extracting a second route from the external request, and determining a target microservice corresponding to the second route in each of the microservices based on the second corresponding relationship;

[0009] A target service instance corresponding to the target microservice is determined based on the first corresponding relationship, and the external request is responded to through the target service instance.

[0010] In one embodiment, the service instance includes an upstream instance, and the step of creating a service instance corresponding to each microservice includes:

[0011] Traverse the predefined microservice online list file to identify the microservice identifier to be connected to the service gateway;

[0012] For any of the microservice identifiers, perform a key-value matching query in the gateway configuration repository according to the microservice identifier to find a preset configuration file corresponding to the microservice identifier;

[0013] Read the configuration information in the preset configuration file and convert the configuration information into an upstream configuration data structure;

[0014] Based on the upstream configuration data structure, dynamically create an upstream instance corresponding to the microservice identifier.

[0015] In one embodiment, before the step of storing the second correspondence between each of the microservices and each of the first routes, the method further includes:

[0016] Extracting the actual domain name identifier corresponding to each microservice from the service access information;

[0017] For any of the actual domain name identifiers, based on a third correspondence between each preset routing table and each preset domain name identifier, matching a target routing table corresponding to the actual domain name identifier;

[0018] The step of storing the second correspondence between each of the microservices and each of the first routes includes:

[0019] For each microservice, the second corresponding relationship between the microservice and the first route is stored in the target routing table corresponding to the microservice.

[0020] In one embodiment, the step of determining, in each of the microservices, a target microservice corresponding to the second route based on the second corresponding relationship includes:

[0021] Identifying the target domain name identifier in the external request, and determining, in each of the routing tables, an actual routing table corresponding to the target domain name identifier based on the third corresponding relationship;

[0022] Based on the second corresponding relationship in the actual routing table, the second route is searched in the actual routing table, and the microservice corresponding to the second route in the actual routing table is used as the target microservice.

[0023] In one embodiment, the step of responding to the external request through the target service instance includes:

[0024] When it is detected that the target microservice is an existing microservice, forward the external request to the IP address and port in the target service instance, so that a server corresponding to the IP address and port responds to the external request;

[0025] In a case where it is detected that the target microservice is an incremental microservice, the external request is processed by the processing logic in the target service instance to respond to the external request.

[0026] In one embodiment, after extracting the second route in the external request, the method further includes:

[0027] Performing authority verification on the second route to obtain an authority verification result;

[0028] When it is detected that the authority verification result indicates that the client that initiated the external request does not have the authority to access the second route, the external request is rejected.

[0029] In one embodiment, the method further comprises:

[0030] Sending heartbeat detection information to the target service instance and receiving heartbeat response information returned by the target service instance;

[0031] Determining the network connectivity of the target service instance according to the heartbeat response information;

[0032] Periodically calling the health check interface of the target service instance to obtain health status data of the target service instance, wherein the health status data includes at least a TCP connection success or an HTTP response code;

[0033] Determining a health status detection result of the target service instance based on the network connectivity and the health status data;

[0034] If the health status detection result indicates that the target service instance is unhealthy, the standby instance of the target microservice is used as a new target service instance, and based on the new target service instance, the step of responding to the external request through the target service instance is performed;

[0035] If the health status detection result indicates that the target service instance is healthy, the step of responding to the external request through the target service instance is performed.

[0036] In addition, to achieve the above objectives, the present application also proposes a microservice access system, which is applied to a service gateway and includes:

[0037] An instance creation module is used to create a service instance corresponding to each microservice and store a first correspondence between each microservice and each service instance, wherein the microservice includes an incremental microservice and an existing microservice. When the microservice is an existing microservice, the service instance corresponding to the existing microservice includes an IP address and a port, and the IP address and port are the IP address and service port of the server where the existing microservice is deployed;

[0038] a routing configuration module, configured to extract, from the service access information corresponding to each of the microservices, the first routes corresponding to each of the microservices, and store a second correspondence between each of the microservices and each of the first routes;

[0039] a target microservice determination module, configured to extract the second route from the external request and determine, based on the second corresponding relationship, a target microservice corresponding to the second route in each of the microservices;

[0040] A request response module is used to determine a target service instance corresponding to the target microservice based on the first corresponding relationship, and respond to the external request through the target service instance.

[0041] In addition, to achieve the above objectives, the present application also proposes a service gateway, which is used to execute the steps of the microservice access method described above.

[0042] In addition, to achieve the above-mentioned purpose, the present application also proposes a microservice basic platform, which includes a service governance center, and the microservice basic platform is connected to a service gateway. The service governance center is used to manage the service gateway, and the service gateway is used to execute the steps of the microservice access method described above.

[0043] One or more technical solutions proposed in this application have at least the following technical effects:

[0044] This application establishes a dynamic mapping relationship between microservices and service instances, and combines it with a routing matching mechanism to achieve unified access and management of existing microservices and incremental microservices in the service gateway. Specifically, this application first creates corresponding service instances for all microservices (existing microservices and incremental microservices), where the instances of existing microservices are directly associated with the IP address and port of their original deployment servers. This not only retains the existing deployment architecture of the existing microservices, but also incorporates them into a unified service instance management system. Then, this application establishes a clear correspondence between microservices and routes by extracting and storing the routing information of each microservice, so that the service gateway can quickly locate the target microservice according to the route in the external request. When an external request arrives, the service gateway first determines the target microservice through routing matching, and then finds the corresponding service instance (for existing microservices, that is, its original server IP and port) according to the pre-established instance mapping relationship, and finally completes the request forwarding. This design allows existing microservices to access the gateway without modification, and incremental microservices can also be managed in a unified manner, achieving seamless integration of the two types of microservices. It can be seen that this application, through the synergy of dual mapping relationships (service-instance, service-route), not only ensures the stability of existing microservices, but also provides consistent routing and access control capabilities for all microservices, ultimately solving the problem of unified access and management of existing microservices and incremental microservices. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0046] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0047] Figure 1 This is a flowchart of the first embodiment of the microservice access method of this application;

[0048] Figure 2 A schematic diagram of the service instance creation process of an embodiment of the microservice access method of this application;

[0049] Figure 3 This is a scenario diagram of an embodiment of the microservice access method of this application;

[0050] Figure 4 This is a schematic diagram of the module structure of the microservice access system according to an embodiment of the present application;

[0051] Figure 5This is a schematic diagram of the microservice infrastructure architecture of an embodiment of the present application.

[0052] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0053] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0054] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0055] Understandably, with the rapid adoption of microservices architectures, the importance of service gateways as unified traffic entry points and governance hubs has become increasingly prominent. As businesses evolve, enterprises continue to introduce incremental microservices based on new technology architectures. These microservices are designed from the outset to be compatible with the technical specifications and communication protocols of service gateways, enabling fast and smooth integration and management. However, existing microservices built earlier face a distinct dilemma: due to the rapid evolution of technology stacks, with the coexistence of multiple technologies, from early Dubbo to modern gRPC, the communication protocols and interface specifications of existing microservices differ significantly from those of service gateways. Forcibly modifying existing microservice code to adapt to service gateways would not only require significant manpower and time, but could also impact the stable operation of existing services. This gap between new and legacy technologies and the risks of this transformation make gateway integration of existing microservices a major bottleneck in microservices governance.

[0056] Therefore, how to connect existing microservices to the service gateway and achieve unified management of existing microservices and incremental microservices is a technical problem that needs to be solved by those skilled in the art.

[0057] To solve the above problems, the present application establishes a dynamic mapping relationship between microservices and service instances, and combines it with a routing matching mechanism to achieve unified access and management of existing microservices and incremental microservices in the service gateway. Specifically, the present application first creates corresponding service instances for all microservices (existing microservices and incremental microservices), where the instances of existing microservices are directly associated with the IP address and port of their original deployment servers. This not only retains the existing deployment architecture of the existing microservices, but also incorporates them into a unified service instance management system. Then, the present application establishes a clear correspondence between microservices and routes by extracting and storing the routing information of each microservice, so that the service gateway can quickly locate the target microservice according to the route in the external request. When an external request arrives, the service gateway first determines the target microservice through routing matching, and then finds the corresponding service instance (for existing microservices, that is, its original server IP and port) according to the pre-established instance mapping relationship, and finally completes the request forwarding. This design allows existing microservices to access the gateway without modification, and incremental microservices can also be managed in a unified manner, achieving seamless integration of the two types of microservices. It can be seen that this application, through the synergy of dual mapping relationships (service-instance, service-route), not only ensures the stability of existing microservices, but also provides consistent routing and access control capabilities for all microservices, ultimately solving the problem of unified access and management of existing microservices and incremental microservices.

[0058] It should be noted that the execution entity of the microservice access method of the present application can be a service gateway with data processing, network communication and program running functions.

[0059] This application embodiment provides a microservice access method, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the microservice access method of this application.

[0060] In this embodiment, the microservice access method includes steps S10 to S40:

[0061] Step S10: Create a service instance corresponding to each microservice and store a first correspondence between each microservice and each service instance. The microservice includes incremental microservices and existing microservices. When the microservice is an existing microservice, the service instance corresponding to the existing microservice includes an IP address and a port. The IP address and port are the IP address and port of the server where the existing microservice is deployed.

[0062] It can be understood that a service instance is a virtual entity used to process external requests. Therefore, in order for the service gateway to respond to external requests, the service gateway needs to establish service instances corresponding to each microservice.

[0063] Please refer to Figure 2In a feasible implementation, the service instance includes an upstream instance, and the above step S10 includes:

[0064] Step S101, traverse the predefined microservice online list file to identify the microservice identifier to be connected to the service gateway;

[0065] Step S102: for any microservice identifier, perform a key-value matching query in the gateway configuration repository according to the microservice identifier to find a preset configuration file corresponding to the microservice identifier;

[0066] Step S103: Read the configuration information in the preset configuration file and convert the configuration information into an upstream configuration data structure;

[0067] It should be noted that the upstream configuration data structure is an internal data structure used to describe and organize backend service cluster information.

[0068] Step S104: Dynamically create an upstream instance corresponding to the microservice identifier based on the upstream configuration data structure.

[0069] It is understood that the service gateway has a microservice launch list file and a gateway configuration repository. The microservice launch list file includes the names of all microservices that the service gateway is preparing to access, and the gateway configuration repository includes the configuration information required to generate instances of each microservice in the microservice launch list file. Typically, the microservice launch list file and the gateway configuration repository are pre-written to the service gateway.

[0070] Therefore, when the service gateway starts, it can traverse all configuration files in the gateway configuration repository based on the microservice online list file, and then find the microservice management file corresponding to the microservice name in the configuration file. Furthermore, the microservice configuration information in the microservice management file can be converted into the data structure required to create the upstream instance. Based on each data structure, the service instance of each microservice in the microservice online list is constructed respectively, and the first correspondence between each microservice and each service instance is stored, so that after determining the microservice to be called, the corresponding service instance can be called.

[0071] Exemplarily, the service gateway traverses the predefined microservice online list file (usually in YAML or JSON format) through a file parser and extracts the unique identifier of each microservice by line. For example, in a list file in YAML format, the service gateway locates the service_id or name field and uses it as the microservice identifier. During this process, the parser automatically filters comment lines and entries in invalid formats, and performs a validity check on the extracted identifier to ensure that it complies with predefined naming specifications (such as only containing alphanumeric characters and hyphens). The extracted microservice identifier will be stored in a temporary cache queue for subsequent configuration query operations.

[0072] The service gateway then performs a key-value matching query in the gateway configuration repository (such as Redis or a configuration center) using the microservice identifier as the key. The configuration information stored in the repository is hierarchical, with each microservice corresponding to an independent configuration node, containing routing rules, load balancing policies, health check parameters, and more. For example, the value corresponding to the key microservice:user-service:config might be a JSON object containing a list of backend instances of the service, timeout settings, and retry policies. The query results are deserialized into an in-memory configuration object to prepare for subsequent data structure conversion.

[0073] During the configuration information conversion phase, the service gateway maps the read configuration object to the upstream configuration data structure. This data structure is a specially designed memory model that contains the following core components: service metadata (such as service name and version), a list of backend instances (each instance contains IP address, port, weight, etc.), load balancing algorithms (such as polling, IP hash), health check configuration (such as check frequency, timeout threshold), and circuit breaker strategy (such as error rate threshold). During the conversion process, the service gateway will perform type conversion and validity verification on the configuration value. For example, it will convert the weight value of the string type in the configuration file into an integer and check whether it is within the legal range (1-100). For missing optional configuration items, the service gateway will automatically fill in the default value to ensure the integrity of the data structure.

[0074] Finally, based on the converted upstream configuration data structure, the service gateway dynamically creates the corresponding upstream instance. This process involves multiple steps: First, the service gateway instantiates a load balancer (such as RoundRobinLoadBalancer or ConsistentHashLoadBalancer) that matches the configuration strategy through the reflection mechanism; second, it creates a connection pool for each backend instance and starts an asynchronous monitoring task based on the health check configuration; then, it registers the instantiated component with the gateway's routing engine to establish a mapping relationship from the request path to the upstream instance; finally, it notifies all gateway nodes to update the local routing table through the publish-subscribe mechanism. After creation, the upstream instance will be in a ready state, receiving and forwarding external requests to the backend microservice cluster in real time, while continuously monitoring the health status of the backend instance and automatically triggering the circuit breaker and traffic switching mechanism when a fault is detected.

[0075] Additionally, it's understandable that the microservice launch list may contain existing microservices that don't support the service gateway technology stack. To prevent code modifications that could render these existing microservices unavailable, you need to include the server IP address and port number of the deployed microservice when creating a service instance.

[0076] Step S20: extracting the first routes corresponding to the microservices from the service access information corresponding to the microservices, and storing the second correspondences between the microservices and the first routes.

[0077] It should be noted that the service access information of the microservice includes information such as the microservice name, version, URL path, service registration center, etc., wherein the URL path includes the first route. Specifically, the URL path can be matched by a regular expression to extract the first route in the URL. It is understandable that the first route in this application refers to the route extracted from the URL path. After extracting the first route, the second correspondence between the microservice and the first route can be stored in the form of a key-value pair, so that the service gateway can respond to external requests in combination with the first correspondence and the second correspondence.

[0078] Step S30: extracting the second route in the external request, and determining a target microservice corresponding to the second route in each microservice based on the second corresponding relationship;

[0079] It is understandable that the external request may also include a URL path, and the second route in this application refers to the route extracted from the URL path in the external request.

[0080] In this embodiment, after extracting the second route, the service gateway can use the second route as the first route to be matched based on the second correspondence between the stored microservice name and the first route, thereby searching the second correspondence for the microservice corresponding to the first route to be matched. Furthermore, the matched microservice can be used as the target microservice. Thus, for a received external request, the service gateway can determine the microservice that the external request intends to call based on the second route.

[0081] Step S40: Determine a target service instance corresponding to the target microservice based on the first corresponding relationship, and respond to the external request through the target service instance.

[0082] In this embodiment, after determining the target microservice, the target microservice can be used as the microservice to be matched based on the first correspondence between the microservice and the service instance, and the service instance corresponding to the microservice to be matched can be determined in the first correspondence, thereby determining the target service instance. Then, the external request can be forwarded to the target service instance, and the external request can be responded to by the target service instance.

[0083] In a feasible implementation manner, the above step S40 includes:

[0084] Step S401: When it is detected that the target microservice is an existing microservice, the external request is forwarded to the IP address and port in the target service instance, so that the server corresponding to the IP address and port responds to the external request;

[0085] It is understood that the configuration information corresponding to the microservice has an identification bit that identifies whether the microservice is an existing microservice. Therefore, after confirming the target microservice, the identification bit used to identify the microservice type in the configuration information of the target microservice can be read. If it is detected that the target microservice is an existing microservice, the external request is forwarded to the IP address and port in the target service instance, so that the server corresponding to the IP address and port calls the target microservice to respond to the external request.

[0086] Step S402: When it is detected that the target microservice is an incremental microservice, the external request is processed by the processing logic in the target service instance to respond to the external request.

[0087] If the target microservice is an incremental microservice, this indicates that the technology stack of the target microservice is compatible with that of the service gateway. Therefore, when a service instance of the target microservice is created, it has complete request processing logic. Therefore, external requests can be processed by the processing logic in the target service instance, achieving the goal of responding to external requests.

[0088] Please refer to Figure 3 , Figure 3 This is a scene diagram of an embodiment of the microservice access method of this application. Figure 3 In the example, the number of microservices is N and the number of external requests is z. For any of the z external requests, the service gateway will determine the target microservice corresponding to the external request from the N microservices, and then determine the target service instance to handle the external request, thereby achieving the purpose of accessing the microservice.

[0089] In this embodiment, the present application realizes the unified access and management of existing microservices and incremental microservices in the service gateway by establishing a dynamic mapping relationship between microservices and service instances, and combining it with a routing matching mechanism. Specifically, the present application first creates corresponding service instances for all microservices (existing microservices and incremental microservices), wherein the instances of existing microservices are directly associated with the IP address and port of their original deployment servers, which not only retains the existing deployment architecture of the existing microservices, but also incorporates them into a unified service instance management system. Then, the present application establishes a clear correspondence between microservices and routes by extracting and storing the routing information of each microservice, so that the service gateway can quickly locate the target microservice according to the route in the external request. When an external request arrives, the service gateway first determines the target microservice through routing matching, and then finds the corresponding service instance (for existing microservices, that is, its original server IP and port) according to the pre-established instance mapping relationship, and finally completes the request forwarding. This design allows existing microservices to access the gateway without modification, and incremental microservices can also be managed in a unified manner, realizing seamless integration of the two types of microservices. It can be seen that this application, through the synergy of dual mapping relationships (service-instance, service-route), not only ensures the stability of existing microservices, but also provides consistent routing and access control capabilities for all microservices, ultimately solving the problem of unified access and management of existing microservices and incremental microservices.

[0090] Furthermore, based on the first embodiment of the microservice access method of the present application, a second embodiment of the microservice access method of the present application is proposed.

[0091] In this embodiment, before the above step S20, the method further includes:

[0092] Step S40: extract the actual domain name identifier corresponding to each microservice from each service access information;

[0093] Step S50: For any actual domain name identifier, based on the third correspondence between each preset routing table and each preset domain name identifier, matching the target routing table corresponding to the actual domain name identifier;

[0094] It is understood that in the first embodiment described above, the correspondence between the first route and the microservice can be recorded in a file. However, in this embodiment, the various route files can be distinguished by domain name identifiers, so that the first routes under different domain names will be stored in different routing tables, which can improve query efficiency.

[0095] For example, if the URL in the service access information of microservice A is https: / / www.xxxyyy1234.com / user / info, the domain name identifier of the microservice can be obtained through regular expression matching as: www.xxxyyy1234.com. Furthermore, if in the pre-set third correspondence, the routing table corresponding to the domain name www.xxxyyy1234.com is routing table 3, then routing table 3 is the target routing table for www.xxxyyy1234.com.

[0096] Based on this, the above step S20 includes:

[0097] Step S201: For each microservice, store the second correspondence between the microservice and the first route in a target routing table corresponding to the microservice.

[0098] It is understandable that, under the condition that there is a correspondence between the domain name and the routing table, and between the domain name and the microservice, there is also a correspondence between the microservice and the routing table. Therefore, for each microservice, the second correspondence between the microservice and the first route can be stored in the target routing table corresponding to the microservice.

[0099] For example, for the above-mentioned microservice A, the first route is “ / user / info”, so the corresponding relationship {microservice A: “ / user / info”} will be stored in routing table 3.

[0100] In a feasible implementation manner, the above step S30 includes:

[0101] Step S301, identifying a target domain name identifier in an external request, and determining an actual routing table corresponding to the target domain name identifier in each routing table based on a third corresponding relationship;

[0102] It is understood that the target domain name identifier refers to the domain name identifier extracted from the external request. After obtaining the target domain name identifier of the external request, based on the third correspondence between the domain name identifier and the routing table, the routing table that matches the target domain name identifier can be searched in the third correspondence to obtain the actual routing table.

[0103] Step S302: Based on the second corresponding relationship in the actual routing table, search for the second route in the actual routing table, and use the microservice corresponding to the second route in the actual routing table as the target microservice.

[0104] It is understandable that after the actual routing table is determined, the microservice corresponding to the second route can be searched in the actual routing table, thereby obtaining the target microservice corresponding to the second route.

[0105] In this embodiment, the present application sets up multiple routing tables based on the domain name, and stores the routing information of the microservice in the routing table corresponding to the domain name. When an external request is received, the actual routing table can be quickly located, thereby improving the efficiency of matching the target microservice.

[0106] Furthermore, based on the above-mentioned embodiments of the microservice access method of the present application, a third embodiment of the microservice access method of the present application is proposed.

[0107] In this embodiment, in the above step of extracting the second route in the external request, the method further includes:

[0108] Step S60, performing authority verification on the second route to obtain an authority verification result;

[0109] Step S70: When it is detected that the authority verification result indicates that the client that initiates the external request does not have the authority to access the second route, the external request is rejected.

[0110] In this embodiment, during the process of performing permission verification on the second route, this solution adopts a multi-dimensional and hierarchical verification mechanism to ensure the accuracy and security of access control.

[0111] First, after an external request reaches the service gateway and the second route is extracted, the system parses the identity information carried in the request based on the preset permission policy. This identity information is usually included in the request header or request parameters, and common forms include JSON Web Token (JWT), OAuth 2.0 tokens, or custom authentication strings. Taking JWT as an example, the system will verify its signature to confirm that the token has not been tampered with, and parse the information contained in it, such as the user ID, user role, and permission scope.

[0112] Secondly, the system matches the parsed user permission information with the pre-defined routing permission rules. Routing permission rules are stored in the form of structured data, such as using JSON format to build a permission configuration file, which defines in detail the accessible microservices corresponding to each second route. For example, for the second route " / admin / user", the permission rule may set that only the caller microservice " / some / caller" can access it. During the matching process, the system will determine whether the microservice route " / admin / user" can be accessed based on the configuration information of " / some / caller". This configuration information is applied for by the caller microservice application administrator of " / some / caller" in the service governance center, and reviewed by the service provider application administrator of "admin / user / ". After the review is passed, it is sent to the caller configuration of the service gateway.

[0113] Furthermore, the system performs dynamic permission verification logic. This step combines contextual information from the request, such as the source IP address, to reconfirm permissions. For example, certain sensitive routes may only allow access from requests originating from a specific IP address range. The system obtains the source IP address of the request in real time and compares it with the preset policy. If the current source IP address is not within the whitelist, the request is deemed denied access.

[0114] When the above verification process is completed, the system will generate a permission verification result. If it is detected that the permission verification result indicates that the client initiating the external request does not have permission to access the second route, the service gateway will immediately reject the external request and return a clear error response to the client. The error response usually contains an HTTP status code (such as 403Forbidden) and a detailed error description, such as "You do not have permission to access this resource." At the same time, relevant access logs are recorded, including the request time, request URL, client IP address, and the reason for rejection, so as to facilitate subsequent security audits and troubleshooting.

[0115] Of course, when it is detected that the permission verification result indicates that the client initiating the external request has the permission to access the second route, the step of determining the target microservice can be performed.

[0116] In this embodiment, the present application maintains the security of microservice calls through permission restrictions, thereby improving the security of microservice calls.

[0117] Furthermore, based on the above-mentioned embodiments of the microservice access method of the present application, a fourth embodiment of the microservice access method of the present application is proposed.

[0118] In this embodiment, the method further includes:

[0119] Step S80: Send heartbeat detection information to the target service instance, and receive heartbeat response information returned by the target service instance;

[0120] Step S90, determining the network connectivity of the target service instance according to the heartbeat response information;

[0121] Step S100: Periodically call the health check interface of the target service instance to obtain health status data of the target service instance, where the health status data at least includes a TCP connection success or an HTTP response code;

[0122] Step S110, determining a health status detection result of the target service instance based on the network connectivity and health status data;

[0123] Step S120: If the health status detection result indicates that the target service instance is unhealthy, the standby instance of the target microservice is used as a new target service instance, and based on the new target service instance, the step of responding to the external request through the target service instance is executed;

[0124] Step S130: If the health status detection result indicates that the target service instance is healthy, the step of responding to the external request through the target service instance is executed.

[0125] First, the service gateway sends a heartbeat message to the target service instance at a fixed frequency (for example, once every 3 seconds). The heartbeat message is usually a lightweight network request data packet, that is, a single TCP connection, to reduce network overhead and service instance processing pressure.

[0126] After receiving the heartbeat detection information, the target service instance will immediately return a heartbeat response message. This response message contains the time when the service instance received the request and the instance's unique identifier. The service gateway can calculate the network latency by comparing the send and receive times. If no response is received within a preset timeout (such as 5 seconds), it will preliminarily determine that there is a problem with the network connectivity of the target service instance and mark it as unreachable.

[0127] Secondly, after completing the preliminary judgment of network connectivity, the service gateway will periodically (e.g., every 10 seconds) call the health check interface exposed by the target service instance. The health check interface is designed using protocols such as TCP or HTTP, and returns information such as TCP connection success or HTTP response code. The specific expected HTTP response content can be customized by each target service. If the HTTP return status code is not 2xx or 3xx, it is usually judged as a failure. The HTTP response content will be compared with the customized return content of the target service. If the return content contains the expected customized content, the health check is judged to be successful, otherwise it is judged to be a health check failure.

[0128] The service gateway then performs a comprehensive analysis of the health check data to determine the final health status of the target service instance. The specific judgment logic is as follows: if three consecutive health checks fail, the target service instance is considered unhealthy; if two consecutive health checks succeed, the target service instance is considered healthy.

[0129] When the health status test results indicate that the target service instance is unhealthy, the service gateway immediately initiates the standby instance switching process. First, a healthy standby instance is selected from the standby instance list corresponding to the target microservice. The original service instances are then selected in the order of the selected results. After the switch is complete, the service gateway reroutes external requests to the new target service instance and continues to execute the steps of responding to external requests through the target service instance to ensure the continuity of request processing. If the health status test results indicate that the target service instance is healthy, the service gateway directly executes the steps of responding to external requests through the target service instance, forwarding the external request to the target service instance for processing, and monitoring its health status in real time to prepare for the next round of testing. Throughout the entire process, the service gateway also records the results of each health test, the time and reason of the switch operation, and other information to form a complete health status log, which facilitates operation and maintenance personnel to trace faults and optimize performance.

[0130] In this embodiment, the present application can avoid the situation where an unhealthy target service instance responds incorrectly or responds untimely when processing external requests by detecting the health status of the target service instance. It can be seen that the present application improves the reliability of microservice responses by detecting the health status of the target service instance.

[0131] In addition, in a feasible implementation, the service gateway can also support a variety of service governance functions, such as gray release configuration, static instance configuration, dynamic registration configuration, load balancing configuration, current limiting and circuit breaker configuration, unified authentication configuration, reverse proxy configuration, pre-processing configuration, site forwarding configuration and other functions. In addition, the service gateway can also be developed using the vertx framework, and through the router and context RoutingContext, external requests are processed layer by layer according to the service governance requirements of the microservice configuration. In a feasible implementation, the configuration file of the service gateway is stored in the configuration center. The service governance center can create and edit configuration files by calling the interface of the configuration center to realize the registration, online launch and configuration management of microservices on the service gateway. In addition, users can log in to their accounts to manage the services within their authority in the service governance center, and adjust the specific configuration of the various policies provided by the service gateway according to needs to improve user experience.

[0132] It should be noted that the above examples are only used to understand this application and do not constitute a limitation on the microservice access method of this application. More simple transformations based on this technical concept are all within the scope of protection of this application.

[0133] This application also provides a microservice access system, which is applied to the service gateway. Figure 4 , the microservice access system includes:

[0134] An instance creation module 10 is configured to create a service instance corresponding to each microservice and store a first correspondence between each microservice and each service instance, wherein the microservice includes an incremental microservice and an existing microservice. When the microservice is an existing microservice, the service instance corresponding to the existing microservice includes an IP address and a port, and the IP address and port are the IP address and service port of the server where the existing microservice is deployed.

[0135] The routing configuration module 20 is configured to extract the first routes corresponding to the microservices from the service access information corresponding to the microservices, and store the second correspondence between the microservices and the first routes.

[0136] a target microservice determination module 30, configured to extract the second route from the external request and determine, based on the second corresponding relationship, a target microservice corresponding to the second route in each of the microservices;

[0137] The request response module 40 is configured to determine a target service instance corresponding to the target microservice based on the first corresponding relationship, and respond to the external request through the target service instance.

[0138] In one embodiment, the service instance includes an upstream instance. The instance creation module 10 is further configured to:

[0139] Traverse the predefined microservice online list file to identify the microservice identifier to be connected to the service gateway;

[0140] For any of the microservice identifiers, perform a key-value matching query in the gateway configuration repository according to the microservice identifier to find a preset configuration file corresponding to the microservice identifier;

[0141] Read the configuration information in the preset configuration file and convert the configuration information into an upstream configuration data structure;

[0142] Based on the upstream configuration data structure, dynamically create an upstream instance corresponding to the microservice identifier.

[0143] In one embodiment, the microservice access system further includes:

[0144] A domain name extraction module is used to extract the actual domain name identifier corresponding to each of the microservices from the service access information;

[0145] a routing table matching module, configured to match, for any of the actual domain name identifiers, a target routing table corresponding to the actual domain name identifier based on a third correspondence between each preset routing table and each preset domain name identifier;

[0146] Based on this, the routing configuration module 20 is further configured to:

[0147] For each microservice, the second corresponding relationship between the microservice and the first route is stored in the target routing table corresponding to the microservice.

[0148] In one embodiment, the target microservice determination module 30 is further configured to:

[0149] Identifying the target domain name identifier in the external request, and determining, in each of the routing tables, an actual routing table corresponding to the target domain name identifier based on the third corresponding relationship;

[0150] Based on the second corresponding relationship in the actual routing table, the second route is searched in the actual routing table, and the microservice corresponding to the second route in the actual routing table is used as the target microservice.

[0151] In one embodiment, the request response module 40 is further configured to:

[0152] When it is detected that the target microservice is an existing microservice, forward the external request to the IP address in the target service instance, so that the server corresponding to the IP address responds to the external request;

[0153] In a case where it is detected that the target microservice is an incremental microservice, the external request is processed by the processing logic in the target service instance to respond to the external request.

[0154] In one embodiment, the microservice access system further includes:

[0155] An authority verification module, configured to perform authority verification on the second route and obtain an authority verification result;

[0156] The request rejection module is configured to reject the external request when it is detected that the authority verification result indicates that the client that initiates the external request does not have the authority to access the second route.

[0157] In one embodiment, the microservice access system further includes:

[0158] A heartbeat detection module, configured to send heartbeat detection information to the target service instance and receive heartbeat response information returned by the target service instance;

[0159] A connectivity determination module is configured to determine the network connectivity of the target service instance based on the heartbeat response information;

[0160] A health status data acquisition module is used to periodically call the health check interface of the target service instance to obtain the health status data of the target service instance, wherein the health status data at least includes a TCP connection success or an HTTP response code;

[0161] A status assessment module, configured to determine a health status detection result of the target service instance based on the network connectivity and the health status data;

[0162] a standby activation module, configured to use the standby instance of the target microservice as a new target service instance if the health status detection result indicates that the target service instance is unhealthy, and execute the step of responding to the external request through the target service instance based on the new target service instance;

[0163] The switching module is configured to execute the step of responding to the external request through the target service instance if the health status detection result indicates that the target service instance is healthy.

[0164] The microservice access system provided in this application, employing the microservice access method of the aforementioned embodiment, can address the technical problem of how to connect existing microservices to a service gateway and achieve unified management of existing and incremental microservices. Compared to the prior art, the beneficial effects of the microservice access system provided in this application are the same as those of the microservice access method provided in the aforementioned embodiment. Other technical features of the microservice access system are the same as those disclosed in the aforementioned embodiment and are not further elaborated here.

[0165] The present application also provides a service gateway, which can execute the microservice access method in the above-mentioned embodiment 1.

[0166] It should be noted that the service gateway is used to handle the routing, filtering, conversion and security of external requests. It can provide one or more functions including but not limited to load balancing, current limiting and circuit breaking, grayscale release, unified authentication, cross-site forwarding, etc.

[0167] Among them, load balancing refers to distributing incoming network traffic (requests) to multiple backend servers or service instances in a relatively balanced manner. Current limiting refers to limiting the number of requests (or rate) allowed to pass through the system per unit time. Circuit breaking is a fault protection mechanism. For example, when a downstream service is detected to have failed continuously or responded too slowly, it automatically stops sending requests to it temporarily ("opening" the circuit breaker), and directly fails quickly or returns a preset fallback response. Grayscale release refers to gradually and controllably pushing a new version of an application or service to a small number of users or traffic, while most of the traffic still uses the old version. After confirming that the new version is running stably, the proportion of the new version traffic is gradually increased until the old version is completely replaced. Unified authentication refers to the centralized processing of identity authentication and authorization verification for all incoming requests. Cross-site forwarding refers to the gateway forwarding received requests to backend services located in different physical locations, network areas, or even different data centers.

[0168] The service gateway provided in this application adopts the microservice access method in the above embodiment to solve the technical problem of how to connect existing microservices to the service gateway and realize the unified management of existing microservices and incremental microservices. Compared with the existing technology, the beneficial effects of the service gateway provided in this application are the same as those of the microservice access method provided in the above embodiment, and the other technical features of the service gateway are the same as those disclosed in the method of the previous embodiment, which will not be repeated here.

[0169] The present application also provides a microservice basic platform, which includes a service governance center, and the microservice basic platform is connected to a service gateway. The service governance center is used to manage the service gateway, and the service gateway is used to execute the steps of the microservice access method as described above.

[0170] It should be noted that the microservice infrastructure platform can connect to one or more service gateways and manage these connected service gateways through the service governance center, such as creating and updating configuration files, configuring service gateway policies (such as routing, current limiting, authentication, circuit breaking, logging rules, etc.), triggering hot updates, etc. The service governance center communicates with other components through aggregation services, such as calling the configuration center and registration center interfaces, and calling the service gateway management interface.

[0171] In addition, the service governance center serves as a centralized management console, and relevant personnel also manage the platform through the service governance center, including service registration review, request routing management, platform usage dashboard, platform data health check, etc.

[0172] Furthermore, in order to improve the security of operations performed by relevant personnel through the service governance center, the data configured in the service governance center can also be verified, and warnings or rejections can be given for risky behaviors; a preview function can be provided when the policy is modified for relevant personnel to refer to the configuration effect; when performing configurations related to business service nodes, real-time node detection is supported to ensure the availability of service nodes; process management is increased, and all configuration changes require another relevant person to review the policy, support pre-distribution of configurations during the review, and provide application administrators with the ability to send request data verification policies, etc.

[0173] The microservices infrastructure platform is used to take over Internet request access, perform domain name management, HTTPS (HyperTextTransfer Protocol Secure, Hypertext Transfer Security Protocol) offloading, and execute configuration governance policies before transferring the request load to the business microservices. Figure 5 As shown, a customer initiates a request over the internet using the HTTPS protocol. The request first reaches the DMZ (Demilitarized Zone) of the computer room. In the DMZ, the access service receives the customer's HTTPS request and offloads it, handling HTTPS protocol-related tasks. It then forwards the request to the intranet's service gateway cluster (i.e., the service gateway accessed by the microservices infrastructure platform). After receiving the request, the service gateway cluster forwards it to the business microservice cluster. The business microservice cluster handles specific business logic, such as data processing and business calculations. Using a load balancing mechanism, the business microservice cluster distributes requests to multiple service instances, improving system availability and performance. After processing the request, the business microservice cluster returns the response to the access service through the service gateway cluster. The access service then returns the response to the customer via the HTTPS protocol. Furthermore, the service gateway cluster implements a series of configuration governance strategies, such as service routing: routing requests to the correct microservice based on the requested URL or other information; request processing: performing necessary processing on requests, such as authentication and authorization; grayscale release: gradually releasing new versions of services to some users for testing and feedback collection; current limiting and circuit breaking: limiting request traffic when the service is overloaded to prevent system crashes; health checks: regularly checking the health status of services to ensure service availability; unified authentication: unified processing of user authentication and authorization; computer room forwarding: forwarding requests to different computer rooms as needed. The service gateway cluster performs service registration and configuration management through the allocation center. The allocation center supports hot updates and service discovery of services to ensure dynamic updates and availability of services.

[0174] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0175] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0176] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0177] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0178] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A microservice access method, characterized in that: The microservice access method is applied to a service gateway, and the microservice access method includes: Create a service instance corresponding to each microservice, and store a first correspondence between each microservice and each service instance, wherein the microservice includes an incremental microservice and an existing microservice. When the microservice is an existing microservice, the service instance corresponding to the existing microservice includes an IP address and a port, and the IP address and port are the IP address and service port of the server where the existing microservice is deployed; Extracting the first routes corresponding to the microservices from the service access information corresponding to the microservices, and storing the second correspondences between the microservices and the first routes; Extracting a second route from the external request, and determining a target microservice corresponding to the second route in each of the microservices based on the second corresponding relationship; A target service instance corresponding to the target microservice is determined based on the first corresponding relationship, and the external request is responded to through the target service instance.

2. The microservice access method according to claim 1, wherein: The service instance includes an upstream instance. The steps of creating a service instance corresponding to each microservice include: Traverse the predefined microservice online list file to identify the microservice identifier to be connected to the service gateway; For any of the microservice identifiers, perform a key-value matching query in the gateway configuration repository according to the microservice identifier to find a preset configuration file corresponding to the microservice identifier; Read the configuration information in the preset configuration file and convert the configuration information into an upstream configuration data structure; Based on the upstream configuration data structure, dynamically create an upstream instance corresponding to the microservice identifier.

3. The microservice access method according to claim 1, wherein: Before the step of storing the second correspondence between each of the microservices and each of the first routes, the method further includes: Extracting the actual domain name identifier corresponding to each microservice from the service access information; For any of the actual domain name identifiers, based on a third correspondence between each preset routing table and each preset domain name identifier, matching a target routing table corresponding to the actual domain name identifier; The step of storing the second correspondence between each of the microservices and each of the first routes includes: For each microservice, the second corresponding relationship between the microservice and the first route is stored in the target routing table corresponding to the microservice.

4. The microservice access method according to claim 3, wherein: The step of determining, in each of the microservices, a target microservice corresponding to the second route based on the second corresponding relationship includes: Identifying the target domain name identifier in the external request, and determining, in each of the routing tables, an actual routing table corresponding to the target domain name identifier based on the third corresponding relationship; Based on the second corresponding relationship in the actual routing table, the second route is searched in the actual routing table, and the microservice corresponding to the second route in the actual routing table is used as the target microservice.

5. The microservice access method according to claim 1, wherein: The step of responding to the external request through the target service instance includes: When it is detected that the target microservice is an existing microservice, forward the external request to the IP address and port in the target service instance, so that a server corresponding to the IP address and port responds to the external request; In a case where it is detected that the target microservice is an incremental microservice, the external request is processed by the processing logic in the target service instance to respond to the external request.

6. The microservice access method according to claim 1, wherein: After the step of extracting the second route in the external request, the method further includes: Performing authority verification on the second route to obtain an authority verification result; When it is detected that the authority verification result indicates that the client that initiated the external request does not have the authority to access the second route, the external request is rejected.

7. The microservice access method according to claim 1, wherein: The method further comprises: Sending heartbeat detection information to the target service instance and receiving heartbeat response information returned by the target service instance; Determining the network connectivity of the target service instance according to the heartbeat response information; Periodically calling the health check interface of the target service instance to obtain health status data of the target service instance, wherein the health status data includes at least a TCP connection success or an HTTP response code; Determining a health status detection result of the target service instance based on the network connectivity and the health status data; If the health status detection result indicates that the target service instance is unhealthy, the standby instance of the target microservice is used as a new target service instance, and based on the new target service instance, the step of responding to the external request through the target service instance is performed; If the health status detection result indicates that the target service instance is healthy, the step of responding to the external request through the target service instance is performed.

8. A microservice access system, characterized in that: The microservice access system is applied to the service gateway, and the microservice access system includes: An instance creation module is used to create a service instance corresponding to each microservice and store a first correspondence between each microservice and each service instance, wherein the microservice includes an incremental microservice and an existing microservice. When the microservice is an existing microservice, the service instance corresponding to the existing microservice includes an IP address and a port, and the IP address and port are the IP address and service port of the server where the existing microservice is deployed; a routing configuration module, configured to extract, from the service access information corresponding to each of the microservices, the first routes corresponding to each of the microservices, and store a second correspondence between each of the microservices and each of the first routes; a target microservice determination module, configured to extract the second route from the external request and determine, based on the second corresponding relationship, a target microservice corresponding to the second route in each of the microservices; A request response module is used to determine a target service instance corresponding to the target microservice based on the first corresponding relationship, and respond to the external request through the target service instance.

9. A service gateway, characterized in that: The service gateway is used to execute the steps of the microservice access method according to any one of claims 1 to 7.

10. A microservices infrastructure platform, characterized in that: The microservice basic platform includes a service governance center, and the microservice basic platform is connected to a service gateway. The service governance center is used to manage the service gateway, and the service gateway is used to execute the steps of the microservice access method as described in any one of claims 1 to 7.

Images