1. What is RPC?

1.1 RPC concept

RPC, Remote Procedure Call, is a remote procedure call, as opposed to a local service call, which is LPC (Local Procedure Call). Local service calls are more commonly used. For example, internal programs in our application (note that this is a program, not a method, a program contains a method) call each other, which is a local procedure call, while a remote procedure call refers to calling a remote procedure locally. use.

The RPC framework is to help us call remote procedures locally as conveniently as calling local procedures.

1.2 The relationship between RPC and HTTP

To sum it up in one sentence:

RPC is a concept, and http is a protocol. You can think of http as an implementation of Rpc, or Rpc includes http. The reason why we say inclusion rather than equality is because Rpc also has many custom Tcp-based protocols, such as Dubbo, etc., and what we often call rpc refers to TCP-based custom protocols in addition to Http.

1.3 Thoughts on Rpc

There are many related articles about Rpc and Http on the Internet. When explaining the concept of RPC, many people will mention that it is a method of remote execution , and then directly conclude that RPC includes http. In fact, if you think according to this concept, you cannot actually conclude that Http is an implementation of Rpc. Because the method of http calling, from the user's perspective, is not to directly call its method, but to complete an http request in a certain way, and then hand it over to the local client for data transmission.

In contrast, if you have used related Rpc frameworks, such as Dubbo, you can directly call remote methods just like calling local methods. The HTTP calling method can be considered a service call , not a method.

I feel that the author of the article should have experience using RPC, so he is a bit preconceived. So what is the relationship between rpc and http? I also thought about it for a long time, and later found that we should start with the definition. Since we are discussing what Rpc is, how can we ignore the simplest definition.

Remote Procedure Call, which "Procedure"according to Google Translate has the following explanations: 程序、过程、步骤, not really 方法(Method). Rather,程序 it is inclusive 方法and includes at the same time 服务. Therefore, it is emphasized above that it is a procedure or process, not a method.

1.4 Rpc framework

The Rpc framework is to help us make it as simple as calling a local service when a local service calls a remote service. We don't need to care about its underlying implementation. We only need to configure the corresponding information, and the RPC framework will do these things for us. For example, in dubbo, we only need to configure the corresponding registration center and the method we want to call, and we can call the remote service in the same way as local call.

1.5 Summary

According to our review process above, it can be considered that Rpc is a concept with two main implementations, one is service invocation via http , and the other is method invocation via custom Tcp protocol , such as dubbo protocol. , of course, the general rpc framework also supports the http protocol. Of course, no matter which method is used, the transmission is ultimately carried out in Tcp/Udp mode.

2. Rpc framework

2.1 What is Dubbo

We mentioned above that the Rpc framework helps us call remote services as easily as calling local services. Dubbo is an RPC framework open sourced by Alibaba.

For example, when we want to call a remote method, we only need to configure the relevant configuration and then call it directly. Dubbo will help us handle the intermediate process.

/*
省略相关配置
*/

//将配置注册到spring
@Resource
private QueryPinService queryPinService;

//直接使用远程方法，像调用本地服务一样简单
ueryPinService.getPinWithConfig(paramMap, null);

The overall architecture diagram of dubbo is as follows:

node	illustrate
Provider	Service provider that provides remote services
Registry	Registration center
Consumer	The service consumer that needs to call the remote service
Container	The container the service runs in
Monitor	monitoring Center

The working process is roughly as follows:

First, the service provider is started and then registers the services it can provide with the registration center.

The service consumer Consumer starts to subscribe to the registration center for the services it needs. Then the registration center notifies the consumer of the provider's metainformation. Afterwards, the consumer can select a provider through load balancing and call it directly because it has obtained the provider's address from the registration center .

If the service provider's metadata changes later, the registration center will push the changes to the service consumers .

Both service providers and consumers will record the number and time of calls in memory, and then send statistical data to the monitoring center regularly .

2.2 The difference between dubbo and spring cloud

First of all, both are currently mainstream microservice frameworks, but there are many differences between them:

The initial positioning is different: SpringCloud is positioned as a one-stop solution under the microservice architecture, mainly including gateway, registration center, configuration center, monitoring center, etc.; Dubbo is mainly focused on service invocation and governance, in which service invocation is more At its core.
Different ecological environments: Spring Cloud relies on the Spring platform and has a more complete ecological system; while Dubbo only made RPC remote calls at the beginning, and the ecosystem was relatively scarce, but now it is gradually enriched.
Calling method: SpringCloud uses the Http protocol for remote calls, and the interface is generally Rest style, which is more flexible; Dubbo uses the Dubbo protocol, and the interface is generally Java's Service interface with a fixed format. However, Netty's NIO method is used when calling, and the performance is better.

Configuration of both components:

It is obvious that SpringCloud has a more complete configuration than dubbo and supports stronger functionality.

In comparison, SpringCloud is like a brand machine. All the internal configurations have been assembled for us. We only need to use it out of the box. Dubbo is more like an assembly machine. We need to choose the configuration ourselves. It only provides core computing power, while the display, power supply, etc. need to be assembled and debugged by ourselves.

From the user point of view, novices are more suitable for brand-name machines. With one-click operation, we can achieve the desired effect. Dubbo is more suitable for computer experts, who can assemble the components they want and use it more smoothly.

Author: JD Technology Korea Kai

Source: JD Cloud Developer Community Please indicate the source when reprinting

Brief analysis of Dubbo source code (1) - RPC framework and Dubbo | JD Cloud technical team