Lección 250: Análisis de errores típicos al usar API Gateway y Service Discovery

Primero imagina un aeropuerto. Allí hay controladores (API Gateway) que gestionan las salidas y llegadas de los aviones (las solicitudes) y se aseguran de que lleguen a las pistas correctas (microservicios). Pero, ¿qué pasa si los controladores pierden la comunicación con los aviones (los servicios se vuelven inaccesibles)? ¿O si los dirigen a las pistas equivocadas (rutas incorrectas)? ¿O surge un lío cuando varios aviones intentan aterrizar en la misma pista (sobrecarga)?

API Gateway y Service Discovery, como los controladores en un aeropuerto, dependen de muchos factores, y el más mínimo fallo puede desencadenar un desastre en cascada. Vamos a ver los problemas más comunes que encuentran los desarrolladores y aprenderemos a solucionarlos.

Top-10 errores típicos al usar API Gateway y Service Discovery

1. Enrutamiento incorrecto de las solicitudes

Descripción del problema:
Has configurado el API Gateway y escrito las rutas, pero las solicitudes se niegan a llegar al microservicio correcto. Puede deberse a una errata en la configuración de rutas o a un predicado mal formado.

Cómo evitarlo:

• Usa rutas claras y lógicas. Por ejemplo, en vez de /api/v1/foo/bar escribe algo obvio como /users/1/orders.
• Siempre prueba las rutas localmente usando herramientas como Postman o curl.
• Recuerda el orden de los predicados: los predicados en Spring Cloud Gateway se procesan en el orden en que los declares.

Ejemplo:

spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: http://localhost:8081
          predicates:
            - Path=/users/**

Comprueba: ¿está bien indicado el path /users/**? ¿Responderán las solicitudes en esa ruta?

2. Problemas con la autenticación y autorización

Descripción del problema:
Las solicitudes de los clientes son rechazadas, aunque estás convencido de que deberían pasar. Puede estar relacionado con fallos en la configuración de OAuth2, tokens o roles de acceso.

Cómo evitarlo:

• Revisa periódicamente la configuración de tokens y los roles de los usuarios. Si usas JWT, asegúrate de que la firma y la fecha de expiración son correctas.
• No olvides probar la autorización manualmente o con tests automáticos.

Ejemplo:

@Bean
public SecurityWebFilterChain securityWebFilterChain(ServerHttpSecurity http) {
    return http.csrf().disable()
               .authorizeExchange()
               .pathMatchers("/admin/**").hasRole("ADMIN")
               .anyExchange().authenticated()
               .and().build();
}

Asegúrate de que los roles (ADMIN, USER) están configurados correctamente en la base de datos.

3. Falta de balanceo de carga

Descripción del problema:
El sistema se cae porque un microservicio sufre una avalancha de peticiones mientras otros están ociosos. Olvidaste configurar el balanceo de peticiones.

Cómo evitarlo:

• Usa las estrategias de balanceo que soporta el API Gateway. Por ejemplo, Round Robin, Random o Least Connections.
• Activa el monitorizado de carga (por ejemplo, con Actuator) y ajusta la configuración según sea necesario.

Ejemplo de configuración de balanceo:

spring:
  cloud:
    gateway:
      routes:
        - id: load-balanced-service
          uri: lb://user-service
          predicates:
            - Path=/users/**

Comprueba: la configuración uri: lb://service-name usa balanceo a través de Eureka.

4. Errores en la integración con Eureka

Descripción del problema:
Los microservicios no aparecen en el registro de Eureka o desaparecen constantemente.

Cómo evitarlo:

• Revisa la configuración de red entre Eureka Server y el cliente. Asegúrate de que las direcciones y puertos son correctos.
• Confirma que todos los microservicios envían heartbeat (señales de "vida").

Ejemplo de configuración del cliente Eureka:

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/
  instance:
    prefer-ip-address: true

En conflictos de direcciones usa prefer-ip-address: true.

5. Configuración incorrecta de CORS

Descripción del problema:
Las peticiones desde el frontend son bloqueadas porque el API Gateway no está configurado para soportar solicitudes cross-domain.

Cómo evitarlo:

• Configura CORS en el Gateway para permitir los dominios del frontend.
• Asegúrate de que los métodos permitidos (GET, POST) y los headers están bien especificados.

Ejemplo:

@Bean
public WebFluxConfigurer corsConfigurer() {
    return new WebFluxConfigurer() {
        @Override
        public void addCorsMappings(CorsRegistry registry) {
            registry.addMapping("/**")
                    .allowedOrigins("http://frontend.com")
                    .allowedMethods("GET", "POST");
        }
    };
}

6. Problemas con el monitorizado

Descripción del problema:
Es difícil saber dónde está el problema — si en el API Gateway, en los microservicios o en la red. No hay métricas ni logs suficientes.

Cómo evitarlo:

• Activa el logging de solicitudes y respuestas en el Gateway.
• Configura Actuator para recopilar métricas y visualízalas con Grafana o Prometheus.

logging:
  level:
    org.springframework.web: DEBUG
    org.springframework.cloud.gateway: DEBUG

7. Problemas con los filtros

Descripción del problema:
Los filtros añadidos en el API Gateway funcionan mal o provocan errores inesperados (por ejemplo, modificar el cuerpo de la solicitud rompe la estructura JSON).

Cómo evitarlo:

• Prueba los filtros de forma aislada.
• Escribe filtros personalizados solo cuando sea necesario; para tareas estándar usa los filtros incorporados de Spring Cloud Gateway.

Ejemplo de filtro para añadir un header:

@Bean
public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
    return builder.routes()
            .route("add_header_route", r -> r.path("/add-header")
                    .filters(f -> f.addRequestHeader("X-Custom-Header", "MyValue"))
                    .uri("http://example.com"))
            .build();
}

8. Falta de mecanismos de fallback

Descripción del problema:
Cuando uno de los microservicios falla, las solicitudes se quedan "colgadas". Los clientes se llevan una mala impresión de la aplicación.

Cómo evitarlo:

• Implementa métodos de fallback usando Resilience4j o Hystrix para manejar las caídas.
• Devuelve mensajes de error amigables.

@Bean
public RouteLocator fallbackRouteLocator(RouteLocatorBuilder builder) {
    return builder.routes()
            .route("fallback_route", r -> r.path("/service")
                    .filters(f -> f.fallbackHeaders()
                            .fallbackUri("forward:/fallback"))
                    .uri("lb://service"))
            .build();
    }
}

9. Re-registro constante de servicios

Descripción del problema:
Eureka Server muestra que los servicios se registran y desaparecen continuamente (flapping).

Cómo evitarlo:

• Revisa la configuración de timeouts (eureka.instance.lease-expiration-duration-in-seconds) para reducir la frecuencia de re-registros.
• Asegúrate de que el heartbeat funciona correctamente.

10. Sobrecarga del API Gateway

Descripción del problema:
Un flujo enorme de peticiones sobrecarga el API Gateway, dejando todo el sistema inaccesible.

Cómo evitarlo:

• Configura límites de peticiones (rate limiting) para el API Gateway.
• Usa escalado horizontal.

Ejemplo de configuración de límites:

spring:
  cloud:
    gateway:
      routes:
        - id: limited-route
          predicates:
            - Path=/limited
          filters:
            - name: RequestRateLimiter
              args:
                redis-rate-limiter.replenishRate: 5
                redis-rate-limiter.burstCapacity: 10

Conclusión

Configurar API Gateway y Service Discovery es al mismo tiempo un arte y una ingeniería. Los errores pueden parecer pequeños, pero tener consecuencias catastróficas. Para minimizarlos, prueba cada ajuste y siempre planifica la tolerancia a fallos. Como desarrollador, tienes que ser un poco "paranoico" — ¡y eso está bien! Cualquier malentendido en tu configuración puede convertirse en una "caída del sistema" en producción — y eso nadie lo quiere, ¿verdad?