42  /  44

Работа под высокими нагрузками

Просмотров: 338

Немного теории

На рисунке показано, как работает самая нагруженная точка приложения - входящие события от Битрикс24:

veb19.png
  • Все облачные порталы отправляют свои запросы в OAuth OAuth - открытый протокол авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищенным ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль.
    Подробнее...
    -сервер.
  • OAuth-сервер добавляет туда токены от вашего приложения и отправляет их на сервер очередей.
  • Сервер очередей все запросы отправляет по адресам, которые вы указали в обработчиках, подписываясь на события.

И основная проблема в том, что если вы подпишетесь на очень много событий, то одновременно их может прийти слишком большое количество. Если сервер не успевает ответить (например, он завис или подвергса DDoS-атаке), то через 3 секунды вы попадете на красный сервер очередей, в котором собираются медленные приложения с низким приоритетом, и работа вашего приложения ухудшится. Поэтому нужно отвечать быстро и четко.

Немного статистики

Исходя из этой теории, понятно, что основными требованиями к приложению будут:

  • Гарантия обработки - приложение не должно терять данных
  • Автомасштабируемость - чтобы переносить пиковые нагрузки
  • Быстрый ответ < 3 сек.

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

SDK CRest

Для реализации микросервисной архитектуры разработана новая версия SDK CRest на Python. Она может работать как с тиражными, так и с локальными приложениями.

Как работает данная версия SDK:

veb9.png
  • Все входящие события, которые создают основную нагрузку, принимает первая Cloud Functions. Эта функция veb10.png обрабатывает события, перформатируя их для SQS Amazon Simple Queue Service (англ. Amazon SQS) — сервис принимает очереди сообщений для хранения. При использовании Amazon SQS, разработчики могут просто переместить данные, распределённые между компонентами своих приложений, которые выполняют различные задачи, не теряя при этом сообщения. При этом достигается высокая масштабируемость и надёжность.
    Подробнее...
    , и сохраняет их в SQS. Тем самым она может ответить даже меньше чем за 1 сек, т.к. количество действий у нее минимальное.
  • После такой быстрой обработки входящих событий приложения, другой функцией veb11.png на триггерах из SQS автоматически разбирается каждое событие и отправляется в Базу данных. Тут важно, что событие или данные не потеряются и не пропадут незамеченными, т.к., если даже База данных подвисла, на триггерах из SQS можно повторить попытку несколько раз.
  • Далее включается функция veb12.png
    , которая сохраняет в Базу данных. И если у нее не получилось сохранить, то она возвращает ошибку и сообщение возвращается в SQS, чтобы обработаться еще раз.

Таким образом можно снизить нагрузку для таких критически важных частей, как База данных.

Бизнес-логика приложения

Рассмотрим простой сценарий работы приложения:

veb18.png

Приложение может быть написано на любом удобном языке.

Порядок работы может быть таким:

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

Как видите, не требуется никаких дополнительных действий. В таблице запросов к Базе данных предусмотрена ячейка Callback`a и возможность отправки событий под определенным пользователем. Если, например, в событии мы сохранили токены, которые пришли с запросом, то мы можем отправить их в таблицу запросов в Битрикс24 и ответ уйдет именно с токеном текущего пользователя, который вам необходим.

Менеджер очереди

Как же уходят запросы к Битрикс24?

Есть функция Менеджер очереди:

veb14.png.

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

  1. Менеджер очереди поднимает функцию с контекстом портала.
  2. Из Базы данных функция забирает все запросы к текущему порталу.
  3. Функция отправляет запросы к Битрикс24.
  4. После того, как Битрикс24 вернет ответы на запросы, функция сохранит их в Базу данных.
  5. Через Callback можно реализовать доступ к таблице запросов и необходимую доработку.

Пример - если подписаться на событие Добавление лида, то всё, что придет - ID лида. Можно сделать в приложении запрос в таблицу Базы данных об этом лиде и добавить в ячейку таблицы Callback-функцию, которая будет запускаться после того, как придет дополнительная информация по лиду. Функция обработает информацию, сохранит результат и на следующем шаге можно доработать всё, что необходимо сделать с этим лидом.

Логика и код Менеджера очереди

  Выводы

Выводы о новой SDK CRest Python:

  • Облачная структура – плата только за использование.
  • Бесконечное масштабирование архитектуры.
  • Обработка ответов сервера, автоматическое продление токенов администратора.
  • Запросы собираются автоматически в batch.
  • Приложения на одном Битрикс24 - пойдут в одном потоке и будут иметь общие лимиты.
  • Open-source.

Выводы о работе облачной архитектуры под высокими нагрузками:

  • Гарантия обработки.
  • Бесконечное масштабирование архитектуры.
  • Быстрый ответ <3 сек.
  • Автомасштабируемость.
  • Минимальное количество усилий для поддержания системы.



0
Курсы разработаны в компании «1С-Битрикс»

Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.
Развернуть комментарии