Understanding Service Gateways: Definition, Necessity, Architecture, and Technical Choices

1. What Is a Service Gateway

Service Gateway = Routing + Filters

Routing: receives all external requests and forwards them to backend micro‑services.

Filters: implement cross‑cutting concerns such as authentication, rate limiting, and monitoring; even routing itself is realized through filters.

2. Why a Service Gateway Is Needed

Cross‑cutting concerns (e.g., authentication) can be placed in three locations:

Implemented individually in each service (inefficient).

Implemented in a shared common service that every micro‑service depends on, which increases JAR size and makes upgrades difficult.

Implemented as a pre‑filter in the service gateway, allowing all requests to be checked centrally.

Placing authentication logic in the gateway avoids JAR bloat and simplifies updates, because only the gateway filter needs to be changed.

3. Service Gateway Technical Selection

The architecture after adding a gateway consists of three parts: the gateway, an open‑service, and downstream services.

3.1 Overall Flow

Gateway, open‑service, and services register themselves with a service registry at startup.

Clients send requests to the gateway, which performs intelligent routing (service discovery, load balancing) and applies authentication, monitoring, and rate‑limiting before forwarding to the open‑service.

The open‑service aggregates responses from internal services and returns them to the gateway, which then forwards them to the client.

3.2 Considerations When Introducing a Gateway

The extra hop introduces some performance overhead, but it is usually negligible because the gateway runs on powerful hardware and communicates over an internal network.

Gateway single‑point‑of‑failure can be mitigated by placing a high‑performance Nginx in front of the gateway or by scaling the gateway horizontally on robust machines.

The gateway should remain lightweight.

3.3 Basic Functions of a Service Gateway

Intelligent routing: forwards only external requests to the open‑service; internal service‑to‑service calls bypass the gateway.

Authentication: validates user requests to the open‑service; internal calls are not authenticated.

API monitoring: tracks requests passing through the gateway and its own performance metrics (e.g., GC).

Rate limiting: works together with monitoring to restrict traffic.

Unified API logging: records entry and exit logs similar to an aspect.

Additional capabilities (to be added later) such as A/B testing and traffic splitting.

3.4 Technical Stack Chosen by the Author

Programming language: Java + Groovy (Groovy enables dynamic filter addition without restarting the gateway).

Micro‑service framework: Spring Boot.

Gateway component: Netflix Zuul.

Service registry: Consul.

Authentication: JWT.

API monitoring: Prometheus + Grafana.

Log aggregation: Logback + ELK stack.

Load testing: JMeter.

Future articles will gradually cover each knowledge point and build a lightweight service gateway.