Service Mesh-Based Service Domain Name Resolution Method, Apparatus, and Equipment

Abstract

This application provides a service domain name resolution method, apparatus, device, and computer-readable storage medium based on a service mesh. The method includes: a service name resolution service receiving a service name resolution request sent by a first microservice; the service name resolution request including a service domain name registered in the service mesh by a second microservice; resolving the service domain name based on a service list in a local cache to obtain the IP address of the second microservice; the service list being obtained synchronously from the control plane of the service mesh; and returning the IP address to the first microservice, enabling the first microservice to access the second microservice in the service mesh based on the IP address. This application enables flexible expansion of multiple registry centers when resolving service domain names in a service mesh, achieving decoupling from the PaaS deployment platform.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of computer technology, and in particular to a service domain name resolution method, apparatus, device, and computer-readable storage medium based on a service mesh. Background Technology

[0002] Service Mesh is the infrastructure layer that handles inter-service communication. It is responsible for reliably delivering requests across the complex service topologies of modern cloud-native applications. In practice, Service Mesh is typically implemented as a lightweight network proxy array, deployed alongside the application code, so the application is unaware of the proxy's existence. In related technologies, Service Mesh solutions do not provide service name-based domain name resolution services themselves. Instead, they rely on the Domain Name System (DNS) component within the service registration and discovery framework of Platform as a Service (PaaS) platforms (such as the kubeDNS component in the Kubernetes container orchestration platform). This results in tight coupling with the registry center used by the PaaS platform, making it difficult to extend to PaaS platforms based on other registry centers. Summary of the Invention

[0003] This application provides a service domain name resolution method, apparatus, device, and computer-readable storage medium based on a service mesh, which can support flexible expansion of multiple registry centers when resolving service domain names in the service mesh, and achieve decoupling from the PaaS deployment platform.

[0004] The technical solution of this application embodiment is implemented as follows: This application provides a service domain name resolution method based on a service mesh, including: The service name resolution service receives a service name resolution request sent by the first microservice; wherein, the service name resolution request includes the service domain name registered by the second microservice in the service mesh; Based on the service list in the local cache, the service domain name is resolved to obtain the IP address of the second microservice; wherein, the service list is obtained synchronously from the control plane of the service mesh; The IP address is returned to the first microservice so that the first microservice can access the second microservice in the service mesh based on the IP address.

[0005] In some embodiments, the service name resolution service is deployed in the data plane of the service mesh in a distributed manner. The service name resolution service receives a service name resolution request sent by a first microservice, including: the service name resolution service receives a service name resolution request sent by a first microservice deployed locally.

[0006] In some embodiments, the first microservice is deployed in an application container, and the service name resolution service and the data plane component of the service mesh are deployed in a proxy container, with the proxy container and the application container sharing the same local network; or, the first microservice, the service name resolution service, and the data plane component of the service mesh are deployed together on the same host.

[0007] In some embodiments, the method further includes: if it is determined that the correspondence between service domain names and IP addresses registered in the service mesh has changed, obtaining the changed service domain name and IP address pair; and updating the service list based on the changed service domain name and IP address pair.

[0008] In some embodiments, obtaining the changed service domain name and IP address pair when the correspondence between the registered service domain name and IP address in the service mesh has changed includes at least one of the following: obtaining the changed service domain name and IP address pair from the control plane when the correspondence between the service domain name and IP address detected by the control plane has changed; obtaining at least one set of service domain names and IP addresses configured by the user from an external service name configuration system, and determining the changed service domain name and IP address pair in the service list based on the at least one set of service domain names and IP addresses configured by the user.

[0009] In some embodiments, resolving the service domain name based on the service list in the local cache to obtain the IP address of the second microservice includes: querying the service list in the local cache based on the service domain name; if the IP address corresponding to the service domain name is not found in the service list, forwarding the service name resolution request to a designated external service name resolution service; and receiving the IP address of the second microservice returned by the external service name resolution service.

[0010] In some embodiments, the method further includes: when the service name resolution service starts, obtaining the full set of currently discovered service domain name and IP address pairs from the control plane; adding the full set of service domain name and IP address pairs to the service list; and caching the service list in a local cache.

[0011] This application provides a service domain name resolution device based on a service mesh, including: The receiving module is used to receive a service name resolution request sent by the first microservice; wherein the service name resolution request includes the service domain name registered by the second microservice in the service mesh; The resolution module is used to resolve the service domain name based on the service list in the local cache to obtain the IP address of the second microservice; wherein the service list is obtained synchronously from the control plane of the service mesh; The return module is used to return the IP address to the first microservice so that the first microservice can access the second microservice in the service mesh based on the IP address.

[0012] In some embodiments, the service name resolution service is deployed in the data plane of the service mesh in a distributed manner, and the receiving module is further configured to: the service name resolution service receive a service name resolution request sent by a first microservice deployed locally.

[0013] In some embodiments, the first microservice is deployed in an application container, and the service name resolution service and the data plane component of the service mesh are deployed in a proxy container, with the proxy container and the application container sharing the same local network; or, the first microservice, the service name resolution service, and the data plane component of the service mesh are deployed together on the same host.

[0014] In some embodiments, the apparatus further includes: a first acquisition module, configured to acquire the changed service domain name and IP address pair when it is determined that the correspondence between the service domain name and IP address registered in the service mesh has changed; and an update module, configured to update the service list based on the changed service domain name and IP address pair.

[0015] In some embodiments, the first acquisition module is further configured to: acquire the changed service domain name and IP address pair from the control plane when a change in the correspondence between the service domain name and IP address detected by the control plane is detected; acquire at least one set of service domain names and IP addresses configured by the user from an external service name configuration system; and determine the changed service domain name and IP address pair in the service list based on the at least one set of service domain names and IP addresses configured by the user.

[0016] In some embodiments, the resolution module is further configured to: query a list of services in a local cache based on the service domain name; if the IP address corresponding to the service domain name is not found in the service list, forward the service name resolution request to a designated external service name resolution service; and receive the IP address of the second microservice returned by the external service name resolution service.

[0017] In some embodiments, the apparatus further includes: a second acquisition module, configured to acquire, from the control plane, all currently discovered service domain name and IP address pairs when the service name resolution service starts; and a caching module, configured to add the all service domain name and IP address pairs to the service list and cache the service list in a local cache.

[0018] This application provides a service domain name resolution device based on a service mesh, including: a memory for storing executable instructions; and a processor for implementing the method provided in this application when executing the executable instructions stored in the memory.

[0019] This application provides a computer-readable storage medium storing executable instructions for inducing a processor to execute and implement the method provided in this application.

[0020] The embodiments of this application have the following beneficial effects: The service name resolution service receives service name resolution requests from the first microservice, including the service domain name registered by the second microservice in the service mesh. Based on a locally cached service list, the service domain name is resolved to obtain the IP address of the second microservice. This service list is synchronized from the service mesh's control plane. Finally, the IP address is returned to the first microservice, enabling it to access the second microservice within the service mesh based on the IP address. Because the service mesh's control plane can adapt to different registry centers, the service list synchronized from the control plane can include the mapping between service domain names and IP addresses of microservices registered through different registry centers. This allows for flexible expansion across multiple registry centers when resolving service domain names in the service mesh, achieving decoupling from the PaaS deployment platform. Attached Figure Description

[0021] Figure 1 This is an optional schematic diagram of a service mesh-based microservice architecture provided in an embodiment of this application; Figure 2 This is an optional structural diagram of a service domain name resolution device based on a service mesh provided in this application embodiment; Figure 3 This is an optional flowchart illustrating a service domain name resolution method based on a service mesh provided in an embodiment of this application. Figure 4 This is an optional flowchart illustrating a service domain name resolution method based on a service mesh provided in an embodiment of this application. Figure 5 This is an optional flowchart illustrating a service domain name resolution method based on a service mesh provided in an embodiment of this application. Figure 6 This is an optional flowchart illustrating a service domain name resolution method based on a service mesh provided in an embodiment of this application. Figure 7 This is an optional flowchart illustrating a service domain name resolution method based on a service mesh provided in an embodiment of this application. Figure 8 This is a schematic diagram of the overall architecture of the distributed DNS service provided in this application embodiment applied in a service mesh; Figure 9 This is a schematic diagram illustrating an implementation process of the service domain name resolution method based on service mesh provided in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0024] If the application documents contain similar descriptions such as "first / second", the following explanation shall be added: In the following description, the terms "first / second / third" are used only to distinguish similar objects and do not represent a specific order of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0025] Unless otherwise defined, 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 application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0026] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0027] 1) pilot-discovery is the control plane component of Service Mesh. As the scheduling and control center, it can provide service registration information and service configuration distribution to control the functions of the data plane components.

[0028] 2) pilot-agent is the data plane component of Service Mesh, responsible for environment initialization and cleanup, as well as the lifecycle management of other data plane components (such as Envoy components).

[0029] 3) Kubernetes is an open-source container orchestration engine used to automate the deployment, scaling, and management of containerized applications.

[0030] To better understand the service domain name resolution method based on service mesh provided in the embodiments of this application, the service domain name resolution scheme used in service mesh in related technologies will be described below.

[0031] In related technologies, Service Mesh solutions do not provide service domain name resolution services themselves. Instead, they rely on DNS components within container orchestration platforms, such as the kubeDNS component in Kubernetes. The kubeDNS component is a centrally deployed DNS service cluster. Taking a Kubernetes-based Service Mesh solution as an example, Kubernetes includes the kubeDNS component and the SkyDNS component. The basic working principle of service domain name resolution in this solution includes: the kubeDNS component is responsible for monitoring changes in services and endpoints within Kubernetes and updating the relevant information in the SkyDNS component to synchronize it to the service list; the SkyDNS component is responsible for receiving service domain name resolution requests, querying the synchronized service list, and returning the resolution results.

[0032] Among the aforementioned technologies, Service Mesh addresses service domain names through a centralized DNS service, which presents the following problems: 1) Service domain name addressing relies on the kubeDNS component, which updates the service list based on changes in Kubernetes platform services and endpoints. This makes it tightly coupled with the Kubernetes platform and difficult to extend to other registry centers; 2) Deploying an additional centralized DNS cluster is required when building a Service Mesh network, which not only increases physical resource costs but also increases post-construction maintenance costs due to the need to consider the high availability and even disaster recovery of the DNS cluster; 3) The centralized DNS service deployment means that once the cluster becomes unavailable, the Service Mesh data plane nodes will not function properly after the DNS cache expires; 4) Centralized DNS services are generally deployed remotely, even across network environments, resulting in a certain response delay in domain name resolution, and even timeouts may occur in heterogeneous network environments; 5) The centralized DNS service handles service name resolution requests from all nodes in the Service Mesh data plane. As the number of data plane nodes increases, it will inevitably put significant pressure on the DNS service, affecting performance and necessitating DNS service expansion, further increasing resource and maintenance costs.

[0033] This application provides a service mesh-based service domain name resolution method, apparatus, device, and computer-readable storage medium, which supports flexible expansion of multiple registries when resolving service domain names in the service mesh, achieving decoupling from the PaaS deployment platform. The following describes exemplary applications of the service mesh-based service domain name resolution device provided in this application. This device can be implemented as a service name resolution service, which can be implemented as various types of user terminals such as laptops, tablets, desktop computers, set-top boxes, and mobile devices (e.g., mobile phones, portable music players, personal digital assistants, dedicated messaging devices, portable gaming devices), or as a server. The following describes exemplary applications when the device is implemented as a server.

[0034] See Figure 1 , Figure 1This is an optional schematic diagram of a service mesh-based microservice architecture 100 provided in this application embodiment. It enables communication between multiple microservices based on the service mesh. Multiple microservices deployed on the service mesh (exemplarily shown as the first microservice 400-1 and the second microservice 400-2) are connected to the server 200 via a network 300, which can be a wide area network (WAN), a local area network (LAN), or a combination of both. The service mesh includes a control plane 510 and a data plane (exemplarily shown as data plane nodes 520-1 and 520-2). Each microservice is deployed with an associated data plane node. The data plane is responsible for converting, forwarding, and monitoring every network packet or request entering or leaving the associated microservice. The control plane 510 is used to provide service registration information and service configuration distribution in the service mesh to control the functionality of the data plane components.

[0035] The first microservice 400-1 is used to: send a service name resolution request to the server 200, the service name resolution request including the service domain name registered by the second microservice 400-2 in the service mesh; receive the IP address returned by the server 200, and access the second microservice 400-2 in the service mesh based on the IP address.

[0036] Server 200 is configured to: receive a service name resolution request sent by a first microservice 400-1; wherein the service name resolution request includes a service domain name registered by a second microservice 400-2 in the service mesh; resolve the service domain name based on a service list in a local cache to obtain the IP address of the second microservice 400-2; wherein the service list is obtained synchronously from the control plane 510 of the service mesh; and return the IP address to the first microservice 400-1 so that the first microservice 400-1 can access the second microservice 400-2 in the service mesh based on the IP address.

[0037] In some embodiments, server 200 can be a standalone physical server or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Server 200 can be deployed centrally or in a distributed manner within the data plane of a service mesh; this is not limited to these methods. Terminals can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart car connectivity, etc., but are not limited to these. The first microservice and the server can be directly or indirectly connected via wired or wireless communication; this is not limited in this embodiment of the invention.

[0038] The microservice architecture 100 involved in this application embodiment can also be a distributed system of a blockchain system. This distributed system can be a distributed network of nodes (any form of computing device accessing the network, such as servers or user terminals) and clients. These nodes form a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). Server 200 can serve as a node in this distributed system. In this distributed system, any machine, such as a server or terminal, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer.

[0039] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the service domain name resolution device 200 based on the service mesh provided in this application embodiment. Figure 2 The service mesh-based service domain name resolution device 200 shown includes at least one processor 210, a memory 250, at least one network interface 220, and a user interface 230. The various components in the service mesh-based service domain name resolution device 200 are coupled together via a bus system 240. It is understood that the bus system 240 is used to implement communication between these components. In addition to a data bus, the bus system 240 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 240.

[0040] Processor 210 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0041] User interface 230 includes one or more output devices 231 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 230 also includes one or more input devices 232, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0042] The memory 250 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 250 may optionally include one or more storage devices physically located away from the processor 210.

[0043] The memory 250 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 250 described in this application embodiment is intended to include any suitable type of memory.

[0044] In some embodiments, memory 250 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0045] Operating system 251 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks; The network communication module 252 is used to reach other computing devices via one or more (wired or wireless) network interfaces 220, such as Bluetooth, WiFi, and Universal Serial Bus (USB). Presentation module 253 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 231 associated with user interface 230 (e.g., a display screen, a speaker, etc.). The input processing module 254 is used to detect and translate one or more user inputs or interactions from one or more input devices 232.

[0046] In some embodiments, the service domain name resolution device based on service mesh provided in this application can be implemented in software. Figure 2 A service mesh-based service domain name resolution device 255, which can be software in the form of programs and plug-ins, is shown stored in memory 250. It includes the following software modules: receiving module 2551, resolution module 2552, and return module 2553. These modules are logically related and can therefore be arbitrarily combined or further split according to the functions they implement.

[0047] The functions of each module will be explained below.

[0048] In other embodiments, the service domain name resolution device based on the service mesh provided in this application can be implemented in hardware. As an example, the service domain name resolution device based on the service mesh provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the service domain name resolution method based on the service mesh provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0049] The following will illustrate the service domain name resolution method based on service mesh provided in this application embodiment with reference to exemplary applications and implementations of the terminal or server provided in the embodiments of this application.

[0050] See Figure 3 , Figure 3 This is an optional flowchart illustrating a service domain name resolution method based on a service mesh provided in this application embodiment. The following will be combined with... Figure 3 The steps shown below can be performed by the service name resolution service mentioned earlier.

[0051] In step S101, the service name resolution service receives a service name resolution request sent by the first microservice; wherein the service name resolution request includes the service domain name registered by the second microservice in the service mesh.

[0052] Here, the service name resolution service is used to resolve service domain names in the service mesh. It can be a distributed or centralized service, and it can be deployed in the service mesh or separately from the service mesh. There are no restrictions here.

[0053] Multiple microservices can be deployed within a service mesh, and each microservice can be deployed and managed through a PaaS platform. During implementation, any suitable PaaS platform can be used to deploy and manage the microservices within the service mesh.

[0054] The first microservice and the second microservice are different microservices connected based on the service mesh. The first microservice and the second microservice are each associated with a data plane node in the service mesh and deployed together with their respective data plane nodes. The first microservice and the second microservice can communicate based on the data plane nodes of the service mesh. In implementation, the first microservice and the second microservice can be any suitable service in the service mesh; there are no limitations on this. In some embodiments, the first microservice can be an upstream service or an upstream application, and the second microservice can be a downstream service or a downstream application that the first microservice needs to invoke.

[0055] Each microservice deployed in the service mesh needs to register a service domain name in the registry. The service domain name is the domain name used to access the microservice within the service mesh. It can be any suitable string or number that can uniquely identify the microservice; there are no restrictions on this. For example, the service domain name of a microservice can be its service name, service ID, etc.

[0056] In step S102, the service domain name is resolved based on the service list in the local cache to obtain the IP address of the second microservice; wherein, the service list is obtained synchronously from the control plane of the service mesh.

[0057] Here, the service list can include the mapping between the service domain names and IP addresses of microservices. Based on this mapping, the service domain names can be resolved to obtain the IP address of the second microservice. During implementation, the service list can be cached in any suitable way; for example, it can be cached in local memory, local disk, or a local database.

[0058] The service mesh control plane can provide service registration information within the service mesh. This allows the control plane to retrieve the service domain names and corresponding IP addresses of registered microservices within the service mesh and synchronize or update them to the locally cached service list. Since the IP address of the same microservice may change dynamically, the service mesh control plane can obtain the latest IP address of the microservice through service discovery. Therefore, the mapping between service domain names and IP addresses in the service list synchronized from the service mesh control plane remains valid.

[0059] In step S103, the IP address is returned to the first microservice so that the first microservice can access the second microservice in the service mesh based on the IP address.

[0060] Here, after resolving the IP address of the second microservice, the IP address is returned to the first microservice, which can then access the second microservice in the service mesh based on the IP address.

[0061] In some embodiments, the service name resolution service is deployed in a distributed manner within the data plane of the service mesh. Step S101 may include: Step S111, whereby the service name resolution service receives a service name resolution request sent by a first microservice deployed locally. Here, the service name resolution service is deployed in a distributed manner, with each service name resolution service node in the distributed service name resolution service deployed together with a data plane node of the service mesh. Since the data plane nodes and microservices are deployed together in the service mesh, each microservice can correspond to a local service name resolution service node. The service name resolution service can receive the service name resolution request sent by the first microservice deployed locally, process the request, and return the corresponding IP address. In this way, each microservice can directly resolve the IP address of the microservice it wants to access through local communication, greatly reducing service name resolution latency. Furthermore, each service name resolution service only needs to process the service name resolution request of its local microservice, resulting in lower request pressure, higher performance, and less likelihood of performance bottlenecks. In addition, the unavailability of a single service name resolution service node will not affect the service name resolution of other data plane nodes, leading to better overall service stability.

[0062] In some embodiments, the first microservice is deployed in an application container, and the service name resolution service and the service mesh data plane component are deployed in a proxy container. The proxy container and the application container share the same local network. Here, the service mesh data plane may include at least one data plane component, such as pilot-agent, Envoy, etc. The first microservice can be deployed in the application container, and the service name resolution service and the service mesh data plane component are deployed together. They can be deployed in a sidecar manner in a proxy container within the same container POD as the application container. A POD is the smallest basic unit for creating or deploying containers. A POD represents a process running on the cluster. Any container within the same POD will share the same namespace and local network, and containers can easily communicate with other containers within the same container POD. In implementation, the application container and the proxy container can be any suitable container, and there are no limitations on this.

[0063] In some embodiments, the first microservice, the service name resolution service, and the data plane component of the service mesh are deployed together on the same host. Here, the host on which the first microservice, the service name resolution service, and the data plane component of the service mesh are deployed together can be any suitable server host, including but not limited to one or more of virtual machines, bare metal servers, etc.

[0064] In this embodiment, a service name resolution request sent by a first microservice is received via a service name resolution service. This request includes the service domain name registered by the second microservice in the service mesh. The service domain name is resolved based on a service list cached locally to obtain the IP address of the second microservice. This service list is synchronized from the control plane of the service mesh. Finally, the IP address is returned to the first microservice, enabling it to access the second microservice within the service mesh based on the IP address. Because the control plane of the service mesh can adapt to different registry centers, the service list synchronized from the control plane can include the mapping between service domain names and IP addresses of microservices registered through different registry centers. This allows for flexible expansion across multiple registry centers when resolving service domain names in the service mesh, achieving decoupling from the PaaS deployment platform.

[0065] In some embodiments, see Figure 4 , Figure 4 This is an optional flowchart illustrating a service domain name resolution method based on a service mesh provided in an embodiment of this application. Figure 3 The method can also perform the following steps S401 to S402, where the execution subject of the following steps can be the service name resolution service mentioned above.

[0066] In step S101, the service name resolution service receives a service name resolution request sent by the first microservice; wherein the service name resolution request includes the service domain name registered by the second microservice in the service mesh.

[0067] In step S102, the service domain name is resolved based on the service list in the local cache to obtain the IP address of the second microservice; wherein, the service list is obtained synchronously from the control plane of the service mesh.

[0068] In step S103, the IP address is returned to the first microservice so that the first microservice can access the second microservice in the service mesh based on the IP address.

[0069] In step S401, if it is determined that the correspondence between the service domain name and IP address registered in the service mesh has changed, the changed service domain name and IP address pair is obtained.

[0070] Here, the microservices registered in the service mesh and their IP addresses are dynamically changing, and the mapping between registered service domain names and IP addresses will also change accordingly. Changes to the mapping between registered service domain names and IP addresses in the service mesh can include, but are not limited to, adding, deleting, or modifying service domain names and IP addresses. Whether the mapping between registered service domain names and IP addresses in the service mesh has changed can be determined through listening or polling.

[0071] In step S402, the service list is updated based on the changed service domain name and IP address pair.

[0072] Here, the service list can include at least one set of service domain name and IP address pairs. The service domain name and IP address pairs in the service list can be updated by adding, deleting, or modifying them based on changes to the service domain name and IP address pairs.

[0073] It should be noted that step S401 above is not limited to... Figure 4 The execution order shown can also be modified, for example, steps S401 to S402 can be executed before step S101.

[0074] In this embodiment, when it is determined that the correspondence between service domain names and IP addresses registered in the service mesh has changed, the changed service domain name and IP address pair is obtained, and the service list is updated based on the changed service domain name and IP address pair. This ensures the validity of the correspondence between service domain names and IP addresses in the service list during service domain name resolution, guaranteeing normal access between microservices.

[0075] In some embodiments, see Figure 5 , Figure 5 This is an optional flowchart illustrating a service domain name resolution method based on a service mesh provided in an embodiment of this application. Figure 4 Step S401 may include at least one of the following steps S501 and S502. The following description will explain each step in detail; the entity executing these steps may be the service name resolution service mentioned earlier.

[0076] In step S101, the service name resolution service receives a service name resolution request sent by the first microservice; wherein the service name resolution request includes the service domain name registered by the second microservice in the service mesh.

[0077] In step S102, the service domain name is resolved based on the service list in the local cache to obtain the IP address of the second microservice; wherein, the service list is obtained synchronously from the control plane of the service mesh.

[0078] In step S103, the IP address is returned to the first microservice so that the first microservice can access the second microservice in the service mesh based on the IP address.

[0079] In step S501, if a change in the correspondence between the service domain name and IP address detected by the control plane is detected, the changed service domain name and IP address pair is obtained from the control plane.

[0080] Here, the control plane can perform service discovery on the microservices deployed in the service mesh, obtaining the service domain names and IP addresses of the discovered microservices, and updating the mapping between the discovered service domain names and IP addresses based on the service discovery results. The service name resolution service can monitor whether the mapping between the service domain names and IP addresses discovered by the control plane has changed. When a change is detected, it retrieves the changed service domain name and IP address pair from the control plane and updates the service list based on the retrieved service domain name and IP address pair.

[0081] In step S502, at least one set of service domain names and IP addresses configured by the user are obtained from the external service name configuration system, and based on the at least one set of service domain names and IP addresses configured by the user, the service domain name and IP address pairs that have changed in the service list are determined.

[0082] Here, the external service name configuration system refers to an application or system outside the service mesh that provides configuration services for the service domain names and IP addresses of microservices registered in the service mesh. Users can configure the service domain names and IP addresses of microservices registered in the service mesh through the external service name configuration system. In implementation, the service name resolution service can obtain at least one set of service domain names and IP addresses configured by the user from the external service name configuration system. By comparing the service domain name and IP address pairs in the service list with the at least one set of service domain names and IP addresses configured by the user, it can determine the service domain name and IP address pairs in the service list that have changed.

[0083] In step S402, the service list is updated based on the changed service domain name and IP address pair.

[0084] In this embodiment, the changed service domain name and IP address pairs can be obtained from the control plane by monitoring whether the mapping between service domain names and IP addresses has changed. Alternatively, the changed service domain name and IP address pairs in the service list can be determined by obtaining the mapping between user-configured service domain names and IP addresses from an external service name configuration system. This allows for a simple and effective way to obtain changed service domain name and IP address pairs, ensuring the validity of the mapping between service domain names and IP addresses in the service list during service domain name resolution.

[0085] In some embodiments, see Figure 6 , Figure 6 This is an optional flowchart illustrating a service domain name resolution method based on a service mesh provided in an embodiment of this application. Figure 3 Step S102 can be implemented through steps S601 to S603. The following will explain each step in detail; the entity executing these steps can be the service name resolution service mentioned earlier.

[0086] In step S101, the service name resolution service receives a service name resolution request sent by the first microservice; wherein the service name resolution request includes the service domain name registered by the second microservice in the service mesh.

[0087] In step S601, the service list in the local cache is queried based on the service domain name.

[0088] In step S602, if the IP address corresponding to the service domain name is not found in the service list, the service name resolution request is forwarded to the designated external service name resolution service.

[0089] Here, the external service name resolution service can be another service name resolution service different from the current service name resolution service. It can be user-configured or the default; there are no restrictions. The external service name resolution service can serve as a backup service name resolution service. When the IP address corresponding to the service domain name is not found in the service list of the current service name resolution service, the service name resolution request can be forwarded to the external service name resolution service.

[0090] In step S603, the IP address of the second microservice returned by the external service name resolution service is received.

[0091] Here, after the external service name resolution service resolves the service domain name of the second microservice in the service name resolution request, it can obtain and return the IP address of the second microservice.

[0092] In step S103, the IP address is returned to the first microservice so that the first microservice can access the second microservice in the service mesh based on the IP address.

[0093] In this embodiment, when the IP address corresponding to a service domain name is not found in the service list of the current service name resolution service, the service name resolution request can be forwarded to an external service name resolution service, and the IP address of the second microservice returned by the external service name resolution service can be obtained. In this way, the external service name resolution service can serve as a backup service name resolution service, improving the success rate of service domain name resolution and further ensuring normal access between microservices.

[0094] In some embodiments, see Figure 7 , Figure 7 This is an optional flowchart illustrating a service domain name resolution method based on a service mesh provided in an embodiment of this application. Figure 3 The method can also execute the following steps S701 to S702, which will be explained in detail below. The execution subject of the following steps can be the service name resolution service mentioned above.

[0095] In step S102, the service domain name is resolved based on the service list in the local cache to obtain the IP address of the second microservice; wherein, the service list is obtained synchronously from the control plane of the service mesh.

[0096] In step S103, the IP address is returned to the first microservice so that the first microservice can access the second microservice in the service mesh based on the IP address.

[0097] In step S701, when the service name resolution service starts, it obtains the full set of currently discovered service domain name and IP address pairs from the control plane.

[0098] In step S702, the full set of service domain name and IP address pairs are added to the service list, and the service list is cached in the local cache.

[0099] In this embodiment, when the service name resolution service starts, it obtains all currently discovered service domain name and IP address pairs from the control plane, adds all service domain name and IP address pairs to the service list, and then caches the service list in the local cache. This allows for a simple and quick initialization of the service list when the service name resolution service starts.

[0100] The following describes an exemplary application of the embodiments of this application in a practical application scenario. This application provides an architectural improvement and optimization of the service domain name resolution scheme used in service meshes in related technologies. Without affecting the original core resolution capabilities, it proposes a distributed DNS architecture based on service discovery, which can realize service domain name resolution based on the service mesh. The application of this distributed DNS architecture is as follows: In a service mesh, when an upstream service accesses a downstream service through a service domain name, it needs to address the service domain name (i.e., domain name resolution). The domain name resolution of the downstream service name is completed through a distributed DNS service based on service discovery. This DNS service is a stateless, distributed service deployed together with the upstream service. By linking with the registration center of the PaaS platform, it automatically synchronizes the downstream service list, resolves the downstream service name in the registration center into a specific IP address, and returns it to the upstream service. The upstream service then accesses the downstream service based on this specific IP address. For downstream service names not in the registration center, the domain name resolution request is forwarded to the DNS service configured by the system.

[0101] The distributed DNS service provided in this application is independent of the PaaS platform on which each service is deployed in the service mesh. It is applicable to deployment scenarios involving bare metal servers, virtual machines, and containers. It can serve as a supplementary component to the service mesh data plane, deployed alongside other data plane components, and its lifecycle can be managed by the data plane's pilot-agent component. See also... Figure 8 , Figure 8This is a schematic diagram of the overall architecture of the distributed DNS service provided in this application embodiment applied in a service mesh. The service mesh includes a control plane 810 and a data plane 820. The control plane 810 can be adapted to various different registry centers 830, such as Kubenets, Consul, etcd, through control plane components (such as the pilot-discovery component). The data plane 820 can include data plane nodes 821 and 822. Data plane node 821 includes a pilot-agent component 821-1 and an Envoy component 821-2. The pilot-agent component 821-1 and the Envoy component 821-2 can be deployed in a container 831. The DNS service node (sidecar-dns) 841 of the distributed DNS service can also be deployed in a container 831. The application (i.e., service) 851 associated with the data plane node 821 is deployed in a container 832. Containers 831 and 832 can be jointly deployed in a container POD. In 830; the data plane node 822 includes pilot-agent component 822-1, envoy component 822-2, pilot-agent component 822-1, envoy component 822-2, the DNS service node (sidecar-dns) of the distributed DNS service 842, and the application 852 associated with the data plane node 822. The deployment can be carried out in a virtual machine or bare metal server 860.

[0102] See Figure 9 , Figure 9 A schematic diagram illustrating the implementation process of the service domain name resolution method based on service mesh provided in this application embodiment is shown below. Figure 9 As shown, the distributed DNS service sidecar-dns 910 in this process includes three components: dns-controller 911, service-cache 912, and dns-server 913. Based on these three components, the method can implement the following process: 1) The DNS-controller component 911 module in sidecar-dns 910 is responsible for interacting with the pilot-discovery component 920 of the service mesh control plane, listening to and synchronizing changes to the service list in the pilot-discovery component 920; here, changes to the service list mainly involve the addition and deletion of services. The pilot-discovery component 920 is the control plane component of the service mesh, which can adapt to various different registry centers, such as Kubennets, Consul, ZooKeeper, etc., and synchronizes the service list from the registry center; 2) DNS-controller component 911 receives changes to the service list from pilot-discovery component 920 and updates the service list to service-cache component 912. Service-cache component 912 caches and records the entire service list. When sidecar-dns 910 starts, it will automatically synchronize the full service list from pilot-discovery component 920 and cache it in service-cache.

[0103] 3) DNS-server component 913 provides DNS services to the outside world and receives DNS resolution requests from local application 930. DNS-server component 913 checks whether the service name to be resolved exists in service-cache component 912. If it exists, it returns a specific IP to application 930; if it does not exist, it forwards the DNS resolution request to external DNS service 940 and then returns the resolved result to application 930.

[0104] In this embodiment of the application, service domain name resolution based on service mesh can be implemented, which can achieve the following effects: 1) In the distributed DNS architecture, each DNS service node interfaces with the control plane component pilot-discovery of the service mesh, and synchronizes the service list from the pilot-discovery component. The pilot-discovery component is adapted to various registry centers and supports flexible expansion; 2) In the distributed DNS architecture, each DNS service node is deployed together with the service mesh data plane node, eliminating the need to deploy and maintain an additional DNS cluster, thus saving users resource costs and the operation and maintenance costs associated with managing a separate DNS cluster; 3) Each data plane node will deploy a DNS service node. Therefore, the unavailability of a single DNS service node will only affect the local application and will not affect the service name resolution of other data plane nodes. In the event of a failure, the scope of the failure can be greatly reduced, and the overall availability of the DNS service can be improved. 4) The data plane node and the DNS service run on the same host or POD, based on local network communication, which greatly reduces the service name resolution latency; 5) Each DNS service node on each data plane node only handles local service name resolution requests, which puts much less pressure on the system compared to a centralized DNS service. As a result, the performance is much higher and less likely to become a performance bottleneck.

[0105] In some embodiments, a centralized cluster deployment approach can be used to deploy the DNS service, which is then integrated with the pilot-discovery component to decouple it from the PaaS deployment platform. In other embodiments, a local DNS service can be customized to resolve service domain names. The mapping relationship between domain names and corresponding IP addresses can be implemented by integrating with an external control center (such as an external DNS configuration system, database, etc.). The external control center can dynamically configure the mapping relationship between the domain name list and its corresponding IP addresses.

[0106] The following description continues to illustrate the exemplary structure of the service domain name resolution device 255 based on the service mesh provided in this application embodiment as a software module. In some embodiments, such as... Figure 2 As shown, the software modules stored in the service mesh-based service domain name resolution device 255 in the memory 250 may include: The receiving module 2551 is used to receive a service name resolution request sent by the first microservice; wherein the service name resolution request includes the service domain name registered by the second microservice in the service mesh; The resolution module 2552 is used to resolve the service domain name based on the service list in the local cache to obtain the IP address of the second microservice; wherein, the service list is obtained synchronously from the control plane of the service mesh; The return module 2553 is used to return the IP address to the first microservice so that the first microservice can access the second microservice in the service mesh based on the IP address.

[0107] In some embodiments, the service name resolution service is deployed in the data plane of the service mesh in a distributed manner, and the receiving module is further configured to: the service name resolution service receive a service name resolution request sent by a first microservice deployed locally.

[0108] In some embodiments, the first microservice is deployed in an application container, and the service name resolution service and the data plane component of the service mesh are deployed in a proxy container, with the proxy container and the application container sharing the same local network; or, the first microservice, the service name resolution service, and the data plane component of the service mesh are deployed together on the same host.

[0109] In some embodiments, the apparatus further includes: a first acquisition module, configured to acquire the changed service domain name and IP address pair when it is determined that the correspondence between the service domain name and IP address registered in the service mesh has changed; and an update module, configured to update the service list based on the changed service domain name and IP address pair.

[0110] In some embodiments, the first acquisition module is further configured to: acquire the changed service domain name and IP address pair from the control plane when a change in the correspondence between the service domain name and IP address detected by the control plane is detected; acquire at least one set of service domain names and IP addresses configured by the user from an external service name configuration system; and determine the changed service domain name and IP address pair in the service list based on the at least one set of service domain names and IP addresses configured by the user.

[0111] In some embodiments, the resolution module is further configured to: query a list of services in a local cache based on the service domain name; if the IP address corresponding to the service domain name is not found in the service list, forward the service name resolution request to a designated external service name resolution service; and receive the IP address of the second microservice returned by the external service name resolution service.

[0112] In some embodiments, the apparatus further includes: a second acquisition module, configured to acquire, from the control plane, all currently discovered service domain name and IP address pairs when the service name resolution service starts; and a caching module, configured to add the all service domain name and IP address pairs to the service list and cache the service list in a local cache.

[0113] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the service mesh-based domain name resolution method described above in this application.

[0114] This application provides a computer-readable storage medium storing executable instructions. When these executable instructions are executed by a processor, they cause the processor to execute the service domain name resolution method based on a service mesh provided in this application. For example... Figure 3 The method shown.

[0115] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EP-ROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0116] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0117] As an example, executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (H-TML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0118] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0119] In summary, the embodiments of this application enable flexible expansion of multiple registry centers when resolving service domain names in the service mesh, thereby achieving decoupling from the PaaS deployment platform.

[0120] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A service domain name resolution method based on service mesh, characterized in that, This method is applied to a service name resolution service, which is deployed in a distributed manner within the data plane of the service mesh. The service name resolution service includes a dns-controller component, a service-cache component, and a dns-server component. The DNS-controller component interacts with the pilot-discovery component of the control plane of the service mesh, listening to and synchronizing changes in the service list in the pilot-discovery component; wherein, the pilot-discovery component adapts to a variety of different registry centers, and the pilot-discovery component synchronizes the service list from the registry center; The DNS-controller component receives a change to the service list from the pilot-discovery component and updates the changed service list to the service-cache component; the service-cache component caches and records the entire service list; when the service name resolution service starts, it automatically synchronizes the full service list from the pilot-discovery component and caches it in the service-cache component. The DNS server component receives a service name resolution request sent by a first microservice deployed locally; wherein the service name resolution request includes the service domain name registered by the second microservice in the service mesh; The dns-server component searches for the service domain name in the service list of the service-cache component. If found, it obtains the IP address of the second microservice corresponding to the service domain name. The service list is obtained synchronously from the control plane of the service mesh; The DNS server component returns the IP address to the first microservice, enabling the first microservice to access the second microservice in the service mesh based on the IP address.

2. The method according to claim 1, characterized in that, The first microservice is deployed in an application container, and the service name resolution service and the data plane component of the service mesh are deployed in a proxy container. The proxy container and the application container share the same local network. Alternatively, the first microservice, the service name resolution service, and the data plane component of the service mesh can be deployed together on the same host.

3. The method according to any one of claims 1 to 2, characterized in that, The method further includes: If the mapping relationship between service domain names and IP addresses registered in the service mesh changes, obtain the changed service domain name and IP address pair; The service list is updated based on the changed service domain name and IP address pairs.

4. The method according to claim 3, characterized in that, When the mapping relationship between service domain names and IP addresses registered in the service mesh changes, obtaining the changed service domain name and IP address pair includes at least one of the following: If a change in the correspondence between service domain names and IP addresses detected by the control plane is detected, the changed service domain name and IP address pair is obtained from the control plane. Obtain at least one set of service domain names and IP addresses configured by the user from the external service name configuration system, and determine the service domain name and IP address pairs that have changed in the service list based on the at least one set of service domain names and IP addresses configured by the user.

5. The method according to any one of claims 1 to 2, characterized in that, The method further includes: Based on the service domain name, query the list of services in the local cache; If the IP address corresponding to the service domain name is not found in the service list, the service name resolution request will be forwarded to the designated external service name resolution service. Receive the IP address of the second microservice returned by the external service name resolution service.

6. A service domain name resolution device based on a service mesh, characterized in that, Applied to a service name resolution service, the service name resolution service is deployed in a distributed manner in the data plane of the service mesh. The service name resolution service includes a dns-controller component, a service-cache component, and a dns-server component. The device includes: The first acquisition module, the second acquisition module, and the caching module are used for the DNS-controller component to interact with the pilot-discovery component of the control plane of the service mesh, and to listen for and synchronize changes to the service list in the pilot-discovery component. The pilot-discovery component is compatible with multiple different registry centers, and it synchronizes the service list from these registry centers. When the DNS-controller component receives a change to the service list from the pilot-discovery component, it updates the changed service list in the service-cache component. The service-cache component caches and records the entire service list. When the service name resolution service starts, it automatically synchronizes the full service list from the pilot-discovery component and caches it in the service-cache component. The receiving module is used by the DNS server component to receive a service name resolution request sent by a first microservice deployed locally; wherein the service name resolution request includes the service domain name registered by the second microservice in the service mesh; The resolution module is used by the DNS-server component to search for the service domain name in the service list of the service-cache component. If the domain name is found, the IP address of the second microservice corresponding to the service domain name is obtained. The service list is obtained by synchronizing from the control plane of the service mesh. The return module is used by the DNS server component to return the IP address to the first microservice, so that the first microservice can access the second microservice in the service mesh based on the IP address.

7. The apparatus according to claim 6, characterized in that, The first microservice is deployed in an application container, and the service name resolution service and the data plane component of the service mesh are deployed in a proxy container. The proxy container and the application container share the same local network. Alternatively, the first microservice, the service name resolution service, and the data plane component of the service mesh can be deployed together on the same host.

8. The apparatus according to any one of claims 6 to 7, characterized in that, The first acquisition module is further configured to acquire the changed service domain name and IP address pair when it is determined that the correspondence between the service domain name and IP address registered in the service mesh has changed; The update module is used to update the service list based on the changed service domain name and IP address pairs.

9. The apparatus according to claim 8, characterized in that, The first acquisition module is further configured to perform at least one of the following: If a change in the correspondence between service domain names and IP addresses detected by the control plane is detected, the changed service domain name and IP address pair is obtained from the control plane. Obtain at least one set of service domain names and IP addresses configured by the user from the external service name configuration system, and determine the service domain name and IP address pairs that have changed in the service list based on the at least one set of service domain names and IP addresses configured by the user.

10. The apparatus according to any one of claims 6 to 7, characterized in that, The parsing module is also used to query the list of services in the local cache based on the service domain name; If the IP address corresponding to the service domain name is not found in the service list, the service name resolution request will be forwarded to the designated external service name resolution service. Receive the IP address of the second microservice returned by the external service name resolution service.

11. A service domain name resolution device based on a service mesh, characterized in that, include: Memory, used to store executable instructions; A processor, when executing executable instructions stored in the memory, implements the method according to any one of claims 1 to 5.

12. A computer-readable storage medium, characterized in that, It stores executable instructions for implementing the method of any one of claims 1 to 5 when executed by a processor.

13. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the method described in any one of claims 1 to 5.

Images