Understanding RPC Frameworks: Concepts, Architecture, and Common Implementations

Interview Question 1: Explain Your Understanding of RPC Frameworks

RPC (Remote Procedure Call) is a common communication method in distributed systems that lets a program invoke a function or method on a remote machine without the programmer having to handle the low‑level network details.

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

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

In plain terms

RPC allows a client on one machine to call a function or method on a server machine and receive the result, hiding socket or HTTP communication details.

The client sends a request, the server returns a response, and the call feels 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 functions.

Consumer: The service that calls remote functions.

Registry: The service‑discovery component.

The diagram shows two servers, A and B. When an application on A wants to invoke a method on B, it must express the call semantics and transmit data over the network because they do not share memory.

Example method signature:

Employee getEmployeeByName(String fullName)

The RPC call proceeds through four main steps:

1. Establish Communication

The client and server first create 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 target host/IP, port, and method name. Service discovery mechanisms such as Redis or Zookeeper are often used to register and locate services.

From the provider side, services register themselves with the registry on startup, deregister on shutdown, and send periodic heartbeats. From the consumer side, they subscribe to the registry, receive provider addresses, and update their view when providers go online or offline.

3. Network Transmission

Serialization : The request data (method name, parameters) is serialized into binary before being sent over TCP.

After serialization, the data is transmitted to the server.

Deserialization : The server deserializes the binary data back into objects, locates the target method (often via a dynamic proxy such as JDK proxy, CGLIB, or Javassist), and invokes it.

4. Service Invocation

The server executes the method, serializes the return value, sends it back over the network, and the client deserializes it to obtain the final result.

Interview Question 2: Common RPC Frameworks

Thrift: A cross‑language framework for building scalable services, supporting languages such as C++, Java, Python, PHP, Ruby, and many others.

Dubbo: A high‑performance Java RPC framework originally developed by Alibaba, offering NIO communication, dynamic routing, load balancing, fault tolerance, and service governance.

Spring Cloud: A suite of projects (Config, Netflix, Consul, etc.) that provide tools for building distributed systems and micro‑services, simplifying configuration, discovery, circuit breaking, routing, and more.

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

1. REST

Typically uses HTTP with JSON payloads, is simple to learn and fast, but offers lower security compared to other protocols.

2. SOAP

A heavyweight XML‑based protocol that includes WS‑Security for robust security features; it is widely supported across vendors.

Advantages: easy to use, flexible, language‑agnostic, and platform‑independent.

3. SOA

Service‑Oriented Architecture enables loosely coupled, coarse‑grained services to be deployed, composed, and used over a network. Services expose well‑defined interfaces and can be combined without exposing low‑level implementation details.