Understanding RPC Frameworks: Concepts, Architecture, and Common Implementations

Author: 熬夜不加班 Link: https://www.jianshu.com/p/210c34970529

Interview Question 1: Explain Your Understanding of RPC Frameworks

RPC (Remote Procedure Call) is a common communication method in distributed systems that allows a program to invoke a procedure or function on another address space (typically another machine on a shared network) without the programmer having to code the remote call details.

Besides RPC, other common inter‑system data exchange solutions include distributed message queues, HTTP request calls, databases, and distributed caches.

Both RPC and HTTP calls are direct, end‑to‑end data interactions without middleware.

In Simple Terms

RPC is calling a function or method on a server machine from a client machine by passing parameters and receiving a result.

RPC hides the underlying communication details (no need to handle sockets or HTTP directly).

The client sends a request and the server returns a response, making the remote call look like a local function invocation.

Follow‑up 1: How Is an RPC Framework Implemented?

An RPC framework typically involves three roles: provider, consumer, and registry.

Provider: the service that exposes functionality.

Consumer: the service that invokes the remote functionality.

Registry: the service registration and discovery center.

The diagram shows that when an application on server A wants to call a method on server B, it must use the network to express the call semantics and transmit data because the two processes do not share memory.

Example: Server A calls Employee getEmployeeByName(String fullName) on server B.

The RPC call goes through several steps:

1. Establish Communication – usually a TCP connection, which can be short‑lived per call or a long‑lived connection shared by multiple calls.

2. Service Addressing – the client must know the host/IP, port, and method signature of the remote service; registries such as Redis or Zookeeper often provide discovery.

From the provider’s perspective, it registers itself with the registry on startup, deregisters on shutdown, and sends periodic heartbeats; the registry removes services that miss heartbeats.

From the consumer’s perspective, it subscribes to registry updates, obtains provider addresses, and reacts to provider online/offline events.

3. Network Transmission – Serialization: the method name and parameters are serialized into binary form for TCP transmission. Deserialization: the receiver converts the binary data back into in‑memory objects.

4. Service Invocation – The provider uses a proxy (e.g., JDK dynamic proxy, CGLIB, Javassist) to invoke the local method, obtains the return value, serializes it, sends it back, and the consumer deserializes it for further processing.

Interview Question 2: Common RPC Frameworks

Thrift – a cross‑language framework supporting C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml, etc.

Dubbo – a distributed service framework from Alibaba offering high‑performance NIO communication, dynamic routing, load balancing, fault tolerance, and service governance.

Spring Cloud – a suite of projects (Config, Netflix, Consul, etc.) that provide configuration management, service discovery, circuit breaking, intelligent routing, distributed locks, and more, built on Spring Boot for easy microservice development.

Interview Question 3: Differences Between RPC, SOA, SOAP, and REST

1. REST – An HTTP‑based style that typically uses JSON, is simple, low‑cost to learn, but offers lower security.

2. SOAP – A heavyweight XML‑based protocol with WS‑Security for robust security; it is flexible, cross‑language, and cross‑platform.

3. SOA – Service‑Oriented Architecture that enables loosely coupled, coarse‑grained services to be distributed, composed, and used across a network, providing a higher‑level abstraction over B/S models and XML/Web Services.