How We Built a Transparent Cross‑Network Dubbo Highway for Cloud‑Native Enterprises

Introduction

For companies that separate cloud platform and island networks, opening ports for cross‑network communication is costly and not fully controllable. A transparent cross‑network transport network with good top‑level design can balance business support, security, and operational cost.

Cross‑Network Data Transfer System Evolution

Initially, a Dubbo Filter forwarding solution enabled one‑way island‑to‑cloud data transfer. Later, point‑to‑point mesh solutions were added. In late 2022 these were consolidated into a “highway” architecture that standardises cross‑island communication and addresses pain points such as one‑way transfer, high whitelist‑opening cost, platform maintenance overhead, and lack of common features like auditing and tracing.

Highway Architecture

The highway consists of four logical modules: Business Web (data sender), Island Business Center (local virtual provider that forwards via HTTP to the cloud Dubbo gateway), Dubbo Gateway (receives HTTP, performs generic invocation of cloud provider), and Cloud Business Center (regular Dubbo provider). The transport uses an HTTP‑based tunnel that leaves the Dubbo protocol untouched on both ends, providing low‑intrusion for existing services.

Key nodes include a client SDK that offers routing without changing Dubbo usage, Dubbo outbound and inbound gateways that proxy traffic, and a unified gateway based on APISIX that can add authentication, auditing, and rate‑limiting.

Technical Challenges and Solutions

1. Client routing – original solutions lacked bidirectional routing and required a local provider. We introduced annotation‑based routing, configuration‑center routing, and thread‑local routing, all transparent to the user.

@DubboReference(check = false, parameters = {"ENV_SHANGHAI", "ALL"}) private DemoService demoService;

2. Dubbo address switching – we leveraged Dubbo’s built‑in route extension but had to fix issues such as incompatibility with Dubbo 2, NPEs, loss of version/group metadata, and retry anomalies. Patches were contributed to the Dubbo community via PRs.

void handleRequest(final ExchangeChannel channel, Request req) throws RemotingException { /* ... */ }

3. Outbound gateway – private protocols cannot be recognised by common load balancers, so we introduced an HTTP‑based tunnel and a central APISIX gateway to reduce whitelist complexity from O(n²) to O(n) and to provide unified observability.

4. Extensibility – Dubbo’s early decode stage offers few extension points. We added an ExceptionProcessor SPI that can wrap exceptions and trigger retry logic, and submitted it to dubbo‑spi‑extensions.

Future Plans

We will improve stability (resource isolation, QoS, automated instance replacement), add protocol support (HTTP/Grpc), enhance security (APISIX plugins for auth and audit), and simplify operations with automated configuration workflows. Long‑term we aim to support multiple languages (Go, Python), additional transport layers (MQ), and richer orchestration capabilities.