1 Introduction to Dubbo
Dubbo is a high-performance, lightweight open source Java RPC framework that provides three core capabilities: interface-oriented remote method invocation, intelligent fault tolerance and load balancing, and automatic service registration and discovery.
As a lightweight RPC framework, Dubbo's design architecture is simple and clear. The main components include Provider (service provider), Consumer (service consumer), and Registry (registry center). In addition, there are Monitors for service monitoring. The relationship between them is as follows:
In a distributed system, in order to achieve high system availability, that is, when the service is down, it does not affect the normal provision of services to the outside world. It is necessary to form a load cluster. When a node in the cluster does not return data in time, cluster fault tolerance (re- Try) mechanism.
2 Dubbo load balancing
For cluster load balancing, Dubbo provides the following 5 balancing strategies, which are called random by default.
Random
Random call
Random LoadBalance
Random, set random probability by weight.
The probability of collision on a cross-section is high, but the larger the amount of calls, the more uniform the distribution, and the more uniform the weight is used according to the probability, which is beneficial to dynamically adjusting the provider weight.
RoundRobin LoadBalance
Round robin, the round robin ratio is set according to the weight after the convention.
There is a problem that slow providers accumulate requests. For example, the second machine is slow, but it is not hung up. When the request is transferred to the second machine, it is stuck there. Over time, all requests are stuck in the second machine.
LeastActive LoadBalance
The minimum number of active calls, the same active number is random, the active number refers to the difference between the counts before and after the call.
The slower provider receives fewer requests, because the slower the provider will have a greater difference in counts before and after the call.
ConsistentHash LoadBalance
Consistent Hash, requests with the same parameters are always sent to the same provider.
When a certain provider hangs up, the request originally sent to that provider will be spread to other providers based on the virtual node without causing drastic changes.
3 Load balancing configuration
Server service level
interface="..." loadbalance="roundrobin" />;
Client service level
interface="..." loadbalance="roundrobin" />
Server method level
<dubbo:serviceinterface="...">
<dubbo:methodname="..." loadbalance="roundrobin"/>
dubbo:service>
Client method level
<dubbo:referenceinterface="...">
<dubbo:methodname="..." loadbalance="roundrobin"/>
dubbo:reference>
4 Dubbo cluster fault tolerance (retry mechanism)
When the cluster call fails, Dubbo provides a variety of fault tolerance solutions, and the default is Failover to retry.
Relationship between nodes:
The Invoker here is an abstraction of the Provider that can call the Service, and the Invoker encapsulates the Provider address and Service interface information
Directory represents multiple Invokers, which can be regarded as List, but unlike List, its value may change dynamically, for example, the registry pushes changes
Cluster disguises multiple Invokers in the Directory as one Invoker, which is transparent to the upper layer. The disguise process includes fault-tolerant logic. After the call fails, try another one again.
Router is responsible for selecting a subset from multiple Invokers according to routing rules, such as read-write separation, application isolation, etc.
LoadBalance is responsible for selecting a specific one from multiple Invokers for this call. The selection process includes the load balancing algorithm. After the call fails, you need to reselect
5 Retry mode and its characteristics
Failover Cluster (default)
Automatically switch on failure, when failure occurs, retry other servers [1]. Usually used for read operations, but retrying will bring longer delays. The number of retries can be set by retries="2" (excluding the first time).
The number of retries is configured as follows:
<dubbo:serviceretries="2" />
or
<dubbo:referenceretries="2" />
or
<dubbo:reference>
<dubbo:methodname="findFoo" retries="2" />
dubbo:reference>
Failfast Cluster
Fail fast, only initiate a call, and immediately report an error if it fails. Usually used for non-idempotent write operations, such as adding records.
Failsafe Cluster
It is safe to fail. When an exception occurs, ignore it directly. Usually used for operations such as writing to the audit log.
Failback Cluster
Automatically recover from failure, record failed requests in the background, and resend regularly. Usually used for message notification operations.
Forking Cluster
Call multiple servers in parallel and return as long as one succeeds. It is usually used for read operations with high real-time requirements, but more service resources are wasted. The maximum number of parallels can be set by forks="2".
Broadcast Cluster
Broadcast calls all providers, call them one by one, and any one of them will report an error [2]. Usually used to notify all providers to update local resource information such as caches or logs.
6 cluster mode configuration
Follow the example below to configure the cluster mode on the service provider and consumer
<dubbo:servicecluster="failsafe" />
or
<dubbo:referencecluster="failsafe" />