Design and Implementation of a Business API Gateway with Protocol Conversion and Service Orchestration

Preface As system scale and complexity increase, microservice architecture becomes mainstream, but it introduces duplicated code for cross‑cutting concerns such as authentication, logging, encryption, and rate limiting, and makes interface management difficult without a centralized solution.

Gateways address these issues by providing interface management, protocol adaptation, circuit breaking, and security features; however, enterprises also need protocol conversion and data aggregation, which many open‑source gateways lack.

1 Technical Selection

1.1 Solution Comparison

We evaluated three popular Java API‑gateway frameworks—Zuul 1, Zuul 2, and Spring Cloud Gateway—across thread model, protocol adaptation, circuit breaking, and service orchestration.

All three have clear strengths and weaknesses but lack Dubbo support and data aggregation, prompting us to develop a custom business gateway.

1.2 System Architecture

The architecture consists of three functional Filters (Inbound, Endpoint, Outbound) plus an Exception Filter, enabling modular, plug‑in‑style extensions without coupling.

2 Architecture Overview

Gateway layers include validation/interception (Inbound/Outbound Filters), core service dispatch (Endpoint Filter), and unified exception handling.

3 Innovations

3.1 Protocol Conversion

Internal services use Dubbo; the gateway must forward Dubbo calls. By scanning Maven‑coordinate JARs, the gateway automatically extracts method signatures, avoiding manual configuration.

All Dubbo References are managed centrally, allowing dynamic updates of timeout, version, etc., while keeping execution efficient.

3.2 Service Orchestration

Orchestration handles complex M:N dependencies, execution timing, data passing, and error handling. The gateway models dependencies as a directed acyclic graph, detects cycles, and uses a message‑bus‑driven approach for parallel execution without a central controller.

3.3 Embedded Gateway

To decouple frequently changing small downstream interfaces from stable main APIs, the core gateway capabilities are packaged as a JAR (configuration sync, orchestration, protocol conversion). Host services import this JAR and delegate downstream calls to the embedded gateway, eliminating the need to modify host code when small interfaces evolve.

4 High‑Availability Exploration

Key performance metrics include throughput, latency, error rate, and especially availability (the “nines”). The gateway implements multiple redundancy and failover mechanisms to achieve high availability.

5 Implementation Results

5.1 Efficiency Gains

After deploying the gateway, development and testing effort decreased by roughly 27% across selected business lines, saving significant person‑hours.

5.2 Fault Handling

The gateway’s data‑adjustment capability enables rapid recovery from data‑related failures. Example fault cases are illustrated below.

6 Typical Cases

1. Pure pass‑through interface – Configure downstream service in the portal; no code changes needed when downstream adds fields.

2. Data aggregation for a new dimension – Add a downstream service in the portal; results are merged automatically.

3. Cross‑origin handling for touch interface – Add /gw location under the touch domain; gateway handles CORS and JSONP with XSS protection.

4. Hotel list enrichment – Define two downstream services; the second depends on the first’s output and loops over the list, with built‑in fallback.