Distributed Systems 1.3: RPC (Remote Procedure Call)

Показать описание

Martin Kleppmann

Рекомендации по теме

Комментарии

I think you're great at explaining complex concepts in an accessible way. I've recently finished reading your book and I think it's amazing! It would be great if at some point you can put up more of the lectures that you do.

martinzokov

Thank you so much for making this awesome series of videos public! Thank you, a thousand times thank you!

iulisloizacarias

this is the best explanation of RPCs I've found! Thank you! From functions -> stubs -> marshalling it's much clearer now!

calmvolatility

Thanks for making the course videos public. Very much appreciated!

wildanzulfikar

to-the-point, very good explanation @Martin, many thanks for sharing.

hellosouvik

I been searching for this for many days...this helped me understand those API calls in Java

sanjayt

now RPC makes sense for me!
Thank you for your great explanations

codeboy

Appreciate these being public - I really enjoy the very practical examples and explanations to supplement my classes more theoretical lectures

AwesomAJ

Amazing how you explain complex concepts in a very simple a clear way! I couldn't understand RPC until you explain

geovanyteca

thank you so much for making this video public. That's really helpful.

yunni

Love from Pakistan... the best ever explanation of RPC on youtube... Martin you are freakin legend 👍👍

quonxinquonyi

Still trying to grasp this topic and your video improved my understanding significantly, examples and code are very important so thank you for this video!

michael.kushnir

Great video, just want to add some details.
RPC is a very broad topic and in fact it's relates to even more broader term API.

Nowadays the term is often used as synonym to gRPC and it's Protobuf IDL and binary Message Encoding and HTTP2 as transport protocol.
The term is used as oppose to REST API style where you acting with resources (i.e. a file) and using basic HTTP methods. The REST style looks great in books for basic CRUD (create, read, update, delete) but it's nightmare in practice. Almost all things are not "resources" but rather objects/services/actors. There is no any commonly used IDL and the HTTP methods can't cover all cases and users .
So for REST like APIs was created a separate IDL called Swagger/OpenAPI. You can describe a service in YAML file and then generate a client and documentation. This doesn't work ether because clients generation for each web framework and programming language is a goal that can't be fully achieved. The big problem here is interoperability.
The gRPC team instead just created a libraries/SDK for ALL languages so interop is good here (but still there some pitfalls).
Another architecture style that is not an RPC is a message bus, queue, Kafka streams, PubSub, CQRS, MQTT and others that are working in asynchronous or event based way.

Almost all RPC systems are built upon HTTP protocol but previously that often meant some kind of binary serialization and working upon raw TCP e.g. Java RMI, CORBA.
HTTP protocol wasn't developed to be used as a transport layer but it's well known for developers and many API gateways, proxies, load balancers and other software can be easily used. Also any developer can write at least basic API that uses HTTP.
Still it's important to remember because in many old books RPC meant some kind of binary protocol that works separately from HTTTP.

Interesting here is a Java RMI. You can expose any java class and call it from another computer. All parameters will be serialized by Java itself and no any additional IDL needed. But it had a lot of problems with compatibility because you may change order of fields and this may break the serialization. It was widely used for internal network calls and with JavaEE stack.

Brief history:
1. CORBA was used in early 90tes. Very complicated
2. JavaRMI. It's not used today but still a good solution for microservices written in Java
3. XML-RPC was first HTTP based protocol but it doesn't defined any IDL/schema
4. SOAP which is XML-RPC + WSDL schema. All enterprise and JavaEE based apps used it. This was a nightmare because XML is a bad serialization format. For example everyone serialized ditcs/maps in different way. Date format is also often was different.
5. "REST" in fact that means not a protocol but a style when HTTP is used not as a transport but as a supper protocol i.e. use GET/POST/PUT/DELETE methods, reuse HTTP status codes and JSON as a serialization format.
6. JSON-RPC similar to XML-RPC but with JSON as a serialization. It's not popular but used as a most simple and clear protocol.
7. gRPC is used mostly for internal interaction between microservices or for low latency APIs.
8. Cap’n Proto is also very interesting but not widely used

An IPC (Inter Process Communication) term is also related and means an RPC between two programs inside of one computer. Here are used COM/ActiveX on Windows, DBus in Linux and UBus in OpenWRT that are working upon a UNIX socket. And here is interesting that this internal RPC systems also can be exposed to a network via HTTP gateways. For example in OpenWrt the uhttpd web server can expose local UBus via JSON-RPC so can be called from outside.

Serialization formats are also can be very different: BSON, MessagePack, AVRO and even plain CSV is often a good solution. Choosing a good format may scientifically improve API speed

stokitko

Thanks for your sharing! I got the concept of RPC very long ago, but never understand what it exactly does and which case it is suitable to use. Your video answers all of my questions, thank you!

murphym