Dubbo provider and Consumer are both configured with timeout

Configure as many Consumer attributes on the Provider as possible for the following reasons:

  1. The provider of the service knows better than the consumer of the service performance parameters, such as the timeout of the invocation, the reasonable number of retries, and so on

  2. After the Provider is configured, if the Consumer is not configured, the Provider configuration is used as the default value for Consumer. Otherwise, the Consumer uses the global Settings on the Consumer side, which is out of the Provider’s control and often unreasonable

  3. Configured coverage rules:

    1. The method level configuration is superior to the interface level, that is, small Scope takes precedence

    2. The Consumer configuration is better than the Provider configuration

How is Dubbo embedded in the Spring container

Dubbo uses BeanFactoryPostProcessor and BeanPostProcessor to complete the registration of ServiceBean and dependency injection of attributes annotated by @Reference. The BeanPostProcessor is used to bind the properties of the configuration file to the relevant configuration class beans.

The bean annotated by @service (Dubbo) is created and managed by Spring, registering a ServiceBean that holds a reference to the bean (beanName). The @service configuration properties are eventually bound to the properties of ServiceBean, which listens for Spring events to export (expose) the Service.

What if Dubbo service is down

  1. The registry is down. You can continue your communication. Consumers pull information such as the provider’s address into the local cache, so communication can continue when the registry is down.
  2. It’s usually a cluster

How does Dubbo service handle high concurrency requests

  1. Mock =force:return+null
  2. Sentinel lightweight flow control product for traffic surge and high system load
  3. Apollo configuration Center

Dubbo timeout retry, degrade

  1. If the consumer initiates a request and does not receive a response from the server within a specified period of time, a timeout exception is returned, but the server code is still executed.
  2. If the client sends a request to the server, the client waits for the response from the server. If the server fails to complete the method execution within the specified time, it returns a timeout exception to the client.

Service timeout setting: Client method level > Server Method level > Client Interface level > Server Interface level > Client Global > Server Global

Service timeout implementation principle: Dubbo uses NetTY as the default network component, which belongs to a NIO mode. When the consumer initiates a remote request, the thread does not block and wait for the server to return it. Instead, the thread immediately gets a ResponseFuture, and the consumer uses a polling mechanism to determine whether the result has been returned. Because it is through polling, polling has a special need to avoid the dead loop, so in order to solve this problem to introduce a timeout mechanism, only within a certain period of time to do polling, if the timeout will return a timeout exception.

Degrade: Call coment Service to degrade the service, such as returning a mock when an exception occurs.

What if the registry is down

If the ZooKeeper registry goes down, the service consumer will still be able to call the provider’s service for a period of time. It actually uses a local cache to communicate, which is just a measure of Dubbo’s robustness.

  1. The breakdown of the monitoring center does not affect the use of the system, but only the loss of some sample data
  2. After the database goes down, the registry can still provide a list of services query through the cache, but it cannot register new services
  3. If one of the registry peer clusters fails, it will automatically switch to the other one
  4. After all registries go down, service providers and service consumers can still communicate through local caches
  5. The service provider is stateless. If any service provider breaks down, the service is not affected
  6. When all service providers go down, the service consumer application becomes unavailable and reconnects indefinitely waiting for the service provider to recover

Dubbo generalization call

There are several scenarios to consider using generalized calls:

  • Service test platform
  • API Service Gateway

Generalization calls are mainly used when there is no API interface on the consumer side; Instead of importing the interface JAR package, the service call is made directly through the GenericService interface, and all POJOs in the parameters and return values are represented by Map. The generalized call is not a concern for the server side, just as normal service exposure.

7. Dubbo exception handling

When a system calls a Dubbo request, the provider throws a custom business exception, but the consumer does not get a custom business exception. If Dubbo’s Provider side throws an exception (Throwable), it is intercepted by the Provider side ExceptionFilter and the following invoke method is executed

How to catch exceptions correctly:

  1. Start the package name of the exception with “Java.” or “javax.
  2. Using checked exceptions (inheriting Exceptions)
  3. Instead of exceptions, use error codes
  4. Put the exception in the JAR package of provider-API
  5. Whether abnormal message to XxxException. Class. GetName () beginning (including XxxException is custom business exceptions)
  6. Provider implements the GenericService interface
  7. The API of provider clearly specifies throws XxxException to publish the provider (XxxException is a user-defined service exception).
  8. Implement dubbo filter, custom provider exception handling logic (method can refer to the previous article to add a white list of Dubbo interface — use dubbo filter)

8. Dubbo service exposed

Dubbo will publish the ContextRefreshEvent event in the last step of refreshing the container after Spring has instantiated the bean, Notifies the ServiceBean class that implements ApplicationListener to call back the onApplicationEvent event method, Dubbo calls the Export method of ServiceBean’s parent ServiceConfig in this method, which actually implements (asynchronous or non-asynchronous) publishing of the service.

9. Dubbo agreement

dubbo:// rmi:// http:// hession:// redis://

10. Are calls between Dubbo services blocked

Dubbo default protocol uses a single long connection, the underlying implementation is Netty NIO asynchronous communication mechanism; Based on this mechanism, Dubbo implements the following calls:

  • A synchronous invocation
  • The asynchronous call
  • Parameters of the callback
  • Event notification

11. Difference between Dubbo and SpringCloud

Dubbo is a product of the SOA era, which focuses on service invocation, traffic distribution, traffic monitoring, and fusing.

Spring Cloud was born in the era of microservice architecture, considering all aspects of microservice governance, and relying on the advantages of Spring and Spring Boot

The two frameworks had different goals from the start, with Dubbo positioning service governance and Spring Cloud building an ecosystem.

  • The bottom layer of Dubbo uses NIO framework such as Netty and is transmitted based on TCP protocol. With the serialization of Hession, RPC communication is completed.
  • Spring Cloud is based on the Http protocol Rest interface to invoke remote process communication, relatively speaking, Http requests will have larger packets, and occupy more bandwidth. However, REST is more flexible than RPC. The dependence of service providers and callers only depends on a contract, and there is no strong dependence at the code level. This is more appropriate in a microservice environment that emphasizes rapid evolution.

12. Dubbo load balancing

Random LoadBalance(default, Random load balancing based on weights)

RoundRobin LoadBalance(not recommended, weighted round load balancing mechanism)

LeastActive LoadBalance Minimum number of active calls

ConsistentHash LoadBalance Consistency Hash

13. Transparent transmission of Dubbo parameters

If you need to view the all-link logs of an invocation, the general practice is to generate a traceId in the system boundary and send the traceId to the subsequent services of the invocation chain. The subsequent services use traceId to print logs and then send the traceId to other subsequent services. This process is referred to as: TraceId passthrough.

  1. Implemented based on RpcContext
  2. Implementation based on Filter

14. Dubbo Filter

  1. To realize the com. Alibaba. Dubbo. RPC. Filter interface:
  2. Profile: add plain text files in the resources directory meta-inf/dubbo/com. Alibaba. Dubbo. RPC. The Filter
  3. Modify the Provider configuration file of dubbo and add the configured filter in dubbo: Provider

15. What are Dubbo’s cluster fault tolerance schemes?

Dubbo provides multiple fault tolerance schemes. By default, failover retry is used

Failsafe Cluster: indicates failure security. If an exception occurs, it is ignored. It is used to write audit logs. Failback Cluster: Automatically recovers when a failure occurs. Failed requests are recorded in the background and resent periodically. Typically used for message notification operations. Forking Cluster: Calls multiple servers in parallel and returns if one is successful. It is usually used for read operations that require high real-time performance but waste more service resources. The maximum parallel number can be set by forks=”2″. Broadcast Cluster: Broadcasts calls to all providers one by one. An error is reported on any provider. Typically used to notify all providers to update local resource information such as caches or logs.

<dubbo:service retries="2" />
Copy the code

www.cnblogs.com/xuwc/p/8974…