Understanding RPC Frameworks: Concepts, Architecture, and Common Implementations

Interview Question 1: What is your understanding of RPC frameworks?

RPC (Remote Procedure Call) is a common communication method in distributed systems that allows a program to invoke a function or method 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 multi-system data interaction solutions include distributed message queues, HTTP request calls, databases, and distributed caches.

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

Plain Explanation

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

RPC hides the underlying communication details, so developers do not need to handle sockets or HTTP directly.

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

Follow‑up 1: How does an RPC framework work?

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

Provider: the service that exposes functions.

Consumer: the client that calls the remote service.

Registry: the service registration and discovery center.

The overall process involves establishing a TCP connection, addressing the service, serializing parameters, transmitting them, deserializing on the server side, invoking the local method (often via a proxy), serializing the result, sending it back, and finally deserializing on the client side.

Key steps include:

1. Establish Communication : Create a TCP connection between the client and server, which can be short‑lived per call or a long‑lived connection shared by multiple calls.

2. Service Addressing : The client must know the server’s host/IP, port, and the method name; service discovery mechanisms such as Redis or Zookeeper are often used.

From the provider’s perspective, it registers itself with the registry on startup, deregisters on shutdown, and sends periodic heartbeats. From the consumer’s perspective, it subscribes to the registry, receives provider updates, and unsubscribes on shutdown.

3. Network Transmission : Parameters are serialized into binary form before being sent over the network, and the server deserializes them back into memory representations.

4. Service Invocation : The server invokes the target method (often via dynamic proxies such as JDK dynamic proxy, CGLIB, or Javassist), obtains the result, serializes it, and sends it back to the client, which then deserializes the result for further processing.

Interview Question 2: Common RPC Frameworks

Thrift : A cross‑language service development framework that supports many languages (C++, Java, Python, PHP, etc.) and provides code generation for efficient services.

Dubbo : A distributed service framework from Alibaba offering high‑performance NIO communication, dynamic service discovery, routing, load balancing, fault tolerance, and more.

Spring Cloud : A suite of projects (Config, Netflix, Consul, etc.) that simplify building distributed systems and microservices on top of Spring Boot.

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

REST : An HTTP‑based style that typically uses JSON, is simple to learn, highly efficient, but offers lower security.

SOAP : A heavyweight XML‑based protocol with extensive standards for security (WS‑Security) and is widely supported by vendors.

SOA : Service‑Oriented Architecture focuses on coarse‑grained, loosely coupled services that can be composed and deployed across a network, providing a higher‑level abstraction than simple B/S or Web Services.

RPC differs by providing a more direct, function‑call‑like interaction, often hiding transport details and allowing binary protocols for higher performance.