Как APISIX способствует локализованному развертыванию платформы социальных сетей Beeto на Ближнем Востоке

Обзор

Проблемы

• Монолитная архитектура сервисов приводит к высоким затратам на обслуживание и эксплуатацию
• Сложная архитектура развертывания и вызовы сервисов, а также множественные технологические стеки

Результаты

• Унификация трафика север-юг и восток-запад, экономия ресурсов и затрат на персонал, а также возможность динамического и унифицированного управления
• Упрощение архитектуры развертывания, что снижает взаимодействие между шлюзом и пользователями
• Множество расширений и плагинов APISIX помогли Beeto эффективно управлять проверкой прав доступа, распределением маршрутов и функциями проверки работоспособности сервисов
• APISIX позволяет Beeto динамически запускать и мигрировать сервисы, что удобно для разработчиков

Введение в Beeto

Для рынка Ближнего Востока Beeto — это арабская социальная медиаплатформа с локализованным дизайном продукта и технической архитектурой. Она занимала 4-е место в топе App Store для iOS в Саудовской Аравии, опережая гиганта социальных платформ Facebook.

Развитие интернета на Ближнем Востоке зрелое, с очень высокой проникновением активных пользователей в социальных сетях. Особенно в Саудовской Аравии, где 90% людей использовали интернет в 2019 году. В 2020 году Саудовская Аравия заняла 9-е место по проникновению активных пользователей.

Зрелость интернет-рынка привела к популярности международных социальных приложений, таких как WhatsApp, YouTube и Instagram. Тем не менее, отсутствует аналогичное локализованное социальное приложение, подобное Twitter. Поэтому, ориентируясь на "зрелый интернет, но слабую локализацию" на Ближнем Востоке, Beeto запустила локализованную разработку продукта.

Локализация важна для Beeto

Сравниваясь с приложениями с лентой новостей, такими как Twitter и Facebook, Beeto разработала относительно полную структуру для развертывания своей бизнес-архитектуры на Ближнем Востоке. Например, она стремилась удовлетворить потребности в социальном взаимодействии, потреблении контента (текст, видеотрансляции, локальная реклама и т.д.), а также различные бизнес-функции, такие как вознаграждения, вывод средств, голосования и лотереи в финансовых и сервисных категориях, а также требования к надзору за платформой и проверке безопасности контента.

Как уже упоминалось, зрелость интернета на рынке Ближнего Востока неизбежно требует высококачественных продуктов. Поэтому первая версия бизнес-архитектуры Beeto представляла собой полноценный продукт, объединяющий все функции, которые должны быть у основного социального приложения. В то же время цель Beeto — стать крупнейшей арабской социальной платформой и лучшим арабским сообществом на Ближнем Востоке с "функциями локализации". Для достижения этой цели Beeto проанализировала требования к локализации, как показано ниже.

Проблемы в архитектурном дизайне Beeto

Локализация включает существующие локальные социальные потребности на уровне бизнеса и локализованные операции на техническом уровне, такие как развертывание сервисов и хранение данных. Те, кто знаком с Weibo или Twitter, знают, что за таким огромным продуктом с потоком информации стоит десятки или сотни архитектурных систем. Проблемы в архитектуре Beeto выглядят следующим образом.

Монолитная архитектура сервисов приводит к высоким затратам

Сервисы Beeto можно разделить на восемь частей, как показано ниже.

Реализация этих бизнес-функций требует локализованного развертывания на Ближнем Востоке. Каждый сервис представляет собой отдельную монолитную архитектуру, если разделять каждый бизнес по сервисам.

На приведенной выше диаграмме монолитной архитектуры показана типичная архитектура развертывания. Возьмем, к примеру, сервис ленты новостей Beeto. Если мы хотим удовлетворить потребность пользователя в просмотре ленты новостей, мы должны поддерживать доступ к публичной сети, то есть доступ к трафику север-юг; в то же время сервис ленты новостей также предоставляет внутренние вызовы в форме тематического бизнеса, то есть вызовы трафика восток-запад.

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

Когда сервисы нескольких бизнесов объединяются, общая архитектура может выглядеть следующим образом:

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

Однако поскольку продукт Beeto находится на стадии запуска и продукт запущен на Ближнем Востоке, но его команда разработчиков находится в Китае, требуются значительные затраты на серверы и обслуживание. Кроме того, с увеличением бизнеса в будущем количество монолитных сервисов неизбежно увеличится, что сделает контроль затрат и операций обслуживания еще более сложным.

Сложность запуска нескольких сервисов

Помимо сложности архитектуры развертывания, вызовы между сервисами внутри кластера также очень сложны.

Трафик север-юг распределяется по различным пулам сервисов, а трафик восток-запад также переплетается между различными сервисами, причем отношения вызовов между этими сервисами переплетены.

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

Помимо сложных отношений вызовов, существуют также различия в технологических стеках между каждым сервисом. Например, в протоколе вызовов некоторые сервисы предоставляют HTTP, а другие — RPC; в плане разработки на языках программирования используется смесь Java, Go и других языков программирования.

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

Поскольку Beeto больше сосредоточена на обновлениях и итерациях бизнеса, архитектура разработана для облегчения обслуживания и унифицированного управления, так как же достичь этой цели?

Шлюз APISIX усиливает архитектуру Beeto

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

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

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

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

Практики после внедрения APISIX

Apache APISIX, как API-шлюз, может обрабатывать различные политики на уровне шлюза, такие как аутентификация, переадресация сервисов и проверка работоспособности. Поэтому Beeto провела множество экспериментов на уровне бизнес-практик после внедрения APISIX.

Безопасность: Плагин аутентификации

Трафик север-юг: Cookie

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

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

Преимущества такого подхода заключаются в следующем:

1. Обеспечивается безопасность cookie пользователей. Только уровень шлюза может получать и обрабатывать cookie во время выполнения, поскольку cookie являются чувствительными данными. Это предотвращает проблемы безопасности, вызванные несогласованностью правил обработки бизнеса, и эффективно избегает утечки cookie из-за человеческого фактора и нерегулярностей.

2. Снижение сложности проверки cookie для сервисов. Cookie необходимо проверять локально или удаленно, а также требуется одновременное обновление сервисов при обновлении cookie. APISIX унифицирует управление и проверку, экономя затраты на проверку бизнес-сервисов и указывая результаты, которые могут быть использованы для обработки бизнес-правил, что позволяет каждому бизнесу сосредоточиться на самом бизнесе.

Трафик восток-запад: Token

На диаграмме ниже Сервис A вызывает Сервис B. Обычно для взаимного вызова достаточно API. Однако во внутреннем процессе необходимо понимать "кто вызвал API, как он был вызван, нужно ли проверять права доступа, нужно ли контролировать исследователя" и так далее, что требует внутренней обработки.

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

Благодаря правилу токена App key, вышеуказанная операция может быть легко отслежена до источника вызова, что может быть использовано для устранения неполадок и контроля доступа, а также для эффективного контроля над незаконными вызовами. Таким образом, преимущество унифицированной аутентификации заключается в том, что, будь то трафик север-юг или восток-запад, она обеспечивает безопасность и единообразие кластера, что значительно помогает в отслеживании проблем и контроле вызовов.

Масштабируемость: Бессерверное расширение и миграция сервисов

Общая архитектура развертывания кластера Beeto сверху вниз состоит из: кластеров шлюза APISIX — кластеров бизнес-сервисов бессерверных сервисов — кластеров центров данных сервисов с состоянием. При локальном развертывании на Ближнем Востоке они все развернуты на крупных облачных кластерах. В зависимости от масштаба облачного покрытия на Ближнем Востоке и облачных провайдеров в разных регионах, необходимо учитывать расширение и миграцию облачных сервисов при развертывании сервисов.

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

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

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

Функциональная расширяемость: Динамическая переадресация сервисов

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

Те, кто знаком с интерфейсом и бэкендом приложений, знают, что разные страницы продукта предоставляются разными сервисами. Страница состоит из разных модулей, содержание которых отправляется через API. Какие данные API отправляет в модуль, то и отображается на клиенте. Это общая спецификация рендеринга на стороне клиента, чтобы сделать процесс рендеринга на стороне клиента более универсальным, а обработку бизнеса более гибкой.

В реализации PageA на рисунке выше, например, клиент вызывает API Сервиса A, отправляет данные соответствующего модуля и завершает рендеринг PageA. Эта операция вызывает проблемы, так как клиенту необходимо поддерживать каждую страницу и API для каждого сервиса. Если контент изменяется, это необходимо решать через публикацию, что очень неудобно с точки зрения оперативности и эффективности.

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

Клиенту нужно только определить спецификацию рендеринга в течение всего процесса, а не источник данных. Уровень шлюза берет на себя ответственность за распределение сервисов и переадресует трафик напрямую. Файл конфигурации плагина в APISIX может быть динамически обновлен в реальном времени, а правила переадресации могут быть динамически изменены, что очень гибко. Фактически, для приложений с архитектурой BFF (Backend for Frontend) такие требования могут быть решены на уровне шлюза.

Заключение

В этой статье представлены практики применения Beeto после внедрения Apache APISIX с точки зрения дизайна и бизнеса.

APISIX помог Beeto контролировать затраты на ресурсы и несколько бизнес-линий продуктов, а также реализовать локализованное развертывание, унифицированное управление и удобные сценарии обслуживания на Ближнем Востоке.