Micro-service request method and system, micro-service gateway device and electronic equipment

Abstract

The invention provides a micro-service request method and system, a micro-service gateway device and electronic equipment, and relates to the technical field of micro-service architecture. The method comprises the following steps: addressing an access gateway instance to an external service registration center through a calling direction to obtain a calling address of an access gateway; sending a micro-service request to an access gateway through a calling party based on a calling address of the access gateway; addressing the proxy gateway instance through the internal service registration center to obtain a calling address of the proxy gateway; forwarding the micro-service request to the proxy gateway through the access gateway based on the calling address of the proxy gateway; forwarding the micro-service request to a corresponding micro-service in the first cluster through the proxy gateway; and the internal service registration center, the access gateway and the proxy gateway are respectively deployed in the first cluster by utilizing a host network mode. The problem that the efficiency of the micro-service request is affected due to the fact that the current API gateway cluster needs to forward the request to the application instance through the Ingress of the cluster is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of micro-service architecture, and in particular to a micro-service request method, a micro-service request system, a micro-service gateway device and an electronic device. BACKGROUND

[0002] Kubernetes (k8s) provides a cluster container orchestration mechanism, which enables application deployment in a distributed manner by managing and scheduling containerized micro-services.

[0003] Please refer to Figure 2 , the current micro-service gateway of the k8s cluster deploys an API gateway cluster in front of the cluster, the API gateway cluster forwards micro-service requests to the internal Ingress of the cluster through SLB, and the Ingress forwards the micro-service requests to the corresponding service. Since the current API gateway cluster needs to forward the requests to the application instances through the Ingress of the k8s cluster, the Ingress has a performance bottleneck, which affects the efficiency of micro-service requests. SUMMARY

[0004] The purpose of the embodiments of the present application is to provide a micro-service request method, system, micro-service gateway device and electronic device.

[0005] In order to achieve the above-mentioned purpose, the first aspect of the present application provides a micro-service request method applied to a micro-service gateway device, wherein the micro-service gateway device includes a first cluster, at least one internal service registry center, at least one access gateway and at least one proxy gateway, and the method includes: obtaining the calling address of the access gateway by calling the external service registry center to address the access gateway instance; sending a micro-service request to the access gateway based on the calling address of the access gateway by the calling party; obtaining the calling address of the proxy gateway by addressing the proxy gateway instance through the internal service registry center; forwarding the micro-service request to the proxy gateway based on the calling address of the proxy gateway by the access gateway; forwarding the micro-service request to the corresponding micro-service in the first cluster by the proxy gateway; Wherein, the access gateway is pre-registered to the external service registry center, the proxy gateway is pre-registered to the internal service registry center, and the internal service registry center, the access gateway and the proxy gateway are respectively deployed in the first cluster by using the host network mode.

[0006] In one embodiment, all microservices in the first cluster are pre-registered to the internal service registry; the proxy gateway instance is addressed through the internal service registry to obtain the calling address of the proxy gateway, including: The microservice instance corresponding to the microservice request is addressed through the access gateway to the internal service registry to obtain the calling address of the microservice instance corresponding to the microservice request; The calling address of the proxy gateway corresponding to the calling address of the microservice instance is determined through the internal service registry.

[0007] In one embodiment, the method further comprises: In the case of generating a new microservice in the first cluster, the new microservice is dynamically discovered through the internal service registry, and the new microservice is stored to the service directory; The service directory is accessed through the proxy gateway to discover the new microservice.

[0008] In one embodiment, the microservice gateway device further comprises a second cluster, and the internal service registry comprises at least a first internal service registry and a second internal service registry; the first internal service registry is deployed in the first cluster using a host network mode; and the second internal service registry is deployed in the second cluster using a host network mode.

[0009] In one embodiment, the access gateway comprises at least a first access gateway and a second access gateway; the first access gateway is deployed in the first cluster using a host network mode; and the second access gateway is deployed in the second cluster using a host network mode.

[0010] In one embodiment, the proxy gateway comprises at least a first proxy gateway and a second proxy gateway; the first proxy gateway is deployed in the first cluster using a host network mode; and the second proxy gateway is deployed in the second cluster using a host network mode.

[0011] The second aspect of the present application provides a microservice gateway device, which comprises at least a first cluster and a second cluster; the first cluster comprises at least a first internal service registry, a first access gateway and a first proxy gateway deployed in the first cluster using a host network mode; the second cluster comprises at least a second internal service registry, a second access gateway and a second proxy gateway deployed in the second cluster using a host network mode; The first cluster or the second cluster is used to execute the above-mentioned microservice request method.

[0012] The third aspect of the present application provides a microservice request system, which comprises: The first addressing module is configured to call a direction external service registry center to address the access gateway instance, and obtain a calling address of the access gateway. The first sending module is configured to send a micro-service request to the access gateway based on the calling address of the access gateway. The second addressing module is configured to call an internal service registry center to address the proxy gateway instance based on the micro-service request, and obtain a calling address of the proxy gateway. The first forwarding module is configured to forward the micro-service request to the proxy gateway based on the calling address of the proxy gateway. The second forwarding module is configured to forward the micro-service request to the micro-service in the first cluster. The access gateway is pre-registered in the external service registry center, the proxy gateway is pre-registered in the internal service registry center, and the internal service registry center, the access gateway and the proxy gateway are respectively deployed in the first cluster in a host network mode.

[0013] The fourth aspect of the present application provides an electronic device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the above micro-service request method when executing the program.

[0014] The fifth aspect of the present application provides a machine-readable storage medium, which stores instructions, and the instructions make the processor be configured to execute the above micro-service request method when executed by the processor.

[0015] The sixth aspect of the present application provides a computer program product, which comprises a computer program, and the computer program implements the above micro-service request method when executed by the processor.

[0016] Through the above technical solution, the access gateway addresses the proxy gateway instance based on the micro-service request sent by the calling party through the internal service registry center, and obtains the calling address of the proxy gateway. The access gateway forwards the micro-service request to the proxy gateway based on the calling address of the proxy gateway. Finally, the proxy gateway forwards the micro-service request to the micro-service in the first cluster. Since the internal service registry center, the access gateway and the proxy gateway are all deployed in the application first cluster and are all deployed in a host network mode to reuse the host IP address, the gateway directly accesses the micro-service instance through the IP address in the cluster, without passing through the Ingress micro-service instance of the k8s cluster. The present application does not have performance bottleneck, and improves the efficiency of micro-service request.

[0017] Other features and advantages of the present application will be described in detail in the following specific embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0018] The accompanying drawings are included to provide a further understanding of embodiments of the application, and are incorporated in and constitute a part of the specification, illustrate embodiments of the application, and together with the description serve to explain the principles of the application. In the drawings: Figure 1 One of flow diagrams of microservice request method according to embodiments of the application is schematically shown; Figure 2 One of flow diagrams of microservice request method according to embodiments of the application is schematically shown; Figure 3 One of flow diagrams of microservice request method according to embodiments of the application is schematically shown; Figure 4 One of flow diagrams of microservice request method according to embodiments of the application is schematically shown; Figure 5 One of flow diagrams of microservice request method according to embodiments of the application is schematically shown; Figure 6 One of flow diagrams of microservice request method according to embodiments of the application is schematically shown; DETAILED DESCRIPTION

[0019] In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. It should be understood that the specific embodiments described herein are merely used to explain and illustrate the embodiments of the present application and should not be used to limit the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0020] In addition, if the present application has a description of "first", "second" and the like, the description of "first", "second" and the like is only for the purpose of description, and cannot be understood as indicating or implying the relative importance of the technical features indicated or implicitly indicating the number of technical features. Therefore, the features limited by "first", "second" can explicitly or implicitly include at least one of the features. In addition, the technical solutions of each embodiment can be combined with each other, but it must be based on the realization of those of ordinary skill in the art, when the combination of technical solutions appears contradictory or unachievable, it should be considered that the combination of technical solutions does not exist, nor within the scope of protection claimed by the present application.

[0021] The acquisition, transmission, storage, use, processing, etc. of data in the technical solutions of the present application comply with relevant provisions of national laws and regulations. In addition, it should be noted that in the embodiments of the present application, some industry existing solutions, components, models, etc. may be mentioned, which should be considered as exemplary, and the purpose is only to illustrate the feasibility of the implementation of the technical solutions of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0022] The technical terms related to the present application are explained as follows: k8s: kubernetes, abbreviated as K8s, is an open source that uses 8 to replace the 8 characters in the middle of the name "ubernete" to form an abbreviation, which is used to manage containerized applications on multiple hosts in the cloud platform.

[0023] SLB: (Server Load Balancer) is a network service that distributes network traffic evenly to multiple servers to ensure that each server can effectively handle requests.

[0024] Host network: The application running in the pod can directly see the network interface of the host that starts the pod.

[0025] Ingress: a k8s resource type, used to realize the access to k8s internal application by domain name.

[0026] Nacos: Alibaba's open source one-stop microservice management platform, providing dynamic service discovery, configuration management, DNS service, etc. Core functions support million-level service scale.

[0027] The current API gateway cluster needs to forward the request to the application instance by applying the Ingress of the k8s cluster, and the Ingress has performance bottleneck, which affects the efficiency of microservice request. Therefore, how to solve the problem that the Ingress has performance bottleneck in the current microservice request, which affects the efficiency of microservice request, has become a problem that needs to be solved at present. In view of this, the purpose of the embodiments of the present application is to provide a microservice request method, system, microservice gateway device and electronic equipment.

[0028] Please refer to Figure 1 , in order to achieve the above purpose, the first aspect of the present application provides a microservice request method, applied to a microservice gateway device, the microservice gateway device includes a first cluster, at least one internal service registry center, at least one access gateway and at least one proxy gateway. Please refer to Figure 3The internal service registry, access gateway, and proxy gateway are all deployed within the first cluster (i.e., application Kubernetes cluster 1). This embodiment uses an application Kubernetes cluster as an example for the first cluster. The access gateway is pre-registered with the external service registry, and the proxy gateway is pre-registered with the internal service registry. For example, in one embodiment, the external service registry uses the open-source component Nacos. The steps for the access gateway to pre-register with the external service registry are as follows: 1. Add dependency: Import the external service registry client dependency into the access gateway project's configuration file; 2. Configure address: Specify the address of the external service registry in the access gateway's configuration file; 3. Enable discovery: A crucial step is to set `spring.cloud.gateway.discovery.locator.enabled=true` (for Spring Cloud Gateway) or use annotations such as `@EnableEurekaClient` to enable integration with the service discovery component. After these steps, the access gateway will send its metadata, including hostname (or IP address) and service port, to the external service registry upon startup. The proxy gateway can also use the open-source component Nacos. The steps for the proxy gateway to pre-register with the internal service registry can be referred to the steps for the access gateway to pre-register with the external service registry, and will not be repeated here.

[0029] The internal service registry, access gateway, and proxy gateway are deployed within the first cluster using host network mode. The internal service registry uses the open-source component Nacos and is deployed on the application Kubernetes cluster, which also uses host network mode. Nacos instances deployed in host network mode can reuse the host machine's IP address. In one embodiment, deploying the internal service registry based on the open-source component Nacos in the application Kubernetes cluster using host network mode requires defining a Pod template that uses host network mode. That is, the core of the deployment lies in the Pod configuration, which requires explicitly setting `hostNetwork: true` in the Pod specification. With this configuration, the internal service registry based on the open-source component Nacos will directly use the host machine's (node's) IP address and network namespace.

[0030] The access gateway in the present application is also deployed in the application k8s cluster, and the application k8s cluster deploys the access gateway instance in a host network mode. In the application k8s cluster, the access gateway is deployed in a host network mode, and the core is to configure a Pod template and a DNS strategy. The specific operation is to enable hostNetwork: true, so that the Pod directly uses the network stack (IP address and port) of the host, bypassing the K8s virtual network. There is also a dnsPolicy: ClusterFirstWithHostNet setting to ensure that the Pod can still resolve services within the cluster through the K8s DNS when using the host network. The internal service registry center based on the open source component Nacos is the same, and the access gateway in the present application also reuses the IP address of the host, and registers with the external service registry center using the IP address of the host, so that the calling party does not need to pass through the ingress of the k8s cluster, and can directly call the IP address of the host of the access gateway to access.

[0031] Similarly, the proxy gateway is deployed in the application k8s cluster, and can also be deployed in a host network mode to reuse the IP address of the host, and can be accessed by the access gateway across clusters using the node IP. The deployment method of the proxy gateway can be referred to the deployment method of the access gateway, which will not be described here.

[0032] It should be noted that although the internal service registry center based on the open source component Nacos, the access gateway, and the proxy gateway are all deployed in the application k8s cluster and are deployed in a host network mode (host network mode) to reuse the IP address of the host. However, the internal service registry center, the access gateway, and the proxy gateway use different ports, so that instances of different services can be deployed on the same host, that is, the same host can deploy one nacos instance (that is, an internal service registry center instance), one access gateway instance, and one proxy gateway instance.

[0033] Please refer to Figure 1 and Figure 3 The microservice request method of the present application comprises: Step 100, address the access gateway instance through the calling direction external service registry center to obtain the calling address of the access gateway.

[0034] The caller can be a business system in various fields. For example, the caller can be a personal loan system (i.e., a personal loan system), a deposit system, a financial management system, etc. in the financial field. The caller in the embodiments of the present application is taken as an example of the personal loan system. When the access gateway is deployed in the application k8s cluster in the host network mode, the access gateway instance will register the IP address of the node in the k8s cluster and the configured service port to the external service registry center when it is started. This is because in the host network mode, the Pod will directly use the network namespace of the node it is in, and the IP address is the node IP. For example, if the access gateway is deployed on two nodes with IP addresses of 10.0.251.153 and 10.0.251.155 and listens to the 8080 port, then the service instance address (the calling address of the access gateway) recorded in the external service registry center (such as Nacos) will be 10.0.251.153:8080 and 10.0.251.155:8080. The caller queries the list of healthy gateway instances from the external service registry center through the service name (such as api-gateway). Then the external service registry center returns the specific K8s node IP and port list. The client of the caller (usually integrated with load balancing capability, such as Spring Cloud's LoadBalancer) will obtain this list and get the calling address of the access gateway from the list, i.e., 10.0.251.153:8080 and 10.0.251.155:8080.

[0035] Step 200, sending a microservice request to the access gateway based on the calling address of the access gateway by the caller.

[0036] In the case of obtaining the calling address of the access gateway, the microservice request is sent to the access gateway by the caller through the calling address of the access gateway, so as to realize sending the microservice request to the access gateway. The service of the microservice request can be various microservices of the personal loan system, for example, the service of the microservice request can be a total loan amount calculation service, an interest rate calculation service, etc. The service of the microservice request in the embodiments of the present application is taken as an example of the interest rate calculation service.

[0037] Step 300, addressing the proxy gateway instance through the internal service registry center to obtain the calling address of the proxy gateway.

[0038] In the embodiments of the present application, the microservice (e.g., interest rate calculation service) in the k8s cluster applies the nacos client to register itself to the internal service registry. The method of registering the microservice to the internal service registry can refer to the method of registering the access gateway to the external service registry, which is not described herein. The service name (e.g., api-gateway) is used to initiate the call. The underlying service discovery client queries the internal service registry for a list of all healthy instances corresponding to the service name. The internal service registry returns a list of available proxy gateway instance addresses. The service discovery client selects a proxy gateway instance address (i.e., the call address of the proxy gateway) from the list of available proxy gateway instance addresses through a load balancing algorithm (e.g., round robin).

[0039] Step 400, forwarding the microservice request to the proxy gateway through the access gateway based on the call address of the proxy gateway.

[0040] Based on the call address of the proxy gateway obtained in step 300, the access gateway forwards the microservice request to the call address of the proxy gateway obtained in step 300, so that the microservice request is forwarded to the proxy gateway.

[0041] Step 500, forwarding the microservice request to the corresponding microservice in the first cluster through the proxy gateway.

[0042] The microservice request (e.g., interest rate calculation service request) first reaches the endpoint of the proxy gateway. According to the service name in the routing rule, the proxy gateway queries the internal service registry for a list of all healthy interest rate calculation service instances for the interest rate calculation service request, and may obtain two call addresses of interest rate calculation service instances: 192.168.1.101:8101 and 192.168.1.102:8101. Then, the load balancer (e.g., Spring Cloud LoadBalancer) built in the proxy gateway selects one of the instances (e.g., through a round robin algorithm) as the actual forwarding target of the microservice request, and forwards the microservice request to the actual forwarding target.

[0043] Since the internal service registry center, the access gateway and the proxy gateway are all deployed in the application first cluster and are all deployed in the host network mode to reuse the host IP address, the communication between the internal service registry center, the access gateway and the proxy gateway directly uses the network stack of the host. This means that the gateway can directly communicate through the IP address of the node where the backend service instance is located, realizing the direct network communication between physical machines or virtual machines, with shorter path and significantly reduced delay. The gateway in the hostNetwork mode accesses the application service instance through the intranet IP, avoiding the performance loss caused by the DNAT (destination network address translation) of the application k8s cluster Service layer through iptables or ipvs. This direct communication mode bypassing the Service improves the throughput without multiple forwarding of data packets. Moreover, the gateway in the embodiment of the application does not need to be deployed in an independent cluster, but can be directly deployed in the application k8s cluster, shortening the access link and eliminating the need for separate maintenance of the gateway cluster.

[0044] The access gateway in the application addresses the proxy gateway instance through the internal service registry center based on the microservice request sent by the calling party, obtains the calling address of the proxy gateway, forwards the microservice request to the proxy gateway based on the calling address of the proxy gateway, and finally the proxy gateway forwards the microservice request to the microservice in the first cluster. Since the internal service registry center, the access gateway and the proxy gateway are all deployed in the application first cluster and are all deployed in the host network mode to reuse the host IP address, the gateway directly accesses the microservice instance through the intranet IP address, rather than through the Ingress microservice instance of the application k8s cluster, so that the application does not have performance bottlenecks and improves the efficiency of microservice requests.

[0045] In other aspects of the embodiment of the application, all microservices in the first cluster are pre-registered in the internal service registry center, and the calling address of the proxy gateway is obtained by addressing the proxy gateway instance through the internal service registry center, including: the access gateway addresses the microservice instance corresponding to the microservice request through the internal service registry center, and obtains the calling address of the microservice instance corresponding to the microservice request; and the internal service registry center determines the calling address of the proxy gateway corresponding to the calling address of the microservice instance.

[0046] The access gateway queries the internal service registry center for a list of all healthy interest rate calculation service instances requested by the interest rate calculation service, such as obtaining two interest rate calculation service instance call addresses: 192.168.1.101:8101 and 192.168.1.102:8101. Then the load balancer (such as Spring Cloud LoadBalancer) selects one of the instances (for example, through a round robin algorithm) as the call address of the interest rate calculation service instance for this microservice request (for example, the call address of the target interest rate calculation service instance: 192.168.1.101:8101). Since the proxy gateway is pre-registered in the internal service registry center, the internal service registry center in the present application stores the call addresses of the corresponding microservice instances in the proxy gateway. For example, the two interest rate calculation service instance call addresses corresponding to the proxy gateway A are: 192.168.1.101:8101 and 192.168.1.102:8101. Then, in the case of obtaining the call address of the target interest rate calculation service instance: 192.168.1.101:8101, it can be determined that the call address of the target interest rate calculation service instance: 192.168.1.101:8101 corresponds to the service gateway: proxy gateway A, and the call address of the proxy gateway A is queried through the internal service registry center, so as to facilitate the access gateway to forward the microservice request to the proxy gateway A in the k8s cluster where the microservice instance is located.

[0047] In other aspects of the embodiments of the present application, the method further comprises: step 500, in the case of generating a new microservice in the first cluster, dynamically discovering the new microservice through the internal service registry center, and storing the new microservice to the service directory; step 600, accessing the service directory through the proxy gateway to discover the new microservice. Steps 500-600 can be arranged after step 400.

[0048] Since all microservices within the first cluster are pre-registered to an internal service registry built based on the open source component nacos. When a microservice instance starts, it will automatically send its metadata (such as service name, IP address, port number, etc.) to the internal service registry in the form of a REST or gRPC request through its built-in Nacos client SDK. After receiving the request, the internal service registry will store the metadata of the microservice instance in its in-memory registry and maintain a list of instances (i.e., service directory) for each microservice instance. To maintain the effectiveness of the registration, the microservice instance will periodically (every 5 seconds by default) send a heartbeat signal to the internal service registry. This is a health check mechanism that indicates that the instance is in a healthy state. If the internal service registry does not receive a heartbeat from a certain microservice instance for a long time (15 seconds by default), it will mark it as unhealthy and may eventually remove it from the instance list of the microservice instance. This means that the internal service registry has almost real-time knowledge of the status of all available microservice instances. The key to the proxy gateway's ability to dynamically discover new services lies in its subscription. When the proxy gateway starts, it also acts as a client of the internal service registry (Nacos) and subscribes to the instance list it cares about in the internal service registry. After successful subscription, the gateway not only pulls the complete instance list of the microservice and caches it locally immediately, but more importantly, it establishes a long connection listening mechanism with the internal service registry (Nacos). When a new microservice is generated and registered in the internal service registry within the k8s cluster, the internal service registry will perceive the change in the instance list and immediately push the change event to all proxy gateways that have subscribed to the service through this long connection. In this way, the proxy gateway can update its locally cached instance list within milliseconds without waiting for the next scheduled pull.

[0049] Unlike traditional service gateways that cannot dynamically discover newly deployed application services and require manual configuration of routing rules for the Ingress to forward requests. By pre-registering all microservices within the first cluster to an internal service registry built based on the open source component nacos, the proxy gateway as a client of the internal service registry (Nacos) subscribes to the instance list (service directory) of the microservice instances it cares about in the internal service registry. The proxy gateway of the present application can dynamically discover new services. After the corresponding new service is published, it can be accessed without manual routing configuration, greatly improving the efficiency of the proxy gateway in discovering new services.

[0050] In other aspects of the embodiments of the present application, please refer to Figure 3The micro-service gateway device further includes a second cluster (application k8s cluster 2), and the internal service registry includes at least a first internal service registry and a second internal service registry; the first internal service registry is deployed in the first cluster by using a host network mode; and the second internal service registry is deployed in the second cluster by using a host network mode.

[0051] In order to realize cross-cluster high availability of the internal service registry, the internal service registry adopts an open source component nacos and is deployed in the first cluster and the second cluster (both the first cluster and the second cluster can adopt an application k8s cluster). That is, the first internal service registry is deployed in the first cluster by using a host network mode; and the second internal service registry is deployed in the second cluster by using a host network mode. Two clusters are deployed in the present application, and cross-cluster high availability is realized. In other embodiments, in order to realize high availability of the internal service registry in a cluster, three instances are deployed in each cluster by using a host network mode. That is, three first internal service registries are deployed in the first cluster by using a host network mode. Three first internal service registries are deployed in the second cluster by using a host network mode, and multiple copies of the internal service registry are deployed in the application k8s cluster, so as to realize high availability of the internal service registry in a cluster. Since the internal service registry instance (nacos instance) deployed by using a host network mode in the present application can reuse the IP address of the host, the six nacos instances of the two clusters can directly communicate by using the fixed host IP address, and there is no ip drift problem of the k8s cluster, forming a nacos cluster with six instances. By deploying the first internal service registry in the first cluster by using a host network mode and deploying the second internal service registry in the second cluster by using a host network mode, the present application supports cross-cluster access and supports cross-cluster high availability of the micro-service.

[0052] In other aspects of the embodiments of the present application, the access gateway includes at least a first access gateway and a second access gateway; the first access gateway is deployed in the first cluster by using a host network mode; and the second access gateway is deployed in the second cluster by using a host network mode.

[0053] In order to realize cross-cluster high availability of the access gateway, the access gateway is deployed in an application k8s cluster, and two clusters are deployed in total. That is, the first access gateway is deployed in the first cluster by using a host network mode; and the second access gateway is deployed in the second cluster by using the host network mode. Cross-cluster high availability is realized. The same as the internal service registry center, the access gateway also reuses the IP address of the host, and is registered to the external service registry center by using the IP address of the host, so that the calling party can directly access the IP address of the host of the access gateway without passing through the ingress of the k8s. It should be noted that, in order to realize high availability in the cluster, multiple instances are deployed in each cluster by using the host network mode. For example, three first access gateways are deployed in the first cluster by using the host network mode, and three second access gateways are deployed in the second cluster by using the host network mode. The application realizes high availability of the access gateway in the cluster by deploying multiple copies of the access gateway in the k8s cluster.

[0054] In other aspects of the embodiments of the application, the proxy gateway at least includes a first proxy gateway and a second proxy gateway; the first proxy gateway is deployed in the first cluster by using a host network mode; and the second proxy gateway is deployed in the second cluster by using the host network mode.

[0055] In order to realize cross-cluster high availability of the proxy gateway, the proxy gateway is deployed in an application k8s cluster, and one set is deployed in each application cluster. That is, the first proxy gateway is deployed in the first cluster by using a host network mode; and the second proxy gateway is deployed in the second cluster by using the host network mode. Similarly, the proxy gateway reuses the IP address of the host by using the host network mode, and can be accessed by the access gateway across the cluster by using the node IP address. In other embodiments, the proxy gateway can also be deployed in multiple copies in the k8s cluster, and support high availability in the cluster.

[0056] In summary, in the microservice request method of the embodiments of the application, the gateway (the access gateway and the proxy gateway) does not need to be independently deployed in a cluster, but is directly deployed in an application k8s cluster, so that the access link is shortened, and the gateway cluster does not need to be maintained separately. The gateway reuses the IP address of the host by using the host network mode, supports cross-cluster access, and thus supports cross-cluster high availability of the microservice. The gateway directly accesses the microservice instance by using the IP in the cluster, does not pass through the ingress of the application k8s cluster, and does not have a performance bottleneck. Moreover, the microservice instance of the embodiments of the application is registered to the internal service registry center nacos, the proxy gateway is registered as a client of the nacos to subscribe to the service directory on the nacos, and can dynamically discover new services. After the new services are published, the new services can be accessed without manual routing configuration.

[0057] Figure 1A flowchart of a method for microservice request in an embodiment. It should be understood that although the steps in the flowchart are shown in a certain order according to the arrows, the steps are not necessarily executed in the order according to the arrows. Unless otherwise specified herein, the steps are not strictly limited in order of execution, and the steps can be executed in other orders. Moreover, Figure 1 At least some of the steps in the flowchart can include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of the sub-steps or stages is not necessarily sequential, but can be alternately or alternately executed with at least some of the other steps or sub-steps or stages of other steps. Figure 1

[0058] Please refer to Figure 4 The second aspect of the present application provides a microservice gateway device, which comprises at least a first cluster 41 and a second cluster 42; the first cluster 41 comprises at least a first internal service registry 411, a first access gateway 412 and a first proxy gateway 413 deployed in the first cluster using a host network mode; the second cluster 42 comprises at least a second internal service registry 421, a second access gateway 422 and a second proxy gateway 423 deployed in the second cluster 42 using a host network mode; The first cluster 41 or the second cluster 42 is used to execute the microservice request method described above. The specific embodiments of the microservice request method are described above. Since the microservice gateway device adopts all the technical solutions of all the embodiments of the microservice request method described above, it at least has all the beneficial effects brought by the technical solutions of the above-mentioned embodiments, which will not be repeated here.

[0059] Please refer to Figure 5 The third aspect of the present application provides a microservice request system, which comprises: A first addressing module 501 is configured to call an external service registry to address an access gateway instance, and obtain a calling address of the access gateway; A first sending module 502 is configured to send a microservice request to the access gateway based on the calling address of the access gateway by the calling party; A second addressing module 503 is configured to address a proxy gateway instance by the access gateway based on the microservice request through an internal service registry, and obtain a calling address of the proxy gateway; A first forwarding module 504 is configured to forward the microservice request to the proxy gateway based on the calling address of the proxy gateway by the access gateway; ​The second forwarding module 505 is configured to forward, by the proxy gateway, the microservice request to a microservice in the first cluster. The access gateway is pre-registered to the external service registry, and the proxy gateway is pre-registered to the internal service registry. The internal service registry, the access gateway, and the proxy gateway are respectively deployed in the first cluster by using a host network mode.

[0060] The access gateway of the present application addresses the proxy gateway instance through the internal service registry based on the microservice request sent by the calling party, obtains the calling address of the proxy gateway, forwards the microservice request to the proxy gateway based on the calling address of the proxy gateway, and finally forwards the microservice request to the microservice in the first cluster. Since the internal service registry, the access gateway, and the proxy gateway are all deployed in the application first cluster and are all deployed by using a host network mode to reuse the host IP address, the gateway directly accesses the microservice instance through the IP address in the cluster, without passing through the Ingress microservice instance of the k8s cluster. The present application does not have a performance bottleneck and improves the efficiency of the microservice request.

[0061] In one embodiment, all microservices in the first cluster are pre-registered to the internal service registry. Addressing the proxy gateway instance through the internal service registry, the calling address of the proxy gateway is obtained, comprising: Addressing the microservice instance corresponding to the microservice request through the access gateway to the internal service registry, the calling address of the microservice instance corresponding to the microservice request is obtained. The calling address of the proxy gateway corresponding to the calling address of the microservice instance is determined through the internal service registry.

[0062] In one embodiment, the system further comprises: The updating module is configured to, in the case of generating a new microservice in the first cluster, dynamically discover the new microservice through the internal service registry, and store the new microservice to a service directory; and access the service directory through the proxy gateway to discover the new microservice.

[0063] In one embodiment, the microservice gateway device further comprises a second cluster, and the internal service registry comprises at least a first internal service registry and a second internal service registry. The first internal service registry is deployed in the first cluster by using a host network mode. The second internal service registry is deployed in the second cluster by using a host network mode.

[0064] In one embodiment, the access gateway comprises at least a first access gateway and a second access gateway; the first access gateway is deployed in the first cluster by using a host network mode; and the second access gateway is deployed in the second cluster by using a host network mode.

[0065] In one embodiment, the proxy gateway comprises at least a first proxy gateway and a second proxy gateway; the first proxy gateway is deployed in the first cluster by using a host network mode; and the second proxy gateway is deployed in the second cluster by using a host network mode.

[0066] The micro-service request system comprises a processor and a memory, and the first addressing module 501, the first sending module 502, the second addressing module 503, the first forwarding module 504 and the second forwarding module 505 are stored in the memory as program units, and the corresponding functions are realized by the processor executing the program modules stored in the memory.

[0067] The processor comprises a core, and the core calls the corresponding program units in the memory. The core can be provided with one or more than one.

[0068] The memory can comprise a non-permanent memory in a computer readable medium, a random access memory (RAM) and / or a non-volatile memory such as a read-only memory (ROM) or a flash memory (flash RAM), and the memory comprises at least one memory chip.

[0069] The fourth aspect of the present application, Figure 6 An example of an entity structure diagram of an electronic device is shown in FIG. 1. Figure 6As shown, the electronic device can include a processor 610, a communications interface 620, a memory 630, and a communications bus 640, wherein the processor 610, the communications interface 620, and the memory 630 complete mutual communication through the communications bus 640. The processor 610 can invoke a logic instruction in the memory 630 to execute a microservice request method, which includes: obtaining a calling address of an access gateway by calling a direction external service registry center to address the access gateway instance; sending a microservice request to the access gateway by the calling party based on the calling address of the access gateway; obtaining a calling address of a proxy gateway by the internal service registry center addressing the proxy gateway instance; forwarding the microservice request to the proxy gateway by the access gateway based on the calling address of the proxy gateway; forwarding the microservice request to the corresponding microservice in the first cluster by the proxy gateway; wherein the access gateway is pre-registered to the external service registry center, the proxy gateway is pre-registered to the internal service registry center, and the internal service registry center, the access gateway, and the proxy gateway are respectively deployed in the first cluster by using a host network mode.

[0070] In addition, the logic instruction in the memory 630 described above can be implemented in the form of a software functional unit and sold or used as an independent product, and can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, includes several instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method described in various embodiments of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various program code storage media.

[0071] In a fifth aspect of the present application, a machine readable storage medium is provided, and the machine readable storage medium stores computer execution instructions. The computer execution instructions are executed by a processor to implement the method described above.

[0072] In a sixth aspect of the present application, a computer program product is provided, which includes a computer program. The computer program is executed by a processor to implement the method described above.

[0073] Other embodiments of the application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. It is intended that the specification and examples be considered as exemplary only, with the true scope and spirit of the application being indicated by the following claims.

[0074] It is to be understood that the application is not limited to the precise construction herein disclosed and shown in the drawings, and that various changes in shape, size and arrangements of parts can be made without departing from the scope of the application. The scope of the application is limited only by the claims that follow.

Claims

1. A microservice request method, characterized in that, The method, applied to a microservice gateway device, the microservice gateway device comprising a first cluster, at least one internal service registry, at least one access gateway, and at least one proxy gateway, includes: The call address of the access gateway is obtained by calling the external service registry to address the access gateway instance; The caller sends a microservice request to the access gateway based on the access gateway's call address; The proxy gateway's invocation address is obtained by addressing the proxy gateway instance through the internal service registry. The access gateway forwards the microservice request to the proxy gateway based on the call address of the proxy gateway; The microservice request is forwarded to the corresponding microservice within the first cluster via the proxy gateway. The access gateway is pre-registered with the external service registry, and the proxy gateway is pre-registered with the internal service registry. The internal service registry, the access gateway, and the proxy gateway are deployed in the first cluster using host network mode.

2. The method according to claim 1, characterized in that, All microservices within the first cluster are pre-registered with the internal service registry; the proxy gateway instance is located through the internal service registry to obtain the proxy gateway's invocation address, including: The access gateway addresses the microservice instance corresponding to the microservice request to the internal service registry, thereby obtaining the calling address of the microservice instance corresponding to the microservice request. The internal service registry determines the call address of the proxy gateway corresponding to the call address of the microservice instance.

3. The method according to claim 2, characterized in that, The method further includes: When a new microservice is generated within the first cluster, the new microservice is dynamically discovered through the internal service registry and stored in the service directory. The new microservices are discovered by accessing the service catalog through the proxy gateway.

4. The method according to claim 1, characterized in that, The microservice gateway device further includes a second cluster, and the internal service registry includes at least a first internal service registry and a second internal service registry; the first internal service registry is deployed in the first cluster using a host network mode; and the second internal service registry is deployed in the second cluster using a host network mode.

5. The method according to claim 4, characterized in that, The access gateway includes at least a first access gateway and a second access gateway; the first access gateway is deployed in the first cluster using a host network mode; the second access gateway is deployed in the second cluster using a host network mode.

6. The method according to claim 4, characterized in that, The proxy gateway includes at least a first proxy gateway and a second proxy gateway; the first proxy gateway is deployed in the first cluster using a host network mode; the second proxy gateway is deployed in the second cluster using a host network mode.

7. A microservice gateway device, characterized in that, The device includes at least a first cluster and a second cluster; the first cluster includes at least a first internal service registration center, a first access gateway, and a first proxy gateway deployed in the first cluster using a host network mode; the second cluster includes at least a second internal service registration center, a second access gateway, and a second proxy gateway deployed in the second cluster using a host network mode. The first cluster or the second cluster is used to execute the microservice request method according to any one of claims 1 to 6.

8. A microservice request system, characterized in that, The system includes: The first addressing module is used to address the access gateway instance by calling the external service registry center to obtain the call address of the access gateway; The first sending module is used to send a microservice request to the access gateway through the caller based on the call address of the access gateway; The second addressing module is used by the access gateway to address the proxy gateway instance through the internal service registry based on the microservice request, and obtain the calling address of the proxy gateway; The first forwarding module is used to forward the microservice request to the proxy gateway through the access gateway based on the call address of the proxy gateway; The second forwarding module is used by the proxy gateway to forward the microservice request to the microservice in the first cluster; The access gateway is pre-registered with the external service registry, and the proxy gateway is pre-registered with the internal service registry. The internal service registry, the access gateway, and the proxy gateway are deployed in the first cluster using host network mode.

9. 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, it implements the microservice request method as described in any one of claims 1 to 6.

10. A machine-readable storage medium storing instructions thereon, characterized in that, When executed by a processor, this instruction causes the processor to be configured to perform the microservice request method according to any one of claims 1 to 6.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the microservice request method according to any one of claims 1 to 6.

Images