Token Transmission and Internal Service Call Strategies in Spring Boot Microservices

When first learning microservices, many online solutions use token transmission for authentication, but this approach mixes internal and external APIs, reduces statelessness, and lowers code reuse; instead, the gateway should parse the token, authenticate the user, and pass explicit parameters such as userId to downstream services.

To prevent exposing internal APIs to the public internet, define a path rule like /api/inside/** and reject such requests at the gateway layer.

Unified Authorization centralizes API authentication at the application gateway, which validates the token and forwards user information in request headers.

Feign Internal Call Method

Using Spring Cloud Gateway with Feign, the gateway adds authenticated information (e.g., userId ) to request headers for downstream services. The drawback is that each target service must implement a dedicated internal controller interface for Feign to call, increasing code volume.

Dubbo Internal Call Method

Spring Cloud Gateway with Dubbo also forwards authenticated data via headers, but it avoids extra controller interfaces; the local service calls a remote DubboService , resulting in cleaner code at the cost of slightly higher stack complexity.

Spring Boot Web + Dubbo Internal Call Method

This design removes the gateway, using a Spring Boot Web project (preferably with Undertow for non‑blocking I/O) to host all service controllers and perform unified authentication. Controllers can be modularized per service and integrated via dependencies, simplifying the architecture while sacrificing dynamic routing via configuration centers.

Non‑Unified Authorization

In this mode, each service handles its own authentication, optionally sharing a common library for consistency.

Regular Mode

A generic authentication module is added to each service, providing JWT token parsing, permission interception, and caching (local or Redis). This suits large teams where each microservice is owned by a separate group but follows shared permission rules.

Integration with Kubernetes

Replacing the application gateway with a K8s Ingress simplifies deployment; the Ingress forwards traffic to service pods, eliminating the need for a separate service registry. Services can be accessed directly via internal DNS names, e.g., http://goods-svc:8080/api/goods/info/10001 or dubbo://goods-svc:20880 .

Ultimately, there is no universally correct solution—choose the pattern that best fits your project's requirements.