Core RPC principles of distributed architecture

In the iterative evolution of applications, as the system traffic increases, the Business complexity increases, and the Code complexity increases, the application gradually changes from a monolithic architecture to a service-oriented distributed architecture. RPC (Remote Procedure Call Protocol remote process call) is the core of the distributed architecture. There are two types of response methods:

Synchronous call: the client calls the service provider's method and waits until the service provider returns the result or times out.

Asynchronous call: the client sends messages to the middleware and directly continues its operations without waiting for the server to return.

Synchronous calling can be implemented through WebService and RMI. The services provided by Web Service are based on WEB containers, and the underlying layer uses http protocol, so they are suitable for calls between heterogeneous systems in different languages. RMI is actually an RPC implementation in the Java language. It allows methods to return Java objects and basic data types, and is suitable for calls between different systems built in the Java language.

The Java implementation version of asynchronous calling is JMS (Java Message Service). Currently, the open-source JMS middleware includes activemq and Kafka in the Apache community, and Alibaba rocketmq. Yesterday (November 28, 2016) alibaba has donated this component to the Apache Community fund.

The following describes the principle of RPC synchronous call. Simply put, an RPC architecture contains the following four components:

1. Client: Service caller

2. client stub: stores server address information, packs client request parameters into network messages, and sends them to the service provider through the network.

3. Server stub: receives and unpacks messages sent from the client, and then calls the local service.

4. SERVER: a real service provider.

The call sequence of these four components is shown below:

1. The service caller (client) calls the Service locally;

2. After receiving the call, client stub is responsible for assembling methods and parameters into a message body capable of network transmission. in Java, It is the serialization process.

3. client stub finds the service address and sends the message to the server over the network;

4. Server stub decodes the message after receiving it. in Java, It is the deserialization process;

5. Server stub calls the local service based on the decoding result;

6. Local Service Execution and processing logic;

7. The local service returns the result to the server stub;

8. Server stub packs the returned results into messages and serializes them in Java;

9. Server stub sends the packaged message over the network to the consumer.

10. The client stub receives and decodes the message, and deserializes the message in Java;

11. The service caller (client) obtains the final result.

The objective of the RPC framework is to encapsulate 2-10 steps and call, encoding, and decoding processes so that users can call remote services just like local services. To make the client (caller) Transparent, the RPC framework should consider solving the following problems:

1. How to publish services provided by the server and discover services by the client;

2. How to serialize and deserialize the request object and returned results;

3. How to make network communication more efficient.

The above problems have been well solved in some open-source RPC frameworks, such as Alibaba's Dubbo and Facebook's thrift. If you are interested, you can study these two frameworks in depth.

RPC is a must-use technique for every distributed application. This article only gives a rough description, hoping to help you and attract more people to realize the underlying technology.

Welcome to Java engineers who have worked for one or five years to join Java architecture development: 855801563

Free Java architecture learning materials (including high availability, high concurrency, high performance and distributed, JVM performance tuning, spring source code, mybatis, netty, redis, Kafka, MySQL, zookeeper, tomcat, docker, Dubbo, nginx, and other architectural materials with multiple knowledge points. You can learn and improve yourself by taking advantage of every minute and every second, do not use "no time" to hide your laziness! Work hard while you are young and give yourself an explanation of the future.

Core RPC principles of distributed architecture