Attribute configuration override rule: consumer side takes precedence over provider side, method takes precedence over interface configuration, and interface takes precedence over global configuration

Load balancing, service downgrade, console dynamic control is generally used.

1. Start check: check="false"

Normally, there are checks at startup, errors if some exceptions are checked, configurations can be used to turn off startup checks, and checks when real calls are made

<dubbo:reference interface="com.foo.BarService" check="false" />　　//Do not check if the current service does not have a provider
<dubbo:consumer check="false" />　　　　　　　　　　　　　　　　　　　　　//Do not check if all services have no providers
<dubbo:registry check="false" />　　　　　　　　　　　　　　　　　　　　　//Registry not started, no check

2. Timeout: timeout="1"

Default 1000ms

    <dubbo:reference interface="com.ll.service.UserService" id="userService" timeout="1000" >
        <dubbo:method name="getUserAddressList" timeout="2000" />
    </dubbo:reference>
　　<dubbo:consumer timeout="5000" />

3. Number of retries:

You can set the number of retries (same as executing multiple times) in the case of idempotent [query, delete, modify]

You cannot set the number of retries (cannot execute more than once) in non-power [increase] cases, etc.

    <dubbo:reference interface="com.ll.service.UserService" id="userService" retries="2" >
        <dubbo:method name="getUserAddressList" retries="1" />
    </dubbo:reference>
　　<dubbo:consumer check="false" retries="3" />

4. Multi-version: Grayscale publishing can be achieved

When an interface implementation has incompatible upgrades, it is possible to transition using version numbers, where services with different versions do not reference each other.

Follow these steps to migrate versions:

0. Upgrade half of the providers to the new version during periods of low pressure

1. Upgrade all consumers to a new version

2. Then upgrade half of the remaining providers to the new version

<dubbo:service interface="com.foo.BarService" version="1.0.0" />    //Older version service provider configuration
<dubbo:service interface="com.foo.BarService" version="2.0.0" />    //New version service provider configuration

<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />    //Old version service consumer configuration
<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />    //New Version Service Consumer Configuration

<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />        //If you don't need to distinguish between versions, you can use*To configure

5. Local stubs:

After remote services, the client usually only has interfaces, but the implementation is all on the server side, but the provider sometimes wants to perform some logic on the client side, such as making ThreadLocal caches, validating parameters in advance, forging fault tolerant data after a call fails, and so on.
At this point, you need to bring a Stub in the API, the client generates a Proxy instance, passes the Proxy to the Stub through the constructor, and then exposes the Stub to the user, who can decide whether to call the Proxy or not.
If the condition is satisfied, do not call the remote interface if it is not

Implementation of Stub:

public class UserServiceStub implements UserService {
    private final UserService userService;
// Constructor passes in a real remote proxy object
    public UserServiceStub(UserService userService) {
        this.userService = userService;
    }
    // This code is executed on the client side, You can do it on the client side ThreadLocal Local caching, or pre-validation of parameters, etc.
    @Override
    public List<UserAddress> getUserAddressList(String userId) {
        return StringUtils.isEmpty(userId)  ? userService.getUserAddressList(userId) : null ;
    }
}

"Configured in the spring dubbo configuration file:

    <dubbo:reference interface="com.ll.service.UserService" id="userService" stub="com.ll.service.impl.UserServiceStub" />

6. High Availability: zookeeper Downtime and dubbo Direct Connection

zookeeper downtime: After all registry downtime, service providers and service consumers can still communicate through the local cache.When the provider is called once, the host information, methods, etc. of the provider are cached

dubbo Direct Connection:

@Reference(url = "192.168.28.219:2181")　　//annotation

<dubbo:reference interface="com.ll.service.UserService" id="userService" url="192.168.28.219:2181">　　//configuration file

7. Load Balancing Mechanism:

In cluster load balancing, Dubbo provides a variety of balancing strategies, defaulting to random random random calls.

　　>Random LoadBalance
Random, set random probability by weight.
The probability of collision on a section is high, but the larger the call volume, the more evenly distributed, and the weights used by probability are more evenly distributed, which facilitates dynamic adjustment of provider weights.
　　>RoundRobin LoadBalance
Round robin, set the round robin ratio according to the weight after the convention.
There is a problem with slow providers accumulating requests, such as: the second machine is slow but hangs up, gets stuck there when the request is transferred to the second machine, and over time all requests get stuck in the second machine.
　　>LeastActive LoadBalance
Minimum number of active calls, random number of the same active number, the active number refers to the difference between the counts before and after the call.
Make slower providers receive fewer requests because slower providers have a greater difference in count before and after invocation.
　　>ConsistentHash LoadBalance
Consistent Hash, requests for the same parameters are always sent to the same provider.
When a provider hangs up, requests originally sent to that provider are spread out to other providers based on virtual nodes without causing drastic changes.See: http://en.wikipedia.org/wiki/Consistent_hashing
The default is only for the first parameter Hash, if you want to modify it, configure <dubbo:parameter key="hash.arguments" value="0,1"/>
The default is 160 virtual nodes. If you want to modify them, configure <dubbo:parameter key="hash.nodes" value="320"/>

</dubbo:reference>
<!--Service-side Service Level-->
<dubbo:service interface="..." loadbalance="roundrobin" />
<!--Server-side method level-->
<dubbo:service interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>

<!--Client Service Level-->
<dubbo:reference interface="..." loadbalance="roundrobin" />
<!--Client Method Level-->
<dubbo:reference interface="...">
<!--Overall situation-->
<dubbo:consumer check="false" loadbalance="roundrobin" />

8. Service downgrade:

When server pressure increases dramatically, some services and pages are not handled strategically or simply in a different way based on actual business conditions and traffic, thereby freeing up server resources to ensure the normal or efficient operation of core transactions.
You can temporarily block a non-critical service from failing through service demotion and define a return policy after demotion.
mock=force:return+null indicates that the consumer's method calls to the service directly return null values without making remote calls.Used to shield callers from unavailability of unimportant services.
mock=fail:return+null indicates that the consumer returns a null value after a method call to the service fails without throwing an exception.Used to tolerate the impact on callers when insignificant services are unstable.

9. Service fault tolerance:

Dubbo provides a variety of fault tolerance schemes when cluster calls fail, defaulting to failover retries.
Cluster Fault Tolerant Mode
Failover Cluster failed to switch automatically. When a failure occurs, try another server again.Usually used for read operations, but retrying can cause longer latencies.retries="2" can be used to set the number of retries (excluding the first).
Failfast Cluster failed quickly, making only one call, and the failure immediately reported an error.Usually used for write operations that are not idempotent, such as adding records.
Failsafe Cluster fails to be safe and is ignored when an exception occurs.Usually used for operations such as writing audit logs.
Failback Cluster failed automatic recovery, failed requests are logged in the background and resended regularly.Typically used for message notification operations.
Forking Cluster calls multiple servers in parallel and returns with only one success.Usually used for read operations with high real-time requirements, but more service resources are wasted.You can set the maximum number of parallels by forks="2".
Broadcast Cluster Broadcast calls all providers one by one, and any one of them fails [2].Usually used to notify all providers to update local resource information such as caches or logs.

//Cluster Mode Configuration
<dubbo:service cluster="failsafe" />　　<dubbo:reference cluster="failsafe" />

In practice, fault tolerance is achieved by integrating "hystrix":

(1). Import dependent packages:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
    <version>2.1.2.RELEASE</version>
</dependency>

(2). Then add @EnableHystrix on the Application class to enable hystrix starter:

@SpringBootApplication
@EnableHystrix　　//Open Service Fault Tolerance
public class ProviderApplication {

(3). Configure Provider side:

Add the @HystrixCommand configuration to the Provider of Dubbo so that the subcall passes through the Hystrix proxy.

@HystrixProperty
public String sayWord(String name) {

(4). Configure the Consumer side:

On the Consumer side, you can add a layer of method calls and configure @HystrixCommand on the method.When an error occurs in the call, it goes to the fallbackMethod = "reliable" call.

@HystrixCommand(fallbackMethod = "hello")　　//Error calling hello method
public String sayHello(String name) {

Cluster Mode Configuration