Introduction to RPC

In modern distributed systems and microservices architectures, applications are frequently decomposed into independent s

In modern distributed systems and microservices architectures, applications are frequently decomposed into independent services running across different machines or processes. To enable these decoupled components to collaborate seamlessly, a robust and efficient communication mechanism is essential. Remote Procedure Call (RPC) stands out as one of the fundamental technologies addressing this challenge.

This article explores the core concepts, working principles, and underlying mechanisms of RPC, while comparing it with alternative communication paradigms to help developers build a systematic understanding.
At its core, RPC is a communication protocol that allows a program running on one computer to execute a subroutine on another computer without the programmer needing to explicitly code the complex details of network interactions.

In a traditional monolithic application, invoking a function is straightforward—it simply requires calling the function name with the necessary arguments. However, in a distributed environment, when Service A needs to invoke a method on Service B across a network boundary, direct memory sharing is impossible. The primary philosophy of RPC is to make remote method invocation as transparent as local function calls.

Architecture and Core Components

To achieve this "transparency," an RPC framework abstracts away the intricacies of network programming. A standard RPC workflow typically involves several key components:

  1. Client: The service initiator that triggers the remote call.
  2. Client Stub: A local proxy holding the remote service's address information, responsible for packing the invocation parameters into a binary format suitable for network transmission.
  3. Network Layer: The underlying transport protocol (such as TCP, UDP, or HTTP/2) that carries data packets from the client to the server.
  4. Server Stub: The component on the receiving end that unpacks the network packet and reconstructs the parameters.
  5. Server: The actual service provider that executes the business logic and returns the resulting output back to the server stub.

The Complete Call Lifecycle

  1. The client invokes a local method provided by the Client Stub, mimicking a local execution.
  2. The Client Stub serializes the method name and arguments into a byte stream.
  3. The Client Stub transmits the byte stream over the network layer using protocols like TCP.
  4. The server-side Server Stub receives the byte stream and deserializes it back into the method name and parameters.
  5. The Server Stub invokes the actual business logic on the server.
  6. The server finishes execution and hands the result back to the Server Stub.
  7. The Server Stub serializes the result and sends it back across the network to the client.
  8. The Client Stub receives and deserializes the response, finally returning the result to the original client caller.

Key Technologies Behind RPC

Building a high-performance, production-ready RPC framework relies on several critical technological pillars:

  • Serialization and Deserialization:
    Because data transmitted over a network must be in binary format, choosing an efficient serialization protocol is vital. Common options include JSON, XML, Protocol Buffers (Protobuf), Thrift, and MessagePack. Formats like Protobuf and Thrift are widely adopted in high-performance RPC systems due to their compact message size and rapid serialization speed.
  • Transport Protocols:
    An RPC implementation can rely on customized private protocols built on top of TCP (such as Apache Dubbo), or leverage modern standards like HTTP/2 (such as gRPC). HTTP/2 introduces advanced features such as multiplexing and header compression, making HTTP/2-based RPC exceptionally performant.
  • Service Discovery:
    In dynamic microservice environments, service addresses change frequently. RPC frameworks typically integrate with service registries (such as ZooKeeper, Nacos, or Consul), allowing clients to dynamically resolve the actual IP addresses of target services using logical service names.

RPC vs. RESTful API

Developers new to distributed architectures often confuse RPC with HTTP-based RESTful APIs. Their fundamental differences lie in design philosophy, efficiency, and typical use cases:

  • Design Philosophy:
    • RESTful API: Resource-oriented, utilizing standard HTTP verbs (GET, POST, PUT, DELETE) to manipulate resources, emphasizing standardization and universal reach.
    • RPC: Action/Procedure-oriented, focusing on "what function is being called," closely resembling local function execution.
  • Performance and Efficiency:
    • RESTful APIs typically rely on text-based formats like JSON, resulting in larger payloads and slower parsing overhead.
    • RPC generally employs binary protocols (such as Protobuf), yielding smaller payloads, faster network transmission, and superior serialization efficiency, which suits high-frequency internal communication.
  • Use Cases:
    • RESTful APIs excel in external-facing architectures, such as web frontends, mobile-to-backend communication, and third-party developer platforms.
    • RPC is tailor-made for internal microservices within large-scale systems where latency and throughput are critical.

Rather than building an RPC mechanism from scratch, developers typically leverage mature open-source frameworks:

  • gRPC: A high-performance, open-source universal RPC framework developed by Google, built on HTTP/2, supporting multi-language environments and utilizing Protocol Buffers by default.
  • Dubbo: A high-performance Java-based RPC framework open-sourced by Alibaba, widely adopted in enterprise microservice ecosystems.
  • Thrift: A scalable cross-language software framework maintained by the Apache Software Foundation, ideal for building efficient multi-language services.
  • JSON-RPC: A lightweight, JSON-based remote procedure call protocol valued for its simplicity and ease of debugging.

Conclusion

As a foundational pillar of modern distributed systems, RPC dramatically simplifies the communication complexity between isolated services. By harmonizing serialization, network transport, and stub generation, it achieves the goal of transparent remote execution. Selecting the appropriate RPC framework—such as gRPC or Dubbo—tailored to specific business requirements can significantly elevate both system performance and development velocity in a microservices architecture.