See some frameworks about RPC such as Soap,yar,phprpc,thrift. Don't know much about these things, what's the role
Reply content:
See some frameworks about RPC such as Soap,yar,phprpc,thrift. Don't know much about these things, what's the role
Answer the first question: What is the RPC framework? If you summarize RPC in a nutshell: call the framework remotely
What is a "remote call"?
Usually we call a method, for example: Localadd (Ten), the implementation of the Localadd method is either the user's own definition, or exists in the library function of the language, it is said that the code of the Localadd method is implemented locally, it is a local call !
"Remote invocation" means that the specific implementation of the called method is not local to the program, but somewhere else;
Remote invocation principle
For example, the Remoteadd method provided by a call B:
First, a TCP connection is established between a and B;
Then a will call the method name (here is Remoteadd) as well as the method parameters (10, 20) serialized into a stream of bytes sent out;
B accepts a stream of bytes sent over a, then deserializes the target method name, method parameters, then executes the corresponding method call (possibly Localadd) and returns the result 30;
- A Accept Remote Call results
The RPC framework is nothing more than the details I just said to encapsulate, to the user exposed to simple and friendly API use (PS: Some remote calls to choose the lower socket protocol, some remote calls to compare the upper layer of the HTTP protocol);
Remote Invocation Benefits:
- Decoupling: When a method provider needs to implement modifications within a method, the caller is completely unaware and does not have to make any changes, which is often used in cross-sectoral, cross-company collaboration, and the provider of the method we often call: the exposed side of the service
As for the soap,yar,phprpc,thrift these things, one has not been used, so bad evaluation
The more classic and popular RPC framework should be Facebook's Open source THIRFT framework. You can refer to this blog post
On Facebook's server architecture
What is RPC (remote procedure Call)
- In a nutshell, RPC invokes a function or method (collectively referred to as a service) on the other machine (the server) on a machine (client), which is passed as a parameter, and results are returned.
- RPC hides the underlying communication details (no need to process socket or HTTP traffic directly)
- RPC is a request response model. The client initiates the request and the server returns a response (similar to how HTTP works)
- RPC calls a remote function (or method) as if it were called a local function (or method).
Remote Procedure Call development history
- ONC RPC (Remote procedure call for open Network Computing), OSF RPC (Open Software Foundation Remote Procedure Call)
- CORBA (Common object Request Broker Architecture public Object Solicitation broker 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 of RPC (ONC RPC,OSF RPC) does not support the delivery of objects.
- CORBA is too complex, a variety of different implementations are incompatible, the general programmer will not play.
- Dcom,com+ can't escape from the palm of Windows.
- RMI can only play in Java.
- . NET Remoting can only be played on the. NET platform.
Xml-rpc,soap,webservice
- Too much redundant data, too slow to process.
- RPC-style Web service is poorly cross-lingual, and Document-style Web service is too difficult to use.
- Web Service does not solve the user's real problem, it just turns one problem into another.
- The specification of Web Service is so complex that there is no really good implementation outside of the. NET and Java platforms, and even no implementations are available.
- Cross-language cross-platform is just a slogan for Web Service, although many people are superstitious about it, but in fact it doesn't really happen.
Phprpc
- Based on the PHP built-in serialization format, there is a mishap in cross-language type mapping.
- Communication relies on the HTTP protocol, there is no alternative to the underlying communication methods.
- The built-in encryption 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 non-readable.
- The official offers only two half-language implementations (Java,actionscript and less-than-perfect Python implementations), and third-party implementations in other languages are mixed.
- There are not enough supported languages to completely ignore JavaScript on the Web front-end.
- Although it is dynamic RPC, the dynamics are still poor.
- Although it is faster than XML-based RPC, it is not fast enough.
Json-rpc
- JSON is text-readable and more concise than XML.
- JSON is limited by a subset of the JavaScript language and can represent less than enough data types.
- The JSON format cannot represent self-references, cross-references, and circular references within the data.
- Some languages have implementations of multiple versions, but there is no uniform standard on type innuendo and there is a compatibility issue.
- Json-rpc Although there are norms, but there is no unified implementation. There is a compatibility problem with each implementation in different languages and cannot be truly interoperable.
Microsoft Wcf,webapi
- They are a unified package on a. NET platform for Microsoft's existing technology, a consolidation of. NET Remoting, WebService, and REST-style services based on data formats such as JSON, XML, and more.
- While it is claimed that these services can be invoked externally on the. NET platform, it is completely different from actually invoking it within the. NET Platform. It does not provide any tools that can be used in the languages of other platforms.
Zeroc ICE,THRIFT,GRPC
- The cross-language object-oriented regression of the first generation RPC technology.
- You still need to write type and interface definitions in intermediate languages.
- It is still necessary to use the code generator to translate the type and interface definitions written in the intermediate language into the client and server-side placeholder programs for the programming language you are using.
- You must write the service separately based on the generated server code, and you cannot publish the existing code directly as a service.
- You have to invoke the service with the generated client code, and there is no more flexible way.
- If your intermediate code is modified, you should repeat at least one of the above steps.
Hprose
- No intrusive design, no separate definition of the type, no need to write the service separately, the code can be published directly as a service.
- With a rich data type and perfect cross-language type mapping, support self-referencing, cross-referencing and circular reference data.
- Supports many modes of transmission, such as HTTP, TCP, Websocket, and so on.
- The client has a more flexible invocation mode, supports synchronous invocation, asynchronous invocation, dynamic parameters, variable parameters, reference parameter passing, multi-result return (Golang) and other linguistic features, Hprose 2.0 even supports push.
- It has good expansibility and can realize various functions such as encryption, compression, caching, proxy and so on through filter and middleware.
- Compatible, non-discriminatory, cross-language calls
- Support for more common languages and platforms
- Support for cross-domain calls on the browser side
- No intermediate language, no learning cost
- Excellent performance, easy to use
The way soap is used in Web Service.
RPC is the abbreviation for remote Procedure call
Procedure is the alternative notation of function, RPC is to call a function on the remote server locally, that's all.
RPC has multiple protocols. Soap is the RPC protocol for Http+xml base. The thrift is a binary RPC protocol.
The main purpose of RPC is to solve the problem of mutual invocation between different languages. A complex enough cluster, some servers run PHP, some servers run Python, some servers run C + +, how to pass information between each other? This requires a convention: What is the function name requirement? What type does the function parameter support? Is the variable of type int 32bit unsigned or 16bit signed? is the byte stream of communication between the server and client a big endian or a little endian? These conventions are called RPC protocols.
As for what is the RPC framework? This really doesn't know. The first time I heard.
I'm drunk too, what's the difference between this and the API? API can also be more convenient to make restrictions, RPC is not very important for PHP
