Latest / M365.FM – подкаст о Microsoft 365, Copilot и ИИ на русском / API Gateway простыми словами: маршрутизация, безопасность и ограничение запросов для микросервисов — нужен ли он вам? (ИИ-дубляж)

Transcript

API Gateway простыми словами: маршрутизация, безопасность и ограничение запросов для микросервисов — нужен ли он вам? (ИИ-дубляж) · M365.FM – подкаст о Microsoft 365, Copilot и ИИ на русском

• 0:00
  Готовы к 10 дням погружения в Microsoft 365, Капайлот, ИИ, Азур и знакомство с людьми,
• 0:06
  определяющими будущие работы. В этом январе М365Кон возвращается, и мы станем еще масштабнее.
• 0:12
  Присоединяйтесь к нам для участия в живых сессиях, демонстрациях реальных кейсов и получения
• 0:16
  практических знаний от MVP и экспертов со всего мира. Никаких общих слайдов и бесконечных модных
• 0:21
  словарей. Мы решаем реальные задачи, Капайлот Студия, ИИ Агенты, Фабрик, Безопасность,
• 0:27
  Управление и Автоматизация. Независимо от того, являетесь ли вы это специалистом,
• 0:31
  разработчиком или руководителем бизнеса, у нас есть сессии специально для вас.
• 0:35
  За 10 полных дней вы сможете изучить множество технологий и наладить связи с глобальным
• 0:39
  сообществом. Смотрите в прямом эфире и применяйте практические идеи в своей организации.
• 0:44
  Январь 2027 года, 10 дней, одно сообщество Microsoft. Регистрация уже открыта. Зайдите на
• 0:52
  m365con.net и забронируйте свое место уже сегодня. Это m365con.net.
• 1:00
  Присоединяйтесь на m365con.net. Увидимся в прямом эфире в январе. Вы создали работающие
• 1:05
  приложения, затем добавили еще один сервис, потом еще, и внезапно управление трафиком между
• 1:10
  ними превратилось в кошмар. Итак, что же такое API-шлюз и действительно ли он вам нужен? К концу
• 1:14
  этого эпизода вы поймете, что делает API-шлюз, почему он решает хаос управления множеством сервисов и как
• 1:21
  понять, нужен ли он вам? Давайте начнем с проблемы, затем разберем компоненты и то,
• 1:26
  как они взаимодействуют. Проблема – слишком много дверей. Представьте, что вы управляете
• 1:30
  компанией, которая быстро растет. У вас отдел продаж на третьем этаже, бухгалтерия в подвале,
• 1:35
  а это отдел в заднем крыле. Теперь представьте, что у каждого из этих отделов есть своя отдельная
• 1:39
  дверь, свой номер телефона и свой охранник, который не общается с остальными. Если вы посетитель и хотите
• 1:44
  доставить посылку, удачи вам. Вы должны точно знать, в какую дверь стучаться, с каким охранником говорить и что
• 1:49
  делать, когда этот охранник на перерыве. Это именно то, что происходит, когда в приложении множество
• 1:53
  бэкенд-сервисов, и каждый клиент обращается к ним напрямую. Клиент, будь то мобильное приложение,
• 1:58
  сайт или другой сервис, должен знать адрес каждого сервиса, как проходить аутентификацию и что делать,
• 2:03
  если что-то сломалось. Каждый отдельный сервис вынужден самостоятельно заниматься безопасностью,
• 2:07
  ограничением частоты запросов и обработкой ошибок. Это дублирование работы, из-за чего легко возникают
• 2:11
  несогласованности. Возьмем, к примеру, банк. У них есть отдельные сервисы для счетов, платежей, кредитов и
• 2:16
  обнаружения мошенничества. При старом подходе каждый из них открыт для прямого доступа.
• 2:19
  Мобильному приложению приходится знать 4 разных URL, 4 разных метода аутентификации и 4 разных
• 2:24
  способа обработки ошибок. Это в 4 раза больше сложностей и в 4 раза больше возможностей для сбоев,
• 2:29
  а именно этот хаос и призван устранить API-шлюз. Итак, какое же решение? Что такое API-шлюз?
• 2:35
  Представьте API-шлюз как стойку регистрации в отеле. Когда вы входите, вам не нужно знать,
• 2:40
  на каком этаже находится горничная, где кухня или как связаться с техническим персоналом.
• 2:44
  Вы просто подходите к стойке, говорите, что вам нужно, и они берут все на себя. Они направляют
• 2:49
  ваш запрос нужному сотруднику, проверяют, есть ли у вас право доступа, и даже сами выполняют
• 2:53
  простые запросы. API-шлюз делает то же самое для вашего программного обеспечения. Это единая
• 2:57
  точка входа, которая располагается между вашими клиентами и серверными службами. Каждый запрос
• 3:02
  сначала проходит через шлюз. Он решает, куда его направить, разрешить его или нет, и что отправить
• 3:07
  в ответ. Конечно, это не новая идея. Обратные прокси-серверы существуют десятилетиями,
• 3:11
  но с появлением микросервисов API-шлюз стал незаменим. Когда вы разбиваете приложение на множество
• 3:15
  мелких сервисов, у вас внезапно появляется много дверей. Шлюз предоставляет вам одну парадную
• 3:19
  дверь. В мире Azure полноценной платформой является Azure API Management, а шлюз — это ключевой
• 3:23
  компонент, управляющий трафиком. Однако этот шаблон везде одинаков. Одна точка входа — централизованный
• 3:28
  контроль. Поступает каждый запрос. Шлюз проверяет его, маршрутизирует и отправляет ответ обратно.
• 3:33
  Клиент никогда не взаимодействует с вашими серверными службами напрямую. Он общается только
• 3:36
  со шлюзом. Давайте разберем, что это значит на самом деле. Начнем с самой базовой задачи — маршрутизации.
• 3:42
  Часть первая — маршрутизация трафика. Простейшая задача API-шлюза — это маршрутизация,
• 3:46
  то есть направление каждого запроса к нужному сервису. Подумайте о том, как работает веб-сайт.
• 3:50
  Когда вы кликаете по ссылке, ваш браузер отправляет запрос. У этого запроса есть путь. Если путь
• 3:55
  ведет к пользователям, шлюз знает, что его нужно отправить в сервис пользователей. Если к заказам,
• 3:58
  он направляется в сервис заказов. Шлюз считывает путь, определяет, куда нужно идти,
• 4:02
  и перенаправляет запрос. Без шлюза вашим клиентам пришлось бы знать URL каждого отдельного сервиса.
• 4:07
  Мобильному приложению нужны адреса сервиса пользователей, сервиса заказов,
• 4:10
  платежного сервиса и сервиса каталогов. Это очень много URL, которыми нужно управлять.
• 4:14
  И если любой из этих адресов изменится, вам придется обновлять каждого клиента.
• 4:17
  С использованием шлюза клиенты знают только один URL — адрес самого шлюза. Им не важно,
• 4:21
  где фактически расположены сервисы. Они просто отправляют запрос на шлюз, а шлюз берет все остальное на себя.
• 4:26
  Это один из самых частых сценариев использования API-шлюза — маршрутизация на основе ресурсов.
• 4:30
  Исследование Apache AppXX прямо указывает на это. Вы строите маршруты на основе пути,
• 4:34
  HTTP метода, заголовков и даже геолокации клиента. Если запрос поступает из Европы,
• 4:39
  вы можете направить его в европейский дата-центр. Если запрос поступает из США,
• 4:42
  он направляется в американский дата-центр. Клиент даже не догадывается, что все это происходит.
• 4:46
  Он просто получает быстрый ответ. Маршрутизация также решает вопросы
• 4:49
  версионирования. Допустим, у вас появилась новая версия сервиса пользователей. Старые клиенты
• 4:52
  все еще используют V1 — Узерс, а новые — V2 — Узерс. Шлюз направляет их на разные быкенды.
• 4:58
  Старые клиенты продолжают работать, пока вы развертываете новую версию. Вы можете менять
• 5:02
  быкенд, не нарушая работу клиентов. Это критически важно, когда вы управляете работающим
• 5:06
  приложением с реальными пользователями. Вспомните платформу электронной коммерции.
• 5:09
  У вас есть отдельные сервисы для каталога, корзины, оформления заказа и аккаунтов пользователей.
• 5:13
  Без шлюза мобильному приложению пришлось бы знать четыре разных URL. С использованием шлюза
• 5:18
  оно знает один. Шлюз считывает путь, каталог, корзина, заказ, аккаунт и пересылает каждый запрос
• 5:23
  нужному сервису. Простая маршрутизация — это самая легкая часть. Следующая задача — вот где
• 5:28
  начинается настоящая польза. Часть вторая — безопасность на входе. Каждый вызов API должен быть
• 5:32
  проверен. Кто отправляет этот запрос? Есть ли у них необходимые права доступа? Без шлюза каждый
• 5:37
  сервис должен сам заниматься аутентификацией. Это дублирование работы, и здесь легко допустить
• 5:41
  ошибку. Один сервис может проверять токены правильно, другой — пропустить шаг, а третий — использовать
• 5:46
  совершенно другой метод. В итоге вы получаете разрозненную систему безопасности во всем
• 5:50
  приложении. Шлюз это меняет. Он берет на себя аутентификацию и авторизацию в одном
• 5:54
  централизованном месте. Одно место для проверки, одно для контроля, одно для обновления правил
• 5:58
  при их изменении. Это одна из главных передовых практик безопасности. Он проверяет API-ключи,
• 6:03
  JWT, OAT-токены или сертификаты для каждого запроса. Любой запрос проходит через одну и ту же проверку.
• 6:09
  Никаких исключений. Шлюз также может принудительно применять правила. Вы можете указать,
• 6:13
  этот API-ключ может вызывать только инпоинты чтения. Или этот клиент может получить доступ только
• 6:17
  к сервису каталога, а не к сервису оплаты. Вы настраиваете точечные права доступа на уровне
• 6:21
  шлюза, и они применяются автоматически. Бэкенд-сервисам больше не нужно беспокоиться
• 6:25
  об авторизации. Они просто обрабатывают запрос и возвращают данные. В чем же дело?
• 6:29
  Шлюз — это единый центр для отзыва доступа в случае проблем. Если API-ключ клиента скомпрометирован,
• 6:35
  вы отзываете его на шлюзе. Одно изменение — и готово. Не нужно обновлять каждый сервис
• 6:39
  или перезапускать что-либо. Следующий запрос с этим ключом будет немедленно отклонен.
• 6:43
  Рассмотрим реальный пример. В банке есть платежный сервис и биллинговая система.
• 6:46
  Только платежный сервис должен иметь доступ на запись в биллинг. Шлюз обеспечивает
• 6:50
  соблюдение этого правила. Если клиент пытается обратиться к биллингу через неверный инпоинт,
• 6:54
  шлюз блокирует это. Биллинговый сервис даже не видит этот запрос. Шлюз также может поддерживать
• 6:59
  взаимный ТЛС и интеграцию с WAF для усиленной защиты. Но в основе своей это ваша первая линия
• 7:04
  обороны. Безопасность — это одно, но что делать, если поступает слишком много запросов сразу?
• 7:08
  Часть третья — управление трафиком. Что будет, если 10 тысяч пользователей одновременно зайдут в ваше
• 7:13
  приложение? Возможно, у вас флеш распродажа, вирусный запуск продукта или просто обычный вторник,
• 7:18
  когда все решили войти в систему одновременно. Без шлюза ваши бэкенд-сервисы примут удар на себя
• 7:23
  и могут выйти из строя. Не постепенно, а все сразу. Вот здесь и вступает в дело управления
• 7:28
  трафиком. Шлюз может ограничивать количество запросов для каждого клиента. Ограничение частоты
• 7:32
  запросов и тротлинг — это стандартные функции. Вы задаете правила на шлюзе, а он их применяет.
• 7:37
  Ваши бэкенд-сервисы даже не почувствуют всплеска нагрузки. Вы можете установить квоты на пользователя,
• 7:41
  на API-ключ или на IP-адрес. Допустим, у вас есть бесплатная версия вашего API. Бесплатные
• 7:45
  пользователи получают 100 запросов в час. Премиум-пользователи получают 10 тысяч. Шлюз
• 7:49
  отшлеживает каждый запрос и применяет эти лимиты на входе. Когда бесплатный пользователь достигает
• 7:53
  лимита, шлюз отправляет вежливое сообщение «Попробуйте позже». Бэкенд-сервисы даже не узнают
• 7:58
  о существовании такого запроса. Они продолжают спокойно обслуживать платных клиентов. Шлюз также берет
• 8:03
  на себя балансировку нагрузки. Если у вас запущено несколько экземпляров одного сервиса,
• 8:07
  шлюз распределяет запросы между ними. Первый запрос – первому экземпляру, второй – второму,
• 8:11
  третий – третьему. Это происходит автоматически. А если один экземпляр выйдет из строя,
• 8:15
  шлюз перенаправит трафик на другой. Клиенты даже не заметят. Они просто получат свой ответ.
• 8:19
  Балансировка нагрузки с проверкой работоспособности обеспечивает бесперебойную работу. Шлюз
• 8:22
  пингует каждый экземпляр, чтобы убедиться, что он работает. Если нет, он прекращает отправлять туда трафик.
• 8:27
  Это особенно важно для высоконагружанных API. Без шлюза всплеск трафика попадает прямо на ваши сервисы.
• 8:33
  Со шлюзом всплеск сначала попадает на него. Шлюз поглощает и распределяет нагрузку,
• 8:38
  защищая ваши сервисы от перегрузки. Хорошо. А что, если данные приходят в некорректном виде?
• 8:44
  Часть четвертая – преобразование данных. Иногда данные, которые отправляет клиент,
• 8:48
  не соответствуют тому, что ожидает бэкенд. Может быть, клиент отправляет JSON,
• 8:52
  а бэкенд понимает только XML. Может, названия полей не совпадают. Клиент использует
• 8:56
  FirstName, а бэкенд ожидает FirstName. Такие несоответствия все ломают. Раньше вам пришлось бы исправлять
• 9:02
  каждого клиента или переписывать бэкенд. Не лучший вариант. Шлюз может преобразовывать
• 9:06
  данные до того, как они дойдут до бэкенда. Представьте его в роли переводчика. Он находится
• 9:10
  посередине и может менять данные на входе, на выходе или в обоих случаях. Это и есть преобразование
• 9:14
  запросов и ответов в двух словах. Приведу реальный пример. Допустим, у вас есть устаревшая система,
• 9:18
  которая ожидает XML. Она работает уже 15 лет. Работает исправно. Но теперь вы создаете мобильное
• 9:23
  приложение, а они общаются на JSON. Без шлюза пришлось бы переписывать старую систему или заставлять
• 9:28
  приложение Slate XML. Со шлюзом делать этого не нужно. Мобильное приложение отправляет JSON.
• 9:33
  Шлюз конвертирует его в XML. Система получает то, что ожидает. Мобильное приложение получает ответ
• 9:37
  уже в формате JSON. Никому не пришлось ничего переписывать. В этом вся прелесть. Шлюз также может
• 9:42
  добавлять или удалять заголовки, менять URL или маскировать конфиденциальные данные. Представьте,
• 9:46
  что ответ содержит номер кредитной карты. Вы не хотите, чтобы он ушел клиенту. Шлюз может удалить его
• 9:51
  перед отправкой ответа или заменить на маскированную версию. Бэкенту ничего не нужно менять. Шлюз все
• 9:56
  сделает сам. Это особенно полезно при модернизации старых систем. Вам не нужно переписывать
• 10:00
  бэкент. Вам не нужно заставлять клиентов вносить изменения. Вы просто меняете настройки шлюза.
• 10:04
  Это как переводчик на международной конференции. Все говорят на своих языках, но переводчик делает
• 10:09
  так, чтобы все понимали друг друга. Шлюз – это такой переводчик для вашего ПА. Итак, маршрутизация,
• 10:13
  безопасность, ограничение трафика, преобразование – это немало. Но это не четыре разрозненные вещи.
• 10:17
  Покажу вам, как они связаны, как все это соединяется. Суть в следующем. Эти четыре задачи не отделены друг от
• 10:23
  друга. Они работают сообща с каждым запросом, каждый раз при его поступлении. Шлюз проверяет
• 10:27
  аутентификацию. Он проверяет лимит запросов. Он направляет запрос к нужному сервису. При
• 10:31
  необходимости он преобразует данные. Он получает ответ обратно. При необходимости он преобразует его.
• 10:36
  Затем он отправляет все обратно клиенту. Один конвейер. Каждый шаг выполняется автоматически,
• 10:40
  по порядку, и сервисам не нужно об этом думать. Настоящая сила не в какой-то одной функции. Она в
• 10:45
  интеграции. Можно добавить новую политику безопасности, не затрагивая маршрутизацию.
• 10:49
  Бэкенд-сервис можно менять, не затрагивая клиент. Можно обновить лимиты запросов без повторного
• 10:54
  развертывания. Каждая часть независима, но все они работают в одном конвейере. А поскольку все
• 10:58
  проходит через одно место, вы получаете полный обзор происходящего. Логи, метрики, аналитика – все из
• 11:04
  одной точки. Вы видите, сколько поступило запросов, какие из них не прошли, какие были медленными,
• 11:08
  какие клиенты потребляют больше всего ресурсов. Без шлюза вам пришлось бы собирать эти данные с каждого
• 11:12
  сервиса отдельно. Со шлюзом все находится в одном месте. В этом главное озарение. Шлюз – это не просто
• 11:17
  маршрутизатор. Это центр управления всей вашей API-платформой. Каждый запрос, каждый ответ,
• 11:22
  каждая ошибка – все проходит через одно место. Вы получаете единую панель управления для всего
• 11:25
  происходящего. Итак, как же этим пользоваться на практике? Давайте обсудим, что можно сделать прямо
• 11:29
  сейчас. Практические выводы. Будем реалистами. Если у вас один или два сервиса, API-шлюз вам,
• 11:34
  скорее всего, пока не нужен. Вы можете настроить маршрутизацию самостоятельно, управляя авторизацией
• 11:38
  в каждом сервисе. Это неизящно, но работает. Но как только у вас появляется три сервиса или вы предоставляете
• 11:43
  API-пи внешним клиентам, сложность быстро возрастает. Шлюз быстро окупает себя. С чего же лучше
• 11:48
  всего начать? Централизуйте аутентификацию на шлюзе. Сделайте это в первую очередь. Выберите один
• 11:52
  сервис, перенесите проверку авторизации на шлюз. Вы сразу заметите, что код вашего сервиса стал чище.
• 11:57
  Больше никакой логики проверки токенов, разбросанной повсюду. Больше не нужно гадать, реализовали ли вы
• 12:02
  ее одинаково во всех сервисах. Шлюз обрабатывает это один раз, и выигрывают все сервисы. Следующий шаг – ограничение
• 12:08
  частоты запроса. Даже простое ограничение защищает ваш бейкенд от перегрузки. Начните с чего-то
• 12:12
  базового, например, 100 запросов в минуту на клиента. Это не даст вышедшему из-под контроля клиенту
• 12:15
  уронить ваши сервисы. Вы можете обсудить.