How dubbogo 3.0 Bridges Java and Go with gRPC‑Compatible Protocols

Background

Since its open‑source release in 2011, Dubbo has become the most popular RPC framework among Chinese enterprises. After a maintenance pause in 2014 and the rise of Spring Cloud, the ecosystem shifted toward cloud‑native technologies such as Docker, Kubernetes, gRPC, protobuf, and service‑mesh solutions like Envoy and Istio.

dubbogo 3.0 Mission

dubbogo aims to bridge Java and Go, keeping cross‑language interoperability while leveraging Go as the de‑facto cloud‑native language. The community’s 2020 roadmap focuses on three arrows: the released dubbogo v1.5 (aligned with Dubbo 2.7), the upcoming sidecar‑style dubbo‑go‑proxy project, and the in‑progress dubbogo 3.0.

Version Roadmap

Released dubbogo v1.5 (compatible with Dubbo 2.7)

Upcoming dubbo‑go‑proxy sidecar project

Ongoing development of dubbogo 3.0

New Communication Protocol

dubbogo 3.0’s communication layer draws heavily from gRPC. To be fully compatible, it must support gRPC’s HTTP/2 transport, protobuf serialization, and retain Dubbo’s service‑governance features such as mesh support and application‑level registration.

Three Compatibility Levels

Application‑level support: the framework wraps a third‑party SDK, offering limited extensibility.

Protocol‑level support: Dubbo provides configuration and governance, but relies on a fixed underlying transport, which can limit full compatibility (e.g., missing stream RPC support in dubbo‑go 1.5).

Transport‑level support: the framework implements the exact wire protocol (HTTP/2 frames, headers, data) to achieve maximal extensibility, such as adding back‑pressure strategies.

HTTP/2 Communication Flow

Client sends the HTTP/2 magic preface:

PRI * HTTP/2.0

SM

Server validates the preface.

Client and server exchange SETTINGS frames and ACKs.

Client sends a HEADERS frame containing gRPC‑specific fields, terminated by END_HEADERS.

Client sends a DATA frame with the RPC request, terminated by END_STREAM.

Server processes the request and produces a response.

Server sends a HEADERS frame with gRPC status fields, terminated by END_HEADERS.

Server sends a DATA frame with the RPC response.

Server sends a final HEADERS frame with RPC status and message, terminated by END_STREAM.

The same sequence is used by dubbogo 3.0 on top of HTTP/2 to guarantee seamless interaction with gRPC services.

Transport Model

dubbogo 3.0 adopts HTTP/2 as the transport protocol and introduces a new protobuf‑based “triple” protocol (dubbo3) for serialization, laying the groundwork for multi‑language support.

Supports both unary and streaming RPC by adding asynchronous data‑flow structures on client and server sides.

Retains existing TCP communication.

Decodes protobuf messages in a way that is compatible with gRPC, ensuring interoperability.

Application‑Level Service Registration

dubbogo 3.0 replaces the traditional interface‑level registration (Service → Instance) with an application‑level model (Application → Instance). This reduces the amount of data stored in the registry, lowers push pressure, and aligns data volume with the number of applications rather than the number of interfaces.

In production tests by Industrial and Commercial Bank of China, the new model reduced registry data to 1.68 % of the original size, allowing Zookeeper to handle up to 100 k services and nodes comfortably.

Metadata Synchronization

Because interface‑level data disappears in the new model, dubbogo 3.0 introduces a dedicated metadata channel between consumer and provider. Two implementation options are offered:

Built‑in MetadataService.

Separate metadata center that coordinates fine‑grained metadata clusters.

Routing Enhancements

Routing selects a subset of IP addresses from the full list based on configured rules, forming a routing chain where each router applies its own filter. The final address set is the intersection of all router outputs.

Routing Chain

Conceptually: target = rN(...r2(r1(src))). Each router splits the input address pool into mutually exclusive sub‑pools and returns the intersection defined by its rule.

Failover

If address lookup fails, the failover field triggers selection of an alternative subset and retries until a reachable address is found or an error is raised.

Fallback Routing

A catch‑all match rule without conditions guarantees that at least one subset is selected, providing protection against empty address sets.

Conclusion

dubbogo 3.0 brings a gRPC‑compatible communication stack, a lightweight application‑level registration model, flexible metadata synchronization, and advanced routing features, delivering a modern, cloud‑native experience for developers working with Java and Go services.