Design and Implementation of a Reactive API Gateway Based on RxNetty
This article details the architecture, core functions, and implementation techniques of a reactive API gateway built with RxNetty, covering request dispatch, conditional routing, API management, rate limiting, security policies, monitoring, and future optimization directions within a microservices environment.
With the rise of microservices, API gateways have become an indispensable component, serving as the sole entry point for external traffic while providing common cross‑cutting functionalities.
The overall architecture places the API gateway at the top, handling all north‑south traffic and routing requests downstream to microservice or BFF aggregation applications. The gateway is implemented with RxNetty, providing an asynchronous, reactive processing pipeline capable of high concurrency.
Key functions include request dispatch, conditional routing, API management, rate‑limiting/isolation, circuit‑breaker degradation, security policies, monitoring/alerting, and tracing.
Request Dispatch
The gateway treats each incoming URL as a dispatch key, normalizing it and mapping it to a namespace that corresponds to a specific microservice. Service discovery is leveraged from the existing microservice framework, allowing dynamic addition or removal of services via configuration updates.
Conditional Routing
Conditional routing enables traffic segmentation based on request content or traffic proportion, supporting gray releases, blue‑green deployments, and A/B testing. Rules are defined per application, often using a "version" label, and are evaluated by the microservice framework without additional development.
API Management
The gateway stores API metadata in a database; publishing actions from the control platform are pushed via the configuration center, and a filter removes unpublished or offline APIs during namespace matching. The UI supports bulk import, environment promotion, status filtering, and integration with DevOps pipelines.
Rate Limiting / Isolation & Circuit‑Breaker
Based on a customized Sentinel platform, the gateway enforces QPS limits, concurrency isolation, and error‑rate‑based circuit breaking. Rules are configured centrally and propagated to the gateway, which updates its in‑memory cache on the fly. Metrics are exposed via Prometheus for monitoring.
Security Policies
To mitigate malicious traffic such as web crawlers, the gateway offers configurable security rules based on client IP, user ID, headers, or attributes. Rules can be manually set or automatically generated by analyzing logs in a big‑data platform, with support for fast‑fail and CAPTCHA challenges.
Monitoring, Alerting & Tracing
The gateway integrates with a monitoring platform to expose Metrics, tracing data, and logs. Alerts can be triggered on metric thresholds, error logs, or host‑level issues. Dual‑side alerts notify both the gateway owner and the downstream service owner when failures originate from downstream services.
Summary and Future Work
The current implementation supports WebSocket, multi‑cloud traffic scheduling, and basic rate‑limiting, but high‑concurrency testing, rule‑engine integration, and richer security expressions remain open areas for improvement.
Original article: https://fredal.xin/build-api-gateway
IT Architects Alliance
Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.