Designing a “Highway” Architecture for Hybrid Cloud‑Native Data Sync with Dubbo

01 Project Background

The government procurement platform (similar to an e‑commerce site) operates a central cloud platform and multiple isolated "islands" (regional LANs such as Anhui or Shanxi). Data synchronization between cloud and islands is required for nationwide announcements and other cross‑region operations, exposing challenges in network connectivity, security policies, and management overhead.

02 Why “Highway”?

The new solution is called a “highway” because it aims to build a single, reusable transmission channel that can serve multiple routes, hide network complexity with a tunnel mechanism, and consider performance requirements when a shared link must handle traffic from many business units.

03 Implementation Practice

Key problems identified were:

Strong dependency on Dubbo.

Need for transparent transmission without altering existing Dubbo usage.

Flexible integration supporting other protocols such as HTTP.

Three Dubbo integration methods were evaluated:

Annotation method: Use @DubboReference with custom parameters to embed routing info, which the highway SDK intercepts and processes.

Configuration‑center method: Store routing parameters in a configuration service (e.g., Apollo); however, this approach was deemed unintuitive for newcomers.

Thread‑local method: Set routing info in the current thread; requires careful handling to avoid repeated code.

The “highway” architecture introduces a lightweight point‑to‑point network with reduced whitelist complexity. A central gateway opens a whitelist entry for a specific source‑destination pair, enabling direct traffic flow across six logical links. The core diagram shows how an APP in Shanxi routes to an APP in Shanghai via a Dubbo proxy, HTTP gateway, and generic invocation, preserving original Dubbo semantics.

A Dubbo Proxy aggregates connections, reduces long‑link pressure on the unified gateway, and consolidates security checks, making the system more scalable and easier to upgrade.

The tunnel mechanism wraps HTTP bodies, forwards them unchanged, and unwraps them at the destination, providing a transparent, protocol‑agnostic path that retains most Dubbo features while handling occasional token or network‑specific edge cases.

04 Future Planning

The roadmap follows a layered network architecture:

Physical layer: Streamline port opening and network provisioning.

Communication‑protocol layer: Accelerate HTTP forwarding (e.g., Triple over HTTP/2) and consider replacing HTTP with more efficient protocols.

Language layer: Explore GraalVM or Go for faster compilation and execution of high‑throughput gateway services.

Framework layer: Continue middleware enhancements.

General task scheduling & orchestration: Manage complex multi‑hop routing scenarios.

Custom task scheduling & orchestration.

Monitoring, alerting, observability.

Standards, processes, security.

The solution has already been adopted by many internal applications, becoming the unified approach for cross‑network government data exchange, and the team is collaborating with the Dubbo open‑source community to upstream customizations.