Today, some practical micro began to talk service, the first piece, RPC framework of principles and practice, why should get micro-service architecture, RPC framework to get it?
First, the demand for origin
One of the benefits of the service is not limited to the service provider to use what technology selection, enable large companies across teams decoupling technique, as shown below:
A service team to provide service in Europe, the European team of technical background is Java, Java can be used to realize services;
B service team to provide services in the Americas, the service can be implemented using C ++;
C is a Chinese service team to provide services, can be achieved with Go service;
Upstream of the caller and services, in accordance with the interface protocol to complete the call to the remote service.
But in fact, 99.9% of the limited size of the company's team, technical team size is limited, basically using the same set of technologies and systems to provide call services:
In this case, if there is no uniform service framework, RPC framework, various teams of service providers we need each implement a set of serialization, deserialization, network framework, connection pooling, transceiver thread, time-out processing, state and other "business of outside "repeat skilled labor, resulting in the overall inefficiency. Therefore, RPC unified framework to "outside business" said technical work centrally, the service of the primary problem.
In reaching [ "RPC using a unified framework," is this the right path] under the same premise, this article about a technology with a simple point and achieve common popular language RPC framework outlined expectations.
Two, RPC background and process
What is RPC (Remote Procedure Call Protocol), remote procedure call?
First look at what is a local function calls, when we wrote:
int result = Add(1, 2);
When this code, we know that we have passed the 1, 2, into two parameters, call the native code segment Add a function to obtain a result the parameters. In this case, the incoming data, outgoing data, code segment in the same process space, which is a local function call.
There is no way that we can call a cross-process (so called "remote", typical of this process deployed on another server) function do?
Most likely to think, two processes agreed a protocol format, the use of Socket Communications, to transmit to the Senate [] [] [out of which the function call parameters].
Protocol request packet is assumed that a stream of bytes 11 bytes:
(1) the first three bytes of fill function name
(2) intermediate the first 4 bytes fill parameter
(3) the end of the 4 bytes fill the second parameter
While the response packet may be designed protocol is a 4-byte byte stream:
That process results.
The caller code might become:
request = MakePacket(“add”, 1, 2);
SendRequest_ToService_B(request);
response = RecieveRespnse_FromService_B();
int result = unMakePacket(respnse);
Simple explanation:
(1) speaks incoming byte stream parameter becomes
(2) the byte stream sent to Service B
(3) receiving returns from the byte stream service B
(4) returns the bytes for outgoing rheological parameters
Service side code may become:
request = RecieveRequest();
args/function = unMakePacket(request);
result = Add(1, 2);
response = MakePacket(result);
SendResponse(response);
This process is also well understood:
(1) server receives the byte stream
(2) the byte transfer as a function of the parameter name
(3) function call to get local results
(4) The results are converted into a stream of bytes
(5) to send a byte stream to the caller
The process described above using a map, and the processing of step caller service side are very clear. What's the biggest problem with this process is it exist?
Answer: The caller too much trouble, every time the concern of many low-level details
(1) Reference to the conversion into byte stream, i.e. a sequence of the application layer protocol details
(2) socket transmission, i.e., network transmission protocol details
(3) socket accepts
(4) a flow-byte conversion parameters, i.e., the application layer protocol deserialization details
Can not call this layer does not care about the details of it?
Answer: Yes, RPC framework is to solve this problem, it allows the caller "like calling a local function as a remote function calls (service)."
Three, RPC framework duties
By the above discussion, RPC framework caller would like to shield various complexity, service providers also want to shield all kinds of complexity:
(1) the caller feels like to call local functions, like
(2) the service provider feels like to achieve as a local function to implement the service
So the whole RPC framework is divided into client and server part part, responsible for the entire non (1) (2) of the complexity of the various types of shielding, these complexities is the responsibility RPC framework.
Some further refinement, client-side and includes: serialization, deserialization, connection pool management, load balancing, failover, queue management, overtime management, asynchronous management and so much more responsibility.
end server comprising: a server component, the server send and receive packet queue, IO thread, the worker thread, the sequence deserialization, context manager, managing a timeout, asynchronous callback functions, etc. and the like.
however, because of space limitations, these details do not do well under way