Dubbo is a high-performance, light-weight, open-source rpc (teleprocess call) framework that is primarily used to construct distributed services and micro-service structures. So how does dubbo run? Let's see。
Core components
To say that dubbo runs the core component of dubbo has to be understood first, because dubbo's interactive process is related to the core component。
Dubbo has the following core components:
2. Operational processes
Dubbo runs the following processes:
Its implementation process is as follows:
The service provider registers the example (url address) in the registration centre, which is responsible for synthesizing data (health testing). Consumers read the address list from the registration centre and subscribe to changes, and whenever the address list changes, the registration centre informs all subscribers of the latest list. After consumer access to the service, one of the nodes was selected through the dubbo built-in load equilibrium strategy, followed by rpc-based connections to service providers and communication and service calls。
More detailed call processes are as follows:
3. Supported communication agreements
The dubbo framework provides a self-defined high performance rpc communication protocol: a triple agreement based on http/2 and a dubbo2 agreement based on tcp. In addition, the dubbo framework supports arbitrary third-party communication agreements, such as officially supported grpc, thrift, rrt, jsonrpc, hessian2, etc., and more can be achieved by means of a self-defined extension. This is very useful for multi-negotiation communication scenarios that are often addressed in microservice practices。
The dubbo framework does not bind any communication protocols, and is flexible in achieving the dubbo support for multi-agreements, which allows you to publish multiple services using different protocols in one application and supports the publication of all agreements in the same port port。
Through multi-agreement support in the dubbo framework, you can:
4. Dubbo load balance strategy
At present dubbo (3. X) incorporates the following load equilibrium strategy:
Weighted random loadbalance (weighted random): default load balance algorithm, default weight equals. Sets a random probability by weight. Shortcomings: there is a problem with the accumulated requests of slow providers, for example: the second machine is slow, but it is not hung, it is stuck when the request is moved to the second, and all requests are stuck to the second. Rundrobin loadbalance (weighted rounding): drawing on the smooth-weighted rounding method of nginx, the default weight is the same, the rotation rate is set for post-convention weights, and nodes are rotated. Disadvantages: there is also the problem of slow provider cumulative requests. Lastactive loadbalance (minimum active priority + weighted random): behind the back is the mind of the capable, the lower the active number, the higher the priority call, the same active number weighted randomly. The active number refers to the difference in the number of times before and after the call (specific provider: number of requests sent - number of responses returned), indicating the volume of tasks performed by a particular provider, the lower the active number, the greater the processing capacity of the provider. Fewer requests are received by slow providers, as the difference between the number of calls made by slow providers is greater; in contrast, the processing capacity is stronger and more requests are processed. Shortest-respoNse loadbalance (lowest response priority + weighted random): pay more attention to the speed of response, the shorter the response time and the higher the call in a recent slide window. The same response time is weighted randomly. The faster the response, the more requests are processed. Disadvantages: this may result in an over-concentration of flows at high performance nodes. CoIntersistenthash loadbalance (harsh consistency): established inclusion, identified provider, applicable to status requests. When a provider hangs up, the original request to the provider, based on virtual nodes, is distributed evenly to the other provider and does not cause dramatic changes. P2c loadbalance (random selection of two nodes + smaller number of connections): after random selection of two nodes, choose the smaller node. For each call, make two random selections from the list of available providers, select two nodes providera and providerb, compare the two nodes of providera and providerb, and select the smaller node of its "currently processed connections". Adaptive loadbalance (self-adapted load balance): on the basis of the p2c algorithm, selecting the smallest of the two is an algorithm that automatically adjusts the flow distribution to the back-end case load, which always attempts to forward the request to the smallest load node。
