Why RPC Beats HTTP for Enterprise Services – Architecture, Sync/Async, Top Frameworks

For a long time I hadn't clearly distinguished RPC (Remote Procedure Call) from HTTP calls, assuming both simply involve writing a service and invoking it from a client.

OSI Network Seven‑Layer Model

Before comparing RPC and HTTP, it helps to understand the OSI model, which traditionally has seven layers (often simplified to five). The key layers for our discussion are the Application layer (HTTP) and the Transport layer (TCP).

Layer 1: Application – defines interfaces for communication and data transfer.

Layer 2: Presentation – defines data format, encoding, and decoding.

Layer 3: Session – manages user sessions and logical connections.

Layer 4: Transport – handles end‑to‑end data transmission.

Layer 5: Network – defines how data moves between devices.

Layer 6: Data Link – packages network‑layer packets into frames.

Layer 7: Physical – transmits binary data.

In practice, the Presentation and Session layers are often merged with the Application layer, so we focus on the Application (HTTP) and Transport (TCP) layers.

RPC Services

We examine RPC from three angles: its architecture, synchronous vs. asynchronous invocation, and popular RPC frameworks.

RPC Architecture

A typical RPC system consists of four core components: Client, Server, Client Stub, and Server Stub.

Client – the caller of the service.

Server – the actual service provider.

Client Stub – stores the server address, packages request parameters into a network message, and sends it remotely.

Server Stub – receives the message, unpacks it, and invokes the local method.

RPC is widely used in large enterprises where many subsystems and complex business lines demand high efficiency. Projects typically manage dependencies with Maven, package interfaces into JARs, and share these JARs between client and server to reduce client size and improve decoupling.

Synchronous vs. Asynchronous Calls

Synchronous calls block the client until the server returns a result, while asynchronous calls allow the client to continue processing and receive the result later via callbacks or futures. In Java, this corresponds to using Callable with Future for asynchronous results, or Runnable when the result is ignored.

Popular RPC Frameworks

gRPC – an open‑source framework from Google built on HTTP/2, supporting many languages and using Netty under the hood.

Thrift – a Facebook project offering a cross‑language service framework with an IDL code generator.

Dubbo – Alibaba’s widely adopted RPC framework with pluggable protocols and serialization, integrated with Spring; internally many teams now prefer HSF (Good‑Comfort Service).

HTTP Services

HTTP (often RESTful) is the traditional approach for building service interfaces, suitable for small projects with few APIs. Developers write endpoints, document request methods, parameters, and responses, typically returning JSON or XML.

For large enterprises with many subsystems, RPC offers advantages such as persistent connections (reducing handshake overhead), built‑in service registries, rich monitoring, and seamless deployment, which HTTP lacks.

Conclusion

RPC services are generally better suited for large‑scale enterprise systems due to higher efficiency, while HTTP services excel in rapid development for smaller projects. The choice should be based on a thorough evaluation of project requirements rather than simply following market trends.