Request processing method, device, server and computer-readable storage medium

Abstract

The present application relates to a request processing method, device, server and computer-readable storage medium. The method comprises: receiving a service request sent by a client, the service request carrying a target URI; querying a configuration file based on the target URI to obtain the external communication addresses of multiple target services that can respond to the service request, wherein each of the target services is deployed in a container or a physical machine, and the configuration file includes a correspondence between the URI and the external communication address of the service deployed in the container or the physical machine; based on a preset load balancing strategy, determining the target service from the multiple target services, and directing the service request to the target service based on the external communication address of the target service. This method can enable services deployed in physical machines to respond to client service requests based on Kubernetes.

Description

Technical Field

[0001] The present application relates to the field of Internet technology, and in particular to a request processing method, device, server and computer-readable storage medium. Background Art

[0002] Kubernetes is an open source cluster for managing containerized services. The goal of Kubernetes is to make the deployment of containerized services simple and efficient. Kubernetes provides application deployment, planning, updating, and maintenance of services.

[0003] At present, many enterprises' early services are deployed on physical machines. In the process of enterprises implementing containerization and migrating services, some services with dependencies still need to continue to be deployed on physical machines.

[0004] Therefore, how to enable services deployed on physical machines to respond to client service requests based on Kubernetes has become a problem that needs to be solved urgently. Summary of the invention

[0005] Based on this, it is necessary to provide a request processing method, device, server and computer-readable storage medium that can enable services deployed in physical machines to respond to client service requests based on Kubernetes in response to the above technical problems.

[0006] In a first aspect, a request processing method is provided, the method comprising:

[0007] Receive a service request sent by a client, wherein the service request carries a target URI;

[0008] Querying a configuration file based on the target URI to obtain external communication addresses of multiple target services that can respond to the service request, wherein each of the target services is deployed in a container or a physical machine, and the configuration file includes a corresponding relationship between the URI and the external communication address of the service deployed in the container or the physical machine;

[0009] Based on a preset load balancing strategy, a target service is determined from the multiple target services, and the service request is directed to the target service based on an external communication address of the target service.

[0010] In one of the embodiments, before querying the configuration file based on the target URI, the method further includes:

[0011] Obtain at least one Ingress resource, each of which includes a URI and a service resource name;

[0012] For each of the Ingress resources, search for the target service resource based on the service resource name included in the Ingress resource, obtain the external communication address of the service deployed on the physical machine or container associated with the target service resource based on the indication information in the target service resource, and establish a correspondence between the URI included in the Ingress resource and the external communication address of the service associated with the target service resource;

[0013] Based on the corresponding relationships, the configuration file is created.

[0014] In one embodiment, the indication information includes a custom resource name, and obtaining, based on the indication information in the target service resource, an external communication address of a service deployed on a physical machine or a container and associated with the target service resource includes:

[0015] Searching for a target custom resource based on the custom resource name, where the target custom resource includes a first external communication address, where the first external communication address is an external communication address of a service deployed in a physical machine and associated with the target service resource;

[0016] The first external communication address is obtained from the target custom resource.

[0017] In one of the embodiments, the target service resource includes an annotation field, and the annotation field includes the custom resource name.

[0018] In one of the embodiments, the target custom resource includes a spec field, and the spec field includes the first external communication address;

[0019] The target custom resource also includes at least one of an apiVersion field, a kind field, a metadata field, and a health check field, wherein the apiVersion field includes version information of the target custom resource, the kind field includes type information of the target custom resource, the metadata field includes the name of the target custom resource and namespace information of the target custom resource, and the health check field includes a health check address, and the health check address is used by the server to perform a health check on a service deployed in a physical machine that is associated with the target service resource.

[0020] In one of the embodiments, when the target custom resource includes the health check field, the method further includes:

[0021] Generate a target address based on the health check address and the first external communication address;

[0022] Sending a health check instruction to the target address to obtain a return result, wherein the return result is used to indicate whether the service deployed in the physical machine corresponding to the first external communication address is alive or dead;

[0023] If it is determined according to the returned result that the service deployed in the physical machine corresponding to the first external communication address is not alive, the first external communication address in the configuration file is deleted.

[0024] In one embodiment, the indication information includes a Pod resource label and a first part of a second external communication address, the second external communication address is an external communication address of a service deployed in a container associated with the target service resource, and obtaining the external communication address of a service deployed in a physical machine or a container associated with the target service resource based on the indication information in the target service resource includes:

[0025] Searching for a target Pod resource based on the Pod resource label, where the target Pod resource includes the second part of the second external communication address;

[0026] The second part is obtained from the target Pod resource, and the second external communication address is generated based on the first part and the second part.

[0027] In a second aspect, a request processing device is provided, the device comprising:

[0028] A first control module, configured to receive a service request sent by a client, wherein the service request carries a target URI;

[0029] A second control module is used to query a configuration file based on the target URI to obtain external communication addresses of multiple target services that can respond to the service request, wherein each of the target services is deployed in a container or a physical machine, and the configuration file includes a corresponding relationship between the URI and the external communication address of the service deployed in the container or the physical machine;

[0030] The third control module is used to determine a target service from the multiple target services based on a preset load balancing strategy, and direct the service request to the target service based on an external communication address of the target service.

[0031] In a third aspect, a server is provided, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the request processing method as described in the first aspect when executing the computer program.

[0032] In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the request processing method as described in the first aspect is performed.

[0033] The beneficial effects brought by the technical solution provided by the embodiment of the present application include at least:

[0034] In traditional technology, when enterprises implement containerization, the services that were previously deployed in physical machines will be migrated to Kubernetes containers. The server can direct the service request sent by the client to the service in a container, and the service will respond to the service request. However, in the actual containerization process, some enterprises are worried that the instability of the container may cause the service to crash, or some services with dependencies must be deployed in physical machines, so some services will continue to be deployed in physical machines; however, in the above traditional technology, the server cannot direct the client's service request to the service deployed in the physical machine, which cannot meet the actual business needs.

[0035] The technical solution provided by the embodiment of the present application receives a service request sent by a client, wherein the service request carries a target URI; then, based on the target URI, a configuration file is queried to obtain the external communication addresses of multiple target services that can respond to the service request, wherein each target service is deployed in a container or a physical machine, and the configuration file includes a correspondence between the URI and the external communication address of the service deployed in the container or the physical machine; then, based on a preset load balancing strategy, a target service is determined from the multiple target services, and the service request is directed to the target service based on the external communication address of the target service. Since the configuration file includes the external communication address of the service deployed in the physical machine, the server can discover the service deployed in the physical machine included in the configuration file, and can thus direct the service request to the target service deployed in the physical machine, thereby enabling the service deployed in the physical machine to respond to the client's service request based on Kubernetes, which can better meet customer needs. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 An application environment diagram of a request processing method in an embodiment;

[0037] Figure 2 A schematic diagram of a request processing method in one embodiment;

[0038] Figure 3-1 A flowchart of a request processing method in another embodiment;

[0039] Figure 3-2 This is a schematic diagram of an exemplary Kubernetes-based service architecture;

[0040] Figure 4 A schematic diagram of a process of performing health check on a server in another embodiment;

[0041] Figure 5 A flowchart of a request processing method in another embodiment;

[0042] Figure 6 is a structural block diagram of a request processing device in one embodiment;

[0043] Figure 7 is a structural block diagram of a request processing device in another embodiment;

[0044] Figure 8 FIG. 4 is a diagram showing the internal structure of a server in one embodiment. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0046] Kubernetes is a cluster for managing containerized services. In Kubernetes, various resources are defined, such as Service, Pod, etc. Among them, Pod is the smallest deployment unit in Kubernetes. Pod is an environment (including container, storage, IP address: port number, container configuration). One or more containers can run in a Pod. Containers in a Pod share all resources, including the endpoint (IP address: port number) and disk of the shared Pod; Service is used to automatically discover services deployed in containers.

[0047] Ingress is also a resource defined in Kubernetes. Ingress is used to expose services deployed in Kubernetes. It defines a set of domain names, URIs, SSL, and Service resource names that can be accessed by clients. Through Ingress, clients can access services deployed in containers in Kubernetes. However, Ingress itself cannot perform traffic penetration. It is just a collection of rules. These rules must rely on Ingresscontroller to work.

[0048] Ingress controller can be deployed in the server and is responsible for implementing Ingress in Kubernetes. At the same time, Nginx can also be deployed in the server. Ingress controller interacts with the Kubernetes API to dynamically perceive the rule changes of Ingress in Kubernetes, then reads the rule changes, generates Nginx configuration files according to the template, and writes the configuration files to Nginx. Nginx can direct the client's service request to a service in a container according to the configuration file, and the service responds to the service request.

[0049] However, Pod is mainly used for internal access of the cluster where the service is located, and is invisible to clients outside the cluster. Ingress only defines external traffic to reach Pod, that is, according to the definition of Ingress, the client's service request can only reach the service deployed in the container. If there are customers who are worried about the instability of the container and need to deploy some services in the physical machine, or some services with dependencies must be deployed in the physical machine, this will result in the server being unable to direct the client's service request to the service deployed in the physical machine, and unable to meet actual business needs.

[0050] Taking the above into consideration, the embodiments of the present application provide a request processing method, device, server and computer-readable storage medium, in which the server receives a service request sent by a client, wherein the service request carries a target URI; then, based on the target URI, the configuration file is queried, and after the query, the external communication addresses of multiple target services that can respond to the service request are obtained, wherein each target service is deployed in a container or a physical machine, and the configuration file includes a correspondence between the URI and the external communication address of the service deployed in the container or the physical machine; then, based on a preset load balancing strategy, the target service is determined from the multiple target services, and the service request is directed to the target service based on the external communication address of the target service. In this way, since the configuration file includes the external communication address of the service deployed in the physical machine, the server can direct the service request to the target service deployed in the physical machine, thereby realizing that the service deployed in the physical machine can respond to the client's service request based on Kubernetes, so as to better meet customer needs.

[0051] Below, the implementation environment involved in the request processing method provided in the embodiment of the present application will be briefly described.

[0052] like Figure 1As shown, the implementation environment may include a client 101, a server 102, Kubernetes 103, and a physical machine 104. The server 102 may communicate with the client 101 through a network, and the server 102 may also communicate with Kubernetes 103 and the physical machine 104 through a network.

[0053] The server 102 may be a single server or a server cluster consisting of multiple servers. The server 102 may be a tower server, a rack server, a blade server, a high-density server, a single-channel server, a dual-channel server, or a multi-channel server, etc. The embodiment of the present application does not specifically limit the type of the server 102. The client 101 may be a personal computer, a laptop computer, a media player, a smart TV, a smart phone, a tablet computer, a portable wearable device, etc. The embodiment of the present application does not specifically limit the type of the client 101.

[0054] In one embodiment, Figure 2 As shown, a request processing method is provided, which is applied to Figure 1 Taking the server in as an example, the method includes step S100, step S200 and step S300:

[0055] Step S100: The server receives a service request sent by the client.

[0056] When the client needs to obtain a certain service, the client sends a service request, and the server receives the service request sent by the client. In the embodiment of the present application, the service request sent by the client carries a target URI. In a possible implementation, the service required by the client may be accessing a certain web page, and the target URI may be the URI of the web page that the client needs to access.

[0057] Step S200: The server queries the configuration file based on the target URI to obtain external communication addresses of multiple target services that can respond to the service request.

[0058] In an embodiment of the present application, the configuration file includes a correspondence between a URI and an external communication address of a service deployed in a container or physical machine of Kubernetes. The server queries the configuration file based on the target URI, and may search the configuration file for the external communication addresses of multiple target services corresponding to the target URI, thereby obtaining the external communication addresses of multiple target services that can respond to the service request, wherein each target service is deployed in a container or physical machine.

[0059] In an embodiment of the present application, the configuration file may be created by the server through the Ingresscontroller deployed in the server. The configuration file may include multiple URIs, each URI in the configuration file may correspond to the external communication addresses of multiple services, and multiple services corresponding to each URI may respond to service requests carrying the corresponding URIs. Each service corresponding to each URI in the configuration file may be deployed in a container or in a physical machine.

[0060] As an implementation method, the URI in the configuration file consists of a domain name part and a path part. For example, the URI consisting of the domain name part "**.com" and the path part " / *" is "http: / / **.com / *", where "http: / / " is a protocol identifier. In a possible implementation method, for example, the URI in the configuration file corresponds to the external communication addresses of 10 services. Among these 10 services, 6 services are deployed in containers and the other 4 services are deployed in physical machines. Each of these 10 services can provide clients with access to the web page corresponding to the URI "http: / / **.com / *". If the target URI carried in the service request sent by the client is also "http: / / **.com / *", the server will find the external communication addresses of the 10 target services (i.e., the above-mentioned 10 services) corresponding to the target URI "http: / / **.com / *" in the configuration file. Among these 10 target services, 6 target services are deployed in containers and the other 4 target services are deployed in physical machines.

[0061] In a possible implementation, the external communication address of the target service may include an IP address and a port number. If the target service is deployed in a physical machine, the IP address is the IP address of the physical machine where the target service is deployed; if the target service is deployed in a container, the IP address is the IP address of the Pod where the container is deployed.

[0062] Step S300: The server determines a target service from multiple target services based on a preset load balancing strategy, and directs the service request to the target service based on the external communication address of the target service.

[0063] After the server finds out the external communication addresses of multiple target services corresponding to the target URI from the configuration file, it determines the target service from the multiple target services according to the preset load balancing strategy, and the target service is used to respond to the service request.

[0064] In a possible implementation, Nginx is deployed in the server of the embodiment of the present application. Nginx is mainly responsible for exposing services to the outside in Kubernetes, while providing functions such as load balancing. The server provides a reverse proxy for the backend deployed services based on Nginx.

[0065] In the embodiment of the present application, the configuration file is an Nginx configuration file, and the Nginx configuration file is configured with a correspondence between the URI and the external communication address of the service deployed in the container or physical machine; when the client needs to access the service deployed in Kubernetes, the client only needs to send a service request to the server, and the server runs Nginx to select the target service deployed in the container or physical machine to respond to the service request, thereby realizing the reverse proxy function of Nginx.

[0066] When the server runs Nginx and selects the target service deployed in the container or physical machine to respond to the service request, it is necessary to determine the target service from multiple target services based on the preset load balancing strategy. In the embodiment of the present application, the preset load balancing strategy can be pre-configured in Nginx, and the load balancing strategy can be a polling strategy, a random strategy or a minimum connection strategy. Among them, the polling strategy is to distribute the received service request in turn to the multiple target services corresponding to the service request; the random strategy is to randomly distribute the received service request to any one of the multiple target services corresponding to the service request; the minimum connection strategy is to distribute the received service request to the target service with the minimum number of connections currently among the multiple target services corresponding to the service request. Taking the preset load balancing strategy as the minimum connection strategy as an example, the server runs Nginx, determines the target service with the minimum number of connections currently from multiple target services as the target service, and forwards the service request to the external communication address of the target service, and the target service responds to the service request, thereby realizing the load balancing function of Nginx.

[0067] Therefore, if a target service deployed in a physical machine among multiple target services satisfies the preset load balancing strategy, the server determines that the target service is the target service.

[0068] In the above request processing method, the server receives a service request sent by the client, wherein the service request carries a target URI; then, based on the target URI, the configuration file is queried, and after the query, the external communication addresses of multiple target services that can respond to the service request are obtained, wherein each target service is deployed in a container or a physical machine, and the configuration file includes a correspondence between the URI and the external communication address of the service deployed in the container or the physical machine; then, based on the preset load balancing strategy, the target service is determined from the multiple target services, and the service request is directed to the target service based on the external communication address of the target service. In this way, since the configuration file includes the correspondence between the URI and the external communication address of the service deployed in the container or the physical machine, the server can discover the service deployed in the physical machine included in the configuration file, and then can direct the service request to the target service deployed in the physical machine, thereby realizing that the service deployed in the physical machine can respond to the client's service request based on Kubernetes, which can better meet customer needs.

[0069] It is understandable that in the embodiment of the present application, since the server can discover the services deployed in the physical machine included in the configuration file, when the container is unstable, by directing the service request to the target service deployed in the physical machine, the service crash caused by the instability of the container can be avoided. Therefore, the embodiment of the present application can also improve service reliability and reduce the risk of service crash.

[0070] In one embodiment, based on the above Figure 2 The embodiment shown in the figure is related to the process of how the server creates a configuration file. Figure 3-1 As shown, in this embodiment, before step S200, step S400, step S500 and step S600 are also included:

[0071] Step S400: The server obtains at least one Ingress resource.

[0072] In the embodiment of the present application, the server uses Nginx as a load balancer to implement the data plane, and the server implements the control plane by running the Ingress controller program. The server runs the Ingress controller, and can obtain the Ingress resources created in Kubernetes to generate the Nginx configuration file.

[0073] See also Figure 3-2 , which is a schematic diagram of an exemplary Kubernetes-based service architecture. Figure 3-2As shown in the figure, the entire Kubernetes architecture is divided into a master node (also known as a master node) and a child node (also known as a node node). The master node provides cluster control for Kubernetes, and Pods are deployed in child nodes. Multiple containers can be deployed in a Pod. It should be noted that Figure 3-2 The structure shown in does not limit the number of sub-nodes that can be set, the number of Pods in the sub-nodes, the number of physical machines, and the number of services deployed in the physical machines when the embodiments of the present application are actually implemented.

[0074] Please continue to see Figure 3-2 The server runs the Ingress controller, which interacts with the API-Server in the master node of Kubernetes through the Ingress controller. After the Ingress resource changes, it obtains at least one Ingress resource from the APIServer. Each Ingress resource includes a URI and a Service resource name, and generates an Nginx configuration file based on the Ingress resource.

[0075] Step S500, for each Ingress resource, the server searches for the target Service resource based on the Service resource name included in the Ingress resource, obtains the external communication address of the service deployed on the physical machine or container associated with the target Service resource based on the indication information in the target Service resource, and establishes a correspondence between the URI included in the Ingress resource and the external communication address of the service associated with the target Service resource.

[0076] In a possible implementation, when the server obtains Ingress resources from the API-Server through the Ingress controller, it also obtains Service resources and the external communication address of the service deployed on the physical machine or container, and stores the obtained data in the cache of the Ingress controller.

[0077] In the embodiment of the present application, each Ingress resource includes a URI and a Service resource name. As an implementation method, the Ingress resource may include a host field and a path field. The host field includes a domain name part, and the path field includes a path part. The domain name part and the path part constitute the URI corresponding to the Ingress resource. For example, if an Ingress resource includes a host field of "host: **.com" and a path field of "path: / *", the URI corresponding to the Ingress resource is "host: / / **.com / *".

[0078] For an Ingress resource, the server searches the cache for a target Service resource corresponding to the Service resource name included in the Ingress resource. The resource name of the target Service resource is consistent with the Service resource name included in the Ingress resource.

[0079] In an embodiment of the present application, the target Service resource includes indication information, and the server searches the cache for the external communication address of the service deployed on the physical machine or container corresponding to the indication information, and obtains the external communication address of the service deployed on the physical machine or container associated with the target Service resource.

[0080] In a possible implementation, the indication information includes a custom resource name. In step S500, the server obtains the external communication address of the service deployed on the physical machine or container associated with the target Service resource based on the indication information in the target Service resource, which can be implemented by executing the following steps A1 and A2:

[0081] Step A1: The server searches for a target custom resource based on the custom resource name.

[0082] The server searches the cache for a target custom resource whose resource name is the custom resource name. The target custom resource includes a first external communication address, which is an external communication address of a service associated with the target Service resource and deployed in a physical machine.

[0083] Step A2: The server obtains a first external communication address from the target custom resource.

[0084] In a possible implementation, the target Service resource includes an annotations field, and the annotation field includes a custom resource name.

[0085] For example, the custom resource name of the target custom resource is phyendpoint-sample, and the annotation field of the target Service resource can be expressed as follows:

[0086] “annotations:

[0087] aquaman.yy.com / physical.deployment.endpoints: phyendpoint-sample”

[0088] Therefore, the target Service resource is associated with the target custom resource using the annotation field of the target Service resource. The server can find the target custom resource in the cache based on the custom resource name included in the annotation field in the target Service resource, avoiding the problem that the Service resource in the traditional technology only includes the field for discovering the Pod. If the service is deployed in a physical machine, the Service resource in the traditional technology cannot discover the service deployed in the physical machine.

[0089] In an embodiment of the present application, the target custom resource defines a service deployed in a physical machine. In a possible implementation, the target custom resource includes a spec field, and the spec field includes a first external communication address.

[0090] In the embodiment of the present application, the target custom resource is implemented by using the custom resource function of Kubernetes. Taking the target custom resource definition as a service deployed on physical machines 10.21.2.49 and 10.21.2.48 with port 8084 as an example, the spec field of the target custom resource may include:

[0091] "endpoints:10.21.2.49:8084, 10.21.2.48:8084"

[0092] The endpoints indicate that the first external communication address of the service deployed on the physical machine 10.21.2.49 is 10.21.2.49:8084, and the first external communication address of the service deployed on the physical machine 10.21.2.48 is 10.21.2.48:8084.

[0093] As an implementation method, the target custom resource may also include at least one of an apiVersion field, a kind field, a metadata field, and a health check field, wherein the apiVersion field includes the version information of the target custom resource, the kind field includes the type information of the target custom resource, the metadata field includes the name of the target custom resource and the namespace information of the target custom resource, and the health check field includes a health check address, and the health check address is used for the server to perform a health check on the service deployed in the physical machine that is associated with the target Service resource.

[0094] For example, apiVersion: thor.aquaman.io / v1beta1 indicates that the version of the target custom resource is thor.aquaman.io / v1beta1; kind: PhyEndpoint indicates that the type of the target custom resource is PhyEndpoint; name: phyendpoint-sample indicates that the name of the target custom resource is phyendpoint-sample; namespace: test indicates that the namespace of the target custom resource is test; in the health check fields http_check_path: / conf / and Interval: 10, / conf / indicates the health check address, Interval: 10 indicates the time period of the health check, and so on.

[0095] Therefore, by defining the service deployed in the physical machine as a target custom resource and using the annotation field of the target Service resource to associate the target Service resource with the target custom resource, the server can discover the service deployed in the physical machine based on the target Service resource, and can obtain the external communication address of the service deployed in the physical machine that is associated with the target Service resource and included in the target custom resource, that is, the first communication address.

[0096] After obtaining the first external communication address from the target custom resource, the server establishes a correspondence between the URI included in the Ingress resource and the external communication address of the service associated with the target Service resource, that is, associates the URI included in the Ingress resource with the first external communication address.

[0097] In another possible implementation, the indication information includes a Pod resource label and a first part of a second external communication address, and the second external communication address is an external communication address of a service deployed in a container associated with the target Service resource. In the above step S500, the process of the server obtaining the external communication address of a service deployed in a physical machine or a container associated with the target Service resource based on the indication information in the target Service resource can be implemented by executing the following steps B1 and B2:

[0098] In step B1, the server searches for a target Pod resource based on a Pod resource label, wherein the target Pod resource includes a second part of the second external communication address.

[0099] The server searches the cache for a target Pod resource having the Pod resource label based on the Pod resource label, where the target Pod resource includes the second part of the second external communication address.

[0100] In a possible implementation, the content included in the "labels" part of the target Service resource is the Pod resource label, and the "port" part of the target Service resource is the first part of the second external communication address, which is the external communication address of the service deployed in the container associated with the target Service resource.

[0101] In the embodiment of the present application, by adding the first external communication address of the service deployed in the physical machine in the annotation field of the target Service resource, the original function of the target Service resource can be associated with the service deployed in the container corresponding to the Pod resource label. Therefore, the embodiment of the present application transforms the service discovery logic in the traditional Service resource, and the transformed target Service resource can not only identify the Pod, that is, identify the service deployed in the container, but also discover the service deployed on the physical machine.

[0102] Step B2: The server obtains the second part from the target Pod resource, and generates a second external communication address based on the first part and the second part.

[0103] In one possible implementation, the second external communication address includes an IP address and a port number, the first part is the port number, and the second part is the IP address. The server combines the acquired first part and the second part in the form of IP address: port number to obtain the second external communication address, which is the external communication address of the service deployed in the container and associated with the target Service resource.

[0104] After the server generates the second external communication address, it establishes a correspondence between the URI included in the Ingress resource and the external communication address of the service associated with the target Service resource by running the Ingress controller, that is, associates the URI included in the Ingress resource with the second external communication address.

[0105] Step S600: The server creates a configuration file based on each corresponding relationship.

[0106] The server creates an Nginx configuration file based on the correspondence between the URI and the external communication address of the service deployed on the physical machine and the correspondence between the URI and the external communication address of the service deployed on the container. The created configuration file includes the correspondence between the URI and the external communication address of the service deployed on the container and the physical machine. The services deployed on the container and the physical machine can both provide services for the URI.

[0107] The server refreshes the created configuration file to Nginx. In this way, after the server receives the service request sent by the client (the service request is as follows Figure 3-2 If the service request 1, service request 2 or service request 3 is shown in the figure, the external communication addresses of multiple target services corresponding to the target URI carried in the service request can be queried through Nginx in the refreshed configuration file. Each target service is deployed in a container or a physical machine, and each target service can be used to respond to the service request; the server runs Nginx, and based on the preset load balancing strategy, determines the target service from the multiple target services, directs the service request to the target service based on the external communication address of the target service, and the target service responds to the service request.

[0108] In actual applications, for application scenarios that require services to be deployed in both containers and physical machines, the embodiments of the present application expose the services deployed in the container and the services deployed in the physical machine to external access through the above-mentioned implementation method, which can better meet customer needs; at the same time, since the services are deployed in containers and physical machines, service crashes caused by container instability can be avoided, and the stability of the service can be improved. However, traditional technologies can only discover services deployed in containers, but cannot discover services deployed in physical machines. The embodiments of the present application can discover services deployed in physical machines through the above-mentioned implementation method. Compared with traditional technologies, the embodiments of the present application are also beneficial to improving the stability of the service.

[0109] In the above Figure 3-1 Based on the embodiment shown, see Figure 4 This embodiment relates to the process of how the server performs health check according to the health check field. Figure 4As shown, in this embodiment, the target custom resource includes a health check field, and the process of the server performing a health check according to the health check field may include the following steps:

[0110] Step S710: Generate a target address based on the health check address and the first external communication address.

[0111] In an embodiment of the present application, for each service deployed on the physical machine in the configuration file, the server generates a target address for each service deployed on the physical machine based on the health check address and the first external communication address of each service deployed on the physical machine.

[0112] In one possible implementation, the first external communication address of a service deployed on a physical machine is 10.21.2.49:8084, and the first external communication address of another service deployed on the physical machine is 10.21.2.48:8084. The server generates the target addresses of these two services based on the health check address / conf / : 10.21.2.49:8084 / conf / and 10.21.2.48:8084 / conf / .

[0113] Step S720, send a health check instruction to the target address and obtain a return result.

[0114] The server sends a health check instruction to each generated target address, and obtains a return result returned by each target address, where the return result is used to indicate whether the service deployed in the physical machine corresponding to the first external communication address is alive or dead.

[0115] In one possible implementation, the return result may be in the form of an HTTP code. For example, if the return result of a target address is "200", it indicates that the service deployed in the physical machine corresponding to the target address is alive; and if the return result of a target address is "405", it indicates that the service deployed in the physical machine corresponding to the target address is not alive.

[0116] Step S730: If it is determined according to the returned result that the service deployed in the physical machine corresponding to the first external communication address is not alive, the first external communication address in the configuration file is deleted.

[0117] If the server determines that the service deployed in the physical machine corresponding to the first external communication address is not alive according to the returned result, the first external communication address in the configuration file is deleted. In a possible implementation, the server can perform health checks periodically according to the instructions of the Interval field included in the target custom resource. For example, in the example of the target custom resource above, Interval: 10, the server can perform a health check every 10 seconds, so that the dead service can be deleted from the configuration file in time, ensuring that the service in the configuration file can provide services normally and improving the reliability of the service.

[0118] See also Figure 5 , which shows a flowchart of a request processing method provided by an embodiment of the present application, which can be applied to Figure 1 In the implementation environment shown. Figure 5 As shown, the method may include the following steps:

[0119] Step S1001: The server obtains at least one Ingress resource.

[0120] Step S1002, for each Ingress resource, the server searches for the target Service resource based on the Service resource name included in the Ingress resource, obtains the external communication address of the service deployed on the physical machine or container associated with the target Service resource based on the indication information in the target Service resource, and establishes a correspondence between the URI included in the Ingress resource and the external communication address of the service associated with the target Service resource.

[0121] In a possible implementation, the indication information includes a custom resource name. The server obtains the external communication address of the service deployed on a physical machine or container and associated with the target Service resource based on the indication information in the target Service resource through the following steps: the server searches for the target custom resource based on the custom resource name, the target custom resource includes a first external communication address, and the first external communication address is the external communication address of the service deployed on a physical machine and associated with the target Service resource; the server obtains the first external communication address from the target custom resource.

[0122] The target Service resource includes an annotation field, which includes a custom resource name. The target custom resource includes a spec field, which includes a first external communication address. The target custom resource also includes at least one of an apiVersion field, a kind field, a metadata field, and a health check field, wherein the apiVersion field includes the version information of the target custom resource, the kind field includes the type information of the target custom resource, the metadata field includes the name of the target custom resource and the namespace information of the target custom resource, and the health check field includes a health check address, which is used for the server to perform a health check on the service deployed in the physical machine associated with the target Service resource.

[0123] In a possible implementation, the indication information includes a Pod resource label and a first part of a second external communication address, where the second external communication address is the external communication address of a service deployed in a container and associated with a target Service resource. The server can obtain the external communication address of a service deployed in a physical machine or a container and associated with the target Service resource based on the indication information in the target Service resource by the following steps: the server searches for the target Pod resource based on the Pod resource label, where the target Pod resource includes the second part of the second external communication address; the server obtains the second part from the target Pod resource, and generates the second external communication address based on the first part and the second part.

[0124] The second external communication address includes an IP address and a port number, the first part is the port number, and the second part is the IP address.

[0125] Step S1003: The server creates a configuration file based on each corresponding relationship.

[0126] Step S1004: the client sends a service request, which carries a target URI.

[0127] Step S1005: the server receives the service request sent by the client.

[0128] Step S1006: The server queries the configuration file based on the target URI to obtain external communication addresses of multiple target services that can respond to the service request.

[0129] Among them, each target service is deployed in a container or a physical machine, and the configuration file includes a corresponding relationship between a URI and an external communication address of the service deployed in the container or the physical machine.

[0130] Step S1007 , the server determines a target service from multiple target services based on a preset load balancing strategy, and directs the service request to the target service based on the external communication address of the target service.

[0131] Step S1008: The server generates a target address based on the health check address included in the health check field included in the target custom resource and the first external communication address.

[0132] Step S1009: Send a health check instruction to the target address to obtain a return result, where the return result is used to indicate whether the service deployed in the physical machine corresponding to the first external communication address is alive or dead.

[0133] Step S1010: If it is determined according to the returned result that the service deployed in the physical machine corresponding to the first external communication address is not alive, the first external communication address in the configuration file is deleted.

[0134] It should be understood that although Figure 2-5 The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, Figure 2-5 At least part of the steps may include multiple steps or multiple stages. These steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed in turn or alternately with other steps or at least part of the steps or stages in other steps.

[0135] In one embodiment, Figure 6 As shown, a request processing device is provided, the device comprising:

[0136] The first control module 10 is used to receive a service request sent by a client, wherein the service request carries a target URI;

[0137] A second control module 20 is used to query a configuration file based on the target URI to obtain external communication addresses of multiple target services that can respond to the service request, wherein each of the target services is deployed in a container or a physical machine, and the configuration file includes a corresponding relationship between the URI and the external communication address of the service deployed in the container or the physical machine;

[0138] The third control module 30 is used to determine a target service from the multiple target services based on a preset load balancing strategy, and direct the service request to the target service based on the external communication address of the target service.

[0139] exist Figure 6 Based on the embodiment shown, see Figure 7 , the device further comprises:

[0140] The fourth control module 40 is used to obtain at least one Ingress resource, each of which includes a URI and a Service resource name;

[0141] The fifth control module 50 is used to search for a target Service resource for each of the Ingress resources based on the Service resource name included in the Ingress resource, obtain the external communication address of the service deployed on the physical machine or container associated with the target Service resource based on the indication information in the target Service resource, and establish a correspondence between the URI included in the Ingress resource and the external communication address of the service associated with the target Service resource;

[0142] The sixth control module 60 is used to create the configuration file based on the corresponding relationships.

[0143] Optionally, the indication information includes a custom resource name, and the fifth control module 50 is specifically used to:

[0144] Searching for a target custom resource based on the custom resource name, where the target custom resource includes a first external communication address, where the first external communication address is an external communication address of a service associated with the target Service resource and deployed in a physical machine;

[0145] The first external communication address is obtained from the target custom resource.

[0146] Optionally, the target Service resource includes an annotation field, and the annotation field includes the custom resource name.

[0147] Optionally, the target custom resource includes a spec field, and the spec field includes the first external communication address;

[0148] The target custom resource also includes at least one of an apiVersion field, a kind field, a metadata field, and a health check field, wherein the apiVersion field includes version information of the target custom resource, the kind field includes type information of the target custom resource, the metadata field includes the name of the target custom resource and namespace information of the target custom resource, and the health check field includes a health check address, and the health check address is used by the server to perform a health check on the service deployed in a physical machine that is associated with the target Service resource.

[0149] Optionally, when the target custom resource includes the health check field, the apparatus further includes:

[0150] An address generation module, configured to generate a target address based on the health check address and the first external communication address;

[0151] A health check module, used to send a health check instruction to the target address and obtain a return result, wherein the return result is used to indicate whether the service deployed in the physical machine corresponding to the first external communication address is alive or dead;

[0152] The result confirmation module is used to delete the first external communication address in the configuration file if it is determined according to the returned result that the service deployed in the physical machine corresponding to the first external communication address is not alive.

[0153] Optionally, the indication information includes a Pod resource label and a first part of a second external communication address, where the second external communication address is an external communication address of a service deployed in a container and associated with the target Service resource, and the fifth control module 50 is specifically configured to:

[0154] Searching for a target Pod resource based on the Pod resource label, where the target Pod resource includes the second part of the second external communication address;

[0155] The second part is obtained from the target Pod resource, and the second external communication address is generated based on the first part and the second part.

[0156] Optionally, the second external communication address includes an IP address and a port number, the first part is the port number, and the second part is the IP address.

[0157] For the specific definition of the request processing device, please refer to the definition of the request processing method above, which will not be repeated here. Each module in the above request processing device can be implemented in whole or in part by software, hardware and a combination thereof. The above modules can be embedded in or independent of the processor in the server in hardware form, or can be stored in the memory in the server in software form, so that the processor can call and execute the operations corresponding to the above modules.

[0158] In one embodiment, a server is provided, whose internal structure diagram can be as follows: Figure 8 As shown. The server includes a processor, a memory and a network interface connected through a system bus. Among them, the processor of the server is used to provide computing and control capabilities. The memory of the server includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the server is used to store request processing data. The network interface of the server is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a request processing method is implemented.

[0159] Those skilled in the art will understand that Figure 8 The structure shown in the figure is only a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation on the server to which the solution of the present application is applied. The specific server may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0160] In one embodiment, a server is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:

[0161] Receive a service request sent by a client, wherein the service request carries a target URI;

[0162] Querying a configuration file based on the target URI to obtain external communication addresses of multiple target services that can respond to the service request, wherein each of the target services is deployed in a container or a physical machine, and the configuration file includes a corresponding relationship between the URI and the external communication address of the service deployed in the container or the physical machine;

[0163] Based on a preset load balancing strategy, a target service is determined from the multiple target services, and the service request is directed to the target service based on an external communication address of the target service.

[0164] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0165] Obtain at least one Ingress resource, each of which includes a URI and a Service resource name;

[0166] For each of the Ingress resources, search for the target Service resource based on the Service resource name included in the Ingress resource, obtain the external communication address of the service deployed on the physical machine or container associated with the target Service resource based on the indication information in the target Service resource, and establish a correspondence between the URI included in the Ingress resource and the external communication address of the service associated with the target Service resource;

[0167] Based on the corresponding relationships, the configuration file is created.

[0168] In one embodiment, the indication information includes a custom resource name, and the processor implements the following steps when executing the computer program:

[0169] Searching for a target custom resource based on the custom resource name, where the target custom resource includes a first external communication address, where the first external communication address is an external communication address of a service associated with the target Service resource and deployed in a physical machine;

[0170] The first external communication address is obtained from the target custom resource.

[0171] In one embodiment, the target Service resource includes an annotation field, and the annotation field includes the custom resource name.

[0172] In one embodiment, the target custom resource includes a spec field, and the spec field includes the first external communication address;

[0173] The target custom resource also includes at least one of an apiVersion field, a kind field, a metadata field, and a health check field, wherein the apiVersion field includes version information of the target custom resource, the kind field includes type information of the target custom resource, the metadata field includes the name of the target custom resource and namespace information of the target custom resource, and the health check field includes a health check address, and the health check address is used by the server to perform a health check on the service deployed in a physical machine that is associated with the target Service resource.

[0174] In one embodiment, when the target custom resource includes the health check field, the processor further implements the following steps when executing the computer program:

[0175] Generate a target address based on the health check address and the first external communication address;

[0176] Sending a health check instruction to the target address to obtain a return result, wherein the return result is used to indicate whether the service deployed in the physical machine corresponding to the first external communication address is alive or dead;

[0177] If it is determined according to the returned result that the service deployed in the physical machine corresponding to the first external communication address is not alive, the first external communication address in the configuration file is deleted.

[0178] In one embodiment, the indication information includes a Pod resource label and a first part of a second external communication address, where the second external communication address is an external communication address of a service deployed in a container and associated with the target Service resource, and the processor executes the computer program to specifically implement the following steps:

[0179] Searching for a target Pod resource based on the Pod resource label, where the target Pod resource includes the second part of the second external communication address;

[0180] The second part is obtained from the target Pod resource, and the second external communication address is generated based on the first part and the second part.

[0181] In one embodiment, the second external communication address includes an IP address and a port number, the first part is the port number, and the second part is the IP address.

[0182] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0183] Receive a service request sent by a client, wherein the service request carries a target URI;

[0184] Querying a configuration file based on the target URI to obtain external communication addresses of multiple target services that can respond to the service request, wherein each of the target services is deployed in a container or a physical machine, and the configuration file includes a corresponding relationship between the URI and the external communication address of the service deployed in the container or the physical machine;

[0185] Based on a preset load balancing strategy, a target service is determined from the multiple target services, and the service request is directed to the target service based on an external communication address of the target service.

[0186] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0187] Obtain at least one Ingress resource, each of which includes a URI and a Service resource name;

[0188] For each of the Ingress resources, search for the target Service resource based on the Service resource name included in the Ingress resource, obtain the external communication address of the service deployed on the physical machine or container associated with the target Service resource based on the indication information in the target Service resource, and establish a correspondence between the URI included in the Ingress resource and the external communication address of the service associated with the target Service resource;

[0189] Based on the corresponding relationships, the configuration file is created.

[0190] In one embodiment, the indication information includes a custom resource name, and when the computer program is executed by a processor, the following steps are specifically implemented:

[0191] Searching for a target custom resource based on the custom resource name, where the target custom resource includes a first external communication address, where the first external communication address is an external communication address of a service associated with the target Service resource and deployed in a physical machine;

[0192] The first external communication address is obtained from the target custom resource.

[0193] In one embodiment, the target Service resource includes an annotation field, and the annotation field includes the custom resource name.

[0194] In one embodiment, the target custom resource includes a spec field, and the spec field includes the first external communication address;

[0195] The target custom resource also includes at least one of an apiVersion field, a kind field, a metadata field, and a health check field, wherein the apiVersion field includes version information of the target custom resource, the kind field includes type information of the target custom resource, the metadata field includes the name of the target custom resource and namespace information of the target custom resource, and the health check field includes a health check address, and the health check address is used by the server to perform a health check on the service deployed in a physical machine that is associated with the target Service resource.

[0196] In one embodiment, when the target custom resource includes the health check field, the computer program further implements the following steps when executed by the processor:

[0197] Generate a target address based on the health check address and the first external communication address;

[0198] Sending a health check instruction to the target address to obtain a return result, wherein the return result is used to indicate whether the service deployed in the physical machine corresponding to the first external communication address is alive or dead;

[0199] If it is determined according to the returned result that the service deployed in the physical machine corresponding to the first external communication address is not alive, the first external communication address in the configuration file is deleted.

[0200] In one embodiment, the indication information includes a Pod resource label and a first part of a second external communication address, where the second external communication address is an external communication address of a service deployed in a container and associated with the target Service resource. When the computer program is executed by a processor, the following steps are specifically implemented:

[0201] Searching for a target Pod resource based on the Pod resource label, where the target Pod resource includes the second part of the second external communication address;

[0202] The second part is obtained from the target Pod resource, and the second external communication address is generated based on the first part and the second part.

[0203] In one embodiment, the second external communication address includes an IP address and a port number, the first part is the port number, and the second part is the IP address.

[0204] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), tape, floppy disk, flash memory or optical memory, etc. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0205] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0206] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A request processing method, characterized in that: The method comprises: Receive a service request sent by a client, wherein the service request carries a target URI; Querying a configuration file based on the target URI to obtain external communication addresses of multiple target services that can respond to the service request, wherein each of the target services is deployed in a container or a physical machine, and the configuration file includes a corresponding relationship between the URI and the external communication address of the service deployed in the container or the physical machine; Based on a preset load balancing strategy, determine a target service from the multiple target services, and direct the service request to the target service based on an external communication address of the target service; Before querying the configuration file based on the target URI, the method further includes: Obtain at least one Ingress resource, each of which includes a URI and a Service resource name; For each of the Ingress resources, search for the target Service resource based on the Service resource name included in the Ingress resource, obtain the external communication address of the service deployed on the physical machine or container associated with the target Service resource based on the indication information in the target Service resource, and establish a correspondence between the URI included in the Ingress resource and the external communication address of the service associated with the target Service resource; Based on the corresponding relationships, the configuration file is created.

2. The method according to claim 1, characterized in that The indication information includes a custom resource name, and acquiring, based on the indication information in the target Service resource, an external communication address of a service deployed on a physical machine or a container and associated with the target Service resource includes: Searching for a target custom resource based on the custom resource name, where the target custom resource includes a first external communication address, where the first external communication address is an external communication address of a service associated with the target Service resource and deployed in a physical machine; The first external communication address is obtained from the target custom resource.

3. The method according to claim 2, characterized in that The target Service resource includes an annotation field, and the annotation field includes the custom resource name.

4. The method according to claim 2, characterized in that: The target custom resource includes a spec field, and the spec field includes the first external communication address; The target custom resource also includes at least one of an apiVersion field, a kind field, a metadata field, and a health check field, wherein the apiVersion field includes version information of the target custom resource, the kind field includes type information of the target custom resource, the metadata field includes the name of the target custom resource and namespace information of the target custom resource, and the health check field includes a health check address, and the health check address is used for the server to perform a health check on the service deployed in a physical machine that is associated with the target Service resource.

5. The method according to claim 4, characterized in that In the case where the target custom resource includes the health check field, the method further includes: Generate a target address based on the health check address and the first external communication address; Sending a health check instruction to the target address to obtain a return result, wherein the return result is used to indicate whether the service deployed in the physical machine corresponding to the first external communication address is alive or dead; If it is determined according to the returned result that the service deployed in the physical machine corresponding to the first external communication address is not alive, the first external communication address in the configuration file is deleted.

6. The method according to claim 1, characterized in that The indication information includes a Pod resource label and a first part of a second external communication address, where the second external communication address is an external communication address of a service deployed in a container and associated with the target Service resource, and acquiring, based on the indication information in the target Service resource, an external communication address of a service deployed in a physical machine or a container and associated with the target Service resource, includes: Searching for a target Pod resource based on the Pod resource label, where the target Pod resource includes the second part of the second external communication address; The second part is obtained from the target Pod resource, and the second external communication address is generated based on the first part and the second part.

7. A request processing device, characterized in that: The device comprises: A first control module, configured to receive a service request sent by a client, wherein the service request carries a target URI; A second control module is used to query a configuration file based on the target URI to obtain external communication addresses of multiple target services that can respond to the service request, wherein each of the target services is deployed in a container or a physical machine, and the configuration file includes a correspondence between the URI and the external communication address of the service deployed in the container or the physical machine; A third control module is used to determine a target service from the multiple target services based on a preset load balancing strategy, and direct the service request to the target service based on an external communication address of the target service; The device also includes: A fourth control module, used to obtain at least one Ingress resource, each of which includes a URI and a Service resource name; A fifth control module is used to search for a target Service resource for each of the Ingress resources based on the Service resource name included in the Ingress resource, obtain the external communication address of the service deployed on a physical machine or container associated with the target Service resource based on the indication information in the target Service resource, and establish a correspondence between the URI included in the Ingress resource and the external communication address of the service associated with the target Service resource; A sixth control module is used to create the configuration file based on each of the corresponding relationships.

8. The device according to claim 7, characterized in that The indication information includes a custom resource name, and the fifth control module is specifically used to search for a target custom resource based on the custom resource name, wherein the target custom resource includes a first external communication address, and the first external communication address is an external communication address of a service deployed in a physical machine and associated with the target Service resource; the first external communication address is obtained from the target custom resource.

9. A server, comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images