iQIYI открывает инновации API Gateway с помощью Apache APISIX

Обзор

Проблемы

1. Большой трафик приводит к ежедневным уведомлениям о слишком низком уровне простоя CPU.
2. Слишком много компонентов зависят от архитектуры системы.
3. Высокая стоимость эксплуатации и обслуживания (O&M).

Цели

1. Выбрать высокопроизводительный API-шлюз, соответствующий требованиям iQIYI.
2. Минимизировать затраты на миграцию.
3. Найти API-шлюз с активным сообществом и здоровой экосистемой.
4. Построить новый API-шлюз, соответствующий трендам облачных технологий.

Результаты

1. Производительность улучшилась в 10 раз, обрабатывая миллионы запросов в секунду ежедневно.
2. Легко поддерживает более 9,000 API онлайн-бизнес-проектов.
3. Успешно реализована аварийная регенерация данных на множестве сайтов и уровней по всей Китае.

Что произошло за кулисами iQIYI?

Конг Хэ, старший инженер по разработке в iQIYI, поделился докладом на встрече Apache APISIX в Шанхае. Он работает в команде облачных вычислений отдела инфраструктуры IIG и отвечает за разработку шлюза и операционную работу в iQIYI. Давайте углубимся в его доклад и историю API-шлюза iQIYI, чтобы лучше понять Apache APISIX.

Основанная 22 апреля 2010 года компанией Baidu, создателем крупнейшей китайской поисковой системы, iQIYI в настоящее время является одним из крупнейших мировых сайтов онлайн-видео, с почти 6 миллиардами часов, проведенных на его сервисе каждый месяц, и более чем 500 миллионами активных пользователей в месяц.

iQIYI ранее разрабатывала собственный API-шлюз под названием Skywalker, основанный на Kong. Skywalker сегодня должен обрабатывать огромный трафик, и его пиковая нагрузка может достигать миллиона запросов в секунду и тысяч маршрутов API. Однако недостатки этого продукта начали проявляться постепенно.

1. Производительность шлюза больше не удовлетворяет требованиям iQIYI, и он получает множество уведомлений о слишком низком уровне простоя CPU из-за большого трафика.
2. Слишком много зависимостей компонентов от архитектуры системы.
3. Слишком высокая стоимость эксплуатации и обслуживания.

После того как Конг взял на себя этот проект в этом году, он начал исследовать аналогичные продукты шлюзов для решения вышеуказанных проблем и трудностей и в итоге нашел Apache APISIX.

Как Apache APISIX превосходит Kong

Прежде чем выбрать Apache APISIX, iQIYI уже начала использовать Kong, но позже отказалась от него.

Почему отказались от Kong?

После практического использования Kong, Конг объяснил, почему его команда отказалась от Kong. Ниже приведены несколько основных недостатков Kong.

1. Маршруты Kong используют поиск по обходу, что не очень быстро.
2. База данных Postgres в Kong приводит к громоздкому развертыванию, неэффективной синхронизации и низкой доступности.
3. Код имеет высокую степень связанности.

Почему выбрали APISIX?

"Мы сравнили производительность Apache APISIX и Kong во время исследования и с удивлением обнаружили, что Apache APISIX в 10 раз лучше Kong с точки зрения оптимизации производительности. Мы также сравнили Apache APISIX с другими основными продуктами шлюзов, и задержка ответа Apache APISIX всегда более чем на 50% ниже, чем у других продуктов. Более того, Apache APISIX может стабильно работать даже при использовании CPU более 70%. APISIX действительно впечатляет!" — сказал Конг.

И Apache APISIX, и Kong были разработаны на основе OpenResty на техническом уровне, что обеспечивает относительно низкую стоимость миграции. Кроме того, Apache APISIX обладает отличной адаптивностью и может быть легко развернут в различных средах, включая облачные платформы.

"Тем временем мы также обнаружили, что Apache APISIX — это высокоактивный проект с открытым исходным кодом, который быстро решает проблемы. Его облачная архитектура также соответствует нашим планам на будущее. Таким образом, мы выбрали Apache APISIX в качестве нашего API-шлюза."

Инновации в архитектуре API-шлюза iQIYI после использования APISIX

После выбора отличного API-шлюза iQIYI начала создавать новую архитектуру API-шлюза, которая показана ниже, включая доменное имя, шлюз, экземпляры сервисов и мониторинг с уведомлениями.

DPVS — это проект с открытым исходным кодом, разработанный на основе LVS компанией iQIYI. Мониторинг и уведомления Hubble также являются глубокой кастомизацией на основе проекта с открытым исходным кодом, а также были сделаны оптимизации производительности и высокой доступности Consul.

Достижение 1: Улучшение плоскостей данных и управления для кластеров и управления сервисами

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

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

Достижение 2: Добавление новых функций: контроль безопасности, ограничение скорости и мониторинг

iQIYI реализовала некоторые базовые функции в архитектуре API, такие как ограничение скорости, аутентификация, уведомления, мониторинг и т.д., после перехода на Apache APISIX.

Первая часть касается HTTPS. Для контроля безопасности iQIYI не хранит сертификаты или ключи на серверах шлюза, а на выделенном удаленном сервере. Однако это было сложно реализовать при использовании Kong; вместо этого iQIYI использовала префикс NGINX для разгрузки HTTPS. После миграции на Apache APISIX iQIYI успешно реализовала эту функцию на Apache APISIX, что экономит еще один уровень передачи по каналу.

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

Функция мониторинга и уведомлений реализована с использованием встроенного плагина Apache APISIX — Prometheus, и данные показателей напрямую отправляются в систему мониторинга компании. Apache APISIX также поддерживает iQIYI в логировании и анализе трассировки.

Достижение 3: Установлен процесс динамического обновления обнаружения сервисов

Что касается обнаружения сервисов, упомянутого выше, оно в основном регистрирует сервисы в кластерах Consul через сервисный центр, а затем использует DNS-обнаружение сервисов для их динамического обновления. QAE на графике — это микросервисная платформа, используемая внутри компании. Давайте используем пример, чтобы кратко продемонстрировать процесс обновления экземпляров.

При обновлении экземпляров мы сначала отключаем соответствующие узлы из Consul и отправляем запросы на обновление DNS-кэша на шлюз через контроллер API-шлюза. Когда кэш успешно обновлен, контроллер отправляет запросы на платформу QAE, чтобы остановить все связанные узлы бэкенд-приложений, чтобы избежать перенаправления трафика на отключенные узлы.

Достижение 4: Улучшена возможность направленных маршрутов

Шлюз имеет развертывание на нескольких сайтах, и был заранее построен полный набор резервных каналов на нескольких сайтах. Кроме того, Конг также рекомендует пользователям иметь развертывание с ближайшим доступом на нескольких сайтах для своих бэкенд-сервисов. Таким образом, пользователи могут создать API-сервис на платформе шлюза Skywalker, и контроллер развернет маршруты API во всех кластерах шлюзов DC. В то же время, CNAME домена сервиса по умолчанию будет направлен на унифицированное доменное имя шлюза.

Apache APISIX может напрямую предоставлять услуги с ближайшим доступом на нескольких сайтах и возможностью аварийного переключения для восстановления после сбоев, а также поддерживает пользовательское определение маршрутов. Кроме того, пользователи могут настроить конфигурацию разрешения маршрутов через доменное имя UUID, если им нужно аварийное переключение, сине-зеленое развертывание и канареечное развертывание. Дополнительно, Apache APISIX также поддерживает пользовательское планирование восстановления бэкенд-сервисов.

Достижение 5: Улучшена многосайтовая и многоуровневая отказоустойчивость

Для обработки ситуаций с большим трафиком, множеством кластеров и широкой аудиторией клиентов, iQIYI требует доступа к ближайшему сервису и аварийного восстановления на операционном уровне.

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

1. Если самый удаленный узел бэкенд-сервиса выходит из строя, iQIYI может достичь отключения одного узла или аварийного переключения неработоспособного DC через механизм проверки работоспособности сервисного центра и шлюза. Таким образом, влияние будет ограничено конкретными сервисами, не затрагивая пользователей.
2. Если шлюз выходит из строя, то iQIYI может использовать механизм проверки работоспособности L4 DPVS для отключения неработоспособных узлов шлюза, и влияние относительно невелико, не затрагивая пользователей.
3. Если вышеуказанные меры по отключению не могут восстановить неработоспособный узел, то iQIYI может достичь автоматического аварийного переключения в DNS через тестирование доступности на уровне доменного имени в экстранете. Однако этот метод относительно медленный и может повлиять на многие другие сервисы, и пользователи могут быть осведомлены об этом.

Планы iQIYI на будущее

В интеграции с APISIX iQIYI пытается оптимизировать некоторые проблемы, чтобы лучше соответствовать своему бизнесу.

1. Учитывая возможные узкие места некоторых зависимых компонентов, таких как etcd, мониторинг Prometheus и сервис логирования, iQIYI планирует использовать гибридный метод развертывания. То есть: делиться информацией внутри больших кластеров и сохранять независимость небольших кластеров. Например, важные сервисы будут развернуты с небольшими кластерами.

2. Будет проведено больше соответствующих сокращений и оптимизаций для метрик мониторинга Prometheus, особенно для DNS-обнаружения сервисов.

Конг сказал: "Мы надеемся, что Apache APISIX сможет поддерживать больше функций и сохранять отличную производительность и стабильность в будущих разработках и обновлениях."

Ищете поддержку APISIX?

Хотите ускорить свою разработку с уверенностью, как iQIYI? Чтобы максимально использовать поддержку APISIX, вам нужен API7. Мы предоставляем глубокую поддержку APISIX и решения для управления API в соответствии с вашими потребностями!

Свяжитесь с нами в любое время: https://api7.ai/contact.