Dubbo, Dubbo, Dubbo!

1. Dubbo core functions:

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.

2. Dubbo Frame Diagram:

3, introduce Dubbo dependency defaults and other dependencies:

4. Dubbo configuration diagram:

Dubbo configuration overview:

5. Start with a simple configuration test

“Dubbo: service interface =” tuling. Dubbo. Server. UserService “timeout =” 2000 “>

Timeout is the execution timeout of the service. The timeout stack is as follows:

You can see that the error expression means that the Response message cannot be returned because the Channel is closed. The reason for this is that although the timeout configuration is used on the server side, it is used on the client side, which indicates that the client call has expired, not that the server method has timed out. We can see the timeout exception when we look at the client logs

Similar configurations on the server are used on the client, such as REtries, async, and loadBalance.

6. Configuration priority problem:

Dubbo :provider and Dubbo :service, dubbo:consumer and Dubbo :reference?

After timeout is configured on the server, all clients use the timeout. Can clients customize the timeout? This can be set by <dubbo:reference timeout= “2000” > or by <dubbo: Consumer timeout= “2000” >, You can even set it to the method level <dubbo:method name= “getUser” timeout= “2000” />. With the server configuration, there are a total of six places you can configure timeouts. If different values are configured for each of the six places, only one timeout value will eventually take effect, and its priority is as follows:

7. Interface exposure and Reference:

The usual way to expose an interface is to separate the interface from the implementation, with the server putting the interface, model, exception, and so on in one module and the implementation in another. The caller makes the reference through Maven.

Zookeeper, the registry recommended by Dubbo

Zookeeper is a subproject of Apacahe Hadoop. It is a tree directory service that supports change push and is suitable for Dubbo service registry. It has high industrial intensity and can be used in production environment

9, failure to reconnect

Sudden provider disconnection: Implemented based on the Zookeeper temporary node mechanism, Zookeeper automatically deletes all temporary nodes after the client session times out. The default value is 40 seconds.

Question: Will a defunct provider connection be invoked if a client joins within 40 seconds of zooKeeper being disconnected?

A: No, when the provider goes down, its connection to the client is immediately broken, and the client detects the long connection status before invoking it.

Dubbo call module Overview:

The core function of dubbo call module is to initiate a remote method call and get the return result smoothly. Its system is composed as follows:

  1. Transparent proxy: With dynamic proxy technology, remote call details are shielded for programming friendliness.
  2. Load balancing: How to choose which load algorithm to call when there are multiple providers.
  3. Fault tolerance: The policy adopted when a service invocation fails
  4. Call mode: Supports synchronous and asynchronous call

10.1. Load Balancing

Dubbo currently officially supports the following load balancing strategies:

Random: Set the random probability according to the weight. This is the default algorithm.

Roundrobin: Set the round-robin ratio according to the weight after the convention.

Minimum number of active calls (LEastActive): a random number of the same number of active calls.

Consistenthash (Hash): The same parameters are always sent to the same machine

Setting Mode You can set the priority in one of the following modes from low to high

  • 1 <– server level — >

“Dubbo: service interface =”…” Roundrobin loadbalance = “” / >

  • 2 <– client level — >

“Dubbo: reference interface =”…” Roundrobin loadbalance = “” / >

  • 3 <– server method level — >

“Dubbo: service interface =”…” >

“Dubbo: method name =”…” Roundrobin loadbalance = “” / >

</dubbo:service>

  • 4 <– client method level — >

“Dubbo: reference interface =”…” >

“Dubbo: method name =”…” Roundrobin loadbalance = “” / >

</dubbo:reference>

10.2. Consistent Hash Algorithm Diagram:

(In the interval where the calculation result falls, the first node is searched clockwise for access. In order to prevent uneven distribution caused by the proximity of several nodes, 160 nodes are created internally by default to make access distribution even)

10.3, fault tolerance,

Dubbo currently supports the following fault tolerance policies:

  1. Automatic switchover when a call fails: Retry another server based on retries= “2”
  2. Fast failure: The system fails quickly. An error message is displayed immediately after the invocation fails.
  3. Do not skip failure: Do not skip failure and do not throw an exception to the client.
  4. Retry on failures: The system automatically recovers failures, records failed requests in the background, and periodically resends failed requests. Typically used for message notification operations
  5. Parallel calls: returns on any one success, parallel calls to a specified number of machines, the maximum number of parallel calls can be set by forks= “2”.
  6. Broadcast call: Broadcast calls all providers, one by one, and an error is reported on any one

Setting mode You can set the priority in either of the following ways from low to high

“Dubbo: service interface =”…” Cluster = “broadcast” / >

“Dubbo: reference interface =”…” Cluster = “broadcast” / >

< — –

Failover fails Automatic switchover retries= 1 Number of switchover times

Failfast Rapidly fails

Don’t fail Failsafe

Failback Fails and retry 5 seconds later

Forking parallel calls forks= “2” maximum parallel number

Broadcast call

— – >

10.4. Call Method:

  1. Synchronous wait result return (default)
  2. Asynchronously wait for results to return
  3. There is no need to return the result

The realization process of asynchronous wait result return in Dubbo is shown as follows:

In asynchron, the UserThread submits to the IOThread until the remote interface is called, and then executes the following code until the IOThread receives the return value from the remote service. Therefore, the return value variable must be volatile and visible to the thread.

11. Token validation

Controlling permissions in the registry to decide whether to issue a token to a consumer through token authentication prevents consumers from bypassing the registry to access providers, and the registry provides flexibility to change authorization without modifying or upgrading the provider

< – Random token, generated using UUID – ><dubbo:provider interface= “com.foo.BarService” token= “true” />

Well, that’s all for today’s article, hoping to help those of you who are confused in front of the screen