Лекція 250: Розбір типових помилок при використанні API Gateway та Service Discovery

Спочатку уявіть аеропорт. У ньому є диспетчери (API Gateway), які керують відправленням і прибуттям літаків (запитів) і забезпечують, що вони потрапляють на потрібні злітно-посадкові смуги (мікросервіси). Але що, якщо в диспетчерів зламається зв'язок із літаками (сервіси стануть недоступними)? Або вони направляють літаки не на ті смуги (неправильні маршрути)? Або виникне плутанина, коли кілька літаків спрямовуються на одну смугу (перевантаження)?

API Gateway та Service Discovery, як і диспетчери в аеропорту, залежать від безлічі факторів, і найменша помилка може перерости в каскадну катастрофу. Розберемо найпоширеніші проблеми, з якими зіштовхуються розробники, і навчимося їх вирішувати.

ТОП-10 типових помилок при використанні API Gateway та Service Discovery

1. Неправильна маршрутизація запитів

Опис проблеми:
Ви налаштували API Gateway, прописали маршрути, але запити вперто не доходять до потрібного мікросервісу. Причиною може бути опечатка в конфігурації маршрутів або некоректний predicate.

Як уникнути:

• Використовуйте чіткі й логічні шляхи запитів. Наприклад, замість /api/v1/foo/bar пиши щось очевидне на кшталт /users/1/orders.
• Завжди тестуйте маршрути локально, використовуючи інструменти типу Postman або curl.
• Пам'ятайте про порядок predicate'ів: predicates у Spring Cloud Gateway обробляються в порядку їх вказування.

Приклад:

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

Перевірте: правильно вказаний шлях /users/**? Чи відповідатимуть запити за цим шляхом?

2. Проблеми з аутентифікацією та авторизацією

Опис проблеми:
Запити від клієнтів відкидаються, хоча ви впевнені, що вони мають проходити. Це може бути пов'язано з помилками в налаштуванні OAuth2, токенів або ролей доступу.

Як уникнути:

• Регулярно перевіряйте конфігурацію токенів і ролей користувачів. Якщо використовується JWT, переконайтеся в правильності підпису й терміні дії токенів.
• Не забувайте про тестування авторизації вручну або за допомогою автоматичних тестів.

Приклад:

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

Переконайтеся, що ролі (ADMIN, USER) коректно налаштовані в базі даних.

3. Відсутність балансування навантаження

Опис проблеми:
Система падає, бо один мікросервіс потерпає від лавини запитів, тоді як інші простають. Ви забули налаштувати балансування запитів.

Як уникнути:

• Використовуйте вбудовані стратегії балансування навантаження, які підтримує API Gateway. Наприклад, Round Robin, Random або Least Connections.
• Увімкніть моніторинг навантаження (наприклад, через Actuator) і коригуйте налаштування.

Приклад настройки балансування:

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

Перевірте: конфігурація uri: lb://service-name використовує балансування через Eureka.

4. Помилки в інтеграції з Eureka

Опис проблеми:
Мікросервіси не видимі в реєстрі Eureka або постійно зникають із нього.

Як уникнути:

• Перевірте мережеві налаштування між Eureka Server і клієнтом. Переконайтеся, що використовуються коректні адреси й порти.
• Переконайтеся, що всі мікросервіси відправляють heartbeat (сигнали про 'живість').

Приклад конфігурації клієнта Eureka:

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

У разі конфліктів адрес використовуйте prefer-ip-address: true.

5. Некоректна конфігурація CORS

Опис проблеми:
Запити з фронтенду блокуються, бо API Gateway не налаштований на підтримку крос-доменних запитів.

Як уникнути:

• Налаштуйте CORS в Gateway, щоб дозволити домени фронтенду.
• Переконайтеся, що дозволені методи (GET, POST) і заголовки вказані правильно.

Приклад:

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

6. Проблеми з моніторингом

Опис проблеми:
Складно визначити, де проблема — в API Gateway, мікросервісах чи в мережевому з'єднанні. Відсутні метрики та логування.

Як уникнути:

• Увімкніть логування запитів і відповідей в Gateway.
• Налаштуйте Actuator для моніторингу метрик і їхньої подальшої візуалізації в Grafana або Prometheus.

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

7. Проблеми з фільтрами

Опис проблеми:
Фільтри, додані в API Gateway, працюють некоректно або призводять до несподіваних помилок (наприклад, зміна тіла запиту ламає JSON-структуру).

Як уникнути:

• Тестуйте фільтри ізольовано.
• Пишіть власні фільтри тільки за необхідності, а для стандартних задач використовуйте вбудовані фільтри Spring Cloud Gateway.

Приклад фільтра для додавання заголовка:

@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. Відсутність fallback-механізмів

Опис проблеми:
Коли один із мікросервісів відмовляє, запити просто зависають. Клієнти отримують жахливе враження від роботи вашого додатка.

Як уникнути:

• Реалізуйте fallback-методи з використанням Resilience4j або Hystrix для обробки відмов.
• Повертайте дружні повідомлення про помилки.

@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. Постійна перереєстрація сервісів

Опис проблеми:
Eureka Server показує, що сервіси постійно то реєструються, то зникають (flapping).

Як уникнути:

• Перевірте конфігурацію таймаутів (eureka.instance.lease-expiration-duration-in-seconds), щоб зменшити частоту перереєстрацій.
• Переконайтеся, що heartbeat працює коректно.

10. Перевантаження API Gateway

Опис проблеми:
Величезний потік запитів перевантажує API Gateway, роблячи всю систему недоступною.

Як уникнути:

• Налаштуйте ліміт запитів (rate limiting) для API Gateway.
• Використовуйте горизонтальне масштабування.

Приклад настройки обмежень:

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

Підсумок

Конфігурація API Gateway і Service Discovery — це водночас мистецтво й інженерія. Помилки можуть здаватися дрібними, але мати катастрофічні наслідки. Щоб звести їх до мінімуму, тестуйте кожне налаштування і завжди плануйте відмовостійкість. Як розробники ви маєте бути трохи "параноїками" — і це нормально! Адже будь-яке непорозуміння в конфігурації може перетворитися на "падіння системи" на проді — а цього ніхто не хоче, правда?