Service Registration and Discovery

Service Registration

Why do services need to be registered

In a cloud-native environment, the communication address of a service may be uncertain and change according to changes in its life cycle, and it may also have multiple running instances. Then the premise for other services to communicate with is to discover the communication address of the service, so the service needs to register its communication address and running status to the service registry through service registration. For example, the SpringCloud architecture has eureka registry.

Service registration granularity and scope

The granularity of Kato service registration is port level, which means that if the service component has multiple ports, it can control the registration separately. At the same time, in order to distinguish whether the service is to provide services to the external network (through the application gateway) or to the internal network (through ServiceMesh), Kato sets up two registration ranges for each port of the service.

Service registration method

Since Kato is different from the Spring Cloud architecture and also provides a service operating environment, the service registration of Kato is automatic, that is, the service instance will be registered to the registry when it starts. However, users are required to specify the scope of registration and enable internal or external services.

Service Discovery

Service discovery and service registration are corresponding concepts, that is, when service A wants to access service B, it needs to obtain the service address of the other party first. Kato provides two service discovery strategies.

Declarative service discovery

The so-called declarative service discovery means that when service A needs to access service B, it needs to explicitly set the dependency relationship in Kato, that is, A depends on B. When the dependency is established, the Mesh service in the same cyberspace of service A will obtain all running and healthy service instances of service B from the Kato service registry through the XDS protocol, thereby establishing local monitoring to load balance service B. For service A, the way to access B is a fixed local address. For example, to access port 8080 of service B, the access address is 127.0.0.1:8080. This address can be fixedly configured in the code or obtained through corresponding environment variables. It can be concluded that Kato’s service discovery is transparent to the business layer, that is, the user’s business does not need to process the logic of service discovery, and the Mesh layer will automatically complete it. According to the custom routing configuration and load balancing algorithm configuration of the Mesh layer, this method currently mainly supports stateless services, single-instance stateful services, and stateful cluster services that can run indiscriminately with multiple instances.

DNS-based service discovery

In addition to the service types mentioned above, there is another special type of service communication, such as the following scenarios:

  1. Clustered service supports horizontal expansion, and communication between instances is required. Such as zookeeper, etcd, etc.
  2. The master-slave cluster service, the slave instance needs to communicate with the master instance. For example, Mysql master-slave cluster, Redis master-slave replication cluster

The above services mainly involve communication between multiple instances of the same service. For such requirements, the service type must be set to Stateful Service

Service discovery through fixed DNS resolution:

For the deployed stateful service, we can enter the container to view the host name, as shown below:

As you can see, the hostname of the service instance is generated according to the following rules:

Service Alias-Service Instance ID. Service Alias. Tenant ID.svc.cluster.local

The main variables involved for different services are as follows:

  • Service alias, which can be obtained by obtaining the environment variable SERVICE_NAME
  • The service instance number is numbered sequentially from 0 according to the number of instances. Their startup sequence and update data will be in the order of numbering, so generally number 0 will be used as a special instance, such as the master instance of a master-slave cluster.
  • Tenant ID, which can be obtained by obtaining the environment variable TENANT_ID

Through the above analysis, you should have understood that when you need to discover the addresses of all running instances of the current service, you can obtain the DNS records of the service alias.tenant ID.svc.cluster.local domain name by means of DNS nslookup. There are many ready-made tools for this method. For example, reference: yugabytedb service source code

If you need to communicate with the master node, simply request the domain name of the master node. For example, service alias-0.service alias.tenant ID.svc.cluster.local