Добро пожаловать в очередной выпуск Microsoft Knowledge Nogetos. Я ваш ведущий, Мирку Питерс. Тема сегодняшнего выпуска – то, о чем слышали почти все, но мало кто понимает API. Вы наверняка часто слышали этот термин. Это одно из тех модных словечек, которые используют, чтобы казаться экспертами. Но на самом деле все просто. API – это совсем не сложно. Это всего лишь способ общения одной программы с другой. Ваш телефон запрашивает данные у сервера. Сервер их присылает. Это и есть вызов API. А теперь представьте, что у вас их 20, 50 или 100. Каждый может использовать свою аутентификацию, свои лимиты запросов и свою документацию, если она вообще есть. Внезапно-то, что начиналось как простой диалог двух приложений, превращается в полный хаос. Без централизованного управления каждая команда изобретает велосипед. Одна создает свою систему авторизации, другая – свою систему логирования. Повсюду возникают дыры в безопасности. Разработчики путаются в API, и у вас нет единого представления о том, что происходит во всей системе. Azure API Management решает эту проблему. Он предоставляет вам единый центр управления. Представьте его как диспетчерскую вышку для ваших API. К концу этого выпуска вы поймете, что это такое, почему это важно и как все это работает вместе. Берите кофе и приступим. Проблема – слишком много API и никакого контроля.

Такова реальность современного программного обеспечения. 10 лет назад у вас было одно большое приложение – Monolith, одна база данных, один API. Все просто. Сегодня то же приложение может быть разбито на десятки микросервисов. Каждый сервис отвечает за что-то одно – учетные записи, платежи, склад, уведомления, и у каждого свой API. В итоге у вас 10, 50, 100 различных точек входа в систему. Представьте, что вы разработчик, которому нужно создать что-то на основе этих API. Вам нужно найти каждый из них и разобраться с аутентификацией для каждого. Одни используют API-ключи, другие – OAT, третьи – вообще ничего. Вам нужно вручную настраивать лимиты запросов, иначе вас заблокируют. Нужно понимать, какой формат данных ожидает каждый API. Это выматывает. С точки зрения эксплуатации все еще хуже. Без центрального шлюза каждой команде приходится вручную добавлять безопасность и логирование в свой сервис. Кто-то делает это хорошо, а кто-то забывает логировать ошибки. Некоторые вообще не проверяют входные данные. Это непоследовательно, чревато ошибками и создает угрозу безопасности. Соблюдение нормативов становится почти невозможным. Нужно подтвердить, кто, к чему и когда обращался. Удачи в сборе аудиторских следов из 20 разных сервисов, у каждого из которых свой формат логов. Нужно узнать, сколько вызовов API обработала ваша система в прошлом месяце. Вам приходится собирать метрики с десятка разных панелей мониторинга. Вот в чем дело. По мере масштабирования это не просто неудобно. Это все ломается.

Нельзя добавлять новых разработчиков, сервисов и клиентов без единой точки управления. Представьте себе здание. В каждой комнате свой замок. Нет ни стойки регистрации, ни справочника. Посетители бродят в поисках нужной двери, злятся и в итоге уходят. Полный хаос. Именно эту проблему призвано решить управление API. Что такое Azure API Management? Диспетчерская вышка. Итак, что же такое Azure API Management? Вот самое простое определение. Это управляемый сервис, который стоит между вашими серверными API и приложениями, сайтами, устройствами и партнерами, которые ими пользуются. Но важно понимать, это не просто прокси. Прокси лишь перенаправляет трафик и все. Azure API Management охватывает весь жизненный цикл ваших API. Публикация, защита, мониторинг и вывод из эксплуатации. Это полноценный центр управления. Давайте разберем его на три основных компонента. Первый – это шлюз. Это парадная дверь. Каждый запрос от приложения или сайта сначала попадает в шлюз, а не напрямую к вам. Шлюз обрабатывает запрос, применяет политики, собирает метрики и перенаправляет к нужному сервису. Представьте его в роли регулировщика.

Далее – плоскость управления. Здесь вы все определяете. Ваши API, политики, продукты и подписки. Это делается через портал Azure, командную строку или код инфраструктуры, такой как BISIP или Terraform. Это операторская, где настраивается работа всей системы. И, наконец, портал разработчика. Это сайт самообслуживания, где разработчики находят ваши API, читают документацию, получают ключи и тестируют вызовы прямо в браузере. Больше никаких PDF-файлов по почте. Вот полезная аналогия. Представьте современный аэропорт. Шлюз – это взлетно-посадочная полоса. Каждый самолет сначала приземляется там. Плоскость управления – это диспетчерская вышка. Она управляет трафиком, задает правила и следит за всем. А портал разработчика – это информационное табло. Пилоты проверяют его перед полетом и находят всю нужную информацию без лишних вопросов. Теперь давайте подробнее остановимся на шлюзе. Именно с ним взаимодействуют ваши приложения, и там происходит вся магия. Шлюз – это парадная дверь вашего API. Поговорим о шлюзе, ведь именно к нему обращаются ваши приложения. Любой запрос из мобильного приложения, веб-сайта или IoT-устройства сначала попадает на шлюз, а не напрямую на бэкенд. В этом-то и вся суть. Шлюз располагается перед системой и служит единой точкой входа. Шлюз может применять политики перед пересылкой запроса. Политики – это правило в формате XML или JSON, например, ограничение частоты запросов, фильтрация IP, изменение заголовков и проверка аутентификации. И все это без изменения ни одной строчки кода вашего бэкенда. Вот конкретный пример. Допустим, у вас есть бесплатные и премиум тарифы для вашего API. С помощью политики вы можете ограничить бесплатных пользователей пятью запросами в минуту, а премиум пользователям дать сто. Ваш бэкенд даже не узнает о разнице.

Он просто обрабатывает запросы. Шлюз берет на себя все ограничения. Шлюз также управляет кэшированием. Если данные запрашиваются постоянно, например, список товаров, который редко меняется, шлюз может кэшировать ответ и отдавать его напрямую. Нет необходимости вообще беспокоить бэкенд, что означает более быстрые ответы и меньшую нагрузку на серверы. Он также может преобразовывать данные. Ваш бэкенд может возвращать XML, а мобильное приложение ожидает JSON. Шлюз может конвертировать их на лету. Вашему бэкенту ничего менять не нужно, как и приложению. Шлюз берет на себя эту трансляцию, и он логирует каждый вызов, каждый запрос, каждый ответ, каждую ошибку. Вы получаете полный аудит того, кто, что вызывал, когда и что произошло. Одно это уже оправдывает использование шлюза для соответствия требованиям. Если у вас глобальная аудитория, вы можете развернуть шлюз в нескольких регионах. Трафик автоматически направляется к ближайшему узлу, что снижает задержки и улучшает опыт. И еще кое-что, шлюз скрывает реальный URL вашего бэкенда. Клиенты видят только адрес шлюза.

Ваши бэкенд-серверы остаются скрытыми от интернета. Это дает огромное преимущество в безопасности из коробки. Политики – движок, который всем управляет. Итак, что насчет политик, о которых я говорил? Это движок, который делает IPAM по-настоящему мощным. Политика меняет поведение запроса или ответа, не затрагивая код вашего бэкенда. Представьте это как обертку вокруг вашего API. Когда проходит трафик, политики могут автоматически добавлять, удалять или менять данные. Политики могут срабатывать в четырех точках жизненного цикла запроса. На входе – inbound, по пути к вам, до того, как запрос достигнет бэкенда. На выходе – outbound, на обратном пути, прежде чем ответ попадет к клиенту. Бэкенд – непосредственно перед тем, как запрос попадет в ваш сервис. И при ошибке – onerror, когда что-то идет не так. К типовым входящим операциям относится проверка JWT-токенов для идентификации вызывающего абонента, проверка ключей API, перезапись URL-адресов и ограничение доступа по IP-адресу. Все это происходит еще до того, как ваш бэкенд увидит хоть один запрос. Для исходящих данных можно преобразовывать тело ответа. Искать и заменять текст, удалять конфиденциальные поля, менять форматы. Можно кэшировать ответы, чтобы повторные запросы не нагружали ваш бэкенд.

Можно даже удалять заголовки, раскрывающие внутреннюю информацию. Вот конкретный пример. Допустим, ваш API возвращает описание продуктов, где везде встречается слово «синий». Вы хотите провести ребрендинг и использовать «желтый». Вместо изменения кода бэкенда вы добавляете одну политику исходящего трафика. Найти «синий», заменить на «желтый». И готово. Ваш бэкенд остается неизменным. Политики ограничения частоты запросов и квоты защищают ваш бэкенд от злоупотреблений. Если чье-то приложение ведет себя некорректно и начинает долбить в Ашапе 10 тысяч раз в секунду, политика вмешивается и говорит «притормози». Ваш бэкенд остается в рабочем состоянии. Нужна расширенная логика. Вы можете писать пользовательские выражения на Ц решетка внутри политик. Они компилируются для обеспечения производительности. Поэтому потерь производительности во время выполнения нет. Вы можете проверять роли пользователей, вычислять динамические лимиты или условно преобразовывать ответы на основе заголовков запросов.

Главная мысль заключается в следующем. Политики позволяют управлять поведением АПИ, не затрагивая код, который ими управляет. Это означает более быстрые изменения, меньше развертываний и меньше рисков. Продукты и подписки – упаковка АПИ для потребителей. Теперь ваши АПИ определены, политики настроены и шлюз работает как часы. Но как предоставить разным клиентам разный уровень доступа? Здесь на помощь приходят продукты и подписки. В API-M вы группируете АПИ в нечто, называемое продуктом. Представьте это как пакет. У вас может быть бесплатный продукт, который включает только базовые АПИ. Возможно, только доступ для чтения, а затем премиум продукт, включающий все, включая операции записи и административные конечные точки. Разработчики подписываются не на отдельные АПИ, а на продукт целиком. При подписке они получают ключ подписки. На самом деле два ключа, чтобы можно было сменить один без простоев. Этот ключ – их пропуск к использованию любого АПИ в рамках данного продукта.

Вы контролируете работу подписок. Для продуктов можно требовать одобрения. Вы можете вручную принимать каждого подписчика или сделать их доступными для самообслуживания. Любой регистрируется и получает немедленный доступ. Вы также можете добавить юридические условия, которые пользователи должны принять перед подпиской. Это важно, если ваши АПИ обрабатывают конфиденциальные данные. Вот как можно монетизировать АПИ. Бесплатный продукт с низкими лимитами – 5 вызовов в минуту. Платный продукт с более высокими лимитами или большим количеством конечных точек – 100 вызовов в минуту, плюс доступ к премиум-функциям. Вашему бэкенту это не важно. Шлюз применяет ограничения в зависимости от того, на какой продукт подписался вызывающий абонент. Вот реальный пример. Представьте, что вы создаете приложение для конференции. Вы создаете продукт для участников с АПИ для расписания сессий, биографии спикеров и карты площадки. Затем продукт для спонсоров, который также включает АПИ для генерации лидов. Спонсоры могут сканировать бейджи участников и получать контактную информацию. Один и тот же бэкент, разные продукты, разные уровни доступа.

Эти два ключа подписки предназначены для ротации. Если ключ скомпрометирован, вы создаете новый. Второй ключ позволяет переключиться без прерывания обслуживания. Создайте новый ключ, обновите приложение, аннулируйте старый. Бешовно. Портал разработчика – самообслуживание для потребителей АПИ. Итак, вы настроили свои АПИ-продукты. Теперь разработчикам нужно их найти. Это задача портала разработчика. Портал разработчика – это веб-сайт, встроенный в каждый экземпляр и API-М. Разработчики используют его для просмотра ваших АПИ, чтения документации и интерактивного тестирования конечных точек прямо в браузере. Никакой настройки и переписки по электронной почте. Но есть нюанс – по умолчанию он не опубликован. Когда вы только создаете экземпляр и API-М, портал существует, но никто его не видит. Сначала его нужно настроить и опубликовать. Это сделано намеренно. Вы же не хотите показывать миру незавершенный портал. Вы можете настроить фирменные цвета, логотипы и даже встроить контент в Wordpress для блога рядом с документацией АПИ.

Он полностью настраивается под стиль и имидж вашей компании. Главная ценность – самообслуживание. Разработчики регистрируются, автоматически получают ключи подписки и сразу начинают вызывать АПИ. Никаких ручных писем, ожиданий одобрения или этикетов в поддержку с вопросами о получении ключа. Они делают все сами, что значительно снижает нагрузку на вашу поддержку. Вы также можете публиковать журналы изменений и примечания к выпуску. Когда вы обновляете АПИ, разработчики видят это на портале без сюрпризов. Доступ может быть публичным для всех, у кого есть URL, или вы можете ограничить его пользователями вашего арендатора IntraID, чтобы просматривать могли только сотрудники организации. Оба варианта существуют для разных сценариев использования. Портал разработчика превращает ваше управление АПИ в полноценную платформу. Думайте о нем как о витрине для ваших АПИ. Без него разработчикам приходится искать документацию и расспрашивать коллег. С ним они находят то, что нужно, и начинают разработку. Безопасность, аутентификация, авторизация и секреты.

Вся эта мощь бесполезна, если безопасность не обеспечена. Итак, давайте поговорим о том, как АПИМ управляет идентификацией, доступом и секретами. АПИМ поддерживает несколько методов аутентификации. Самый простой — это ключи подписки, о которых мы говорили ранее. Однако для промышленных систем требуются более надежные средства, такие как ОАТ-2, 0, JWT-токены, сертификаты клиентов или фильтрация по АПИ. Вы комбинируете их в зависимости от уровня конфиденциальности вашего АПИ. Для промышленной эксплуатации лучшей практикой является использование ОАТ-2, 0 секунд интро-ID. Вот как это работает. Клиентское приложение получает токен от интро-ID и отправляет его вместе с запросом к АПИ. АПИМ проверяет токен, анализируя подпись, издателя, аудиторию и срок действия. Если токен действителен, АПИМ перенаправляет запрос на ваш бэкенд, включая сам токен. Ваш бэкенд доверяет ему, так как АПИМ уже выполнил проверку, поэтому бэкенду не нужно проверять его повторно. Это на одну задачу меньше для каждого сервиса.

Теперь поговорим о секретах. Ключи АПИ, строки подключения, сертификаты, вы не хотите жестко прописывать их в файлах политик или системе контроля версий. В АПИМ есть функция именованных значений. Вы храните секреты, централизованные в АПИМ, и ссылаетесь на них по имени в своих политиках. Фактическое значение никогда не отображается в коде вашей политики. Более того, вы можете подключить именованные значения к Azure Key Vault. Секреты остаются зашифрованными в Key Vault, а АПИМ извлекает их во время выполнения. Никто, даже ваша команда DefOps, не видит реального значения секрета. Когда нужно сменить ключ, вы обновляете его в Key Vault, и АПИМ автоматически подхватывает изменения. АПИМ также поддерживает управляемые удостоверения. Это позволяет АПИМ проходить аутентификацию в других сервисах Azure, таких как Key Vault или Backend API, не храня учетные данные. Azure управляет удостоверением, а вы просто предоставляете разрешение. Для сетевой изоляции вы можете развернуть АПИМ внутри виртуальной сети. Это уровень премиум. Или используете Azure Front Door? Суть в том, что ваши бэкенд-сервисы никогда не должны быть напрямую доступны из интернета. АПИМ – это единственное, что видит внешний мир. Такой многоуровневый подход создает глубокоэшелонированную защиту. Аутентификация на шлюзе, секреты в хранилище, сетевая изоляция вокруг ваших бэкендов. Каждый слой усиливает следующий.

Ценовые уровни. Какой из них подходит вам? Итак, сколько это стоит? Давайте разберем уровни. Уровень потребления. Consumption. Оплата за каждый вызов АПИ без фиксированной ежемесячной стоимости. Идеально подходит для небольших объемов или эпизодических нагрузок. Например, на этапе прототипирования. Если вы еще не уверены, что вам нужно, начните с этого. Уровень разработчика. Девелопер предлагает фиксированную низкую ежемесячную стоимость около 50 долларов. Полный набор функций, но без SLA. Идеально для сред разработки и тестирования. Вы получаете все, что есть в премиум, но не можете использовать это в промышленной среде. Базовый уровень. Basic – это начальный уровень для производства. Более низкая пропускная способность. Отсутствие поддержки виртуальных сетей, но вы получаете реальный SLA. Подходит для внутренних инструментов или небольших проектов, где частная сеть не является критически важной. Большинство компаний выбирают стандартный уровень. Он включает поддержку виртуальных сетей, SLA 99,95% и хорошую пропускную способность.

Если вы используете критически важные API, скорее всего, вы остановитесь на немецком. Уровень премиум предназначен для глобальных предприятий, которым нужна максимальная надежность и частные сети. Развертывание в нескольких регионах, собственный шлюз, SLA 99,99%, полная интеграция с виртуальной сетью. Стоимость начинается примерно от 2700 в месяц за единицу. Microsoft также представила уровни V2, Basic V2, Standard V2 и Premium V2. Они упрощают ценообразование за счет включенных квот на запросы и оплаты сверх лимита за миллион. Вместо отслеживания множества показателей, вы получаете понятный объем запросов и платите за превышение. Вот как сделать выбор. Начните с уровня девелопер для тестирования. Переходите на стандарт для промышленной эксплуатации. Выбирайте премиум, если нужен глобальный масштаб или частная сеть. И помните, что вы всегда можете перейти на другой уровень позже. Начните с малого и развивайтесь по мере роста ваших потребностей. Вот что мы рассмотрели. API Management упорядочивает хаос из множества API, собирая их в единый центр управления шлюзом, политиками и безопасностью.

Главный вывод в том, что это больше, чем просто прокси. Представьте это как мозг и нервную систему вашей экосистемы API. Без этого каждая команда создает свою собственную аутентификацию, логирование и ограничение частоты запросов. В итоге вы получаете несогласованность, уязвимость и отсутствие единого представления о происходящем. С ним вы получаете согласованность, безопасность и масштабируемость, не изобретая велосипед для каждого сервиса. Вот простое упражнение. Вспомните один API, который вы сейчас предоставляете напрямую. Возможно, конечную точку функции или сервис приложений. Как использование API Management изменит вашу защищенность и возможность мониторинга использования. Даже простое обдумывание этого упражнения покажет вам его ценность. Следующий шаг – подпишитесь на канал. В будущих выпусках мы покажем, как импортировать API, применить первую политику и отслеживать использование в реальном времени. Вы перейдете от теории к практике. И если это было полезно, поделитесь этим с тем, кто создает приложение. Это спасет их от многих месяцев головной боли. Спасибо за внимание.