Shulou(Shulou.com)05/31 Report--

This article mainly explains "what are the core knowledge points of RPC". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what are the core knowledge points of RPC".

The full name of RPC is Remote Procedure Call, or remote procedure call, which corresponds to our local call.

Remote actually refers to the need for network communication, which can be understood as calling a method on a remote machine.

Then someone may say: I use HTTP call is not a remote call, isn't that also called RPC?

No, the purpose of RPC is to let us call remote methods as well as local methods.

Let's take a look at the code. For example, the method is written like this when there is no split service that is called locally:

Public String getSth (String str) {return yesService.get (str);}

If the yesSerivce is split, you need to call remotely at this time. If you use HTTP, it may be:

Public String getSth (String str) {RequestParam param = new RequestParam ();. Return HttpClient.get (url, param,.);}

At this point, you need to care about the address of the remote service, assemble the request, and so on, and if you use RPC call, that is:

Public String getSth (String str) {/ / looks no different from the previous call? Haha, I'm not bluffing you. / / the specific implementation has been moved to another service, where there are only interfaces. / / you'll know after reading the following. Return yesService.get (str);}

So RPC is actually used to shield the details related to the remote call network, make the remote call consistent with the local call, and make the development more efficient.

Now that we understand the role of RPC, let's take a look at the steps that RPC calls take.

RPC invocation basic process

In the above example, the yesService service implementation is moved to a remote service, and there is no local implementation but an interface.

So what should we do when we need to call yesService.get (str)?

All we have to do is inform the remote service of the passed-in parameters and the fully qualified name of the calling interface through network communication.

Then the remote service receives the parameter and the fully qualified name of the interface and can select the specific implementation and invoke it.

After the business is processed, and then return the results through the network, this is done!

The above actions are triggered by yesService.get (str).

But we know that yesService is an interface that is not implemented, so how did these operations come from?

It's through a dynamic agent.

RPC generates a proxy class for the interface, so what we call this interface is actually the dynamically generated proxy class, which triggers the remote call, so we are unaware of calling the remote interface.

Dynamic agents must be familiar to everyone, the most common is Spring's AOP, involving JDK dynamic agents and cglib.

Javassist is used in Dubbo, as to why it is used, Liang Fei has already written a blog explanation.

He compared JDK's native, ASM, CGLIB (based on ASM packaging), and Javassist.

After testing, Javassist is finally selected.

Liang Fei: finally decided to use the bytecode generation agent of JAVAASSIST. Although ASM is slightly faster, it is not an order of magnitude faster, and the bytecode generation method of JAVAASSIST is more convenient than ASM. JAVAASSIST only needs to concatenate the Java source code with a string to generate the corresponding bytecode, while ASM needs to write bytecode by hand.

You can see that performance is one thing when choosing a framework, and ease of use is also critical.

Back to RPC.

Now that we know that dynamic proxies mask the details of RPC calls, allowing users to invoke remote services without being aware of them, what are the details of invocation?

Serialization

Like our request parameters are all objects, sometimes defined DTO, sometimes Map, these objects cannot be transmitted directly in the network.

You can understand that the object is "three-dimensional", and the data transmitted by the network is "flat", which eventually needs to be converted into "flat" binary data to be transmitted in the network.

If you think about it, does it seem like a three-dimensional feeling that each object is allocated to different locations of memory and all kinds of references?

In the end, they all have to be transmitted to each other into a number composed of 01. Does the number composed of 01 look very "flat"?

The process of converting an object into binary data is called serialization, and the process of converting binary data into an object is called deserialization.

Of course, how to choose the serialization format is also important.

For example, the use of binary serialization format data is more compact, the use of text-based serialization format such as JSON is more readable, troubleshooting is more convenient.

There are many serialization options, which generally require a combination of generality, performance, readability, and compatibility.

I will not analyze it in this paper, and then I will write a special article to analyze various serialization protocols.

RPC protocol

Just mentioned that only binary data can be transmitted in the network, that pile of binary seems to be connected at the bottom, it doesn't care which data is requested by which one.

But the receiver needs to know, otherwise it will not be able to successfully restore the binary data to the corresponding requests.

So you need to define a protocol to agree on some specifications and set boundaries so that binary data can be restored.

For example, the following string of numbers according to different digits to identify the results are different.

So the protocol actually defines how to construct and parse the binary data.

Our parameters must be more complex than the above, because the length of the parameter value is variable, and the protocol often expands with upgrades, after all, sometimes some new features need to be added, then the protocol has to change.

Generally speaking, the RPC protocol adopts the way of protocol header + protocol body.

The protocol header puts some metadata, including: magic bit, version of the protocol, type of message, serialization method, overall length, header length, extension bit, etc.

The protocol body is to put the requested data.

Through the magic bit, we can know whether this is the agreement we agreed on, for example, the magic bit is fixed to 233, and we know at a glance that this is the 233 protocol.

Then the version of the protocol is for the subsequent upgrade of the protocol.

From the overall length and head length, we can know how many bits there are in the request, how many bits in the first bit are heads, and the rest are protocol bodies, so that the extended bits are reserved for future expansion.

Post the Dubbo protocol:

You can see that there are Magic bits, request ID, data length and so on.

Network transmission

When the data is assembled and ready to be sent, network transmission is involved.

Network communication is inseparable from the network IO model.

Network IO is divided into these four models, specific later write a separate article analysis, this article will not be developed.

Generally speaking, we use IO multiplexing, because most RPC call scenarios are highly concurrent calls, IO multiplexing can use fewer threads hold to hold a lot of requests.

In general, the RPC framework uses built wheels as the underlying communication framework.

For example, the Java language will use Netty, others have encapsulated very well, but also made a lot of optimization, ready-to-use, convenient and efficient.

Summary

The basic process of RPC communication is over. Take a look at the following figure:

There is no painting when the response is returned, but it is backwards anyway.

Let me sum it up with one more paragraph:

Service caller, interface-oriented programming, using dynamic proxy shielding the underlying call details to combine request parameters, interfaces and other data into binary data through serialization, and then through the RPC protocol encapsulation to use the network to transmit to the service provider.

The service provider parses the request data according to the agreed protocol, then deserializes the parameters, finds the specific calling interface, then executes the specific implementation, and then returns the result.

There are many details in this.

For example, requests are asynchronous, so each request will have a unique ID, and the returned result will be accompanied by a corresponding ID, so that the caller can find the corresponding request through ID and plug in the corresponding result.

Some people may ask why it is asynchronous, which is to improve throughput.

Of course, there are many details, which will be mentioned later in the analysis of Dubbo, combined with the actual experience of middleware will be more profound.

Real industrial grade RPC

The above mentioned is only the basic process of RPC, which is far from enough for industrial-level use.

The service providers in the production environment are all deployed in clusters, so there are multiple providers, and the machines will increase or decrease dynamically with the increase of traffic and other traffic conditions.

Therefore, a registry is needed as a service discovery.

Through the registry, the caller can know the meta-information such as the IP address of the service providers and make the call.

The caller can also learn from the registry that the service provider is offline.

It also needs a routing packet strategy, and the caller selects the corresponding service provider according to the routing information sent, which can realize the functions of packet call, grayscale release, traffic isolation and so on.

Also need a load balancing strategy, generally after route filtering, there are still multiple service providers can choose, through the load balancing strategy to achieve traffic balance.

Of course, there needs to be an exception retry, after all, the network is unstable, and sometimes a service provider may have some problems, so an error in a call to retry, less business loss.

Current-limiting circuit breakers are also needed, because the service provider does not know how many callers will be connected, nor the amount of each caller, so you need to measure the acceptance value of your own service to limit the current to prevent the service from collapsing.

The purpose of the circuit breaker is to prevent the failure of the downstream service from causing its own service call timeout blocking accumulation to collapse, especially the one with a long call chain, which has a great impact.

For example, A = > B = > C = > D = > E, and then E breaks down. You can see that the four ABCD services are waiting, and slowly they will collapse when the resources are full.

These are roughly the points mentioned above, but they can be refined, such as various policies of load balancing, whether traffic restrictions are limited by total traffic or specified by each caller, or adaptive traffic restrictions, and so on.

Thank you for your reading, these are the contents of "what are the core knowledge points of RPC". After the study of this article, I believe you have a deeper understanding of what the core knowledge points of RPC have, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.