CN115412530B - Domain name resolution method and system for service under multi-cluster scene - Google Patents
Domain name resolution method and system for service under multi-cluster scene Download PDFInfo
- Publication number
- CN115412530B CN115412530B CN202211048384.5A CN202211048384A CN115412530B CN 115412530 B CN115412530 B CN 115412530B CN 202211048384 A CN202211048384 A CN 202211048384A CN 115412530 B CN115412530 B CN 115412530B
- Authority
- CN
- China
- Prior art keywords
- service
- service instance
- cluster
- address
- domain name
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 57
- 230000004044 response Effects 0.000 claims abstract description 42
- 238000012544 monitoring process Methods 0.000 claims description 18
- 238000004590 computer program Methods 0.000 claims description 4
- 238000012545 processing Methods 0.000 description 11
- 230000008569 process Effects 0.000 description 10
- 238000004891 communication Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 8
- 230000006870 function Effects 0.000 description 8
- 230000007246 mechanism Effects 0.000 description 5
- 230000008859 change Effects 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000002159 abnormal effect Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000000977 initiatory effect Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 238000010295 mobile communication Methods 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008033 biological extinction Effects 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1023—Server selection for load balancing based on a hash applied to IP addresses or costs
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The application relates to the technical field of cloud protogenesis, and provides a domain name resolution method and a domain name resolution system for services in a multi-cluster scene. The method comprises the following steps: in response to receiving a domain name resolution request of a first service instance deployed in a first cluster and directed to a second service, determining an IP address of the second service instance according to a pre-established IP address list of at least one service instance corresponding to the second service; the second service instance is a service instance corresponding to the second service deployed in the first cluster; and using the IP address of the second service instance to replace the virtual IP address of the second service as a response of the domain name resolution request, and feeding back the response to the first service instance. In this way, by returning the IP address of the second service instance, when the first service instance attempts to access the second service, the IP address of the second service instance is directly used to access the second service instance in the same cluster, so that additional network delay and resource overhead generated by accessing the service instance across clusters are avoided.
Description
Technical Field
The application relates to the technical field of cloud protogenesis, in particular to a domain name resolution method, a domain name resolution system, a computer readable storage medium and electronic equipment for services in a multi-cluster scene.
Background
Along with the popularization of cloud native technology, more and more enterprises start to build applications by adopting deployment modes of multiple campaigns or multiple campaigns in different places, namely, a plurality of data centers are built, each data center is provided with a plurality of server nodes, a container arrangement system represented by a Kubernetes system is used for managing all server nodes in the data center as one cluster, a plurality of service instances corresponding to services are deployed in the plurality of clusters, and meanwhile, access requests are responded, so that risks brought by a single data center are reduced, and high service availability is guaranteed.
However, in the related art, when multiple services are accessed to each other in a multi-cluster environment, a situation of accessing service instances across clusters occurs, which causes excessive network delay and resource overhead.
Accordingly, there is a need to provide an improved solution to the above-mentioned deficiencies of the prior art.
Disclosure of Invention
The present application is directed to a domain name resolution method, system, computer readable storage medium, and electronic device for services in a multi-cluster scenario, so as to solve or alleviate the problems in the prior art.
In order to achieve the above object, the present application provides the following technical solutions:
The application provides a domain name resolution method for services in a multi-cluster scene, which comprises the following steps:
at least one service instance is respectively corresponding to a first service and a second service in a plurality of clusters, a first service instance corresponding to the first service is deployed in the first cluster, and the method is executed by a domain name resolution component of the first cluster; the method comprises the following steps:
responding to the received domain name resolution request of the first service instance pointing to the second service, and determining the IP address of the second service instance according to the pre-established IP address list of at least one service instance corresponding to the second service; the second service instance is a service instance corresponding to the second service deployed in the first cluster;
and using the IP address of the second service instance to replace the virtual IP address of the second service, and feeding back the virtual IP address to the first service instance as a response of the domain name resolution request.
In the above solution, the IP address list of at least one service instance corresponding to the second service is established by:
acquiring and recording clusters and IP addresses of all service instances corresponding to the second service in the IP address list by accessing API-Server components of all clusters;
Correspondingly, the determining the IP address of the second service instance according to the IP address list of at least one service instance corresponding to the second service, which is pre-established, includes:
querying whether the second service instance exists or not from the IP address list;
and responding to the existence of the second service instance, and inquiring the IP address of the second service instance from the IP address list.
In the above scheme, the method further comprises: continuously monitoring and recording the running states of all service instances corresponding to the second service in the IP address list;
accordingly, before the querying the IP address of the second service instance from the IP address list, the method further includes:
and inquiring the running state of the second service instance from the IP address list.
In the above scheme, the method further comprises:
querying an IP address of the second service instance from the IP address list in response to the second service instance being in an available state;
querying an IP address of a third service instance from the IP address list in response to the second service instance being in an unavailable state; the third service instance is a service instance corresponding to the second service deployed in a second cluster; and using the IP address of the third service instance to replace the virtual IP address of the second service, and feeding back the virtual IP address to the first service instance as a response of the domain name resolution request.
In the above solution, the continuously monitoring the running states of all service instances corresponding to the second service includes:
monitoring the running state of a container group where all service instances corresponding to the second service are located through the API-Server component; or,
acquiring the running states of all service instances corresponding to the second service through an access monitoring component; or,
and acquiring the running states of all the service instances corresponding to the second service according to the heartbeat data packet sent by the service instance.
In the above scheme, at least one service instance corresponding to the first service and the second service is deployed in a plurality of clusters located in different areas.
In the above solution, a multi-cluster domain name resolution plug-in is provided in the domain name resolution component of the first cluster, where the multi-cluster domain name resolution plug-in is configured to establish and maintain the IP address list, and respond to the domain name resolution request.
The embodiment of the application also provides a domain name resolution system for services in a multi-cluster scene, which comprises:
at least one service instance is respectively corresponding to a first service and a second service in a plurality of clusters, and a first service instance corresponding to the first service is deployed in the first cluster; the system comprises:
The response unit is configured to respond to the received domain name resolution request of the first service instance pointing to the second service, and determine the IP address of the second service instance according to the pre-established IP address list of at least one service instance corresponding to the second service; the second service instance is a service instance corresponding to the second service deployed in the first cluster;
and the feedback unit is configured to replace the virtual IP address of the second service by the IP address of the second service instance and feed back the virtual IP address of the second service instance to the first service instance as a response of the domain name resolution request.
The embodiment of the application also provides a computer readable storage medium, on which a computer program is stored, the computer program being a domain name resolution method for services in a multi-cluster scenario as described in any one of the above.
The embodiment of the application also provides electronic equipment, which comprises: the system comprises a memory, a processor and a program stored in the memory and capable of running on the processor, wherein the processor realizes the domain name resolution method for service in the multi-cluster scene when executing the program.
The beneficial effects are that:
in the technical scheme provided by the application, when the domain name resolution component of the first cluster receives a domain name resolution request of the first service instance pointing to the second service, an IP address of the second service instance is determined by pre-establishing an IP address list of at least one service instance corresponding to the second service, wherein the second service instance is a service instance corresponding to the second service deployed in the first cluster, and the IP address of the second service instance is used for replacing a virtual IP address of the second service to be used as a response of the domain name resolution request and fed back to the first service instance. When the first service example tries to access the second service, the IP address of the second service example replaces the virtual IP address of the second service as a response of the domain name resolution request pointing to the second service, and the response is returned to the first service example, so that the purpose of preferentially returning the IP address of the second service example deployed in the same cluster is achieved, when a plurality of services access each other, the first service example initiating service access can directly access the second service example in the same cluster nearby, and extra network delay and resource overhead generated by cross-cluster access of the service example are avoided.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute an undue limitation to the application. Wherein:
FIG. 1 is a schematic diagram of a related art logic for a first service instance to access a second service instance in a multi-cluster scenario;
fig. 2 is a logic diagram of an implementation of a domain name resolution method for services in a multi-cluster scenario according to some embodiments of the present application;
fig. 3 is a flow chart of a domain name resolution method for services in a multi-cluster scenario provided in some embodiments of the present application;
FIG. 4 is a logic diagram of a first service instance accessing a second service instance in a multi-cluster scenario provided by some embodiments of the present application;
FIG. 5 is a logic diagram of a first service instance accessing a second service instance in a first cluster in a multi-cluster scenario provided by some embodiments of the present application when the second service instance is in an unavailable state;
FIG. 6 is a schematic diagram of a domain name resolution system for services in a multi-cluster scenario provided by some embodiments of the present application;
fig. 7 is a schematic structural diagram of an electronic device provided according to some embodiments of the present application;
Fig. 8 is a hardware block diagram of an electronic device provided according to some embodiments of the present application.
Detailed Description
The present application will be described in detail below with reference to the accompanying drawings in conjunction with embodiments. Various examples are provided by way of explanation of the present application and not limitation of the present application. Indeed, it will be apparent to those skilled in the art that modifications and variations can be made in the present application without departing from the scope or spirit of the application. For example, features illustrated or described as part of one embodiment can be used on another embodiment to yield still a further embodiment. Accordingly, it is intended that the present application include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.
In the following description, the terms "first/second/third" are used merely to distinguish between similar objects and do not represent a particular ordering of the objects, it being understood that the "first/second/third" may be interchanged with a particular order or precedence where allowed, to enable embodiments of the present application described herein to be implemented in other than those illustrated or described herein.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The terminology used herein is for the purpose of describing embodiments of the present disclosure only and is not intended to be limiting of the present disclosure.
In order to facilitate understanding of the technical solution of the present application, a process flow of mutual access between services in a multi-cluster deployment environment in the related art is described below.
With the popularization of cloud native technology, more and more enterprises start to build applications in a deployment mode of multiple campaigns or multiple campaigns in different places, namely, a plurality of data centers are built, each data center is provided with a plurality of server nodes, and all server nodes in the data centers are managed as a cluster by using a container arrangement system represented by a Kubernetes system.
In each cluster there are running multiple container groups, which are the smallest deployable computing units created and managed in the cluster, are a set (one or more) of containers that share resources and dependencies among each other.
The deployment of applications in clusters is in effect the deployment of applications in containers in clusters. To achieve high availability of an application, multiple application instances of the application are typically deployed in a cluster while responding to access requests.
When a container group is created, the cluster will be assigned a unique IP address for communicating with other container groups. It should be understood that each container group is assigned a unique IP address through which an application instance running therein can also be accessed, that is, the IP address of the application instance is the IP address of the container group in which the application instance is located.
Considering that the container arrangement system represented by the Kubernetes system can automatically deploy and manage the container group, when the container group runs abnormally, a rescheduling mechanism is adopted to schedule the application instance running in the container group to create a new container group, so that the IP address of the application instance is changed frequently, the container arrangement system represented by the Kubernetes system introduces a Service (Service) mechanism, the Service is a single unchanged access point resource provided for a group of containers with the same function, and when a certain container group has a Label (Label) specified by a Service selector, the container group becomes a member of the Service, and the application instance running in the container group is called as a Service instance.
When the service is created, the corresponding relation between the service and the container group is determined through the selector in the service configuration file, and once the corresponding relation between the service and the container group is determined, the corresponding relation between the service and the service instance is also determined as the service instance runs in the container. Meanwhile, each created service is allocated with a service domain name and a virtual IP address, which are used for providing an access function to the outside, and the service domain name and the virtual IP address have the same life cycle as the service. That is, regardless of the change in the deployment location of the service instance (e.g., rescheduling of the container group) corresponding to the service, the service domain name and the virtual IP address are fixed, thereby achieving single unchanged access to the service.
In addition, after the corresponding relation between the service and the service instance is established, the corresponding relation is also established between the virtual IP address of the service and the IP address of the service instance, and after the deployment position of the service instance is changed, the IP address of the service instance in the corresponding relation is automatically updated.
Because the functions of the multiple service instances corresponding to the same service are the same, any one service instance can respond to the access request directed to the service, the access requester does not need to know the IP address of the service instance which is actually accessed, only needs to know the virtual IP address of the service, and sends the access request to the virtual IP address, and the access request is sent to a certain service instance corresponding to the service for responding according to the corresponding relation between the virtual IP address and the IP address of the service instance.
Specifically, a service instance corresponding to a service initiating access sends a domain name resolution request containing a domain name of the service to be accessed to a domain name resolution component (such as CoreDNS) to obtain a virtual IP address of the service to be accessed, sends an access request to the virtual IP address of the service to be accessed, and a load balancing component (such as a Kube-proxy component of a Kubernetes system) in a cluster responds by distributing the access request to a certain service instance according to the corresponding relationship between the virtual IP address and the IP address of the service instance and the load condition of each service instance.
In a multi-cluster scene, a plurality of service instances corresponding to the same service are deployed in a plurality of clusters, and simultaneously respond to the access request, so that service unavailability caused by failure or damage and extinction of a single data center is prevented, the risk brought by the single data center is reduced, and the high availability of the service is ensured.
Specifically, referring to fig. 1, in the related art, when a client sends an access request to a first service in a multi-cluster from outside, a load balancer outside the cluster distributes the access request to a service instance on a certain cluster to process, for example, the first service instance on the first cluster, according to a preset load policy (such as local priority, load optimization, polling, random, etc.). At this time, if the first service instance depends on the function of the second service when processing the request, a domain name resolution request directed to the second service is sent to a domain name resolution component (not shown in the figure) of the cluster (i.e., the first cluster) to obtain a virtual IP address of the second service.
The domain name resolution component of the first cluster returns the virtual IP address of the second service to the first service instance according to the domain name of the second service, and the first service instance then issues an access request directed to the virtual IP address of the second service to access the second service. Based on the foregoing, it is known that the virtual IP address of the second service corresponds to a plurality of service instances, and the service instances are distributed in different clusters, so that the access request directed to the virtual IP address will be distributed to a certain service instance for processing, and this process is implemented by a load balancing component (not shown in the figure) in the cluster according to the load situation of each service instance, which is uncontrollable. Once the access request is distributed to other clusters than the first cluster, cross-cluster access will occur, causing network delay and excessive resource overhead.
The applicant has conducted intensive researches and analyses on the technical problems, and found that the core of cross-cluster access of mutual access among multiple services in the current multi-cluster scene is that a virtual IP address is returned to a domain name resolution request of the service by a domain name resolution component. When a client sends an access request pointing to a virtual IP address, a load balancing component in a cluster selects one service instance from a plurality of service instances corresponding to a service according to the corresponding relation between the virtual IP address and the IP address of the service instance and the load condition of each service instance, and redirects the access request to the IP address of the service instance, and the selection is completely automatically completed by the load balancing component in the cluster, so that the access across clusters can be possibly caused.
Therefore, the method is executed by a domain name resolution component, provides service address resolution optimization capability for the domain name resolution component, and can return an IP address of a second service instance corresponding to the second service on a first cluster to a first service application instead of a virtual IP address of the second service when the domain name resolution component receives a domain name resolution request for the first service to access the second service, so that a load balancing component in the cluster can redirect an access request to the IP address of the second service instance, cross-cluster service access caused by the prior art is avoided, network overhead is saved, service response time is shortened, and processing efficiency of the access request is improved.
Exemplary method
The embodiment of the application provides a domain name resolution method of a service in a multi-cluster scene, as shown in fig. 1-5, a first service instance corresponding to a first service is deployed in a first cluster, and the method is executed by a domain name resolution component of the first cluster, wherein the first service instance and the second service in the multi-cluster are respectively corresponding to at least one service instance; the method comprises the following steps:
step S101, responding to a domain name resolution request of the first service instance pointing to the second service, and determining an IP address of the second service instance according to a pre-established IP address list of at least one service instance corresponding to the second service.
The second service instance is a service instance corresponding to the second service deployed in the first cluster.
In this embodiment of the present application, the multiple clusters include at least two clusters, where the first cluster is any one of the multiple clusters, and at least one service instance corresponding to the first service is deployed on the first cluster.
The second service is a service related to the first service, and in some traffic scenarios, the first service needs to access the second service to feed back an access request of the client. It is understood that the second service also corresponds to at least one service instance.
Based on the foregoing, if the first service instance depends on the function of the second service when processing the access request of the client, the first service instance will first send a domain name resolution request to the domain name resolution component of the cluster (i.e., the first cluster) to obtain the access address of the second service. In a conventional manner of processing, the domain name resolution component returns the virtual IP address of the second service to the first service instance as the access address of the second service. When the first service instance accesses the second service through the virtual IP address, a load balancing component in the cluster selects one service instance from all service instances corresponding to the second service to process the access request of the first service instance, so that the selected service instance and the first service instance may be located on different clusters, and cross-cluster access occurs.
In the embodiment of the present application, in order to avoid cross-cluster access caused by selecting a service instance, before returning an IP address of a second service to a first service instance, a domain name resolution component of the first cluster pre-establishes an IP address list of at least one service instance corresponding to the second service.
After the IP address list of the service instance is established, when a domain name resolution request of the first service instance directed to the second service is received, the domain name resolution component of the first cluster can determine the IP address of the second service instance according to the IP address list of at least one service instance corresponding to the second service.
The second service instance is a service instance corresponding to the second service deployed in the first cluster. Because the second service instance and the first service instance are both deployed in the first cluster, the first service instance can directly access the second service instance in the same cluster by using the IP address of the second service instance, thereby avoiding the problem that the first service instance accesses the second service across clusters and improving the access efficiency.
It should be noted that, a plurality of service instances corresponding to the second service may be deployed in the first cluster at the same time, where any one of the first service instances accesses the second service instance, and therefore, a certain service instance may be randomly selected from the first service instance as the second service instance, or a load balancing mechanism may be used, and according to the load condition of the service instance, the service instance with the smallest load is selected from the second service instance.
In some embodiments, the IP address list of at least one service instance corresponding to the second service is established by: acquiring and recording clusters and IP addresses of all service instances corresponding to the second service in an IP address list by accessing API-Server components of all clusters; accordingly, determining the IP address of the second service instance according to the IP address list of at least one service instance corresponding to the second service, which is pre-established, includes: inquiring whether a second service instance exists in the IP address list; in response to the presence of the second service instance, an IP address of the second service instance is queried from the IP address list.
In the embodiment of the application, the multi-cluster scene comprises a plurality of Kubernetes clusters, and each Kubernetes cluster is provided with an API-Server component.
It should be noted that in a multi-cluster environment, two clusters are included: control plane clusters and member clusters. The control plane cluster is provided with a multi-cluster management component which is used for receiving application deployment requirements submitted by users, synchronizing the deployment requirements to each member cluster and synchronizing the deployed running states of the applications from the member clusters.
In addition, the control plane cluster is provided with various components of the member cluster besides the multi-cluster management component, namely the control plane cluster is provided with the multi-cluster management component in addition to the member cluster.
It should be appreciated that when one Kubernetes cluster is registered as a member cluster of a multi-cluster, the multi-cluster management component configures corresponding access rights for the newly added member cluster to enable the newly added member cluster to mutually access any other cluster within the multi-cluster, thereby enabling components of different member clusters to mutually access and communicate.
In one embodiment, the domain name resolution component of the first cluster can obtain the clusters and the IP addresses of all service instances corresponding to the second service in the multiple clusters by actively accessing the API-Server components of all the clusters, and record the obtained clusters and the IP addresses in the IP address list, so that when a request for accessing the second service is received, the domain name resolution component of the first cluster can find the clusters and the IP addresses of all the service instances corresponding to the second service based on the IP address list.
In another embodiment, an agent component is deployed in each cluster in the multiple clusters, and is configured to push, to a domain name resolution component in another cluster, an IP address of a service instance corresponding to a second service in the cluster where the agent component is located, where the domain name resolution component of the first cluster is capable of obtaining, by passively receiving push information of the agent component, the cluster and the IP address where all service instances corresponding to the second service in the multiple clusters are located, and record the obtained cluster and IP address in an IP address list.
For any service in the multiple clusters, the domain name resolution component of the cluster where the service is located can establish an IP address list of the corresponding service instance for the service in the above manner.
In practical applications, in order to keep the record in the IP address list synchronous with the IP address of the service instance in the multiple clusters, an update mechanism of the IP address list may be further set, for example, the domain name resolution component accesses the API-Server components of all the clusters at a specific time interval to update the IP address list, or the proxy component may also monitor the API-Server components of the clusters where the proxy component is located, and once the service instance is monitored to change, the change condition of the service instance is pushed to the domain name resolution component, which is not limited in this embodiment of the present application.
After the IP address list is established, when a domain name resolution request of the first service instance pointing to the second service is received, the domain name resolution component of the first cluster firstly queries whether a service instance corresponding to the second service (namely, a second service instance) exists in the first cluster from the IP address list, if the second service instance exists in the IP address list, the first service instance directly accesses the second service instance in the same cluster to realize access to the second service, and then the IP address of the second service instance is determined from the IP address list.
Step S102, the IP address of the second service instance is used for replacing the virtual IP address of the second service, and the virtual IP address is fed back to the first service instance as a response of the domain name resolution request.
In this embodiment of the present application, after determining the IP address of the second service instance, the domain name resolution component of the first cluster uses the IP address of the second service instance to replace the virtual IP address of the second service, and feeds back the virtual IP address to the first service instance as a response to the domain name resolution request. In this way, the IP address of the second service instance is used to replace the virtual IP address of the second service, so that the first service instance can access the second service instance of the first cluster preferentially and nearby, thereby reducing network delay.
It should be understood that when the domain name resolution component of the first cluster queries whether the second service instance exists in the IP address list, if the second service instance does not exist in the IP address list, the domain name resolution component of the first cluster can obtain the IP addresses of other service instances corresponding to the second service, and feed back the IP addresses to the first service instance as a response to the domain name resolution request.
Further, to determine availability of the second service instance, the first service instance is prior to accessing the second service instance, the method further comprises: continuously monitoring and recording the running states of all service instances corresponding to the second service in the IP address list; accordingly, before querying the IP address of the second service instance from the IP address list, the method further comprises: and inquiring the running state of the second service instance from the IP address list.
In this embodiment of the present application, the domain name resolution component of the first cluster continuously monitors and records, in the IP address list, the running states of all service instances corresponding to the second service, where the running states of the service instances are used to indicate health conditions of the corresponding service instances, so as to determine whether the corresponding service instances can normally process the access request. Therefore, before the IP address of the second service instance is queried from the IP address list, in order to determine the running state of the second service instance, the domain name resolution component of the first cluster queries the running state of the second service instance from the IP address list, thereby ensuring that the second service instance can correctly process the access request of the first service instance.
Specifically, since the service instance is running in a Container, the running state of the service instance may be determined by the state of the Container group running the service instance, the state of the Container (Container), and the running state of the service instance itself, and whether the Container group or the Container, the service instance itself are abnormal, the service instance is in an unavailable state.
In practical application, there are multiple implementations of continuously monitoring the running states of all service instances corresponding to the second service, including: monitoring the running state of a container group where all service instances corresponding to the second service are located through an API-Server component; or, acquiring the running states of all the service instances corresponding to the second service through the access monitoring component; or acquiring the running states of all the service instances corresponding to the second service according to the heartbeat data packet sent by the service instance.
It will be appreciated that when an exception occurs to the operation of a container group, the instance of the service that is operating must also be present. Specifically, each node in the Kubernetes cluster is deployed with a Kubelet component for managing the container group of the node where the Kubelet component is located, and the Kubelet component actively reports the running state of the managed container group through an API-Server component and records the running state in the ETCD.
Based on the above, the domain name resolution component of the first cluster can monitor the running states of the container group where all the service instances corresponding to the second service are located through the API-Server component, so as to determine the running states of all the service instances on the container group. Specifically, the domain name resolution component of the first cluster may obtain the running states of the container group where all the service instances corresponding to the second service are located by accessing the API-Server components of all the clusters one by one. Based on the foregoing description, the domain name resolution component of the first cluster may obtain the clusters and IP addresses where all service instances corresponding to the second service in the multiple clusters are located by actively accessing the API-Server components of all clusters, and access the API-Server components of all clusters at specific time intervals to update the IP address list. That is, in order to establish and maintain the IP address list, the domain name resolution component of the first cluster needs to continuously access the API-Server components of all clusters, so that the running state of the container group where the service instance is located is determined by accessing the API-Server components, the acquisition of the cluster where the service instance is located, the IP address and the running state information can be completed in the same access process, the monitoring capability of the Kubernetes cluster is fully utilized, and the complexity of cluster management is reduced.
Although the running state of the service instance running therein can be reflected using the running state of the container group according to the correlation of the running state of the container group with the service instance running therein, there is still a possibility that the situation that the container group state in which the service instance is located is normal and the service instance itself is abnormal in operation, at this time, if the running state of the service instance running therein is judged by the running state of the container group, erroneous judgment will be caused. For this reason, in some application scenarios, the running states of all service instances corresponding to the second service may be obtained by accessing a monitoring component, where the monitoring component may be Metrics-server, prometheus, etc. By accessing the monitoring components, the running states of all the service instances corresponding to the second service can be directly obtained, and misjudgment on the running states of the service instances under the conditions that the container group where the service instance is located runs normally and the service instance is abnormal is avoided.
In other application scenarios, the running states of all service instances corresponding to the second service may also be obtained by actively sending heartbeat packets according to the service instances. In this embodiment of the present application, each service instance corresponding to the second service may inform the domain name resolution component of the first cluster of its own running state by sending a heartbeat packet periodically. Therefore, the domain name resolution component of the first cluster can directly judge the running states of all the service instances corresponding to the second service only according to the received heartbeat data packet, and the accuracy of the running states of the service instances is improved.
After acquiring the running state of the second service instance, the method further comprises: querying an IP address of the second service instance from the IP address list in response to the second service instance being in an available state; querying an IP address of the third service instance from the IP address list in response to the second service instance being in an unavailable state; the third service instance is a service instance corresponding to a second service deployed in a second cluster; and using the IP address of the third service instance to replace the virtual IP address of the second service, and feeding back the virtual IP address to the first service instance as a response of the domain name resolution request.
It should be noted that the running state of the service instance includes an available state and an unavailable state. When the service instance is in an available state, the service instance is indicated to run normally, and the access request sent to the service instance can be correctly processed; otherwise, when the service instance is in an unavailable state, the service instance is indicated to run abnormally, and the access request sent to the service instance cannot be processed correctly.
In this embodiment of the present application, before responding to the domain name resolution request, the domain name resolution component of the first cluster obtains the running state of the second service instance from the IP address list, and determines, according to the running state, whether the second service instance is in an available state.
When the second service instance is in an available state, the second service instance is indicated to be capable of correctly processing the access request, at this time, the domain name resolution component of the first cluster queries the IP address of the second service instance from the IP address list, uses the IP address of the second service instance to replace the virtual IP address of the second service, and feeds back the virtual IP address of the second service instance to the first service instance as a response to the domain name resolution request.
When the second service instance is in an unavailable state, the second service instance is not capable of responding to the access request, and in order to ensure the availability of the second service, the domain name resolution component of the first cluster queries the IP address of the third service instance from the IP address list, uses the IP address of the third service instance to replace the virtual IP address of the second service, and feeds back the virtual IP address of the third service instance to the first service instance as a response to the domain name resolution request.
The third service instance is a service instance corresponding to the second service deployed in the second cluster. Here, the second cluster may be any one of a plurality of clusters.
It should be noted that, before querying the IP address of the third service instance, the domain name resolution component of the first cluster first queries, from the IP address list, the service instance in an available state in all service instances corresponding to the second service, as the third service instance, that is, a service instance in an available state corresponding to the second service deployed outside the first cluster is used as the third service instance, so as to ensure that the third service instance can correctly process the access request.
Thus, when the second service instance on the first cluster is in the unavailable state, the service availability is ensured by returning the IP addresses of the service instances on the other clusters in the available state.
It should be appreciated that when the running state of the second service instance on the first cluster is restored from the unavailable state to the available state, the domain name resolution component of the first cluster can timely sense the change of the running state of the second service instance through the foregoing continuous monitoring, and when receiving the domain name resolution request of the first service instance directed to the second service, can make a response to the corresponding domain name resolution request, that is, use the IP address of the second service instance as the response to the domain name resolution request, and feed back to the first service instance. In this way, by continuously monitoring the running state of the second service instance, the response of the domain name resolution request is determined according to the running state, and the availability and the access efficiency of the second service are considered while the region affinity rule is realized.
Further, when selecting the third service instance, according to the pre-collected network communication condition, from all clusters deployed with the service instance corresponding to the second service and in a usable state, the cluster with the best network communication with the first cluster is selected as the second cluster, and the third service instance is selected from the second cluster, so that network delay and resource overhead caused by cross-cluster access between the first service instance and the third service instance are reduced as much as possible.
In order to improve the flexibility and scalability of the domain name resolution component, in some embodiments, a multi-cluster domain name resolution plug-in is provided in the domain name resolution component of the first cluster, the multi-cluster domain name resolution plug-in being configured to build and maintain an IP address list and to respond to domain name resolution requests.
It should be noted that, in the embodiment of the present application, the domain name resolution component of the first cluster is constructed based on a standard open plug-in mechanism, including a core service module, a traffic forwarding plug-in and a multi-cluster domain name resolution plug-in.
The core service is a core module of the domain name resolution component and is used for receiving the domain name resolution request and realizing the core function of the domain name resolution component.
The traffic forwarding plug-in is used for intercepting the domain name resolution request and forwarding the domain name resolution request to the multi-cluster domain name resolution plug-in so as to process the domain name resolution request by the multi-cluster domain name resolution plug-in.
The multi-cluster domain name resolution plug-in is used for establishing and maintaining an IP address list, and responding to the domain name resolution request according to the established and maintained IP address list when the domain name resolution request forwarded by the flow forwarding plug-in is received, so that the service address resolution capability of the domain name resolution component of the first cluster is enhanced.
Therefore, the domain name resolution of the service is realized through the multi-cluster domain name resolution plug-in, and the plug-in can be used alone or in combination with other plug-ins, so that the method provided by the embodiment of the application is more flexible in deployment and application, and the applicability of the method is improved.
It should be understood that at least one service instance corresponding to each of the first service and the second service may be deployed in the same cluster in the same area, or may be deployed in multiple clusters located in different areas.
In some embodiments, at least one service instance respectively corresponding to the first service and the second service is deployed in a plurality of clusters located in different areas.
Here, the Region (Region) is divided from the geographic location and the network delay dimension, and public services such as elastic computation, block storage, object storage, VPC network, elastic public network IP, mirror image, etc. are shared in the same Region.
In practical applications, the area may correspond to a regional space defined by the administrative division units, for example, provinces, cities, and the like, or may be a regional space unrelated to the administrative division units at different positions.
In some application scenarios, the area may be divided into a plurality of available zones (AZ, availability Zone), an available zone being a physical area where power and network are isolated from each other, one available zone being unaffected by other available zone failures. The plurality of availability intervals are connected by a high-speed network to meet the requirements of users for building high availability systems across the availability intervals.
In the embodiment of the application, at least one service instance corresponding to each of the first service and the second service is deployed in a plurality of clusters located in different areas. For example, the first service deploys corresponding service instances on the first cluster of the area a, the second cluster of the area B and the third cluster of the area C; similarly, the second service deploys corresponding service instances on the first cluster of the area a, the second cluster of the area B and the third cluster of the area C.
It should be appreciated that despite the high speed network connections, the mutual access between clusters deployed in different areas still faces more resource overhead, also resulting in longer network delays.
In the related technology, for the access request outside the multi-cluster, the load equalizer is arranged outside the cluster to schedule the access request, and a local priority load strategy is set for the load equalizer, so that the client can acquire the required content nearby when accessing the service on the multi-cluster, the network congestion is reduced, and the access response speed and the hit rate of the user are improved.
However, when the access request is initiated by a first service instance within the multi-cluster, the first service instance first performs domain name resolution to obtain a virtual IP address of the second service; the first service instance then sends an access request to the virtual IP address. The load balancing component in the cluster may forward the access request to the IP address of any service instance corresponding to the second service when processing the access request, where the service instance may be deployed in another cluster of areas different from the area in which the first service instance is located, for example, the first service is deployed on the first cluster of the area a, and the access request is routed to the service instance corresponding to the second service in the area B, resulting in cross-area scheduling.
By the domain name resolution method for the service under the multi-cluster scene, even if at least one service instance corresponding to the first service and the second service is deployed in a plurality of clusters located in different areas, the IP address of the second service instance of the second service on the first cluster can be returned preferentially, that is, the first service instance in the first cluster always accesses the second service instance located in the first cluster, so that the original access request distribution strategy based on the virtual IP address is changed, the nearby scheduling strategy based on the area affinity is realized, and the cross-area scheduling is avoided.
In summary, in the technical solution provided in the present application, when the domain name resolution component of the first cluster receives a domain name resolution request of the first service instance directed to the second service, an IP address of the second service instance is determined by pre-establishing an IP address list of at least one service instance corresponding to the second service instance, where the second service instance is a service instance corresponding to the second service deployed in the first cluster, and the IP address of the second service instance is used to replace a virtual IP address of the second service, and is fed back to the first service instance as a response to the domain name resolution request. Therefore, the IP address of the second service instance is used for replacing the virtual IP address of the second service to return to the first service instance, the purpose of preferentially returning the IP address of the second service instance of the first cluster is achieved, when a plurality of services are mutually accessed, the first service initiating service access can access the second service instance of the same cluster nearby, and network delay and resource overhead caused by cross-cluster access to the service instance are avoided.
Exemplary System
The embodiment of the application provides a domain name resolution system of services in a multi-cluster scene, wherein a first service and a second service in the multi-cluster are respectively corresponding to at least one service instance, and a first service instance corresponding to the first service is deployed in the first cluster; the system comprises: a response unit 601 and a feedback unit 602. Wherein:
a response unit 601, configured to determine, in response to receiving a domain name resolution request of the first service instance directed to the second service, an IP address of the second service instance according to a pre-established IP address list of at least one service instance corresponding to the second service; the second service instance is a service instance corresponding to a second service deployed in the first cluster.
And a feedback unit 602 configured to use the IP address of the second service instance instead of the virtual IP address of the second service as a response to the domain name resolution request, and feed back the response to the first service instance.
The domain name resolution system for services in the multi-cluster scene provided by the embodiment of the application can realize the flow and steps of the domain name resolution method for services in the multi-cluster scene in any embodiment, and achieve the same technical effects, and are not described in detail herein.
Exemplary apparatus
Fig. 7 is a schematic structural diagram of an electronic device provided according to some embodiments of the present application; as shown in fig. 7, the electronic device includes:
one or more processors 701;
a computer readable medium may be configured to store one or more programs 702, the one or more processors 701, when executing the one or more programs 702, implement the steps of: responding to the received domain name resolution request of the first service instance pointing to the second service, and determining the IP address of the second service instance according to the pre-established IP address list of at least one service instance corresponding to the second service; the second service instance is a service instance corresponding to the second service deployed in the first cluster; and using the IP address of the second service instance to replace the virtual IP address of the second service as a response of the domain name resolution request, and feeding back the response to the first service instance.
FIG. 8 is a hardware architecture of an electronic device provided in accordance with some embodiments of the present application; as shown in fig. 8, the hardware structure of the electronic device may include: a processor 801, a communication interface 802, a computer readable medium 803, and a communication bus 804.
Wherein the processor 801, the communication interface 802, and the computer-readable storage medium 803 communicate with each other via a communication bus 804.
Alternatively, the communication interface 802 may be an interface of a communication module, such as an interface of a GSM module.
The processor 801 may specifically include a domain name resolution component of the first cluster, where the domain name resolution component of the first cluster performs the following steps: responding to the received domain name resolution request of the first service instance pointing to the second service, and determining the IP address of the second service instance according to the pre-established IP address list of at least one service instance corresponding to the second service; the second service instance is a service instance corresponding to the second service deployed in the first cluster; and using the IP address of the second service instance to replace the virtual IP address of the second service as a response of the domain name resolution request, and feeding back the response to the first service instance.
The processor 801 may be a general purpose processor including a central processing unit (central processing unit, CPU for short), a network processor (Network Processor, NP for short), etc., or may be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The electronic device of the embodiments of the present application exist in a variety of forms including, but not limited to:
(1) A mobile communication device: such devices are characterized by mobile communication capabilities and are primarily aimed at providing voice, data communications. Such terminals include: smart phones (e.g., iPhone), multimedia phones, functional phones, and low-end phones, etc.
(2) Ultra mobile personal computer device: such devices are in the category of personal computers, having computing and processing functions, and generally also having mobile internet access characteristics. Such terminals include: PDA, MID, and UMPC devices, etc., such as iPad.
(3) Portable entertainment device: such devices may display and play multimedia content. The device comprises: audio, video players (e.g., iPod), palm game consoles, electronic books, and smart toys and portable car navigation devices.
(4) And (3) a server: the configuration of the server includes a processor, a hard disk, a memory, a system bus, and the like, and the server is similar to a general computer architecture, but is required to provide highly reliable services, and thus has high requirements in terms of processing capacity, stability, reliability, security, scalability, manageability, and the like.
(5) Other electronic devices with data interaction function.
It should be noted that, according to implementation requirements, each component/step described in the embodiments of the present application may be split into more components/steps, and two or more components/steps or part of operations of the components/steps may be combined into new components/steps, so as to achieve the purposes of the embodiments of the present application.
The above-described methods according to embodiments of the present application may be implemented in hardware, firmware, or as software or computer code storable in a recording medium such as a CD ROM, RAM, floppy disk, hard disk, or magneto-optical disk, or as computer code originally stored in a remote recording medium or a non-transitory machine storage medium and to be stored in a local recording medium downloaded through a network, so that the methods described herein may be stored on such software processes on a recording medium using a general purpose computer, a special purpose processor, or programmable or dedicated hardware such as an ASIC or FPGA. It is understood that a computer, processor, microprocessor controller, or programmable hardware includes a memory component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code that, when accessed and executed by the computer, processor, or hardware, implements the domain name resolution methods of services in the multi-cluster scenario described herein. Furthermore, when a general purpose computer accesses code for implementing the methods illustrated herein, execution of the code converts the general purpose computer into a special purpose computer for performing the methods illustrated herein.
Those of ordinary skill in the art will appreciate that the elements and method steps of the examples described in connection with the embodiments disclosed herein can be implemented as electronic hardware, or as a combination of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the embodiments of the present application.
It should be noted that, in the present specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment is mainly described in a different point from other embodiments. In particular, for the apparatus and system embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, with reference to the description of the method embodiments in part.
The above-described apparatus and system embodiments are merely illustrative, in which elements illustrated as separate elements may or may not be physically separate, and elements illustrated as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.
The foregoing description is only of the preferred embodiments of the present application and is not intended to limit the same, but rather, various modifications and variations may be made by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.
Claims (9)
1. The domain name resolution method of the service under the multi-cluster scene is characterized in that at least one service instance corresponds to a first service and a second service in the multi-cluster respectively, a first service instance corresponding to the first service is deployed in the first cluster, and the method is executed by a domain name resolution component of the first cluster; the method comprises the following steps:
responding to the received domain name resolution request of the first service instance pointing to the second service, and determining the IP address of the second service instance according to the pre-established IP address list of at least one service instance corresponding to the second service; the second service instance is a service instance corresponding to the second service deployed in the first cluster;
using the IP address of the second service instance to replace the virtual IP address of the second service, and feeding back the virtual IP address to the first service instance as a response of the domain name resolution request;
The domain name resolution component of the first cluster is provided with a multi-cluster domain name resolution plug-in, and the multi-cluster domain name resolution plug-in is used for establishing and maintaining the IP address list and responding to the domain name resolution request.
2. The method for domain name resolution of a service in a multi-cluster scenario according to claim 1, wherein the IP address list of at least one service instance corresponding to the second service is established by:
acquiring and recording clusters and IP addresses of all service instances corresponding to the second service in the IP address list by accessing API-Server components of all clusters;
correspondingly, the determining the IP address of the second service instance according to the IP address list of at least one service instance corresponding to the second service, which is pre-established, includes:
querying whether the second service instance exists or not from the IP address list;
and responding to the existence of the second service instance, and inquiring the IP address of the second service instance from the IP address list.
3. The method for domain name resolution for a service in a multi-cluster scenario of claim 2, further comprising:
continuously monitoring and recording the running states of all service instances corresponding to the second service in the IP address list;
Accordingly, before the querying the IP address of the second service instance from the IP address list, the method further includes:
and inquiring the running state of the second service instance from the IP address list.
4. A method for domain name resolution for a service in a multi-cluster scenario as recited in claim 3, further comprising:
querying an IP address of the second service instance from the IP address list in response to the second service instance being in an available state;
querying an IP address of a third service instance from the IP address list in response to the second service instance being in an unavailable state; the third service instance is a service instance corresponding to the second service deployed in a second cluster; and using the IP address of the third service instance to replace the virtual IP address of the second service, and feeding back the virtual IP address to the first service instance as a response of the domain name resolution request.
5. The method for domain name resolution of a service in a multi-cluster scenario according to claim 3, wherein the continuously monitoring the running states of all service instances corresponding to the second service includes:
monitoring the running state of a container group where all service instances corresponding to the second service are located through the API-Server component; or,
Acquiring the running states of all service instances corresponding to the second service through an access monitoring component; or,
and acquiring the running states of all the service instances corresponding to the second service according to the heartbeat data packet sent by the service instance.
6. The method for domain name resolution of a service in a multi-cluster scenario according to claim 1, wherein at least one service instance corresponding to each of the first service and the second service is deployed in a plurality of clusters located in different areas.
7. The domain name resolution system of the service under the multi-cluster scene is characterized in that at least one service instance is respectively corresponding to a first service and a second service in the multi-cluster, and a first service instance corresponding to the first service is deployed in the first cluster; the system comprises:
the response unit is configured to respond to the received domain name resolution request of the first service instance pointing to the second service, and determine the IP address of the second service instance according to the pre-established IP address list of at least one service instance corresponding to the second service; the second service instance is a service instance corresponding to the second service deployed in the first cluster;
a feedback unit configured to replace the virtual IP address of the second service with the IP address of the second service instance, and to feed back the virtual IP address to the first service instance as a response to the domain name resolution request;
The domain name resolution component of the first cluster is provided with a multi-cluster domain name resolution plug-in, and the multi-cluster domain name resolution plug-in is used for establishing and maintaining the IP address list and responding to the domain name resolution request.
8. A computer readable storage medium having stored thereon a computer program, wherein the computer program is a domain name resolution method for a service in a multi-cluster scenario according to any of claims 1-6.
9. An electronic device, comprising: memory, a processor, and a program stored in the memory and executable on the processor, the processor implementing the domain name resolution method of services in a multi-cluster scenario according to any one of claims 1-6 when the program is executed.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211048384.5A CN115412530B (en) | 2022-08-30 | 2022-08-30 | Domain name resolution method and system for service under multi-cluster scene |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211048384.5A CN115412530B (en) | 2022-08-30 | 2022-08-30 | Domain name resolution method and system for service under multi-cluster scene |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115412530A CN115412530A (en) | 2022-11-29 |
| CN115412530B true CN115412530B (en) | 2024-01-30 |
Family
ID=84164618
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211048384.5A Active CN115412530B (en) | 2022-08-30 | 2022-08-30 | Domain name resolution method and system for service under multi-cluster scene |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115412530B (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109542645A (en) * | 2018-11-20 | 2019-03-29 | 北京锐安科技有限公司 | A kind of method, apparatus, electronic equipment and storage medium calling service |
| CN111464592A (en) * | 2020-03-09 | 2020-07-28 | 平安科技（深圳）有限公司 | Load balancing method, device, equipment and storage medium based on microservice |
| CN111464648A (en) * | 2020-04-02 | 2020-07-28 | 聚好看科技股份有限公司 | Distributed local DNS system and domain name query method |
| CN113938464A (en) * | 2021-09-24 | 2022-01-14 | 福建天泉教育科技有限公司 | Access request method and terminal |
| CN113946450A (en) * | 2021-11-03 | 2022-01-18 | 北京航空航天大学 | Self-adaptive authorized polling load balancing system for K8S micro service framework |
| CN114153566A (en) * | 2021-12-20 | 2022-03-08 | 浪潮电子信息产业股份有限公司 | Cross-processor architecture multi-container inter-cluster service discovery method, device and equipment |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110520843B (en) * | 2017-03-23 | 2023-08-29 | Dh2I公司 | Highly available stateful containers in clustered environments |
| US11301279B2 (en) * | 2019-02-26 | 2022-04-12 | International Business Machines Corporation | Associating virtual IP address of virtual server with appropriate operating system in server cluster |
-
2022
- 2022-08-30 CN CN202211048384.5A patent/CN115412530B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109542645A (en) * | 2018-11-20 | 2019-03-29 | 北京锐安科技有限公司 | A kind of method, apparatus, electronic equipment and storage medium calling service |
| CN111464592A (en) * | 2020-03-09 | 2020-07-28 | 平安科技（深圳）有限公司 | Load balancing method, device, equipment and storage medium based on microservice |
| CN111464648A (en) * | 2020-04-02 | 2020-07-28 | 聚好看科技股份有限公司 | Distributed local DNS system and domain name query method |
| CN113938464A (en) * | 2021-09-24 | 2022-01-14 | 福建天泉教育科技有限公司 | Access request method and terminal |
| CN113946450A (en) * | 2021-11-03 | 2022-01-18 | 北京航空航天大学 | Self-adaptive authorized polling load balancing system for K8S micro service framework |
| CN114153566A (en) * | 2021-12-20 | 2022-03-08 | 浪潮电子信息产业股份有限公司 | Cross-processor architecture multi-container inter-cluster service discovery method, device and equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115412530A (en) | 2022-11-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2020253266A1 (en) | Method for providing edge service, apparatus and device | |
| US11445039B2 (en) | Method and apparatus for providing edge computing services | |
| US20190028538A1 (en) | Method, apparatus, and system for controlling service traffic between data centers | |
| CN110012437B (en) | Method, device and system for sending multicast message | |
| CN111615066B (en) | Distributed micro-service registration and calling method based on broadcast | |
| US8972519B2 (en) | Optimization of multimedia service over an IMS network | |
| EP2710817B1 (en) | Methods and devices for content distribution | |
| US9342575B2 (en) | Providing high availability in an active/active appliance cluster | |
| US9075660B2 (en) | Apparatus and method for providing service availability to a user via selection of data centers for the user | |
| KR101914488B1 (en) | Server cluster and method for push notification service | |
| US10064096B2 (en) | Traffic distribution in heterogenous network environment | |
| US11251981B2 (en) | Communication method and apparatus | |
| US11432137B2 (en) | Service notification method for mobile edge host and apparatus | |
| CN110381131B (en) | Method for realizing MEC node identification, mobile terminal, server and storage medium | |
| KR20220001963A (en) | Method and apparatus for interaction between edge computing system and mobile communication network to provide mobile edge computing service | |
| JP7237195B2 (en) | COMMUNICATION METHOD, APPARATUS, ENTITY AND COMPUTER PROGRAM | |
| CN112351083B (en) | Service processing method and network service system | |
| CN109547508B (en) | Method, device and system for realizing resource access | |
| CN105656978A (en) | Resource sharing method and device | |
| CN115280288A (en) | Server system and method of managing server system | |
| CN115412530B (en) | Domain name resolution method and system for service under multi-cluster scene | |
| EP4057577A1 (en) | Addressing method, addressing system and addressing apparatus | |
| CN110958182B (en) | Communication method and related equipment | |
| CN116962446B (en) | Dynamic NVMe-oF link management method and system | |
| WO2023152980A1 (en) | Resource sharing system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |