Shulou(Shulou.com)06/02 Report--

This article mainly explains "Summary of important knowledge points of dubbo". Friends who are interested may wish to have a look. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn the "Summary of important knowledge points of dubbo"!

Dubbo architecture

Provider: the provider of the exposed service, which can be started by jar or container

Consumer: the service consumer that invokes the remote service.

Registry: service registry and discovery center.

Monitor: count the number of calls to the service and the call time

Container: the container in which the service runs.

Network Transport Protocol of Dubbo

RPC communication protocol

Serialization method provided by Dubbo

Dubbo:Dubbo default protocol adopts single long connection and NIO asynchronous communication, which is suitable for service calls with small amount of data and large concurrency, and when the number of service consumer machines is much larger than that of service provider machines.

Rmi:RMI protocol is implemented by java.rmi.* of JDK standard, blocking short connection and JDK standard serialization.

Hessian:Hessian protocol is used to integrate Hessian services, Http communication is used at the bottom of Hessian, Servlet exposure service is adopted, and Jetty is embedded in Dubbo by default.

Http: HttpInvoker implementation using Spring

Webservice: frontend-simple and transports-http implementation based on CXF

The registry of Dubbo

The default is zk, and there are Redis, Multicast, and Simple registries, but it is not recommended.

What are the ways to configure Dubbo?

Spring configuration method (XML file)

Java API configuration mode (annotation mode)

Core configuration of Dubbo

Dubbo:service service configuration (as a service provider, expose the configuration of the service)

Dubbo:reference reference configuration (external service needs to be invoked)

Dubbo:protocol protocol configuration (protocol configuration supported by the service. If you need to support multiple protocols, you can declare multiple tags)

Dubbo:application application configuration (application information configuration, including current application name, application owner, application version, application environment, etc.)

Dubbo:module module configuration (module information configuration, including current module name, module owner, module version, etc.)

Dubbo:registry registry configuration (if you have multiple different registries at the same time, you can declare multiple tags and specify the registry to use in the or registry attribute. )

Dubbo:monitor monitoring center configuration (with two attributes: protocol and address. When protocol= "registry" indicates discovery of the monitoring center address from the registry, when address= "10.20.130.230RV 12080" indicates directly connected monitoring center address)

Dubbo:provider provider configuration (service provider default configuration, which is set to the default value of the and tags. )

Dubbo:consumer consumer configuration (service consumer default configuration, which is set by the default value of the label. )

Dubbo:method method configuration (the label is a subtag of or and is used to control to the method level. )

Dubbo:argument parameter configuration (the label is a child tag for the characteristic description of method parameters)

Timeout of Timeout

In the configuration files of provider and consumer of dubbo, if the timeout of timeout is configured, dubbo defaults to the time configured in consumer.

Examples are as follows:

Configuration in provider.xml:

Configuration in conusmer:

The timeout for the last service call is 3 seconds.

In addition:

1.consumer gets an exception with a call timeout for more than 3 seconds.

The execution of the code in 2.provider will not be interrupted by a timeout, and when it is finished, you will get a warning from dubbo.

Configure as many Consumer-side properties as possible on Provider

In the dubbo user's manual, it is recommended to configure as many Consumer-side properties as possible on the Provider

The reasons are as follows:

As the service provider, you know the service performance parameters better than the service consumer, such as the timeout of the call, the reasonable number of retries, etc.

After Provider is configured, if Consumer is not configured, the configuration value of Provider is used, that is, Provider configuration can be used as the default value of Consumer. Otherwise, Consumer will use the global settings on the Consumer side, which is out of control for Provider and is often unreasonable

PS: configured override rules:

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

Consumer side configuration is better than Provider configuration is better than global configuration, and finally, the configuration value of Dubbo Hard Code (see configuration document)

The Consumer-side properties that can be configured on Provider are:

Timeout: method call timeout

Retries: the number of failed retries. The default is 2 (indicating that 3 calls will be made plus the first call).

Loadbalance: load balancing algorithm (how to pick the Provider call when there are multiple Provider). The default is random. There can also be rotation training (roundrobin), least activity first (leastactive), which refers to the best Provider calls concurrently from the Consumer side, which can reduce the number of slow Provider calls, because the response is easier to accumulate concurrent calls)

Actives: consumer side, maximum concurrent invocation limit, that is, when the concurrent invocation of a service by Consumer reaches the upper limit, the new call will Wait until the timeout. If you configure (dubbo:method) the concurrency limit on the method and configure (dubbo:service) on the interface, the concurrency limit is directed to the service.

What happens if the dependent service is not available when Dubbo starts?

By default, Dubbo checks whether the dependent service is available at startup, and throws an exception when it is not available to prevent Spring initialization from being completed. The default check= "true" can be turned off by check= "false".

Serialization framework supported by Dubbo

Hessian serialization is recommended, and Duddo, FastJson, and Java come with serialization.

Communication framework used by Dubbo

Dubbo uses Netty framework by default, which is also the recommended choice. In addition, Mina and Grizzly are integrated in the content.

Cluster Fault-tolerant Scheme of Dubbo

Failover Cluster fails to automatically switch and automatically retry other servers (default)

Failfast Cluster fails quickly, reports an error immediately, and initiates only one call

Failsafe Cluster failed security. If an exception occurs, ignore it directly.

Failback Cluster fails to recover automatically, record failed requests and resend them regularly.

Forking Cluster calls multiple servers in parallel, and returns as long as one succeeds

Broadcast Cluster broadcasts call all providers one by one, and any error is reported.

Load balancing Strategy of Dubbo

Random LoadBalance random, set random probability by weight (default)

RoundRobin LoadBalance polling, which sets the polling rate according to the weight after the convention

LeastActive LoadBalance minimum number of active calls, random with the same number of active calls

ConsistentHash LoadBalance conformance Hash. Requests with the same parameters are always sent to the same provider.

Multiple identical services have been registered, what to do if you need to test one of the specified services

You can configure the environment point-to-point direct connection, bypass the registry, and ignore the list of providers in the registry in terms of service interfaces.

Dubbo support service multi-protocol

Dubbo allows you to configure multiple protocols to support different protocols on different services or multiple protocols on the same service at the same time.

Different services and different protocols:

Multiple protocols for the same service

What to do when a service interface has multiple implementations

When an interface has multiple implementations, it can be grouped with the group attribute, and both the provider and the consumer specify the same group.

Provider:

Consumer side:

How is the service online compatible with the old version?

You can transition with a version number (version). Multiple different versions of services are registered with the registry, and services with different version numbers do not refer to each other. This is a bit similar to the concept of service grouping. For example:

Service provider:

Service consumers:

In addition, when consumers consume any version of the service:

The result caching mechanism of Dubbo

Dubbo provides declarative caching, which is used to speed up the access to popular data to reduce the workload and usage of caching:

The entry points of the three cache interfaces provided by Dubbo, all of which inherit the AbstractCacheFactory interface. They are:

1.threadlocal=com.alibaba.dubbo.cache.support.threadlocal.ThreadLocalCacheFactory

2.lru=com.alibaba.dubbo.cache.support.lru.LruCacheFactory (LRU deletes redundant caches based on the principle of least recent use, keeping the hottest data cached; this type of cache is cross-thread; using linked list implementation, new data is inserted into the header, cache hit data is moved to the header, and footer data is deleted when the linked list is full)

3.jcache=com.alibaba.dubbo.cache.support.jcache.JCacheFactory

Dubbo synchronous / asynchronous invocation

The default protocol of Dubbo uses a single persistent connection, and the underlying implementation is Netty's NIO asynchronous communication mechanism. Based on this mechanism, Dubbo implements the following call methods:

Synchronous call

Asynchronous invocation

Parameter callback

Event notification

Dubbo synchronous call

Synchronous invocation is a blocking method, that is, the code on the Consumer side blocks waiting until the Provider side returns

In general, a typical synchronous call procedure is as follows:

The Consumer business thread calls the remote interface to send a request to Provider, while the current thread is in a blocking state

After receiving the request from Consumer, Provider begins to process the request and returns the result to Consumer

After the Consumer receives the result, the current thread continues to execute back.

Here are two questions:

How did the Consumer business thread enter the blocking state?

After the Consumer receives the result, how does the business thread wake up to execute it later?

In fact, the underlying IO operations of Dubbo are asynchronous. After the Consumer side initiates the call, it gets a Future object. For synchronous calls, the business thread blocks and waits for the result to be returned by the Provider side through Future#get (timeout); timeout is the timeout defined by the Consumer side. When the result returns, the Future will be set to this and the blocked business thread will be awakened; when the timeout time expires and the result has not been returned, the business thread will return abnormally.

Dubbo asynchronous invocation

The implementation of asynchronous calls based on the asynchronous NIO at the bottom of Dubbo is necessary for scenarios with long Provider response time. It can make effective use of resources on the Consumer side and is less expensive than using multi-threads on the Consumer side. Asynchronous call, no special configuration is required for the Provider side.

To configure methods that need to be called asynchronously on the Consumer side, you need to use tags to describe them:

After the Dubbo Consumer side initiates the call, it also gets the Future object associated with the returned result through RpcContext.getContext (). GetFuture (), and then you can start processing other tasks; when you need the result of this asynchronous call, you can get it through future.get (timeout) at any time.

In some special scenarios, in order to call return as soon as possible, you can set whether to wait for the message to be sent:

Sent= "true" waits for the message to be sent. An exception will be thrown if the message fails to be sent.

Instead of waiting for the message to be sent, the sent= "false" puts the message on the IO queue and returns immediately.

The default is false. The configuration is as follows:

If you just want to be asynchronous and completely ignore the return value, you can configure return= "false" to reduce the cost of creating and managing Future objects:

At this point, RpcContext.getContext () .getFuture () returns null.

Dubbo parameter callback

Parameter callback is somewhat similar to the local Callback mechanism, but Callback is not a class or interface within Dubbo, but is customized by the Provider side; Dubbo will generate a reverse proxy based on a persistent connection, thus realizing the logic of calling the Consumer side from the Provider side.

The Provider side defines Service and Callback:

Public interface CallbackService {void addListener (String key, CallbackListener listener);} public interface CallbackListener {void changed (String msg);}

Implement service on Provider:

Public class CallbackServiceImpl implements CallbackService {private final Map listeners = new ConcurrentHashMap () Public CallbackServiceImpl () {Thread t = new Thread (new Runnable () {public void run () {while (true) {try {for (Map.Entry entry: listeners.entrySet () {try { Entry.getValue () .changed (getChanged (entry.getKey ()) } catch (Throwable t) {listeners.remove (entry.getKey ());}} Thread.sleep (5000) / / timely trigger change event} catch (Throwable t) {t.printStackTrace ();}); t.setDaemon (true); t.start ();} public void addListener (String key, CallbackListener listener) {listeners.put (key, listener) Listener.changed (getChanged (key)); / / send notification for change} private String getChanged (String key) {return "Changed:" + new SimpleDateFormat ("yyyy-MM-dd HH:mm:ss") .format (new Date ());}}

Expose the service on the Provider side:

Implement Callback interface on Consumer side

CallbackService callbackService =...; callbackService.addListener ("foo.bar", new CallbackListener () {public void changed (String msg) {System.out.println ("callback1:" + msg);}})

The implementation class of the Callback interface is on the Consumer side. When a method is called, the Consumer side will automatically export a Callback service. When the Provider side handles the call, it determines that if the parameter is Callback, a proxy is generated, so when the Callback method is called in the service implementation class, it will be passed to the Consumer side to execute the code of the Callback implementation class.

Dubbo event notification

Event notification allows the Consumer side to trigger oninvoke, onreturn, and onthrow events before, after, or when an exception occurs.

You can specify the methods in which events need to be notified when configuring Consumer, such as:

The code of NotifyImpl is as follows:

Public class NotifyImpl implements Notify {public Map ret = new HashMap (); public void onreturn (String name, int id) {ret.put (id, name); System.out.println ("onreturn:" + name);} public void onthrow (Throwable ex, String name, int id) {System.out.println ("onthrow:"+ name);}}

It should be emphasized here that the parameter rules of the three methods in the custom Notify interface are as follows:

The parameters of the oninvoke method are the same as those of the calling method

The first parameter of the onreturn method is the return value of the calling method, and the rest are the parameters of the calling method.

The first parameter of the onthrow method is the call exception, and the rest are the parameters of the calling method.

In the above configuration, the sayHello method is called synchronously, so the execution of the event notification method is also synchronous. You can configure async=true to make the method call asynchronous, so that the method notified by the event is also executed asynchronously. In particular, oninvoke methods are executed synchronously, whether called asynchronously or not.

Does Dubbo support distributed transactions?

It is not supported at present, and may be implemented based on JTA/XA specification in the future.

Dubbo service downgrade (supported by version 2.2.0 and above)

Through the service degradation feature, you can temporarily block a non-critical service with an error, and define the return policy after the downgrade.

Write dynamic configuration override rules to the registry:

RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader (RegistryFactory.class). GetAdaptiveExtension ()

Registry registry = registryFactory.getRegistry (URL.valueOf ("zookeeper://10.20.153.10:2181"))

Registry.register (URL.valueOf ("override://0.0.0.0/com.foo.BarService? category=configurators&dynamic=false&application=foo&mock=force:return+null"))

Where:

Mock=force:return+null means that all method calls to the service by the consumer directly return the null value and do not initiate remote calls. Used to shield the impact on the caller when an unimportant service is unavailable.

It can also be changed to mock=fail:return+null to indicate that the consumer's method call to the service returns a null value without throwing an exception after a failure. Used to tolerate the impact on callers when unimportant services are unstable.

How does Dubbo stop gracefully?

Dubbo does graceful downtime through JDK's ShutdownHook, so if you use a forced shutdown instruction such as kill-9 PID, graceful downtime will not be performed, only through kill PID.

Service provider: when it stops, it is marked not to receive a new request, and when the new request comes, it directly reports an error and asks the client to retry other machines. Then, it detects whether the thread in the thread pool is running, and if so, waits for all threads to complete, and forces it to shut down unless it times out.

Service consumer: when stopped, no new invocation requests are made, and all new calls are reported as errors on the client side. Then, check to see if the response to the request has not been returned, wait for the response to return, and force it to close unless it times out.

What is the principle that the service provider of Dubbo can implement failure kick-out?

Service failure kick-out is based on the temporary node principle of Zookeeper.

The nodes in zk are divided into temporary nodes and permanent nodes. The type of nodes is determined at the time of creation and cannot be changed.

Temporary nodes for ZooKeeper: the life cycle of this node depends on the session in which they were created. Once the session ends, the temporary node is automatically deleted, either manually or manually. In addition, it should be noted that temporary nodes of ZooKeeper are not allowed to have child nodes.

Permanent node of ZooKeeper: the life cycle of this node does not depend on the session, and they can be deleted only if the client shows that the delete operation is performed.

In distributed systems, we often need to know whether a certain machine is available. In traditional development, it can be achieved by Ping a host, and Ping means that the other side is available, on the contrary, it is not available.

In ZK, we let all machines register a temporary node. To determine whether a node is available, we only need to determine whether the temporary node exists in ZK. We do not need to directly connect to the machines that need to be checked, thus reducing the complexity of the system.

What is the fault tolerance strategy recommended by Dubbo services for reading and writing?

For read operations, it is recommended to use Failover to automatically switch if it fails, and retry other servers twice by default.

It is recommended to use Failfast for write operations to fail quickly. If a call fails, an error will be reported immediately.

How to solve the problem that the service call chain is too long?

Dubbo can use Pinpoint and Apache Skywalking (Incubator) for distributed service tracking, as well as many other scenarios.

What can the administrative console of Dubbo do?

The management console mainly includes: routing rules, dynamic configuration, service degradation, access control, weight adjustment, load balancing, and other management functions.

At this point, I believe you have a deeper understanding of the "summary of important knowledge points of dubbo". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.