Reading Phoenix Architecture - History and knowledge of RPC

read 《 Phoenix Architecture 》- RPC History and knowledge

quote ： 《 Phoenix Architecture 》- Zhi-ming zhou

Access remote services

• The two processes exchange data , In computer science become IPC, at present IPC Technology has ：pipe The Conduit , Interrupt signal , Synchronous semaphore , Message queue , Shared memory ,IPC socket.
• RPC Regarded as a special IPC, In the early RPC Used in network communication , Transparent invocation features lead to abuse , Even questioned .
• Remote calls require extra attention than local calls ： Network reliability , bandwidth , Security , Extensibility , Maintenance and transmission costs .
• RPC As transparent as local calls, you have to pay for these problems .
• RPC It is business level communication ,IPC It is the bottom communication of the system , It is a mainstream view in the industry .
• 1981 Year of RPC The definition of call emphasizes RPC It is the process at the language level , Based on limited bandwidth , For transmitting control information .（ Environment and use ）
• Understand ,RPC Is to achieve transparent cross process control under limited conditions .
• RPC The problems that need to be solved can be summarized as “ According to the data ”“ To transmit data ”“ Representation ”. With webservice As an example , Corresponding “XML”“SOAP”“WSDL”
• If it is JSON-RPC The corresponding solution to the problem is “json”“HTTP”“JSON webservice agreement ”
• RPC The three problems to be solved are all cross platform
• Modern RPC The protocol has won top and bottom battles on cross platform and lightweight .
• webservice Not light enough , The reason is that the extension of his protocol stack contains too many complex things , Including the nature of things , Uniformity , event , notice , Security , Anti replay, etc .
• RPC The dilemma is to solve network and other problems transparently , And the agreement itself is light and simple .（ It's like asking 25 Year old you 10 Years of working experience ）
• Even now, this problem still plagues the industry （ therefore , Don't be too obsessed json-rpc and grpc La ）
• Based on this embarrassing fact ,RPC There are three popular genres “ object-oriented RMI”“ Performance oriented gRPC”“ Pursue simple json-rpc”
• Personal experience , Large scale selection gRPC type , Pursue agility json-rpc. as for RPC Network problems faced （ Security , thing , reliable , cost ） Just introduce other components to make up for it according to business trade-offs .
• Also because of the pursuit of portability , quite a lot RPC Not solved positively RPC Three questions （ The data shows , Communication mode , Methods described ）, Instead, the solution to the problem is made into an extension port , Users unplug as needed .
• therefore , We know a little , Various “ Load balancing , Service discovery , Observability ” And so on RPC Three problems in （ The data shows , Communication mode , Methods described ） It caused .
• Distributed systems do not have to be method oriented , That is to say, you don't have to go to the front RPC Three big questions .
• REST and RPC It's something different , It's hard to compare .
• REST The proposer is engaged in a lifetime web Of ,RPC The proposal of is to do system process communication . In essence, it is not a Tao .
• REST representational state transfer Medium “representational characterization ” It can be understood as hyper text Further abstraction of hypertext .
• REST It seems too simple , So that when dealing with complex business RPC It seems to be tied up .
• In the context of complex technology , Popular lightweight and customized design , Like lightweight RPC And Backend For Frontend The proposed .
• Gateway significance , Forward routing and reverse proxy .