Design and Implementation of an RxNetty‑Based API Gateway for Microservice Architectures

With the rise of micro‑services, an API gateway has become an indispensable entry point that consolidates common cross‑cutting concerns. The author, a senior architect, shares the design of their gateway, which sits at the north‑south traffic boundary and forwards requests to micro‑service or BFF applications.

The gateway is built on RxNetty, providing an asynchronous, reactive processing pipeline that achieves high concurrency on a single machine. Most functionalities reuse existing platforms: request dispatch and conditional routing rely on the micro‑service framework, rate‑limiting and circuit breaking on a customized Sentinel‑based stability platform, monitoring on a metrics platform, and security policies on a big‑data analysis platform. Service registration and configuration are handled by separate registry and config centers.

Request Dispatch – The gateway treats each micro‑service as a subscriber; it discovers services via the registry and constructs namespace objects based on URL prefixes. Dispatching then uses the existing framework’s routing and load‑balancing mechanisms.

Conditional Routing & Gray Release – Requests can be filtered by header, attribute, or traffic proportion and routed to specific instance groups (e.g., version‑based groups). The gateway creates Invoker objects for each service, each containing multiple Space objects representing groups; matching rules are evaluated by the micro‑service framework without additional code.

API Management – APIs are stored in a database; publishing actions from the control platform are pushed via the config center. A filter removes offline or deleted APIs before namespace matching, enabling hot updates.

Rate Limiting & Circuit Breaking – Implemented via a Sentinel‑derived stability platform. Rate limiting controls QPS, isolation limits concurrent requests, and circuit breaking triggers on error‑rate thresholds, with metrics exposed to Prometheus.

Security Policies – Basic protections against malicious traffic (e.g., crawlers) are configured manually or automatically via real‑time log analysis on a big‑data platform, which can generate blocking rules and alerts.

Monitoring & Alerting – The gateway exposes metrics, tracing, and logs through embedded SDKs. Alerts cover metric thresholds, error logs, and host‑level issues. A dual‑side alert mechanism notifies both gateway and downstream service owners when downstream failures occur.

Summary & Future Work – The gateway also supports WebSocket, multi‑cloud traffic scheduling, and plans to improve high‑concurrency testing, introduce a rule engine for dynamic policies, and extend security rule expressiveness (e.g., IP ranges, logical operators).