RPC is not conceptually a protocol, nor does it belong to the category of communication;
is a programming technology, a code encapsulation that aims to improve the efficiency of code construction and maintenance.
RPC (Remote Procedure Call) encapsulates the communication process between processes (including cross-server) into a function call mode, hides the complex communication processing details, facilitates the use and simplifies the code, and enables the caller to call the processing provided by other processes as if it were a local function.
once we understand RPC as a code encapsulation technology, it is easy to understand why it seems that "more intranets are used" and "clients use less".
intranet is not the key. The key to
is that RPC adds coupling while simplifying the code.
if we define that two entities communicate over HTTP (or any other protocol), there is no problem as long as both parties follow the HTTP protocol and have nothing to do with their language implementation.
if it is RPC, then what we present to the outside is the function interface, which is related to the language and platform, and needs to provide the caller with function declaration files and link libraries.
when the coupling cost of our scenario is relatively high, for example, the service we build is provided to users outside the team or even outside the company, it is more troublesome to use RPC than to use HTTP directly-
We need to provide various versions to support users' platforms and languages.
even with a RPC framework that supports multiple languages, the framework (essentially a code base) is referenced and dependent on both sides, which is much heavier than using protocols directly.
obviously, what the subject sees is not the essence of "much interaction within the server inside the network". The essence is:
the internal interaction of the same system, because the same basic platform (or framework) can be used, so you can consider using RPC to encapsulate the communication process to improve the efficiency of code construction and maintenance, while most of the internal interactions of the system go through the intranet.
RPC is a protocol used for peer-to-peer communication. This kind of peer-to-peer communication not only refers to the communication between server and server, but also can be RPC (remote procedure call / remote method call) in a broad sense.
There are many ways of
RPC, common raw xxxRPC/SOAP/REST/Thrift/gRPC/ProtoBuf and so on, which can be divided into the following categories according to different usage scenarios:
- for the need for business decoupling;
- for cross-language or cross-platform needs;
- is the need for services, clustering, load balancing and scalability;
the selection and architecture design of RPC are not the same for different usage scenarios.
is it unnecessary for me to use rpc?
because I only have one server?
No, the interprocess communication of your operating system uses a lot of rpc technology, because when the software is complex to a certain extent, it needs to be decoupled by modules, so it is easy to upgrade and maintain separately, and it is convenient for team development.
does rpc want to be available for remote client-server communication?
Yes, http-rpc knows. To deal with today's micro-services is a similar concept, what needs to be done is to deal with security, and traffic management issues, these are ready-made solutions. The question is which technology is more suitable.
can rpc be cross-language?
of course, cross-platform and cross-language has long been invented. But if you serialize in the same language, it will obviously be more convenient, more efficient, and cheaper, as long as you don't have cross-language requirements.
