The overview

Service invocation as a whole is divided into two steps, with ZooKeeper as the registry and the default Dubbo protocol

  1. The client gets the remote service address from the registry
  2. The client initiates the call from the remote service address

  1. How are the service providers’ services registered in the registry?
  2. If a server goes down, how does the registry know to remove failed services from it?
  3. Clients often get multiple service providers from the registry. Which one should they choose to invoke?
  4. How many TCP connections need to be established when the client calls the server?
  5. What if the registry dies?

The service provider registers the service in the registry

Assume that the project provider currently has only UserService and ProductService registered, then in ZooKeeper they are represented as

  • /
    • dubbo
      • com.example.api.service.UserService
        • configurators
        • providers
          • Dubbo: / / 10.211.55.11:20880 / com. Example. API. Service. The UserService? Anyhost = true&application = user – provider&deprecated = false&dubbo = 2.0.2 & dynamic = true&generic = false&interface = com. Example. API . Service. UserService&methods = deleteUser register&pid = 3906 & release = 2.7.5 & revision 1.0.0 & side of = = provider&timestamp = 157810539 0062 & version = 1.0.0
          • Dubbo: / / 10.211.55.12:20880 / com. Example. API. Service. The UserService? Anyhost = true&application = user – provider&deprecated = false&dubbo = 2.0.2 & dynamic = true&generic = false&interface = com. Example. API . Service. UserService&methods = deleteUser register&pid = 3906 & release = 2.7.5 & revision 1.0.0 & side of = = provider&timestamp = 157810539 0062 & version = 1.0.0
      • com.example.api.service.ProductService
        • Something like that

Here we deploy the provider on two machines, which provide UserService and ProductService. The client will get providers and choose one to call according to the load balancing algorithm

The consumer gets the service from the registry to make the invocation

  1. The consumer then invokes the Register interface, which first fetches the providers service list from ZooKeeper and caches it
  2. Select a set of providers that meet the requirements of the Register method and parameter rules
  3. Then check whether routing rules are configured. If yes, filter the service provider based on the routing rules. Assume that no routing rules are configured
    • 10.211.55.11:20880, the methods = register…
    • 10.211.55.12:20880, the methods = register…
  4. Then according to the corresponding load balancing algorithm to select one of the servers to call the service
  5. By default, the Dubbo protocol uses the Netty to communicate with each other. By default, only one Netty client exists.
  6. The corresponding bytecode is assembled according to the DuBBO protocol, and then the data entities to be transmitted are serialized into the corresponding binary bytecode and put into the corresponding content for data transmission
  7. Because of the single TCP long connection data transmission, the amount of data transmitted will greatly affect the throughput

Reading the Dubbo protocol is recommended

What if a server goes down

For the service provider

Assume that 10.211.55.12 is down or the network is faulty. After establishing a connection with the zooKeeper registry in Dubbo, it sends heartbeat messages. Once ZooKeeper finds that it has not received heartbeat packets within a specified period of time, or that the server has actively disconnected, the created providers nodes are temporary. This node will be deleted automatically when the connection is disconnected

For consumers

After consumers obtain all provider services from the registry, they are cached locally and do not need to pull them from ZooKeeper every time they are invoked. When the ZooKeeper node is deleted, consumers will be notified to update the list of available service providers. If the failed server has been invoked before, another machine will be selected for invocation according to the load balancing policy

What if the registry dies

After the provider successfully obtains providers from ZooKeeper, it will cache them in the application memory, and then the service invocation load balancing algorithm will directly select corresponding providers from the memory to invoke them. Even if the registry is down, the provider can communicate normally, but the client cannot be notified of service changes

When the client calls the server, it needs to establish several TCP connections

  1. The default duBBo protocol is used. The DuBBO protocol uses netTY for communication
  2. The default number of connections is 1, that is, dubbo is single-connected by default
  3. The number of Connections determines the number of Netty clients, that is, the number of TCP connections to be created
  4. The client cannot create as many connections as it wants, for example, connection = 1000. In this case, the service provider will set a limit, for example, to create a maximum of 5 connections per consumer, so the client only has 5 connections