Choosing a Microservice Gateway: Spring Cloud Gateway vs APISIX

The author, newly joined to a business unit without its own gateway, explains the need for a dedicated service gateway to handle IP blocking, URL redirection, rate limiting, tracing, and other cross‑cutting concerns that were previously managed manually on Nginx or by operations.

Motivated by frequent service abuse and the desire for a stable, production‑ready gateway, the author decided to build one and share the experience in a series of articles covering end‑to‑end gateway construction and common challenges such as service discovery, traffic limiting, circuit breaking, and tracing.

Gateway Middleware Selection

The two most well‑known open‑source gateway solutions considered are Spring Cloud Gateway and APISIX . Both provide routing, load balancing, canary releases, service circuit breaking, authentication, and observability, but they differ in language, ecosystem, and deployment model.

APISIX

APISIX is an Apache Cloud‑Native API gateway built on NGINX+Lua . It is designed for large‑scale, cloud‑native environments and supports being used as a K8s Ingress Controller . Its architecture includes a visual dashboard for routing configuration and a plugin system that supports Java, Go, Python, and other languages.

Key characteristics highlighted:

Cloud‑native: not written in Java, offering fast startup and low memory usage.

Kubernetes support: can fully manage request dispatching via the Ingress Controller.

High performance thanks to the NGINX+Lua stack.

The gateway also offers a plugin system where developers can write extensions in their preferred language, making it accessible even to teams not familiar with Lua.

Spring Cloud Gateway

Spring Cloud Gateway is a mature Java‑based gateway built on Spring WebFlux , which uses Project Reactor for asynchronous, non‑blocking processing. It inherits the robustness of the Spring ecosystem and integrates tightly with Spring Cloud Discovery, Sentinel for circuit breaking, and rate limiting.

Notable features include:

Based on Spring Framework 5, Project Reactor, and Spring Boot 2.0.

Rich routing predicates and filters that can match any request attribute.

Built‑in circuit breaker and rate‑limiting support.

Easy to write custom predicates and filters using the familiar Java programming model.

The implementation follows the responsibility‑chain pattern, similar to Spring Security, allowing filters to be added for extensibility.

Selection Criteria

The author weighs the two options against practical needs: performance, ease of onboarding, language familiarity, and operational overhead. While APISIX offers higher raw performance, its Lua‑based ecosystem introduces a learning curve and may require additional ops support.

Spring Cloud Gateway, being a pure Java project, aligns with the team’s existing skill set, provides sufficient performance, and grants full control over the codebase, leading the author to choose it for the current project.

Nevertheless, the author acknowledges that APISIX is an excellent choice for a company‑wide, NGINX‑replacing gateway due to its visual configuration and comprehensive feature set.

Conclusion

The article’s primary purpose is to share the author’s thought process in gateway selection and to familiarize readers with both Spring Cloud Gateway and APISIX. The next article in the series will dive into hands‑on implementation of Spring Cloud Gateway with Nacos for dynamic service discovery.