Implementing Internal/External API Isolation with Gateway, Redis Whitelist, and AOP in Java Microservices

When developing business services, you may encounter interfaces that must not be exposed externally and should only be called by internal services. This article reviews three feasible solutions and demonstrates a concrete implementation using Spring Cloud Gateway and AOP.

1. Internal/External Microservice Isolation

Place publicly exposed interfaces and internal‑only interfaces in two separate microservices. The public service exposes all external APIs, while the internal service aggregates APIs that are only callable within the intranet.

This adds an extra microservice for request forwarding, increasing system complexity, latency, and maintenance cost.

2. Gateway + Redis Whitelist Mechanism

Maintain a whitelist of allowed interfaces in Redis. When a request reaches the gateway, the gateway checks the whitelist; requests on the list are allowed, others are rejected.

Advantages: zero intrusion to business code, only whitelist maintenance required. Drawbacks: continuous operational overhead to keep the whitelist, possible need for ticket‑based Redis access, and added latency for every request.

3. Gateway + AOP

Instead of checking the whitelist at the gateway, embed the check in business services using AOP. The gateway adds a header (e.g., from=public) to external requests; services inspect this header and decide whether to allow the call.

This distributes access control to each service, removes the gateway bottleneck, and improves response speed, though it introduces some code intrusion that can be mitigated with annotations.

Specific Implementation (Solution 3)

First, add a header on the gateway side to mark external requests:

@Component
public class AuthFilter implements GlobalFilter, Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        return chain.filter(
            exchange.mutate().request(
                exchange.getRequest().mutate()
                    .header("id", "")
                    .header("from", "public")
                    .build())
            .build());
    }

    @Override
    public int getOrder() {
        return 0;
    }
}

Next, create an AOP aspect and annotation to enforce intranet‑only access:

@Aspect
@Component
@Slf4j
public class OnlyIntranetAccessAspect {
    @Pointcut("@within(org.openmmlab.platform.common.annotation.OnlyIntranetAccess)")
    public void onlyIntranetAccessOnClass() {}

    @Pointcut("@annotation(org.openmmlab.platform.common.annotation.OnlyIntranetAccess)")
    public void onlyIntranetAccessOnMethod() {}

    @Before(value = "onlyIntranetAccessOnMethod() || onlyIntranetAccessOnClass()")
    public void before() {
        HttpServletRequest hsr = ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest();
        String from = hsr.getHeader("from");
        if (!StringUtils.isEmpty(from) && "public".equals(from)) {
            log.error("This api is only allowed invoked by intranet source");
            throw new MMException(ReturnEnum.C_NETWORK_INTERNET_ACCESS_NOT_ALLOWED_ERROR);
        }
    }
}

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface OnlyIntranetAccess {}

Finally, annotate any API that must be intranet‑only:

@GetMapping("/role/add")
@OnlyIntranetAccess
public String onlyIntranetAccess() {
    return "该接口只允许内部服务调用";
}

The article concludes with a call to share the content and join the architecture community for further learning.