dubbo related

The picture is good, http://study.163.com/course/introduction/1003828012.htm

Dubbo's default protocol uses a single long connection and NIO asynchronous communication. Of course, the client can configure the number of long connections established for each provider (the default configuration is 0, that is, a long connection is shared. For details, check DubboProtocol.java). In addition, in Transporters.java, you can see that the connection is established through Netty, Mina, and Grizzly.

 

Single long connection: In fact, there is only one long connection to do all operations. So how to deal with multi-threaded concurrent requests of the sender client? In fact, each thread encapsulates an object such as the request method, parameters, unique ID, etc., and then puts it in the ConcurentHashMap, puts the object in the request object and sends it to the server through a single connection, and locks the wait, that is, done.await(timeout, TimeUnit .MILLISECONDS). One connection can support 70Mbype network traffic.

Protocol: The default protocol, based on netty3.2.2+hessian3.2.1 interaction

Java extension implementation: very similar to the SPI mechanism, such as extending Filter, etc. For example, the interface AService has a default implementation of DefaultAService. If you want to implement customization, you can write a MyAService first, and put a file named com.alibaba.dubbo.xxx.A under META-INF. The content of the file is xxxAService=com.xxx .MyAService will do. Then the instance acquisition implementation class can be simply understood as reading the class specified by the configuration.

Container implementation: @SPI Ali custom annotation is used, and its subclass SpringContainer is an ioc container containing ClassPathXmlApplicationContext, which generates objects through ExtensionLoader. Among them are JettyContainer, Log4jContainer.

 

 

Source code:

Dubbo uses jetty nested at the bottom to report status.

dubbo-common Common logic modules, including Util classes and common models.

dubbo-remoting remote communication module, equivalent to the implementation of the Dubbo protocol, if the RPC uses the RMI protocol, this package is not required.

The dubbo-rpc remote call module, abstracting various protocols, and dynamic proxy, only includes one-to-one calls, and does not care about cluster management.

The dubbo-cluster cluster module disguises multiple service providers as one provider, including: load balancing, fault tolerance, routing, etc. The address list of the cluster can be statically configured or issued by the registry.

The dubbo-registry registry module, based on the clustering method of addresses issued by the registry, and the abstraction of various registries.

The dubbo-monitor monitoring module, which counts the number of service calls, the call time, and the service tracked by the call chain.

The dubbo-config configuration module is Dubbo's external API. Users can use Dubbo through Config to hide all the details of Dubbo.

The dubbo-container container module is a Standlone container that loads Spring Boot with a simple Main, because services usually do not need the features of web containers such as Tomcat/JBoss, so there is no need to use a web container to load services

 

Relationship Description:

Protocol: In RPC, Protocol is the core layer, that is, as long as there is Protocol + Invoker + Exporter, non-transparent RPC calls can be completed, and then Filter intercepts points on the main process of Invoker. Protocol is a remote service protocol interface. There are several specific implementations, such as DubboPrptpcpl, HttpProtocol, etc. Among them, Dubbo and RMI protocols are implemented based on TCP, and Hessian and WebService are implemented based on HTTP.

In remoting-http: In the same way for remoting-netty, there is a Map<Integer, HttpHandler>, the port number corresponds to the processor, and there are three types of HttpHandler (HessianProtocol, WebServiceProtocol, HttpProtocol). The Remoting implementation is the implementation of the Dubbo protocol. If you choose the RMI protocol, the entire Remoting will not be used. The Remoting is divided into the Transport transport layer and the Exchange information exchange layer. The Transport layer is only responsible for one-way message transmission. It is for Mina, Netty , Grizzly's abstraction, it can also extend UDP transport, and the Exchange layer encapsulates Request-Response semantics on top of the transport layer.

Cluster: Peripheral concept, so the purpose of Cluster is to disguise multiple Invokers as one Invoker, so that other people only need to pay attention to the Protocol layer Invoker. Adding or removing Cluster will not affect other layers, because there is only one provider When the cluster is not required.

Proxy layer: A transparent proxy that encapsulates all interfaces, while other layers are centered on Invoker. Only when it is exposed to users, can Proxy be used to convert Invoker into an interface, or the interface implementation into an Invoker, that is, to remove Proxy layer RPC can be run, but it is not so transparent, and it does not seem to adjust remote services like local services. Javassist and jdk dynamic proxy: JavassistProxyFactory, JdkProxyFactory two classes are very simple. Generate the client-side Stub and server-side Skeleton of the service.

 

 

Model:

Protocol is the service domain, it is the main function entry exposed and referenced by Invoker, and it is responsible for the life cycle management of Invoker

Invoker is the entity domain. It is the core model of Dubbo. Other models rely on it or convert it into it. It represents an executable body and can initiate an invoke call to it. It may be a local implementation, or it may be is a remote implementation, possibly a cluster implementation

Invocation is the session domain, which holds variables in the calling process, such as method names, parameters, etc.

 

in addition:

Dubbo handles the problem of TCP unpacking and sticking: due to the buffer size limitation of TCP packets, each request data may not be in one TCP packet, or the data of multiple requests may be in one TCP packet. NettyCodecAdapter is the entry point for dubbo protocol analysis, which contains two parts: decoder and encoder, and the unpacking and sticking of TCP is mainly the decoder part. The decoder in NettyCodecAdapter is implemented by InternalDecoder. Its parent class is Netty's SimpleChannelUpstreamHandler, which can accept all inbound messages, so it can decode the received messages. It needs to be explained here that there is a private InternalDecoder object for a certain Channel, not with other

Channel sharing, here to avoid concurrency problems.

Solving the problem of sticking and unpacking: http://blog.csdn.net/scythe666/article/details/51996268

1. The sender adds a packet header to each data packet. The header should contain at least the length of the data packet, so that the receiver can know the actual length of each data packet by reading the length field of the packet header after receiving the data. .

2. The sender encapsulates each data packet into a fixed length (if it is not enough, it can be filled with 0s), so that the receiving end will naturally split each data packet every time it reads fixed-length data from the receiving buffer. Come.

3. A boundary can be set between data packets, such as adding special symbols, so that the receiving end can split different data packets through this boundary.

 

 

Off topic: dubbo.jar package

 

Migration data tool kettle:

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326611953&siteId=291194637