Welcome to visit the address for a better reading experience

One, foreword

In the last article, we introduced the RPC communication protocol, which is the first step in implementing RPC. Next, we will discuss the Service Discovery of RPC.

What is service discovery?

Conceptually, service discovery is the process of obtaining a service address through a unique service identifier, which plays an important role in RPC. Let me use a take-out example to explain what service discovery actually does. Why is it important?

Suppose I am the owner of a takeout shop, I have to consider a question: how to make customers find my shop and order my takeout? The first thought is to send a small advertisement, customers can find us through the ordering hotline in the advertisement, this process is actually the simplest service discovery.

The program worked, but after operating for a while, I found some problems:

Small ads have limited transmission power and not enough precision, so many people may throw them into the trash


Customers may be unable to place orders because they have lost cards or forgotten numbers


Once the reserved phone is down, the entire service is unavailable


Out of stock or out of business, customers still call


My business grew and I soon opened a new store, but the old customers didn’t know the hotline of the new store

Later, I heard that there was an ordering platform called Ele. me, so I registered my restaurant there with a try attitude. I didn’t expect this platform to bring me a large number of orders, and I no longer need to send small ads everywhere, I just need to concentrate on cooking, improve service quality, maintain a good reputation can get stable customers. Secondly, I don’t have to worry about service changes such as phone outage, out of stock, closing of business, opening of new stores, etc. I just need to modify the service information on the platform. Consumers also don’t need to collect a stack of takeout cards. They can install an app, find a variety of food and choose better service based on ratings. This is a fairly advanced service discovery implementation, and you can see that service discovery is critical for both providers and consumers.

Classification of service discovery

Hard load

As the name implies, the hard load relies on hardware devices as the load. An independently deployed hardware device (generally known as F5/LVS/HAproxy cluster) is added to the invocation link to discover back-end services and load balance traffic.

                                                +------------+
+----------+  invoke   +---------------+        |  Services  |-+
| Consumer | --------> | Load Balancer | -----> |  Providers | |-+
+----------+           +---------------+        +------------+ | |
                                                 |-------------+ |
                                                   +-------------+
Copy the code
  • advantages
    • A unified traffic centralized node implements global control, such as routing, authentication, and security prevention and control
  • disadvantages
    • Hard – loaded devices are costly and difficult to maintain
    • There is some performance loss in calling the primary link
    • Hard – loaded devices need to implement cluster deployment to solve the single point of failure

Soft loading

Similarly, soft load relies on software for service discovery and load balancing, which has the following characteristics:

  • Without centralized hard load devices, LB functions are integrated into service consumer processes in SDK mode
  • A Servcie Registry was introduced to dynamically manage all service addresses
  • The registry is not on the primary link of the call, it is in the bypass
                  +------------------+
                  | Service Registry |
                  +------------------+
                  /                 ^
                 /                   \
	    Discover          Register & Keep Alive
	       /                         \ 
	      /                           \
	     v                             \
+----------+                                +----------+
| Consumer | ---- Load Balance & Invoke --> | Provider |
+----------+                                +----------+
Copy the code
  • advantages
    • The Consumer calls the Provider directly, with no intermediate nodes
    • There is no need for independent load balancing equipment, so there are no cost and operation and maintenance problems
  • disadvantages
    • It is intrusive to the Consumer side and has access costs
    • Decentralized, so weak control
    • Although the registry is in bypass, it is also a critical piece of infrastructure that needs to ensure high availability

Common service discovery solutions in the industry

  • Hard load
    • Alibaba Cloud SLB
    • The AWS ELB
  • Soft loading
    • Eureka
    • zookeeper/etcd/consul
    • Ali and ant’s ConfigServer

Each of these scenarios has its own scenarios, but in RPC we usually use soft load for service discovery

How does Node.js do service discovery?

Interface abstraction

Here we discuss some of the experiences and routines of Node.js accessing soft loads. In typical soft load mode there are three roles:

  • Service Provider
  • Service Consumer
  • Service Registry

Node.js mainly plays the first two roles, so what we need to do is develop the client SDK for the service registry. Although there are multiple implementations of the registry, we can abstract its interface as:

  • The service registry
  • Service cancellation
  • Service subscription
  • Service to subscribe
  • Health check (optional)
  • Service governance related queries (Optional)

From this we can create a RegistryBase class whose API is defined as follows:

interface RegistryBase {
  async register(config: any): void;

  async unRegister(config: any): void;

  subscribe(config: any, listener: function): void;

  unSubscribe(config: any, listener: function): void;

  async close(): void;
}
Copy the code

There are implementations for different servers, such as ZookeeperRegistry, EurekaRegistry, and so on. For a practical example, see the implementation of ZookeeperRegistry

Service discovery own service discovery

Invoking the registry interface itself requires a service discovery process, which feels a bit eggy here. Generally, the service finds that we need to rely on a more basic address service (e.g., DNS), then updates the registry’s address list through rotation training or other strategies, and finally selects one of them to initiate a request. The complete sequence diagram is as follows:

+--------+ +-----------+ +--------------+ | Client | | DNS | | Registry | +--------+ +-----------+ +--------------+ | | | | - 1. Query the registry address - > | | | < -- - return to the registry address - | | | | | | | | -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - 2. Registered customers/distributors -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - > | | < -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- registration result feedback -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - | | | | | | -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 3. Subscription service publisher -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - > | | < -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- subscribe result feedback -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - | | | | | | < -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4. Push service address -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - | | -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- feedback received -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - | | |Copy the code

About the Health check

A service registry is different from a normal dynamically configured system because services are stateful (at least available and unavailable). After a service is successfully published, ongoing health checks are required to ensure that the service is available.

There are two ways of health examination:

1. Through the heartbeat

The service provider and the registry maintain a long connection by periodically sending heartbeat packets. As long as the long connection is continuous, the service is available.

  • advantages
    • Transparent to the business and simple to implement
    • You can make sure that at least the Internet connection is working
  • disadvantages
    • If the granularity is coarse, the actual service health cannot be checked
    • There are a lot of long connections to maintain for registries

Zookeeper and Ali’s ConfigServer all use this method for health checks

2. The exposed interface is used for periodic inspection

The service provider exposes a single interface to the registry for rotation and determines whether the service is available based on the return status of the interface

  • advantages
    • Businesses can customize health standards to perform more accurate health checks
    • Do not maintain long connections
  • disadvantages
    • There is some intrusion into business

K8s’ Health Checks does that

Five, to be continued

Relationship between service discovery and load balancing

Finally, the concept of load balancing is mentioned to lay the foundation for later articles, as it is easy to confuse it with service discovery, and in many simple scenarios we don’t even distinguish between them. In essence, they have different levels and solve different problems. Simply speaking, service discovery is the premise of load balancing. Load balancing is to solve the problem of allocating traffic reasonably to each node after getting the service list.