Почему популярная жилищная платформа Beike выбирает Apache APISIX

Привет, меня зовут Хуэй Ван, я отвечаю за разработку системы API-шлюза в компании Ke Holdings (Beike), ведущей интегрированной онлайн- и оффлайн-платформы для сделок и услуг в сфере недвижимости в Китае. Beike использует Apache APISIX в качестве API-шлюза в производственной системе. Как компания, ориентированная на данные, миллионы запросов ежедневно проходят через API-шлюз, и Apache APISIX демонстрирует стабильную и выдающуюся производительность. Недавно Apache APISIX присоединился к инкубатору Apache, и я хотел бы воспользоваться этой возможностью, чтобы поделиться причинами, по которым мы изначально выбрали Apache APISIX, а также опытом его использования.

Kong или Apache APISIX

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

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

После изучения официального сайта Kong и чтения нескольких связанных статей я подумал, что Kong — это подходящий вариант, так как он может удовлетворить большинство потребностей пользователей, а его производительность также очень стабильна. Я сразу же клонировал код и начал его изучать. Однако даже после нескольких дней исследования я чувствовал себя довольно растерянным. Я думаю, что понял причину, по которой у Kong такой огромный код: он должен предоставлять множество функций.

Внезапно в моей голове возникло несколько вопросов. Сколько времени мне потребуется, чтобы полностью понять Kong? Сколько времени потребуется для создания проекта, который соответствует всем требованиям? Нужны ли мне все эти функции, которые предоставляет Kong?

Несколько дней назад была выпущена версия 0.5 API-шлюза Apache APISIX. С учебной целью я быстро взглянул на этот открытый проект и с удивлением обнаружил, что его разработали Юаньшэн Ван и Мин Вэнь, два эксперта в области API. Я не мог отказаться от этого продукта, учитывая рекомендации этих экспертов.

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

Однако самой критической проблемой является то, что производительность Apache APISIX может быть слабым местом из-за его ограниченного времени существования в качестве открытого проекта. Сравнив результаты стресс-тестов с Kong в одинаковых условиях, Apache APISIX в конечном итоге победил Kong. Однако это не совсем справедливо для Kong, так как он гораздо более тяжелый и сложный. С другой стороны, в моем случае это не имеет значения, так как все необходимые функции предоставляются в Apache APISIX. Согласно отчету о производительности Apache APISIX, одноядерный процессор может достигать 24k QPS, при этом задержка составляет всего 0,7 миллисекунды.

В итоге я выбрал Apache APISIX по следующим причинам:

• При условии, что он может удовлетворить все потребности проекта, затраты на обучение Apache APISIX низкие
• У Kong большой объем кода, что делает его сложным для поддержки
• Авторы Apache APISIX более активны в сообществе OpenResty, что обеспечивает лучшее качество кода
• Самое важное — возможность быстро решить любые вопросы, напрямую общаясь с авторами

Причины выбора APISIX, предоставленные на официальном сайте, показаны на следующем рисунке:

Какие возможности предоставляет Apache APISIX

• Горячие обновления и плагины
• Динамическая балансировка нагрузки
• Активная и пассивная проверка здоровья
• Автоматическое отключение
• Аутентификация
• Ограничение скорости
• Преобразование протокола gRPC
• Динамический TCP/UDP, gRPC, WebSocket, MQTT брокер
• Панель управления
• Списки запрещенных и разрешенных
• Serverless

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

История интеграции APISIX

После нескольких дней изучения кода я получил базовое понимание Apache APISIX, но возник вопрос: я никогда не разрабатывал открытые проекты. Как я могу это сделать? Я создал три разные ветки локально: одна ветка Apache APISIX указывает на репозиторий с открытым исходным кодом, другая ветка dev используется для регулярных бизнес-итераций, а последняя ветка main используется для обновлений в реальном времени.

После двух недель напряженной работы мой проект наконец-то обрел некоторые базовые структуры. Пришло время проверить результат, и мы начали этап стресс-тестирования. Сервис развернут на Tencent Cloud с серверами на 8 ядер и 32 ГБ оперативной памяти, а вышестоящая среда — это обычная облачная производственная среда, поэтому тестирование не может быть слишком жестким. Отчет о производительности выглядит следующим образом:

Итог отчета о производительности: Время выполнения интерфейса сокращено на 47%, ошибки не возникают, стабильность улучшена. Пиковое значение TPS увеличено на 82%, ошибки не возникают, стабильность улучшена.

Разработка среды завершена, и мы начали изучать облачное развертывание. Apache APISIX поддерживает множество способов установки: Docker, RPM-пакеты, Luarocks и исходный код. Плохая новость заключается в том, что в облачной среде ничего нельзя устанавливать, и исходный код может быть размещен только по фиксированному пути. Поэтому многие функции Apache APISIX не будут поддерживаться, так как они разработаны на основе OpenResty 1.15.8. Что я могу сделать? Скомпилированные файлы генерируются в репозитории кода, их необходимо компилировать в определенном каталоге, и нельзя использовать статическую привязку PCRE, что заняло у нас 1-2 дня. В итоге мы настроили постепенное развертывание; трафик увеличился с 2% до полного объема в течение нескольких недель. К счастью, в конце концов все прошло успешно.

После нескольких недель мониторинга онлайн-сервис оказался относительно стабильным. Многие функции Apache APISIX 0.5 должны быть реализованы через вызовы API-интерфейсов. Параметры запроса склонны к синтаксическим ошибкам, и нет интуитивно понятной и удобной страницы. Кроме того, наш бизнес-сценарий требует наличия функции проверки вышестоящих сервисов. Совпадение ли это, что Apache APISIX версия 0.7 только что была выпущена, и версия 0.7 поддерживает консоль и проверку вышестоящих сервисов, что именно то, что нам нужно сейчас. Какая отличная новость! Нам нужно обновить!

Ветка Apache APISIX легко обновляется до 0.7, но как мы можем объединить код? Изменения кода между этими двумя версиями огромны. Я попытался сначала объединить их, но возникло слишком много конфликтов, и мы находимся в опасном темпе. Стандартный метод разрешения конфликтов нереалистичен, так как может вызвать множество скрытых ошибок. Есть ли эффективное решение? Я поискал в интернете и нашел быстрые методы: git checkout –ours и git checkout –theirs (пожалуйста, поищите, если вы не использовали их), и завершил обновление с APISIX 0.5 до 0.7 за несколько минут. Конечно, это также благодаря надежности кода APISIX, который позволяет мне только добавлять бизнес-плагины без какой-либо связи.

Поскольку Apache APISIX версия 0.7 предоставляет консоль, больше не нужно вручную составлять JSON. Я быстро проверил проверку здоровья, и сначала проблем не было, я мог видеть статус вышестоящего сервиса. Однако, когда я проверил логи вышестоящего сервиса, я обнаружил, что после нескольких перезапусков частота проверки здоровья продолжала увеличиваться. Я предположил, что в проверке здоровья может быть ошибка. После изучения исходного кода я обнаружил, что проверка для каждого маршрута не является глобально уникальной. Вместо этого каждый рабочий процесс имеет свою проверку. Мы можем решить эту проблему, используя одинаковое имя для всех созданных рабочих процессов. Даже если это небольшое исправление, необходимо отправить PR с горячим исправлением.

Я обновил бизнес-APISIX до версии 0.7 и начал мониторить использование ресурсов сервиса. В конце концов, это было значительное изменение версии, и в первые несколько часов я не заметил ничего необычного, как и в случае с версией 0.5. Я посмотрю еще раз, когда закончу работу. Кажется, что использование памяти не соответствует ожиданиям. Версия 0.5 была относительно стабильной, но версия 0.7, похоже, имеет утечку памяти. Поскольку использование памяти растет очень медленно, я решил мониторить его всю ночь. На следующий день я сравнил данные мониторинга, убедился, что утечка памяти действительно есть, и быстро откатился к предыдущей версии. После завершения всех действий я предоставил обратную связь Юань Шэну по этому вопросу. Согласно описанному мной сценарию, я обнаружил проблему с помощью стресс-тестирования. Это была проблема с radix tree. Та же проблема больше не возникала после обновления зависимостей, так как Юань Шэн выпустил новую версию radix tree.

После повторного запуска проекта Apache APISIX версия 0.7 продолжала удивлять меня время от времени. Зависимость маршрутизации, используемая в Apache APISIX 0.5, была libr3, в то время как Apache APISIX 0.7 использовал radix tree, который работает лучше. Процент использования CPU и памяти снизился. В Apache APISIX 0.5 использование CPU составляло 1-10%, а памяти — 0,1%. В Apache APISIX 0.7 использование CPU снизилось до 1-2%, а памяти — менее 0,1%, что отлично.

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

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

Наконец, я хотел бы поблагодарить Юань Шэна и Вэнь Мина за предоставление такого отличного продукта, а также сообщество Apache APISIX за вклад в итеративные функции. Сейчас ежедневный трафик шлюза превышает 100 миллионов, и проблем с производительностью нет. Спасибо за ваше время и внимание!