Microservice architecture has become a necessary project support capability for small and medium-sized enterprises, especially the Internet BATJ enterprise has been very mature in 2004, and summarized many large-scale service scheduling and big data set processing schemes in large-scale core business practice. There are many modules involved in microservice architecture. In this paper, the service registration and discovery product of microservice architecture is used to explain how to do service discovery based on DNS.

Service registration and discovery

In microservice system, service registration and service discovery are two core modules. When the business service invokes the order service, it needs to find the IP and port list of the order service through the service discovery module, and the instance of the order service needs to register the IP and port providing the service with the service registry when it is started. A typical structure is shown below:

The service registry

At present, there are many popular registries, such as Zookeeper, ectD, Consul, Eureka, etc. There are usually three types of service registrations: self-registrations, third-party registrations, and registry active synchronization.

• Since the registration:
  • That is, when the service provider starts the service, he sends the IP address and port of the service to the registry and maintains the health status through heartbeat. When the service goes offline, delete the corresponding data by yourself. Typically like using a ZK client to publish microservices.
• Third Party registration:
  • Third party registration refers to the existence of a third party system responsible for adding or deleting service data to the registry when services are started or stopped. Typically, devOPS systems or container scheduling systems actively call registry interface registration services;
• Active registry synchronization is similar to the third-party registration mode. Active registration means that the registry synchronizes the latest service IP list through the scheduling or publishing system. An example is coreDNS subscription API Server data in Kubernetes architecture.

Service discovery

Before actually making a service call, the caller needs to get a list of available IP addresses and ports for the corresponding service from the registry, known as service discovery. Service discovery can be divided into two categories in terms of invasiveness to applications:

• The SDK service discovery mode requires the caller to rely on the corresponding SDK and explicitly invoke the SDK code to realize service invocation, which is intrusive to services. Typical examples include Eureka and ZooKeeper.

• DNS itself is a domain name resolution system that can meet simple service discovery scenarios, such as the agreed port number and serialization protocol. However, this is far from sufficient for a true microservices scenario.

DNS based service discovery

DNS protocol is one of the most common protocols, almost all operating systems have DNS client implementation. Therefore, it is naturally cross-linguistic. It is also the fastest way to access microservices quickly. To do DNS based service discovery, registry data should first be exposed in the DNS data format. The DNS client of any system can obtain the service list through the DNS protocol.

Note: Only the service discovery system provides DNS access

DNS service discovery methods can be roughly classified into two categories:

Independent DNS server

The basic architecture of the independent DNS Server mode is as follows:

As shown in the figure above, in this architecture, a separate DNS server is required. The DNS server obtains all registered services and the IP port list from the registry. Service A queries the IP address list of A Service through DNS and invokes the Service.

Advantages and disadvantages of this type of service discovery approach are as follows:

• advantages
  • Centralized DNS servers facilitate upgrade and maintenance
• disadvantages
  • The DNS server has high performance requirements
  • In this case, LVS devices are generally required to forward requests for DNS server clusters, resulting in a single point of view

DNS Filter

The DNS Filter pattern is defined to integrate the DNS server into the service caller machine or container, as shown in the following figure:

In this mode, ensure that DNS queries of ServiceA are intercepted to the local DNS server (127.0.0.1:53) and invoked after obtaining the IP address list of the service. Since this approach front-loads the DNS server to the actual calling machine, it solves the single point problem of the standalone DNS server mode, the full P2P mode. However, the maintenance and upgrade costs are higher because the DNS server needs to be installed on the application machine.

DNS based service discovery practice

As early as 2014, Alibaba started to try to make service discovery based on DNS, and now it has formed a relatively mature mode. Alibaba internally takes VIPServer as the registry and develops DNS Filter, which is deployed in the application container. DNS Filters have been installed on over 100 million machines or containers, supporting almost all REST service discovery.

Registry VIPServer

VIPServer is the service registry developed by ali middleware soft load team. VIPServer supports three modes of service registration at the same time, and all of them have considerable applications. In addition, VIPServer has the following features:

• Active and Passive Health Check VIPServer supports both active and passive health check.
  • Active health check Means that the VIPserver server proactively sends health check packets periodically to check whether the service provider can provide services properly.
    • You can configure multiple health check modes, and customize the probe port and probe URL (HTTP).
  • The benefit of active detection is that the service provider can quickly integrate into the microservices architecture without making any changes.
  • Passive health check means that the service provider actively registers its IP address, port and service name and keeps active through heartbeat.
• At the same time, VIPServer supports a variety of load balancing policies, including weight, same room, same region, same environment, etc. It is one of the core systems of remote multi-activity projects.
• Multiple Dr Protection Policies The VIPServer provides multiple Dr Protection policies to effectively reduce the impact caused by human or underlying system (network) faults. Dr Protection includes:
  • Client cache, even if the VIPServer server down will not affect the normal application call;
  • The server protection threshold effectively prevents avalanche due to excessive application pressure.
  • The client Dr Directory provides the ability to manually intervene the service IP address list.
  • Empty list protection on the client, effectively preventing IP list deletion by mistake or VIPServer server exception

DNS – F client

For the sake of performance, we adopt the service discovery mode of the second DNS Filter. For this purpose, we developed a DNS-F client separately, which is deployed in the same host or container as the application. Its working principle is shown in the figure below:

• First, ServiceA obtains the list of available IP addresses for ServiceB through DNS query
• DNS -f intercepts the ServiceA query request, determines whether it has the answer to the query, and returns the IP address list if yes (the service has been registered with the VIPServer).
• If the queried service is not registered in the VIPServer, DNS -f forwards the DNS query to the nameserver of the system, which is resolved by the real DNS system.