Зачем и где нужен API Gateway
Акманова ЕлизаветаСтарший аналитик ГК Юзтех
Елизавета Акманова, старший аналитик ГК Юзтех, снова на связи. Сегодня у меня в планах обсудить, зачем и где нужны API Gateway. Для этого верхнеуровнево пройдём по архитектуре этого паттерна, рассмотрим решаемые задачи. Ключевой вопрос на сегодня: Когда стоит использовать эту технологию? Это полезный инструмент но, увы, не всегда.
Что касается архитектуры, в самом её центре находится шлюз, который служит посредником между клиентами и бэк-сервисами. Это единая точка входа для всех клиентских запросов. Какими функциями он обладает?
Унификация
То есть предоставление единого интерфейса для всех сервисов. Это упрощает жизнь разработчикам, так как им не нужно разбираться с каждой отдельной интеграцией, все сервисы можно подключать по одному и тому же принципу.
Также все изменения и обновления можно применить централизованно, в одном месте.
Маршрутизация
В случае маршрутизации мы должны знать, что есть вот такие сервисы, у них вот такие url и работают по таким правилам. Здесь ещё подойдёт термин балансировка, когда мы знаем, что таких сервисов больше, чем один, и между ними хорошо было бы балансировать нагрузку.
Валидация
Валидация нужна для проверки в запросе всех необходимых параметров. Это помогает сразу отсеять неподходящие запросы и не тратить ресурсы на их обработку.
Авторизация и Аутентификация
Почему хорошо иметь аутентификацию в единой точке, в API Gateway? В этом предложении уже есть ответ на вопрос — единая точка. Сервисам больше не нужно думать об этом, у них есть это из коробки. То есть у нас идет проверка: можно ли этому инициатору запроса исполняться в бизнес-сервере или нет.
Трассировка запросов
В системе возможна логика, которая рискует перерасти в рекурсию. Это может быть нормальным с точки зрения бизнеса, но не нормальным с точки зрения жизни запроса. Важно помнить, что прохождение запроса должно иметь лимит: нельзя, чтобы запрос бесконечно гулял по экосистеме.
Логирование
Логирование позволяет отслеживать каждый запрос в системе. Когда происходит сбой, логи помогают понять, в каком звене цепочки он произошёл. Это значительно упрощает устранение проблемы и повышает надёжность системы, улучшает качество обслуживания и позволяет своевременно выявлять узкие места. Поэтому логирование — не просто формальность, а важный инструмент для стабильной работы системы.
Стандартизация
Каждый запрос нужно привести к единому стандарту. Представьте, что у нас разные клиенты присылают запросы с разными наборами данных, но наши сервисы ожидают определенный формат. API Gateway может автоматически отсеять ненужные данные. Или наоборот, добавить недостающие параметры: текущую дату или информацию о пользователе.
Протоколирование
В текущем мире существует множество протоколов. Если мы говорим об AGW как о возможности работать с любым API, то по-хорошему он должен уметь поддерживать разные протоколы.
Квотирование запросов
В случае, когда мы исчерпали лимит запросов к сервису, может быть 2 ситуации: мы прекращаем обслуживание, и это может быть нормально, но не для всех систем, либо мы просто замедляем входящий запрос. Оба варианта жизнеспособные, нужно смотреть на контекст. То есть квотирование помогает сделать так, чтобы сервисы не упали под нагрузкой.
Возвращаясь к нашей архитектуре, вот через такое сито функций проходит наш запрос:
Промежуточные выводы
Первое: не все функции являются обязательными. Поймите, какие важны для вас и как вы будете их использовать.
Основной плюс у AGW: меньше разработки. Представим, у вас есть определённое количество команд и каждая делает свою авторизацию. Естественно, она тратит на это время. Когда у вас появляется одна централизованная, команды об этом больше не задумываются и занимаются своим делом.
Это лучший контроль, особенно если у вас очень много сервисов, вы начинаете понимать, прикручивая логирование, трассировку, то, как у вас живут запросы, там появляются точки оптимизации.
Минусы AGW: это сложно. Многие знают про готовые решения, но в реальности они требуют доработки. Также этот паттерн сложно интегрировать в уже готовые системы, потому что внедрение потребует времени.
Когда использовать?
На этой ноте мы подходим к важному вопросу: когда действительно пора задуматься о том, что надо выделить команду и представить AGW.
Первая причина, которую я для себя выделила: когда проект разрастается до значительных масштабов. Становится неэффективно, чтобы каждая команда повторно разрабатывала одни и те же функции. Это и лишние усилия, и риск появления ошибок. API Gateway берёт эти задачи на себя.
Если у вас в системе огромное количество микросервисов, важно эффективно управлять их взаимодействием. API Gateway может помочь упорядочить и оптимизировать маршрутизацию запросов, централизованно управлять этим процессом.
Не всегда очевидно, но иногда использование API Gateway может быть экономически выгоднее, чем реализация проекта без него. Вместо разработки и поддержки отдельных решений для каждой задачи вы можете использовать API Gateway.
Когда не использовать?
Если ваш проект не отличается большим масштабом, API Gateway может быть излишним. В небольших проектах унификация функций не является критичной задачей, и добавление API Gateway только увеличит сложность и потребует дополнительных ресурсов на настройку и обслуживание.
Если ваш проект небольшой или построен на монолитной архитектуре. В таких случаях добавление дополнительного уровня инфраструктуры усложняет проект без явных преимуществ. Проще и эффективнее управлять сервисами напрямую. А монолитные системы обычно имеют централизованную структуру, что минимизирует необходимость в API Gateway.
Внедрение и обслуживание API Gateway требует затрат, как финансовых, так и временных. Если проект ограничен в ресурсах, может быть разумнее потратить их на другие критические задачи.
Если эти пункты про вас, скажите нет API Gateway!
Риски внедрения
Примерно так мы сидели и оценивали все риски внедрения этого паттерна, пытаясь сразу найти решение, если какой-то из них стрельнет. Сейчас я с вами поделюсь итогами нашего мозгового штурма:
Проблема | Решение |
Существует риск стать узким местом в системе. Это происходит, когда API Gateway берёт на себя слишком много задач, начинает терять свою гибкость и даже может превратиться в монолит, станет единой точкой отказа. | Нужно разделить нагрузки. Один из способов — это создать несколько API Gateway, сгруппировав микросервисы по типу клиента или по бизнес-логике. |
Шлюз должен помогать вашему API расти и при этом обрабатывать пики запросов без задержек и сбоев. Однако если шлюз не оптимизирован, он может стать узким местом, снижая общую производительность всей системы. | Один из подходов — это горизонтальное масштабирование, когда вы добавляете дополнительные экземпляры API Gateway. Также кэширование и ограничение запросов на уровне шлюза помогает снизить нагрузку на серверы. |
Повышенная сложность системы. У нас появляется ещё один компонент, который нужно развернуть, поддерживать и регулярно обновлять. Каждый новый элемент в системе добавляет свои задачи и сложности, что ведет к увеличению затрат на разработку и эксплуатацию. | Используйте автоматизацию процессов развертывания и мониторинга. Также важно развивать у команды нужные компетенции и навыки, чтобы они могли эффективно справляться с возникающими проблемами. Внедрение API Gateway требует не только технических знаний, но и стратегического подхода к управлению инфраструктурой. |
Привязка к поставщику — это один из самых сложных рисков при внедрении API Gateway. Сегодняшний мир развивается невероятно быстро и то, что сегодня кажется оптимальным, завтра может стать неактуальным. Но когда вы выбираете определенного поставщика, вы автоматически ограничиваете себя его возможностями и решениями. Произвести миграцию на другой Gateway, когда ваша архитектура уже выстроена вокруг одного решения, очень трудно и затратно. Требования будут меняться, и вы не сможете гарантировать, что выбранный вами поставщик сможет удовлетворять их на протяжении долгого времени. | ? ? ? Мы долго думали над этой проблемой, но, честно говоря, пока не нашли подходящего решения. И мы, к сожалению, не знаем, что с этим делать дальше. |
Итог
Во-первых, API Gateway — это не просто какое-то абстрактное понятие, а конкретный набор выполняемых функций. Именно эта функциональность определяет, насколько этот инструмент подходит для вашего проекта. API Gateway как швейцарский нож для интеграции сервисов, но с определенными нюансами.
Во-вторых, API Gateway — это далеко не панацея. Его нельзя просто так взять и применить везде, где захочется. Здесь нужно внимательно оценивать, подходит ли оно именно вам. У каждого проекта свои особенности, и то, что работает в одном случае, может оказаться совершенно неэффективным в другом.
И, наконец, было показано, с какими трудностями и рисками можно столкнуться. Главное, помните, что каждый проект уникален, и именно от ваших требований и условий будет зависеть, стоит ли вообще использовать API Gateway.
Надеюсь, эти мысли помогут вам в принятии правильных решений в ваших будущих проектах! Помните, что каждый проект уникален, а значит, требует индивидуального подхода.
