We can see some RPC frameworks, such as soap, yar, phprpc, and thrift. I don't know much about these things. What are the functions of RPC frameworks such as soap, yar, phprpc, and thrift. I don't know much about these things. What is the role?
Reply content:
We can see some RPC frameworks, such as soap, yar, phprpc, and thrift. I don't know much about these things. What is the role?
Answer the first question: what is the RPC framework? In a word, RPC is:Remote Call framework
What is "Remote Call "?
Generally, we call a method, for example, localAdd (10, 20). The specific implementation of the localAdd method is either defined by the user or stored in the library function of the language, that is to say, the code of the localAdd method is implemented locally, and it isLocal call!
"Remote call" means that the specific implementation of the called method is not in the local running, but somewhere else;
Remote Call Principle
For example, A calls the remoteAdd method provided by B :,
First, establish a tcp connection between A and B;
Then A serializes the name of the method to be called (remoteAdd here) and the method parameter (10, 20) into the word throttling and sends it out;
B accepts the byte stream sent by A and deserializes it to obtain the target method name and method parameter. Then, execute the corresponding method call (probably localAdd) and return the result 30;
- A accepts the remote call result
The RPC framework is nothing more than encapsulating all the details I just mentioned to expose simple and friendly APIs to users (ps: for some remote calls, select the underlying socket protocol, for some remote calls, select the upper-layer HTTP Protocol );
Benefits of remote call:
- Decoupling: when the method provider needs to modify the method, the caller is not aware of it and does not need to make any changes. This method is often used in cross-department and cross-company cooperation, in addition, the method provider is usually called the exposed party of the service.
Soap, yar, phprpc, and thrift have never been used, so it is hard to evaluate them.
The classic and popular RPC framework should be facebook's open-source thirft framework. Refer to the following blog
Talking about Facebook's server architecture
What is RPC (Remote Procedure Call )?
- To put it simply, RPC calls a function or method (collectively referred to as a service) on another machine (server) by passing parameters from one machine (client) and get the returned result.
- RPC hides the underlying communication details (Socket communication or Http Communication is not required)
- RPC is a request response model. When a client initiates a request, the server returns a response (similar to Http)
- RPC calls a remote function (or method) Just like calling a local function (or method ).
Development History of Remote Process calling
- Onc rpc (Remote process call for open network computing) and osf rpc (Remote process call by Open Software Foundation)
- Common Object Request Broker Architecture Common Object Request proxy Architecture)
- DCOM (Distributed Component Object Model), COM +
- Java RMI
- . NET Remoting
- XML-RPC, SOAP, Web Service
- PHPRPC, Hessian, JSON-RPC
- Microsoft WCF, WebAPI
- ZeroC Ice, Thrift, GRPC
- Hprose
Early RPC
- The first-generation RPC (onc rpc, osf rpc) does not support object transmission.
- CORBA is too complex and different implementations are incompatible. Generally, programmers are not familiar with it.
- DCOM and COM + cannot escape the palm of the hand of Windows.
- RMI can only be used in Java.
- . NET Remoting can only be used on. NET platforms.
XML-RPC, SOAP, WebService
- There are too many redundant data and the processing speed is too slow.
- RPC-style Web Services have poor cross-language performance, while Document-style Web services are too difficult to use.
- Web Service does not solve the real problems of users, but changes one problem to another.
- The Web Service Specification is too complex, so that there is no really useful implementation, or even no available implementation, beyond the. NET and Java platforms.
- Cross-language cross-platform is only a slogan of Web Services. Although many people are superstitious about this, it is not actually implemented.
PHPRPC
- Based on the built-in serialization format of PHP, there is a hard flaw in cross-language type ing.
- Communication depends on the HTTP protocol, and there is no other underlying communication method.
- Built-in encrypted transmission is both a feature and a disadvantage.
- Although it is faster than XML-based RPC, It is not fast enough.
Hessian
- The binary data format is completely unreadable.
- The official website only provides two half-language implementations (Java, ActionScript, and less-perfect Python implementations). Third-party implementations in other languages are not good.
- Not many languages are supported, and JavaScript on the Web Front-end is completely ignored.
- Although it is dynamic RPC, its dynamic performance is still poor.
- Although it is faster than XML-based RPC, It is not fast enough.
JSON-RPC
- JSON is readable and simpler than XML.
- JSON is restricted by a subset of JavaScript language, and there are not many data types that can be expressed.
- JSON format cannot represent self-reference, mutual reference, and cyclic reference in data.
- Some languages have multiple versions of implementation, but there is no uniform standard in the type of shadow, there is a compatibility problem.
- Although there are specifications of JSON-RPC, but there is no unified implementation. Different implementations in different languages have compatibility issues and cannot truly communicate with each other.
Microsoft WCF, WebAPI
- They are one of Microsoft's existing technologies.. NET Remoting, WebService, and REST-style services based on JSON, XML and other data formats.
- Although these services can be called outside of the. NET platform, they are totally different from the calls on the. NET platform. It does not provide any tools that can be used in languages of other platforms.
ZeroC Ice, Thrift, GRPC
- Cross-language object-oriented regression of the Early-generation RPC technology.
- You still need to write the type and interface definition in the intermediate language.
- You still need to use a code generator to translate the types and interface definitions written in the intermediate language into the client and server placeholder programs (stub) in your programming language ).
- You must write services independently based on the generated server code, rather than directly publishing existing code as a service.
- You must use the generated client code to call the service, without other more flexible methods.
- If your intermediate code is modified, you must repeat all the above steps at least.
Hprose
- No intrusive design, no need to define the type separately, no need to write services separately, existing code can be directly published as a service.
- It has rich data types and perfect cross-language type ing, and supports self-reference, mutual reference, and cyclic reference data.
- Supports multiple transmission modes, such as HTTP, TCP, and Websocket.
- The client provides more flexible calling methods, including synchronous calling, asynchronous calling, dynamic parameters, variable parameters, reference parameter transmission, and multi-result return (Golang, hprose 2.0 even supports pushing.
- With good scalability, various functional extensions such as encryption, compression, caching, and proxy can be implemented through filters and middleware.
- Compatible and non-differentiated cross-language calls
- Supports more common languages and platforms
- Support cross-origin calling on the browser side
- No intermediate language, no learning cost
- Superior performance, easy to use
The soap method is used in Web Services.
RPC is the abbreviation of Remote Procedure Call.
Procedure is an alternative way of writing functions. RPC is a function locally called on a remote server.
RPC has multiple protocols. SOAP is the RPC protocol of HTTP + XML base. Thrift is the binary RPC protocol.
The main purpose of RPC is to solve the problem of mutual calls between different languages. In a complex cluster, some servers run PHP, some servers run Python, some servers run C ++, and how do they transmit information to each other? This requires a convention: What are the requirements for a function name? What types of function parameters are supported? Is the int type variable 32bit unsigned or 16bit signed? Is the byte stream for communication between the server and the client big endian or little endian? These conventions are called RPC protocols.
What is the RPC framework? I really don't know. The first time I heard about it.
I am also drunk. What is the difference between this and API? API can also be more convenient to limit, RPC is of little significance to PHP
