Understanding RPC Calls: Process, Components, and Performance Bottlenecks

RPC (Remote Procedure Call) enables invoking remote services as if they were local methods, distinct from HTTP which is a transport protocol.

The core components are client, server, and registry, covering service registration, discovery, routing, load balancing, serialization, and I/O models.

Common RPC frameworks include Dubbo, gRPC, Octo, Pigeon, Saf, and SofaRPC, each with different performance characteristics.

Part2: The Journey of a Single RPC Call

Illustrates the steps: stub, routing and load balancing, serialization/deserialization, encoding/decoding, and network transmission (typically Netty over TCP) using protocols such as Bolt, Dubbo, Hessian, Thrift, or RESTful.

Stub

Pre‑call processing like scenario judgment and data mocking.

Routing and Load Balancing

Routing selects the provider; load balancing algorithms (consistent hash, round‑robin, weighted, etc.) distribute requests.

Serialization

Various methods (JDK, Kryo, Hessian, ProtoStuff, Thrift, JSON) with notes on pitfalls of Hessian (property name collisions) and ProtoStuff (field order sensitivity).

Encoding

After serialization, encoding adds timeout, request ID, and protocol headers for efficient transmission.

Network Transmission

Most RPC uses Netty over TCP, with additional protocols like Bolt, Dubbo, Hessian, Thrift, or RESTful to abstract the transport layer.

Part3: Where RPC Latency Comes From

Client‑side latency = connection time + serialization time + waiting for server processing.

Server‑side latency = thread‑pool wait time + service processing time + result serialization time.

Optimization focuses on client routing, serialization choice, server thread‑pool sizing, deserialization, processing speed, and using asynchronous calls instead of synchronous blocking.

Part4: Summary

The article walks through an RPC call lifecycle, references open‑source frameworks, and highlights performance hotspots, offering practical guidance for backend developers.