Name resolution method and apparatus, electronic device, and readable storage medium

Abstract

The application provides a name resolution method and device, electronic equipment and readable storage medium, comprising: receiving a first input, the first input being a service discovery request issued by a service invoker; in response to the first input, a dynamic link library of a name service switch sets an instance environment variable; receiving a second input, the second input being a name of a service provider in the service discovery request; in response to the second input, the name service switch resolves the target IP of the service provider according to the instance environment variable of the service invoker at present and the name of the service provider. The application combines the service discovery provided by the name service switch, realizes the name resolution capability at the operating system level, has certain universality, and the business iteration access is close to zero cost.

Description

Technical Field

[0001] This invention relates to the field of computer network communication technology, and in particular to a name resolution method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] Service discovery is a coordination mechanism that enables service callers to find service providers by name after the registration, publication, and coordination of service caller and service provider information. As business scale grows, the number of service discovery modules also increases, and the call relationships between services become increasingly complex. The traditional solution is to use service discovery as infrastructure, providing SDKs or APIs implemented in various languages. However, for some older services, inter-service calls are often limited by underlying libraries. For example, PHP might use MySQL or Redis for database caching, making it nearly impossible to integrate a service discovery SDK at low cost. Furthermore, the original in-process call relationships are split into multiple services, which are already quite old, making SDK retrofitting costly. In cross-language scenarios, maintenance costs are also high. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a name resolution method to solve the problems of limited service discovery resolution and high transformation costs.

[0004] According to one aspect of the present invention, a name resolution method is provided, comprising:

[0005] Receive the first input, which is a service discovery request sent by the service caller;

[0006] In response to the first input, the instance environment variables are set by the dynamic link library of the name service switch;

[0007] Receive the second input, which is the name of the service provider in the service discovery request;

[0008] In response to the second input, the name service switch outputs the target IP of the service provider based on the current instance environment variables of the service caller and the name resolution of the service provider.

[0009] Optionally, in response to the second input, the name service switch outputs the IP address corresponding to the target instance of the service provider based on the current instance environment variables of the service caller and the name resolution of the service provider, including:

[0010] Receive a third input, which is the list of IPs returned by the name service switch after name resolution;

[0011] In response to the third input, the target IP is selected from the IP list using a pseudo-random function.

[0012] Optionally, in response to the second input, before the name service switch outputs the IP address corresponding to the target instance of the service provider based on the current instance environment variables of the service caller and the name resolution of the service provider, it further includes:

[0013] Receive a fourth input, which is the objective function of the name service switch;

[0014] In response to the fourth input, the name of the service provider is returned to the instance list;

[0015] Receive a fifth input, which is the updated list of instances;

[0016] In response to the fifth input, the dynamic link library is compiled.

[0017] Optionally, after the dynamic link library of the name service switch sets the instance environment variables in response to the first input, it further includes:

[0018] Receive a sixth input, which is an instance environment variable;

[0019] In response to the sixth input, the dynamic link library is loaded;

[0020] Receive a seventh input, wherein the seventh input is the updated dynamic link library;

[0021] In response to the seventh input, the data center corresponding to the service discovery and the service caller is determined and interacted with, and traffic scheduling is performed according to the mapping relationship.

[0022] According to a second aspect of the present invention, a name resolution apparatus is provided, comprising:

[0023] The first receiving module is used to receive the first input, which is a service discovery request sent by the service caller.

[0024] The settings module, in response to the first input, sets the instance environment variables of the dynamic link library for the name service switch;

[0025] The second receiving module is used to receive the second input, which is the name of the service provider in the service discovery request.

[0026] The parsing module, in response to the second input, outputs the target IP of the service provider based on the current instance environment variables of the service caller and the name resolution of the service provider.

[0027] Optionally, the parsing module includes:

[0028] The third receiving module is used to receive a third input, which is the list of IPs returned by the name service switch after name resolution;

[0029] The selection module, in response to the third input, uses a pseudo-random function to select the target IP from the IP list.

[0030] Optionally, the name resolution device further includes:

[0031] The fourth receiving module is used to receive a fourth input, which is the objective function of the name service switch;

[0032] The analysis and feedback module, in response to the fourth input, returns the name of the service provider to the instance list;

[0033] The fifth receiving module is used to receive a fifth input, which is the updated list of instances;

[0034] The compilation module, in response to the fifth input, compiles the dynamic link library.

[0035] Optionally, the name resolution device further includes:

[0036] The sixth receiving module is used to receive the sixth input, which is the instance environment variable;

[0037] The update module, in response to the sixth input, loads the dynamic link library;

[0038] The seventh receiving module is used to receive the seventh input, which is the updated dynamic link library;

[0039] The scheduling module, in response to the seventh input, determines the data center corresponding to the service discovery and the service caller and interacts with it, and performs traffic scheduling according to the mapping relationship.

[0040] According to a third aspect of the present invention, an electronic device is provided, comprising:

[0041] Processor; and

[0042] Stored program memory,

[0043] The program includes instructions that, when executed by the processor, cause the processor to perform the method according to any one of the first aspects of the invention.

[0044] According to a fourth aspect of the present invention, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are configured to cause a computer to perform the method according to any one of the first aspects of the present invention.

[0045] The one or more technical solutions provided in this application embodiment, combining the service discovery function and the scalability of the name service switch, implement a system-level dynamic link library. Combined with the relevant characteristics of service discovery, this enables inter-service communication within the system, avoiding the high-cost SDK modification and integration of legacy services, thus ensuring zero-cost service communication. This embodiment, combined with the service discovery provided by the name service switch, achieves operating system-level name resolution capabilities, possessing a certain degree of universality, and enabling near-zero cost for business iteration integration. Attached Figure Description

[0046] Further details, features, and advantages of the invention are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which:

[0047] Figure 1 A schematic diagram of an example system in which the various methods described herein may be implemented according to exemplary embodiments of the present invention is shown;

[0048] Figure 2 A flowchart of a name resolution method according to an exemplary embodiment of the present invention is shown;

[0049] Figure 3 A flowchart illustrating the operation of the name service switch according to an exemplary embodiment of the present invention is shown;

[0050] Figure 4 A flowchart illustrating the development and deployment process of a name service switch according to an exemplary embodiment of the present invention is shown;

[0051] Figure 5 A flowchart illustrating the name resolution execution process according to an exemplary embodiment of the present invention is shown;

[0052] Figure 6 A schematic block diagram of a name resolution apparatus according to an exemplary embodiment of the present invention is shown;

[0053] Figure 7 A structural block diagram of an exemplary electronic device that can be used to implement embodiments of the present invention is shown. Detailed Implementation

[0054] Embodiments of the present invention will now be described in more detail with reference to the accompanying drawings. While some embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the invention. It should be understood that the accompanying drawings and embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the invention.

[0055] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0056] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this invention are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0057] It should be noted that the terms "a" and "a plurality of" used in this invention are illustrative rather than restrictive. Those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0058] The names of the messages or information exchanged between the multiple devices in the embodiments of the present invention are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0059] The present invention will now be described with reference to the accompanying drawings. The technical solutions provided by the embodiments of this application will be explained in detail through specific examples and application scenarios.

[0060] With the rapid development of internet technology and scale, major internet companies have implemented their own service management and discovery systems. As business scale continues to grow, the number of service modules also increases, and the call relationships between services become increasingly complex. The traditional solution is to use service discovery as infrastructure, providing SDKs or APIs implemented in various languages ​​to meet the needs of business service calls. However, this approach is highly intrusive to various business services. Another feasible approach is to register and manage domain names on top of service discovery, allowing services to be accessed via domain names. In the microservices era, with the implementation of the service mesh concept, these capabilities can be integrated to some extent into the mesh proxy module, achieving both high efficiency and guaranteed reliability.

[0061] The development of services is often limited and affected by the stage of development. Currently, the mainstream is still in the stage of direct interaction between services. Some service calls are made using domain names, while some services need to be transformed into microservices. They are still made through internal inter-process calls. Adapting and transforming such service discovery processes has high costs.

[0062] Traditional service discovery access methods all use SDKs / APIs, or create domain names on top of them to map service discovery results, but both of these methods have many problems.

[0063] The following issues exist with using service discovery SDKs / APIs:

[0064] 1. For service providers, the SDK / API approach is the most suitable, providing basic tools for business modules. Business services only need to integrate them, and there is some management flexibility. However, for some legacy services, inter-service calls may be limited by underlying libraries. For example, PHP may use database services like MySQL or memory caching services like Redis, making it almost impossible to integrate service discovery SDKs at low cost.

[0065] 2. During the microservice transformation process, the original in-process call relationship of the service was split into multiple services. The services themselves are relatively old, and the cost of transforming them to the SDK is high. In addition, the maintenance cost is also relatively high in cross-language scenarios.

[0066] 3. Due to the limitations of the internal production environment, the SDK / API is used on a large scale, and SDK updates are costly for users.

[0067] The method of creating a domain name on top of it to map service discovery results has the following problems:

[0068] 1. Accessing via domain name on top of service registration and discovery information is more user-friendly, but the timeliness does not meet the requirements. When there are instance anomalies or local traffic anomalies, the traffic scheduling and switching capabilities of the domain name service are limited by the domain name resolution TTL, which needs to be at the minute level.

[0069] 2. Service discovery itself solves the relationship between service name and the actual IP of the service provider. Adding domain name at the upper layer increases the cost of service governance and maintenance, and also increases the pressure on DNS resolution.

[0070] like Figure 1 As shown, Figure 1 This is a schematic diagram of an example system for implementing a name resolution method provided in this application embodiment, used to illustrate the core steps of service discovery. The basic principle of service discovery is: when service A needs to access services B, C, X, etc., it only needs to configure the names of B, C, and X in service A, and then use the service discovery SDK to realize the mapping from name to specific IP + Port, thereby achieving the purpose of service access.

[0071] like Figure 2 As shown, Figure 2 This is a flowchart illustrating a name resolution method provided in an embodiment of this application. The method may include the following steps S201 to S204:

[0072] S201, Receive the first input, where the first input is a service discovery request sent by the service caller.

[0073] In an optional embodiment, the operating system receives the first input using service discovery, such as... Figure 1 As shown, the service discovery deployment architecture is a dual-datacenter deployment with both services online simultaneously. When service caller A accesses service provider B, it needs to return a list of B instances through the service discovery module. Ideally, it should return all instances—that is, all instances in the data center that can provide services to B—and then service A selects a specific instance and makes the call. However, for better traffic management, traffic entering from the ingress is randomly routed to a specific data center, and then instances in different data centers are tagged, achieving service discovery within a single data center. Figure 1 The solid line portion of the access link.

[0074] When instances in the same data center malfunction or other changes or external factors cause a decrease in availability, cross-data center traffic scheduling capabilities can be achieved through the automatic degradation capability of service discovery or the traffic scheduling capability of the operation and maintenance management side.

[0075] The services are deployed in a distributed, multi-instance manner. Service calls require a load balancing strategy to achieve balanced traffic scheduling. When using an SDK, load balancing needs to be done on the SDK side, while when using NSS, it can only be done upfront during the parsing process.

[0076] S202, in response to the first input, set the instance environment variable with the dynamic link library of the name service switch.

[0077] In an optional embodiment, the Name Service Switch (NSS) is a name resolution tool in Unix-like operating systems that provides various sources for a general configuration database and name resolution mechanism. Its configuration file, nsswitch.conf (name service switch configuration), is located in the / etc directory and specifies the methods and order in which specific types of information are retrieved, thus illustrating the name resolution process; this is the hosts section of the configuration file.

[0078] The nsswitch.conf file defines the name resolution order, which is from left to right: local file, custom module, DNS, and myhostname. Unix-like operating systems' NSS Modules provide developers with standardized extension capabilities, allowing them to extend the NSS database and provide name resolution services; apptree is one such custom extension module.

[0079] In this embodiment, as Figure 3 As shown, based on the extension method of the Name Service Switch (NSS), the following target functions are implemented: _nss_apptree_gethostbyname_r and _nss_apptree_gethostbyname2_r, and the operating system-adapted MNS_NSS dynamic link library is compiled.

[0080] In an optional embodiment, the underlying interface of the objective function is implemented by MNS_CPP_SDK, supporting key features such as returning a list of IPs from the service name and using a pseudo-random method to achieve load balancing for the final IP selection. Here, MNS (Man Naming Service) refers to a name service system that provides internal service registration and discovery capabilities, supporting SDKs and related tools for various programming languages.

[0081] During service module changes and process startups in the deployment system, instance environment variables are imported into the process space. Simultaneously, the dynamic extension library libnss_apptree.so is loaded to determine the data center to which the caller belongs. Then, based on the routing rules defined in service discovery, traffic is grouped and scheduled. Utilizing interfaces provided by the operating system, combined with internal service management and service discovery capabilities, service discovery becomes as convenient as using domain names.

[0082] S203, Receive the second input, which is the name of the service provider in the service discovery request.

[0083] In this embodiment, the service discovery request includes the name of the service provider sent by the service caller.

[0084] S204, in response to the second input, the name service switch outputs the target IP of the service provider based on the current instance environment variables of the service caller and the name resolution of the service provider.

[0085] In this embodiment, the Unix-like operating system LINUX, short for GNU / Linux, is a free and open-source Unix-like operating system. It is a multi-user, multi-tasking operating system based on the POSIX portable operating system interface. Combined with the features of the operating system's internal name service, it meets business needs in terms of both user cost and traffic management capabilities. Service discovery is essentially the process of resolving service names to service IPs and ports. The service port is defined when the service is created, so only NSS needs to resolve the service name to the IP. Furthermore, considering the requirements of internal service calls, it supports the ability to call traffic groups.

[0086] Name Service Switch (NSS) is a name resolution tool in Unix-like operating systems. Based on the internal service discovery of the operating system, and combined with the extensibility of the name service switch provided by the Linux system, it implements a system-level dynamic link library and, together with the relevant features of service discovery, enables name resolution between internal services.

[0087] In an optional embodiment, in response to the second input, the name service switch outputs the IP address corresponding to the target instance of the service provider based on the current instance environment variables of the service caller and the name resolution of the service provider, including:

[0088] S2041, Receive a third input, wherein the third input is the IP list returned by the name service switch after name resolution;

[0089] S2042, in response to the third input, the target IP is selected from the IP list using a pseudo-random function.

[0090] In this embodiment, after resolving the name of the service provider, the name service switch uses a pseudo-random function to randomly select a unique IP from the IP list as the target IP for name resolution. This random selection method further ensures load balancing of the operating system.

[0091] In one optional embodiment, such as Figure 4 As shown, in response to the second input, before the name service switch outputs the IP address corresponding to the target instance of the service provider based on the current instance environment variables of the service caller and the name resolution of the service provider, it further includes:

[0092] S204a, Receive a fourth input, the fourth input being the objective function of the name service switch.

[0093] The NSS development and deployment process is as follows: Figure 4 As shown, NSS development is performed, and the target function of the name service switch is rewritten during the development process. That is, it receives the fourth input. The target function is as follows: enum nss_status_nss_apptree_gethostbyname_r(const char*name,struct hostent*result,char*buffer,size_tbuflen,int*errnop,int*h_errnop); enum nss_status_nss_apptree_gethostbyname2_r(const char*name,int af,struct hostent*result,char*buffer,size_t buflen,int*errnop,int*h_errnop).

[0094] S204b, in response to the fourth input, return the name of the service provider to the instance list.

[0095] In this embodiment, the data structures and return values ​​of the two target functions corresponding to the NSS extension are implemented. The key return values ​​are fully defined in the entire name resolution service and are of an enumeration type.

[0096] Integrating the MNS_SDK, the SDK accesses the service discovery server, which returns a list of instances. These instances are typically multiple, and the services are deployed in a distributed, redundant manner to ensure that requirements are not met due to a single point of failure. As a name resolution service, the returned IPs should be usable addresses. Therefore, after the SDK returns the information, the service discovery definition needs to be followed to filter out the list of healthy, accessible instances.

[0097] S204c, Receive a fifth input, the fifth input being the updated list of instances.

[0098] S204d, in response to the fifth input, compile the dynamic link library.

[0099] In this embodiment, the compilation of the dynamic link library is to ensure that the generated dynamic link library can be shared by any program, so that applications or processes on the operating system can use the dynamic library, making it a system-level lib library.

[0100] In an optional embodiment, after compiling the dynamic link library, the dynamic link library is deployed, symbolic links are set, and the nsswitch.conf file is configured to achieve name resolution hijacking.

[0101] In one optional embodiment, such as Figure 5 As shown, after the business service starts through the standard deployment process, the process space will contain an environment variable named _MNS_INSTANCEID. The process loads dynamic link libraries, and when name resolution is required, the process follows... Figure 5 The execution proceeds in the order of operating system name resolution. In the diagram, glibc refers to the GNU libc library, which is the C runtime library.

[0102] In this embodiment, the NSS plugin integrates MNS_SDK to resolve service names to an instance list, and converts them into unique IPs in the NSS internal function _internal. The service process's libcurl obtains the IP and uses it to access the corresponding service in the form of IP+PORT.

[0103] This embodiment, based on the role of service discovery in inter-service calls and combined with the operating system's NSS extension capabilities, effectively solves the problem of high maintenance and modification costs for service discovery SDKs, without requiring any code-level modifications to the business logic. By integrating the operating system's internal service management and service discovery capabilities, it possesses a degree of universality, and business iteration integration costs are close to zero. It meets the enterprise's internal service governance and stability management requirements, significantly reducing the cost of integrating standardized service discovery into legacy business modules.

[0104] In an optional embodiment, after the dynamic link library of the name service switch sets the instance environment variables in response to the first input, it further includes:

[0105] S202a, Receive the sixth input, wherein the sixth input is an instance environment variable;

[0106] S202b, in response to the sixth input, load the dynamic link library;

[0107] S202c, Receive the seventh input, wherein the seventh input is the updated dynamic link library;

[0108] S202d, in response to the seventh input, determine the data center corresponding to the service discovery and the service caller and interact with it, and perform traffic scheduling according to the mapping relationship.

[0109] In this embodiment, the upper-layer capabilities of service deployment and traffic scheduling are combined to achieve traffic governance functions and support the ability to detect traffic group switching. Both user costs and traffic governance capabilities meet business needs. Service discovery is essentially the process of resolving a service name to a service IP address and port. The service port is defined when the service is created. The method in this embodiment relies on NSS to only resolve the service name to the IP address, and combined with the requirements of internal service calls, it supports the ability to call traffic groups.

[0110] To better manage traffic, traffic entering from the ingress is randomly routed to a specific data center, where instances in different data centers then label the traffic, enabling service discovery within a single data center. Figure 1 The solid line represents the access link. When an instance in the same data center fails or availability degrades due to changes or external factors, cross-data center traffic scheduling is achieved through service discovery's automatic degradation capability or the traffic scheduling capability of the operations and maintenance management side. Services are deployed in a distributed, multi-instance manner. Inter-service calls require load balancing strategies to achieve balanced traffic scheduling. When using an SDK, load balancing needs to be performed on the SDK side, while using NSS, it can only be moved forward to the resolution process.

[0111] The name resolution method provided in this embodiment combines service discovery functionality with the scalability of name service switches to implement a system-level dynamic link library. Leveraging the relevant features of service discovery, it enables inter-service communication within the system, avoiding the high-cost SDK modifications required for older services and ensuring zero-cost service communication. This embodiment, combined with service discovery provided by name service switches, achieves operating system-level name resolution capabilities, possessing a degree of universality and enabling near-zero-cost business iteration integration.

[0112] Corresponding to the above embodiments, see [link to relevant documentation]. Figure 6This application also provides a name resolution device 600, comprising:

[0113] The first receiving module 601 is used to receive a first input, wherein the first input is a service discovery request sent by the service caller;

[0114] Setting module 602, in response to the first input, sets the instance environment variables of the dynamic link library for the name service switch;

[0115] The second receiving module 603 is used to receive a second input, which is the name of the service provider in the service discovery request.

[0116] In response to the second input, the name service switch of the name service switch outputs the target IP of the service provider based on the current instance environment variables of the service caller and the name resolution of the service provider.

[0117] Optionally, the parsing module 604 includes:

[0118] The third receiving module 6041 is used to receive a third input, which is the IP list returned by the name service switch after name resolution;

[0119] Selection module 6042, in response to the third input, selects the target IP from the IP list using a pseudo-random function.

[0120] Optionally, the name resolution device 600 further includes:

[0121] The fourth receiving module 605 is used to receive a fourth input, which is the objective function of the name service switch;

[0122] The analysis feedback module 606, in response to the fourth input, returns the name of the service provider to the instance list;

[0123] The fifth receiving module 607 is used to receive a fifth input, which is the updated list of instances;

[0124] Compiler module 608, in response to the fifth input, compiles the dynamic link library.

[0125] Optionally, the name resolution device 600 further includes:

[0126] The sixth receiving module 609 is used to receive a sixth input, which is an instance environment variable;

[0127] Update module 610, in response to the sixth input, loads the dynamic link library;

[0128] The seventh receiving module 611 is used to receive a seventh input, wherein the seventh input is the updated dynamic link library;

[0129] The scheduling module 612, in response to the seventh input, determines the data center corresponding to the service discovery and the service caller and interacts with it, and performs traffic scheduling according to the mapping relationship.

[0130] The name resolution device provided in this embodiment combines service discovery functionality with the scalability of the name service switch to implement a system-level dynamic link library. Leveraging the relevant features of service discovery, it enables inter-service communication within the system, avoiding the high-cost SDK modifications required for older services and ensuring zero-cost service communication. This embodiment, combined with the service discovery provided by the name service switch, achieves operating system-level name resolution capabilities, possessing a certain degree of universality and near-zero cost for business iteration integration.

[0131] An exemplary embodiment of the present invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the electronic device to perform a method according to an embodiment of the present invention.

[0132] An exemplary embodiment of the present invention also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of the present invention.

[0133] An exemplary embodiment of the present invention also provides a computer program product, including a computer program, wherein, when executed by a computer's processor, the computer program is used to cause the computer to perform a method according to an embodiment of the present invention.

[0134] refer to Figure 7 The present invention will now be described in the form of a structural block diagram of an electronic device 700 that can serve as a server or client of the present invention, which is an example of a hardware device that can be applied to various aspects of the present invention. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0135] like Figure 7As shown, the electronic device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 702 or a computer program loaded from a storage unit 708 into a random access memory (RAM) 703. The RAM 703 may also store various programs and data required for the operation of the device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0136] Multiple components in electronic device 700 are connected to I / O interface 705, including: input unit 706, output unit 707, storage unit 708, and communication unit 709. Input unit 706 can be any type of device capable of inputting information to electronic device 700. Input unit 706 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 707 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 708 may include, but is not limited to, disk and optical disk. Communication unit 709 allows electronic device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0137] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above. For example, in some embodiments, the auditing method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 700 via ROM 702 and / or communication unit 709. In some embodiments, the computing unit 701 may be configured to perform the auditing method by any other suitable means (e.g., by means of firmware).

[0138] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0139] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0140] As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0141] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0142] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0143] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

Claims

1. A name resolution method, characterized in that, include: Receive the first input, which is a service discovery request sent by the service caller; In response to the first input, the instance environment variables are set by the dynamic link library of the name service switch; Receive the second input, which is the name of the service provider in the service discovery request; In response to the second input, the name service switch outputs the target IP of the service provider based on the current instance environment variables of the service caller and the name resolution of the service provider.

2. The name resolution method according to claim 1, characterized in that, In response to the second input, the name service switch outputs the IP address corresponding to the target instance of the service provider based on the current instance environment variables of the service caller and the name resolution of the service provider, including: Receive a third input, which is the list of IPs returned by the name service switch after name resolution; In response to the third input, the target IP is selected from the IP list using a pseudo-random function.

3. The name resolution method according to claim 1, characterized in that, In response to the second input, before the name service switch outputs the IP address corresponding to the target instance of the service provider based on the current instance environment variables of the service caller and the name resolution of the service provider, it further includes: Receive a fourth input, which is the objective function of the name service switch; In response to the fourth input, the name of the service provider is returned to the instance list; Receive a fifth input, which is the updated list of instances; In response to the fifth input, the dynamic link library is compiled.

4. The name resolution method according to claim 1, characterized in that, In response to the first input, after the dynamic link library of the name service switch sets the instance environment variables, it further includes: Receive a sixth input, which is an instance environment variable; In response to the sixth input, the dynamic link library is loaded; Receive a seventh input, wherein the seventh input is the updated dynamic link library; In response to the seventh input, the data center corresponding to the service discovery and the service caller is determined and interacted with, and traffic scheduling is performed according to the mapping relationship.

5. A name resolution device, characterized in that, include: The first receiving module is used to receive the first input, which is a service discovery request sent by the service caller. The settings module, in response to the first input, sets the instance environment variables of the dynamic link library for the name service switch; The second receiving module is used to receive the second input, which is the name of the service provider in the service discovery request. The parsing module, in response to the second input, outputs the target IP of the service provider based on the current instance environment variables of the service caller and the name resolution of the service provider.

6. The name resolution device according to claim 5, characterized in that, The parsing module includes: The third receiving module is used to receive a third input, which is the list of IPs returned by the name service switch after name resolution; The selection module, in response to the third input, uses a pseudo-random function to select the target IP from the IP list.

7. The name resolution device according to claim 5, characterized in that, The name resolution device further includes: The fourth receiving module is used to receive a fourth input, which is the objective function of the name service switch; The analysis and feedback module, in response to the fourth input, returns the name of the service provider to the instance list; The fifth receiving module is used to receive a fifth input, which is the updated list of instances; The compilation module, in response to the fifth input, compiles the dynamic link library.

8. The name resolution device according to claim 5, characterized in that, The name resolution device further includes: The sixth receiving module is used to receive the sixth input, which is the instance environment variable; The update module, in response to the sixth input, loads the dynamic link library; The seventh receiving module is used to receive the seventh input, which is the updated dynamic link library; The scheduling module, in response to the seventh input, determines the data center corresponding to the service discovery and the service caller and interacts with it, and performs traffic scheduling according to the mapping relationship.

9. An electronic device, comprising: processor; as well as Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1-4.

10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-4.

Images