WEBVTT

00:00:00.000 --> 00:00:04.320
Добро пожаловать в очередной выпуск Microsoft Knowledge Nogetos. Я ваш ведущий, Мирку Питерс.

00:00:04.420 --> 00:00:09.320
Тема сегодняшнего выпуска – то, о чем слышали почти все, но мало кто понимает API. Вы наверняка

00:00:09.320 --> 00:00:14.060
часто слышали этот термин. Это одно из тех модных словечек, которые используют, чтобы казаться

00:00:14.060 --> 00:00:18.860
экспертами. Но на самом деле все просто. API – это совсем не сложно. Это всего лишь способ общения

00:00:18.860 --> 00:00:23.420
одной программы с другой. Ваш телефон запрашивает данные у сервера. Сервер их присылает. Это и

00:00:23.420 --> 00:00:28.120
есть вызов API. А теперь представьте, что у вас их 20, 50 или 100. Каждый может использовать свою

00:00:28.120 --> 00:00:32.600
аутентификацию, свои лимиты запросов и свою документацию, если она вообще есть. Внезапно-то,

00:00:32.720 --> 00:00:37.120
что начиналось как простой диалог двух приложений, превращается в полный хаос. Без централизованного

00:00:37.120 --> 00:00:41.160
управления каждая команда изобретает велосипед. Одна создает свою систему авторизации,

00:00:41.400 --> 00:00:46.420
другая – свою систему логирования. Повсюду возникают дыры в безопасности. Разработчики путаются в API,

00:00:46.680 --> 00:00:51.720
и у вас нет единого представления о том, что происходит во всей системе. Azure API Management решает

00:00:51.720 --> 00:00:56.420
эту проблему. Он предоставляет вам единый центр управления. Представьте его как диспетчерскую

00:00:56.420 --> 00:01:02.040
вышку для ваших API. К концу этого выпуска вы поймете, что это такое, почему это важно и как

00:01:02.040 --> 00:01:08.140
все это работает вместе. Берите кофе и приступим. Проблема – слишком много API и никакого контроля.

00:01:08.300 --> 00:01:12.520
Такова реальность современного программного обеспечения. 10 лет назад у вас было одно большое

00:01:12.520 --> 00:01:18.140
приложение – Monolith, одна база данных, один API. Все просто. Сегодня то же приложение может быть

00:01:18.140 --> 00:01:22.740
разбито на десятки микросервисов. Каждый сервис отвечает за что-то одно – учетные записи,

00:01:22.740 --> 00:01:28.460
платежи, склад, уведомления, и у каждого свой API. В итоге у вас 10, 50, 100 различных точек

00:01:28.460 --> 00:01:32.480
входа в систему. Представьте, что вы разработчик, которому нужно создать что-то на основе этих

00:01:32.480 --> 00:01:36.560
API. Вам нужно найти каждый из них и разобраться с аутентификацией для каждого. Одни используют

00:01:36.560 --> 00:01:40.880
API-ключи, другие – OAT, третьи – вообще ничего. Вам нужно вручную настраивать лимиты запросов,

00:01:41.080 --> 00:01:45.480
иначе вас заблокируют. Нужно понимать, какой формат данных ожидает каждый API. Это выматывает.

00:01:45.480 --> 00:01:49.880
С точки зрения эксплуатации все еще хуже. Без центрального шлюза каждой команде приходится вручную

00:01:49.880 --> 00:01:53.620
добавлять безопасность и логирование в свой сервис. Кто-то делает это хорошо, а кто-то забывает

00:01:53.620 --> 00:01:57.180
логировать ошибки. Некоторые вообще не проверяют входные данные. Это непоследовательно,

00:01:57.400 --> 00:02:01.060
чревато ошибками и создает угрозу безопасности. Соблюдение нормативов становится почти

00:02:01.060 --> 00:02:05.240
невозможным. Нужно подтвердить, кто, к чему и когда обращался. Удачи в сборе аудиторских следов

00:02:05.240 --> 00:02:09.260
из 20 разных сервисов, у каждого из которых свой формат логов. Нужно узнать, сколько вызовов API

00:02:09.260 --> 00:02:13.480
обработала ваша система в прошлом месяце. Вам приходится собирать метрики с десятка разных панелей

00:02:13.480 --> 00:02:17.880
мониторинга. Вот в чем дело. По мере масштабирования это не просто неудобно. Это все ломается.

00:02:17.880 --> 00:02:21.480
Нельзя добавлять новых разработчиков, сервисов и клиентов без единой точки управления.

00:02:21.640 --> 00:02:26.900
Представьте себе здание. В каждой комнате свой замок. Нет ни стойки регистрации, ни справочника.

00:02:27.080 --> 00:02:32.740
Посетители бродят в поисках нужной двери, злятся и в итоге уходят. Полный хаос. Именно эту

00:02:32.740 --> 00:02:38.180
проблему призвано решить управление API. Что такое Azure API Management? Диспетчерская вышка.

00:02:38.360 --> 00:02:43.260
Итак, что же такое Azure API Management? Вот самое простое определение. Это управляемый сервис,

00:02:43.360 --> 00:02:47.260
который стоит между вашими серверными API и приложениями, сайтами, устройствами и партнерами,

00:02:47.260 --> 00:02:51.500
которые ими пользуются. Но важно понимать, это не просто прокси. Прокси лишь перенаправляет

00:02:51.500 --> 00:02:55.960
трафик и все. Azure API Management охватывает весь жизненный цикл ваших API. Публикация,

00:02:56.120 --> 00:03:00.700
защита, мониторинг и вывод из эксплуатации. Это полноценный центр управления. Давайте разберем

00:03:00.700 --> 00:03:05.640
его на три основных компонента. Первый – это шлюз. Это парадная дверь. Каждый запрос от приложения

00:03:05.640 --> 00:03:11.300
или сайта сначала попадает в шлюз, а не напрямую к вам. Шлюз обрабатывает запрос, применяет политики,

00:03:11.540 --> 00:03:16.340
собирает метрики и перенаправляет к нужному сервису. Представьте его в роли регулировщика.

00:03:16.340 --> 00:03:22.560
Далее – плоскость управления. Здесь вы все определяете. Ваши API, политики, продукты и подписки.

00:03:22.740 --> 00:03:27.380
Это делается через портал Azure, командную строку или код инфраструктуры, такой как BISIP или

00:03:27.380 --> 00:03:32.880
Terraform. Это операторская, где настраивается работа всей системы. И, наконец, портал разработчика.

00:03:33.060 --> 00:03:37.880
Это сайт самообслуживания, где разработчики находят ваши API, читают документацию,

00:03:38.120 --> 00:03:43.280
получают ключи и тестируют вызовы прямо в браузере. Больше никаких PDF-файлов по почте.

00:03:43.280 --> 00:03:47.460
Вот полезная аналогия. Представьте современный аэропорт. Шлюз – это взлетно-посадочная

00:03:47.460 --> 00:03:51.260
полоса. Каждый самолет сначала приземляется там. Плоскость управления – это диспетчерская

00:03:51.260 --> 00:03:55.700
вышка. Она управляет трафиком, задает правила и следит за всем. А портал разработчика – это

00:03:55.700 --> 00:03:59.780
информационное табло. Пилоты проверяют его перед полетом и находят всю нужную информацию

00:03:59.780 --> 00:04:04.200
без лишних вопросов. Теперь давайте подробнее остановимся на шлюзе. Именно с ним взаимодействуют

00:04:04.200 --> 00:04:10.120
ваши приложения, и там происходит вся магия. Шлюз – это парадная дверь вашего API. Поговорим о шлюзе,

00:04:10.120 --> 00:04:14.500
ведь именно к нему обращаются ваши приложения. Любой запрос из мобильного приложения,

00:04:14.700 --> 00:04:19.260
веб-сайта или IoT-устройства сначала попадает на шлюз, а не напрямую на бэкенд. В этом-то и вся

00:04:19.260 --> 00:04:23.780
суть. Шлюз располагается перед системой и служит единой точкой входа. Шлюз может применять

00:04:23.780 --> 00:04:28.140
политики перед пересылкой запроса. Политики – это правило в формате XML или JSON, например,

00:04:28.300 --> 00:04:32.620
ограничение частоты запросов, фильтрация IP, изменение заголовков и проверка аутентификации. И все это

00:04:32.620 --> 00:04:37.880
без изменения ни одной строчки кода вашего бэкенда. Вот конкретный пример. Допустим, у вас есть бесплатные и

00:04:37.880 --> 00:04:41.540
премиум тарифы для вашего API. С помощью политики вы можете ограничить бесплатных пользователей

00:04:41.540 --> 00:04:45.600
пятью запросами в минуту, а премиум пользователям дать сто. Ваш бэкенд даже не узнает о разнице.

00:04:45.740 --> 00:04:50.240
Он просто обрабатывает запросы. Шлюз берет на себя все ограничения. Шлюз также управляет

00:04:50.240 --> 00:04:55.020
кэшированием. Если данные запрашиваются постоянно, например, список товаров, который редко меняется,

00:04:55.180 --> 00:04:59.380
шлюз может кэшировать ответ и отдавать его напрямую. Нет необходимости вообще беспокоить бэкенд,

00:04:59.600 --> 00:05:03.980
что означает более быстрые ответы и меньшую нагрузку на серверы. Он также может преобразовывать данные.

00:05:03.980 --> 00:05:09.040
Ваш бэкенд может возвращать XML, а мобильное приложение ожидает JSON. Шлюз может конвертировать

00:05:09.040 --> 00:05:13.800
их на лету. Вашему бэкенту ничего менять не нужно, как и приложению. Шлюз берет на себя эту

00:05:13.800 --> 00:05:18.720
трансляцию, и он логирует каждый вызов, каждый запрос, каждый ответ, каждую ошибку. Вы получаете

00:05:18.720 --> 00:05:22.980
полный аудит того, кто, что вызывал, когда и что произошло. Одно это уже оправдывает использование

00:05:22.980 --> 00:05:27.280
шлюза для соответствия требованиям. Если у вас глобальная аудитория, вы можете развернуть шлюз в

00:05:27.280 --> 00:05:32.700
нескольких регионах. Трафик автоматически направляется к ближайшему узлу, что снижает задержки и улучшает

00:05:32.700 --> 00:05:37.800
опыт. И еще кое-что, шлюз скрывает реальный URL вашего бэкенда. Клиенты видят только адрес шлюза.

00:05:37.980 --> 00:05:42.200
Ваши бэкенд-серверы остаются скрытыми от интернета. Это дает огромное преимущество в безопасности

00:05:42.200 --> 00:05:47.060
из коробки. Политики – движок, который всем управляет. Итак, что насчет политик, о которых я

00:05:47.060 --> 00:05:52.120
говорил? Это движок, который делает IPAM по-настоящему мощным. Политика меняет поведение запроса или

00:05:52.120 --> 00:05:57.180
ответа, не затрагивая код вашего бэкенда. Представьте это как обертку вокруг вашего API. Когда проходит

00:05:57.180 --> 00:06:01.840
трафик, политики могут автоматически добавлять, удалять или менять данные. Политики могут срабатывать

00:06:01.840 --> 00:06:05.920
в четырех точках жизненного цикла запроса. На входе – inbound, по пути к вам, до того,

00:06:06.000 --> 00:06:10.060
как запрос достигнет бэкенда. На выходе – outbound, на обратном пути, прежде чем ответ попадет

00:06:10.060 --> 00:06:14.720
к клиенту. Бэкенд – непосредственно перед тем, как запрос попадет в ваш сервис. И при ошибке – onerror,

00:06:14.900 --> 00:06:18.480
когда что-то идет не так. К типовым входящим операциям относится проверка JWT-токенов для

00:06:18.480 --> 00:06:22.420
идентификации вызывающего абонента, проверка ключей API, перезапись URL-адресов и ограничение доступа

00:06:22.420 --> 00:06:26.720
по IP-адресу. Все это происходит еще до того, как ваш бэкенд увидит хоть один запрос. Для исходящих

00:06:26.720 --> 00:06:31.140
данных можно преобразовывать тело ответа. Искать и заменять текст, удалять конфиденциальные поля,

00:06:31.360 --> 00:06:35.280
менять форматы. Можно кэшировать ответы, чтобы повторные запросы не нагружали ваш бэкенд.

00:06:35.440 --> 00:06:39.440
Можно даже удалять заголовки, раскрывающие внутреннюю информацию. Вот конкретный пример.

00:06:39.620 --> 00:06:43.720
Допустим, ваш API возвращает описание продуктов, где везде встречается слово «синий». Вы хотите

00:06:43.720 --> 00:06:48.580
провести ребрендинг и использовать «желтый». Вместо изменения кода бэкенда вы добавляете одну политику

00:06:48.580 --> 00:06:54.180
исходящего трафика. Найти «синий», заменить на «желтый». И готово. Ваш бэкенд остается неизменным.

00:06:54.180 --> 00:06:57.500
Политики ограничения частоты запросов и квоты защищают ваш бэкенд от злоупотреблений.

00:06:57.620 --> 00:07:01.340
Если чье-то приложение ведет себя некорректно и начинает долбить в Ашапе 10 тысяч раз в секунду,

00:07:01.460 --> 00:07:05.000
политика вмешивается и говорит «притормози». Ваш бэкенд остается в рабочем состоянии.

00:07:05.180 --> 00:07:08.480
Нужна расширенная логика. Вы можете писать пользовательские выражения на Ц решетка внутри

00:07:08.480 --> 00:07:11.220
политик. Они компилируются для обеспечения производительности. Поэтому потерь

00:07:11.220 --> 00:07:14.100
производительности во время выполнения нет. Вы можете проверять роли пользователей,

00:07:14.240 --> 00:07:17.760
вычислять динамические лимиты или условно преобразовывать ответы на основе заголовков запросов.

00:07:17.760 --> 00:07:21.760
Главная мысль заключается в следующем. Политики позволяют управлять поведением АПИ,

00:07:21.920 --> 00:07:25.720
не затрагивая код, который ими управляет. Это означает более быстрые изменения,

00:07:26.000 --> 00:07:30.120
меньше развертываний и меньше рисков. Продукты и подписки – упаковка АПИ для

00:07:30.120 --> 00:07:35.140
потребителей. Теперь ваши АПИ определены, политики настроены и шлюз работает как часы.

00:07:35.260 --> 00:07:40.200
Но как предоставить разным клиентам разный уровень доступа? Здесь на помощь приходят продукты и

00:07:40.200 --> 00:07:45.440
подписки. В API-M вы группируете АПИ в нечто, называемое продуктом. Представьте это как пакет.

00:07:45.440 --> 00:07:49.580
У вас может быть бесплатный продукт, который включает только базовые АПИ. Возможно,

00:07:49.780 --> 00:07:54.300
только доступ для чтения, а затем премиум продукт, включающий все, включая операции записи и

00:07:54.300 --> 00:07:58.840
административные конечные точки. Разработчики подписываются не на отдельные АПИ, а на продукт

00:07:58.840 --> 00:08:03.820
целиком. При подписке они получают ключ подписки. На самом деле два ключа, чтобы можно было сменить

00:08:03.820 --> 00:08:07.840
один без простоев. Этот ключ – их пропуск к использованию любого АПИ в рамках данного продукта.

00:08:07.960 --> 00:08:12.560
Вы контролируете работу подписок. Для продуктов можно требовать одобрения. Вы можете вручную принимать

00:08:12.560 --> 00:08:16.700
каждого подписчика или сделать их доступными для самообслуживания. Любой регистрируется и получает

00:08:16.700 --> 00:08:20.160
немедленный доступ. Вы также можете добавить юридические условия, которые пользователи должны

00:08:20.160 --> 00:08:23.540
принять перед подпиской. Это важно, если ваши АПИ обрабатывают конфиденциальные данные.

00:08:23.740 --> 00:08:28.120
Вот как можно монетизировать АПИ. Бесплатный продукт с низкими лимитами – 5 вызовов в минуту.

00:08:28.220 --> 00:08:32.020
Платный продукт с более высокими лимитами или большим количеством конечных точек – 100 вызовов в минуту,

00:08:32.080 --> 00:08:36.300
плюс доступ к премиум-функциям. Вашему бэкенту это не важно. Шлюз применяет ограничения в зависимости от того,

00:08:36.420 --> 00:08:39.500
на какой продукт подписался вызывающий абонент. Вот реальный пример. Представьте,

00:08:39.500 --> 00:08:43.260
что вы создаете приложение для конференции. Вы создаете продукт для участников с АПИ для

00:08:43.260 --> 00:08:46.980
расписания сессий, биографии спикеров и карты площадки. Затем продукт для спонсоров,

00:08:47.140 --> 00:08:51.000
который также включает АПИ для генерации лидов. Спонсоры могут сканировать бейджи участников и

00:08:51.000 --> 00:08:55.040
получать контактную информацию. Один и тот же бэкент, разные продукты, разные уровни доступа.

00:08:55.120 --> 00:08:59.120
Эти два ключа подписки предназначены для ротации. Если ключ скомпрометирован,

00:08:59.340 --> 00:09:03.280
вы создаете новый. Второй ключ позволяет переключиться без прерывания обслуживания.

00:09:03.500 --> 00:09:06.900
Создайте новый ключ, обновите приложение, аннулируйте старый.

00:09:06.900 --> 00:09:10.560
Бешовно. Портал разработчика – самообслуживание для потребителей АПИ.

00:09:10.680 --> 00:09:14.180
Итак, вы настроили свои АПИ-продукты. Теперь разработчикам нужно их найти.

00:09:14.380 --> 00:09:17.460
Это задача портала разработчика. Портал разработчика – это веб-сайт,

00:09:17.660 --> 00:09:20.920
встроенный в каждый экземпляр и API-М. Разработчики используют его для просмотра

00:09:20.920 --> 00:09:24.900
ваших АПИ, чтения документации и интерактивного тестирования конечных точек прямо в браузере.

00:09:25.080 --> 00:09:29.720
Никакой настройки и переписки по электронной почте. Но есть нюанс – по умолчанию он не опубликован.

00:09:29.720 --> 00:09:33.700
Когда вы только создаете экземпляр и API-М, портал существует, но никто его не видит.

00:09:33.700 --> 00:09:37.640
Сначала его нужно настроить и опубликовать. Это сделано намеренно. Вы же не хотите

00:09:37.640 --> 00:09:40.900
показывать миру незавершенный портал. Вы можете настроить фирменные цвета,

00:09:41.060 --> 00:09:44.280
логотипы и даже встроить контент в Wordpress для блога рядом с документацией АПИ.

00:09:44.400 --> 00:09:47.140
Он полностью настраивается под стиль и имидж вашей компании.

00:09:47.380 --> 00:09:50.640
Главная ценность – самообслуживание. Разработчики регистрируются,

00:09:50.860 --> 00:09:54.240
автоматически получают ключи подписки и сразу начинают вызывать АПИ.

00:09:54.420 --> 00:09:58.500
Никаких ручных писем, ожиданий одобрения или этикетов в поддержку с вопросами о получении

00:09:58.500 --> 00:10:02.180
ключа. Они делают все сами, что значительно снижает нагрузку на вашу поддержку.

00:10:02.180 --> 00:10:05.180
Вы также можете публиковать журналы изменений и примечания к выпуску.

00:10:05.260 --> 00:10:08.860
Когда вы обновляете АПИ, разработчики видят это на портале без сюрпризов.

00:10:09.000 --> 00:10:12.660
Доступ может быть публичным для всех, у кого есть URL, или вы можете ограничить его

00:10:12.660 --> 00:10:16.380
пользователями вашего арендатора IntraID, чтобы просматривать могли только сотрудники

00:10:16.380 --> 00:10:19.640
организации. Оба варианта существуют для разных сценариев использования.

00:10:19.820 --> 00:10:23.220
Портал разработчика превращает ваше управление АПИ в полноценную платформу.

00:10:23.300 --> 00:10:26.660
Думайте о нем как о витрине для ваших АПИ. Без него разработчикам приходится

00:10:26.660 --> 00:10:30.300
искать документацию и расспрашивать коллег. С ним они находят то, что нужно,

00:10:30.300 --> 00:10:35.360
и начинают разработку. Безопасность, аутентификация, авторизация и секреты.

00:10:35.520 --> 00:10:38.480
Вся эта мощь бесполезна, если безопасность не обеспечена.

00:10:38.640 --> 00:10:42.300
Итак, давайте поговорим о том, как АПИМ управляет идентификацией, доступом и секретами.

00:10:42.420 --> 00:10:46.580
АПИМ поддерживает несколько методов аутентификации. Самый простой — это ключи подписки,

00:10:46.700 --> 00:10:49.960
о которых мы говорили ранее. Однако для промышленных систем требуются более надежные

00:10:49.960 --> 00:10:54.240
средства, такие как ОАТ-2, 0, JWT-токены, сертификаты клиентов или фильтрация по АПИ.

00:10:54.360 --> 00:10:57.140
Вы комбинируете их в зависимости от уровня конфиденциальности вашего АПИ.

00:10:57.140 --> 00:11:00.880
Для промышленной эксплуатации лучшей практикой является использование ОАТ-2, 0 секунд интро-ID.

00:11:01.080 --> 00:11:05.300
Вот как это работает. Клиентское приложение получает токен от интро-ID и отправляет его вместе

00:11:05.300 --> 00:11:10.440
с запросом к АПИ. АПИМ проверяет токен, анализируя подпись, издателя, аудиторию и срок действия.

00:11:10.600 --> 00:11:14.760
Если токен действителен, АПИМ перенаправляет запрос на ваш бэкенд, включая сам токен.

00:11:14.820 --> 00:11:19.320
Ваш бэкенд доверяет ему, так как АПИМ уже выполнил проверку, поэтому бэкенду не нужно проверять его

00:11:19.320 --> 00:11:22.060
повторно. Это на одну задачу меньше для каждого сервиса.

00:11:22.060 --> 00:11:26.520
Теперь поговорим о секретах. Ключи АПИ, строки подключения, сертификаты, вы не хотите жестко

00:11:26.520 --> 00:11:30.700
прописывать их в файлах политик или системе контроля версий. В АПИМ есть функция именованных

00:11:30.700 --> 00:11:34.700
значений. Вы храните секреты, централизованные в АПИМ, и ссылаетесь на них по имени в своих

00:11:34.700 --> 00:11:38.580
политиках. Фактическое значение никогда не отображается в коде вашей политики. Более того,

00:11:38.760 --> 00:11:42.760
вы можете подключить именованные значения к Azure Key Vault. Секреты остаются зашифрованными в Key Vault,

00:11:42.940 --> 00:11:46.980
а АПИМ извлекает их во время выполнения. Никто, даже ваша команда DefOps, не видит реального

00:11:46.980 --> 00:11:51.720
значения секрета. Когда нужно сменить ключ, вы обновляете его в Key Vault, и АПИМ автоматически

00:11:51.720 --> 00:11:56.300
подхватывает изменения. АПИМ также поддерживает управляемые удостоверения. Это позволяет

00:11:56.300 --> 00:12:00.680
АПИМ проходить аутентификацию в других сервисах Azure, таких как Key Vault или Backend API,

00:12:00.860 --> 00:12:04.520
не храня учетные данные. Azure управляет удостоверением, а вы просто предоставляете

00:12:04.520 --> 00:12:09.540
разрешение. Для сетевой изоляции вы можете развернуть АПИМ внутри виртуальной сети. Это уровень

00:12:09.540 --> 00:12:15.440
премиум. Или используете Azure Front Door? Суть в том, что ваши бэкенд-сервисы никогда не должны быть

00:12:15.440 --> 00:12:20.380
напрямую доступны из интернета. АПИМ – это единственное, что видит внешний мир. Такой

00:12:20.380 --> 00:12:24.520
многоуровневый подход создает глубокоэшелонированную защиту. Аутентификация на шлюзе,

00:12:24.720 --> 00:12:29.580
секреты в хранилище, сетевая изоляция вокруг ваших бэкендов. Каждый слой усиливает следующий.

00:12:29.700 --> 00:12:34.600
Ценовые уровни. Какой из них подходит вам? Итак, сколько это стоит? Давайте разберем уровни.

00:12:34.740 --> 00:12:38.660
Уровень потребления. Consumption. Оплата за каждый вызов АПИ без фиксированной ежемесячной стоимости.

00:12:38.880 --> 00:12:42.240
Идеально подходит для небольших объемов или эпизодических нагрузок. Например, на этапе прототипирования.

00:12:42.240 --> 00:12:46.080
Если вы еще не уверены, что вам нужно, начните с этого. Уровень разработчика. Девелопер предлагает

00:12:46.080 --> 00:12:49.860
фиксированную низкую ежемесячную стоимость около 50 долларов. Полный набор функций, но без SLA.

00:12:50.080 --> 00:12:53.420
Идеально для сред разработки и тестирования. Вы получаете все, что есть в премиум, но не можете

00:12:53.420 --> 00:12:56.260
использовать это в промышленной среде. Базовый уровень. Basic – это начальный уровень для

00:12:56.260 --> 00:12:59.180
производства. Более низкая пропускная способность. Отсутствие поддержки виртуальных сетей,

00:12:59.320 --> 00:13:02.540
но вы получаете реальный SLA. Подходит для внутренних инструментов или небольших проектов,

00:13:02.720 --> 00:13:06.280
где частная сеть не является критически важной. Большинство компаний выбирают стандартный

00:13:06.280 --> 00:13:11.640
уровень. Он включает поддержку виртуальных сетей, SLA 99,95% и хорошую пропускную способность.

00:13:11.800 --> 00:13:15.340
Если вы используете критически важные API, скорее всего, вы остановитесь на немецком.

00:13:15.480 --> 00:13:19.160
Уровень премиум предназначен для глобальных предприятий, которым нужна максимальная надежность

00:13:19.160 --> 00:13:24.560
и частные сети. Развертывание в нескольких регионах, собственный шлюз, SLA 99,99%, полная

00:13:24.560 --> 00:13:28.660
интеграция с виртуальной сетью. Стоимость начинается примерно от 2700 в месяц за единицу.

00:13:28.820 --> 00:13:34.340
Microsoft также представила уровни V2, Basic V2, Standard V2 и Premium V2. Они упрощают ценообразование

00:13:34.340 --> 00:13:37.960
за счет включенных квот на запросы и оплаты сверх лимита за миллион. Вместо отслеживания

00:13:37.960 --> 00:13:41.940
множества показателей, вы получаете понятный объем запросов и платите за превышение.

00:13:42.120 --> 00:13:45.960
Вот как сделать выбор. Начните с уровня девелопер для тестирования. Переходите на стандарт

00:13:45.960 --> 00:13:49.880
для промышленной эксплуатации. Выбирайте премиум, если нужен глобальный масштаб или частная сеть.

00:13:50.000 --> 00:13:53.800
И помните, что вы всегда можете перейти на другой уровень позже. Начните с малого и развивайтесь

00:13:53.800 --> 00:13:57.620
по мере роста ваших потребностей. Вот что мы рассмотрели. API Management упорядочивает

00:13:57.620 --> 00:14:02.220
хаос из множества API, собирая их в единый центр управления шлюзом, политиками и безопасностью.

00:14:02.220 --> 00:14:06.320
Главный вывод в том, что это больше, чем просто прокси. Представьте это как мозг и нервную

00:14:06.320 --> 00:14:09.800
систему вашей экосистемы API. Без этого каждая команда создает свою собственную аутентификацию,

00:14:09.920 --> 00:14:12.860
логирование и ограничение частоты запросов. В итоге вы получаете несогласованность,

00:14:13.020 --> 00:14:17.280
уязвимость и отсутствие единого представления о происходящем. С ним вы получаете согласованность,

00:14:17.500 --> 00:14:21.460
безопасность и масштабируемость, не изобретая велосипед для каждого сервиса.

00:14:21.660 --> 00:14:26.320
Вот простое упражнение. Вспомните один API, который вы сейчас предоставляете напрямую. Возможно,

00:14:26.540 --> 00:14:30.560
конечную точку функции или сервис приложений. Как использование API Management изменит

00:14:30.560 --> 00:14:34.440
вашу защищенность и возможность мониторинга использования. Даже простое обдумывание этого

00:14:34.440 --> 00:14:38.920
упражнения покажет вам его ценность. Следующий шаг – подпишитесь на канал. В будущих выпусках

00:14:38.920 --> 00:14:43.180
мы покажем, как импортировать API, применить первую политику и отслеживать использование в реальном

00:14:43.180 --> 00:14:47.100
времени. Вы перейдете от теории к практике. И если это было полезно, поделитесь этим с тем,

00:14:47.240 --> 00:14:51.100
кто создает приложение. Это спасет их от многих месяцев головной боли. Спасибо за внимание.