Dubbo Fundamentals Mechanism

Transferred from: http://blog.csdn.net/paul_wei2008/article/details/19355681
distributed Service Framework:

– High-performance and transparent RPC remote service invocation scenario

–soa Service Management Solution

-apache MINA framework based on reactor model communication framework, based on TCP long connection

The Dubbo default protocol uses a single long connection and NIO asynchronous communication,

Service calls that are suitable for large concurrent small data volumes, and the number of service consumer machines is much larger than the number of service provider machines

Analyze the source code, the basic principle is as follows:

The client one thread calls the remote interface, generates a unique ID (such as a random string, uuid, etc.), and Dubbo is the package method invocation information (such as the calling interface name, method name, parameter value list, etc.) that will be used to accumulate numbers starting from 0 atomiclong. And the callback object that processed the result callback, all encapsulated together, forming an object to the global concurrenthashmap that specifically holds the call information inside put (ID, object) Encapsulates the ID and packaged method invocation information into an object connrequest, which is sent asynchronously using Iosession.write (connrequest) to attempt to obtain the result of a remote return using the callback's Get () method, inside the Get () , use synchronized to get the lock of the callback object callback, first to detect if the result has been obtained, if not, then call callback's Wait () method, release the lock on the callback, and leave the current thread in a wait state. After the server receives the request and processes, sends the result (the result contains the preceding ID, that is, the callback) to the client, the client socket connection on the special listener message received the message, parse the result, take the ID, and then from the previous concurrenthashmap inside get (ID), The callback is then found, and the result of the method invocation is set to the callback object. The listener thread then uses synchronized to get the lock of the callback object callback (because the previous call to wait (), that thread has freed the callback lock), and then Notifyall (), Wake up the thread that is waiting before continuing (the callback get () method continues execution to get the result of the call), at this point, the entire process is finished.      How the current thread makes it "paused," and so on, when the result comes back and executes backwards. A: Sir, as an object, obj, put (id,obj) in a global map, then use synchronized to get the obj lock, then call Obj.wait () to let the current thread wait, then another message listener thread wait until the service side results come up, Again Map.get (ID) finds obj, then uses synchronized to obtain the obj lock, and then calls Obj.notifyall () to wake up the thread in front of the waiting state.
As mentioned earlier, the socket communication is a full-duplex way, if there are multiple threads making remote method calls at the same time, there will be a lot of messages sent on the socket connection between client server, and the order may be messy,      After the server finishes processing the result, sends the result message to Client,client to receive a lot of messages, how to know which message result is which thread was originally called. A: Use an ID to make it unique, then pass it to the server, and then return it back to the server, so that the result is the original thread.