What Makes a Good RPC Protocol? Lessons from Dubbo’s Evolution to Dubbo 3.0

Fundamental RPC Protocol Concepts

An RPC protocol must define the serialization format, request/response semantics, and error handling so that client and server can interpret the same byte stream. Common serialization formats (JSON, Protobuf, Hessian, etc.) are evaluated on three dimensions:

Size of the serialized byte array

Serialization and deserialization speed

Human readability

Choosing a format involves trade‑offs between bandwidth, CPU cost and debuggability.

Protocol structures fall into two categories:

Compact protocols – only minimal metadata and payload are transmitted.

Composite protocols – carry additional framework metadata (e.g., RSocket) to provide richer features.

Typical request models include:

Synchronous Request/Response

Asynchronous Request/Response (allows multiplexing of concurrent calls on a single connection)

Streaming (multiple request/response messages within a single logical call, suitable for flow‑controlled data streams)

Comparison of Existing RPC Protocols

HTTP/1.1

Widely supported and language‑agnostic, but suffers from head‑of‑line blocking, verbose text headers, and a pure request/response model that lacks server push and true streaming.

RESP (Redis)

Simple text‑based protocol; shares HTTP/1.1’s performance drawbacks, has weak serialization capabilities, and limited Pub/Sub scalability.

Dubbo 2.0

Built directly on TCP, offering flexibility but resulting in a proprietary, tightly coupled protocol. The body contains extensible attachments, yet the header lacks similar extensibility, and the Java implementation includes redundant information (e.g., service name appears in both header and body).

HTTP/2.0

Introduces binary framing, header compression (HPACK), multiplexing, and native server push/streaming. These improvements solve many HTTP/1.1 issues but add complexity in flow control and header management.

gRPC

Uses HTTP/2 as transport and defines strict header and payload formats. Design goals:

Broad coverage and simplicity – runnable on constrained devices.

Interoperability – works across most network infrastructure.

General‑purpose performance – balances versatility and speed.

Payload agnostic – supports any language‑neutral payload (Protobuf for high performance, JSON for developer convenience).

Streaming – supports unary, client‑streaming, server‑streaming, and bidirectional streaming.

Flow control – built‑in back‑pressure.

Metadata exchange – allows auxiliary data outside the service definition.

gRPC’s reliance on Protobuf ensures consistent cross‑language serialization, while optional JSON eases debugging.

Design Goals of Dubbo 3.0 Protocol

Dubbo 3.0 extends gRPC to meet large‑scale distributed cluster requirements. Its primary objectives are:

More sophisticated load‑balancing to improve performance and stability.

Native support for tracing, monitoring, and smooth migration to micro‑service standards.

Reactive semantics at the protocol layer, providing back‑pressure and richer streaming capabilities.

Additional usability enhancements:

Dual IDL and annotation compilers for service definition.

Native asynchronous callbacks and Future‑style async APIs.

Non‑reflection server invocation to reduce overhead.

These changes aim to minimize migration effort while delivering significant throughput gains.