Введение в API и Kong Gateway

1. Новые функциональные требования: интеграция данных между разнородными системами и обработка статистики

Недавно в сервис, за который я отвечаю, была добавлена новая функция. Она заключалась в том, чтобы напрямую забирать данные, распределенные по другим системам, обрабатывать их в соответствии с целями нашего сервиса и наглядно показывать статистические данные пользователям.

Для реализации этой функции существовали две ключевые задачи.

• Обеспечение надежности данных: необходимо было стабильно вызывать API других систем и интегрировать данные большого объема без потерь.

• Минимизация связности: была необходима структура с низкой связностью, чтобы минимизировать влияние изменений в других системах на наш сервис.

1.1 Почему именно Kong API Gateway? (принятие стандартов архитектуры компании)

Когда мы разрабатываем новые API-эндпоинты и проектируем коммуникацию с другими системами, наша команда решила использовать стандартную архитектурную политику компании — 'Kong API Gateway'.Использование уже хорошо созданной корпоративной инфраструктуры предоставляет мощные технические преимущества, выходящие за рамки простого соблюдения правил.

• Централизованное управление маршрутами: унификация точки входа новых эндпоинтов через Kong позволяет надежно поддерживать внешний интерфейс, даже если сервисы будут расширены или изменится структура внутренних URL.

• Делегирование общих функций: общие функции безопасности и управления API, такие как аутентификация, авторизация и ограничение запросов, можно делегировать экосистеме плагинов Kong, не реализуя их на уровне приложения, что позволяет сосредоточиться только на бизнес-логике (обработка данных и выполнение статистических расчетов).

• Мониторинг и контроль трафика: это было оптимальным выбором для централизованного мониторинга состояния входящего и исходящего трафика от других систем и обеспечения доступности.

В результате эта работа была"реализацией бизнес-логики по безопасному извлечению данных из других систем и их обработке в виде статистики"и"процессом плавного соединения с Kong Gateway, корпоративной стандартной архитектурой, для обеспечения надежной конечной точки сервиса"это было основным моментом.

2. Основные концепции Kong API Gateway и процесс настройки маршрутизации

2.1 Три ключевых объекта Kong, которые должен знать разработчик бэкэнда

Kong Gateway позволяет разработчикам интуитивно понимать сложные настройки прокси и маршрутизацииСлужба,Маршрут,ПотребительМы абстрагируем и управляем с помощью трех основных объектов (Entity). Давайте рассмотрим, как мы сопоставили эти концепции для реализации новой функции, с примерами.

[외부/타 시스템 요청] ──> [ Route (/api/v1/realtime-analytics) ]

                      │ (토큰 검증: Consumer 인증)
                      ▼
            [ Service (internal-stats-cluster) ] ──> [실제 백엔드 API]

1) Сервис (определение внутреннего сервиса)

• понятие: Kong передает трафик Фактическое бекенд-приложение (Upstream адрес)Это означает. На этом этапе настраиваются IP-адрес или домен физического сервера, политика тайм-аута и т.д.

• пример: Один из сервисов — это внутренний Spring Boot/Node сервер, который собирает данные из других систем и обрабатывает статистику (http://internal-stats-cluster.local).

2) Маршрут (определение внешней точки входа)

• концепция: внешние клиенты или другие системы Конечная точка (путь, домен, метод HTTP и т. д.), которую следует использовать для доступа к Kong GatewayЭто означает. Один Service может иметь несколько Route.

• пример: Внешняя система будет обращаться к открытому URL-адресу /api/v1/realtime-analytics для запроса статистики в реальном времени.

3) Потребитель (определение пользователя/целевой системы)

• Концепциязначит: тот, кто использует API(клиент, приложение или другая система)Kong может сопоставлять токены аутентификации на уровне Потребителя или устанавливать ограничения на трафик (Rate Limiting).

• Примерзначит: внешний 'система потребления данных (external-data-consumer)', которая вызывает API нашей системы для получения данных в реальном времени, регистрируется как Потребитель.

2.2 Архитектура сотрудничества по выпуску токенов на основе приложений и проверке на основе шлюза

Функция статистики в реальном времени была адаптирована для обеспечения безопасной передачи данных между гетерогенными системами в среде декларативной конфигурации (Declarative Configuration)."Выпуск токенов, ориентированный на логику бэкенда, и высокоскоростная проверка, ориентированная на шлюз"приняла гибридную архитектуру.

Точные бизнес-правила, такие как управление выпуском токенов и временем истечения,реализованы напрямую внутри логики бэкенд-приложенияи контролируются. С другой стороны, проверка действительности запросов API в реальном времени с уже выданными токенами происходит на передовом уровне слоя Kong Gateway (плагин JWT)структурировано для перехвата и выполнения.

Эта структура была архитектурным выбором для защиты ресурсов ЦП нашего бэкенд-системы, которые должны выполнять операции с большими объемами статистики в реальном времени, и максимизации доступности, выходящей за рамки простой удобства.

• Разделение интересов (Separation of Concerns)Правила бизнеса токенов определяются кастомной бизнес-логикой бэкенда, а фильтрация пакетов и проверка подписи на переднем крае сети выполняется Kong. Это позволяет бэкенду сосредоточиться исключительно на своей основной бизнес-логике, связанной с 'вычислением статистики и очисткой данных'.

• Цепочка доверия через общий секретный ключ (Shared Secret)Мы синхронизировали секретный ключ, используемый бэкендом для подписания токена, и ключ, используемый Kong Gateway для проверки подписи, чтобы реализовать сверхбыструю распределённую аутентификацию без дополнительных накладных расходов на каждую проверку тяжелого сервера аутентификации.

• Оптимизация ресурсов для статистики в реальном времениПоскольку Kong на первом уровне блокирует некорректные запросы с невалидными токенами на уровне 401 Unauthorized, нам удалось предотвратить бесполезные потери ресурсов бэкенд-приложения, выполняющего операции с большими объемами статистики.

3. Устранение неполадок: инфраструктура идеальна, но трафик пропал? (Отладка отсутствующих регистраций приложений)

3.1 Инфраструктура в порядке, но нет ответа от бэкенда

Завершив виртуальную декларативную настройку Kong Gateway и внедрив идеально работающий код API для токенов в реальном времени в соответствии с существующими внутренними методологическими указаниями и правилами логики, я был уверен, что все маршруты инфраструктуры должны прекрасно соединяться.

Но в момент, когда я запускаю тестирование end-to-end (E2E), вызывая конечные точки API через Kong в локальной среде разработки, вместо ожидаемых статистических результатов запросы исчезали по пути или не находили бэкенд.

[Запрос клиента] ──> [ Kong Gateway (пройдёт) ] ──> [ Бэкенд-приложение (потеря соединения) ]

Сначала я думал, что это связано с настройкой strip_path Kong, проблемами передачи заголовков или несоответствием общего секретного ключа, и сосредоточил свою отладку на логах инфраструктуры и контейнерной сети. Но Kong точно маршрутизировал пакеты к целевому серверу бэкенда. Проблема заключалась не в шлюзе, а ввнутри нашего бэкенд-приложения.было.

3.2 Анализ причин: Срок службы фреймворка и пропуск регистрации пустого объекта (Bean)

Причиной является, увы, самое основное и ключевое понятие бэкенда 'Недостаточная регистрация (Bean)'было.

Сосредоточив внимание исключительно на написании нового класса сервиса и логики обработчика/перехватчика токенов для обработки статистики в реальном времени в соответствии с архитектурными правилами и спецификациями фреймворка существующей внутренней системы, я упустил возможность зарегистрировать этот объект в контейнере инверсии управления (IoC) Spring, пропустив аннотации (например, @Service, @Component) или не указав его как компонент в файле конфигурации.

В момент запуска приложения контроллер или перехватчик указанного домена не загружаются корректно, поэтому, даже если Kong Gateway передает реальный трафик на правильный внутренний адрес, в слое приложения не существует контекста, который мог бы его принять, в результате чего запросы неизбежно теряются.

3.3 Решения и уроки

После выявления причины, новый класс бизнес-логики для очистки данных и статистических вычисленийУкажите недостающую аннотацию @Service, чтобы правильно зарегистрировать бин в контейнере IoCсделано.

//Example:Register the misiing bean annotation in the IoC container
@Service
Public class RealtimeStateProcessingServie implements StateServie {
   //Logic for collecting data from external systems and processing real-time statistics

}

Когда зависимость от внедрения (DI) была успешно реализована, я подтвердил, что при вызове тестового API в локальной среде трафик проходит через верификацию JWT Kong и без препятствий попадает в внутреннюю логику бэкенда.

Эта отладка еще раз напомнила мне о том, что даже если в области инфраструктуры (Kong Gateway) все каналы связи настроены идеально, для успешной работы огромной распределенной системы критически важно, чтобы основные компоненты сервера и управление их жизненным циклом были четко согласованы.

4. Заключение: Подводя итоги интеграции первого Kong Gateway, что мы узнали

Этот проект для меня 'Опыт эволюции бекенд-архитектуры с использованием уже разработанной корпоративной инфраструктуры'Это была значимая возможность, которую мне предоставили. Несмотря на то что в компании уже была настроена среда Kong Gateway, у меня не было возможности поработать с ней напрямую, поэтому процесс маршрутизации нового URL и интеграции токен-слоя был для меня новым и свежим испытанием.

В начале я просто думал о API Gateway как о "устройстве, которое подключает сетевые пути", но я смог ощутить, насколько мощным оружием оно может стать с точки зрения разработчика бэкенда.

• Который обрабатывает тяжелый слой проверки аутентификации, который должен был быть реализован непосредственно на сервере, на передовойЭффективная защита ресурсов CPU приложениямогли бы,

• Спасибо этому, я смог только очистить данные других систем и рассчитать точную статистику Сосредоточьтесь только на 'основной бизнес-логике'Я мог бы.

В процессе локального тестирования мы столкнулись с незначительными ошибками, такими как пропуск регистрации, но в результате этого процесса отладки мы смогли расширить наше понимание приложения с точки зрения инфраструктурной осведомленности.

Я также усвоил, что умелое использование мощной общей экосистемы плагинов, предоставляемой инфраструктурой, является ключевым навыком бэкенд-инженера. В различных новых функциях микросервисов, которые будут разрабатываться в будущем, я намерен активно комбинировать ресурсы внутреннего стандарта Kong Gateway для проектирования масштабируемой и надежной системной архитектуры.

kina.j