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

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

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

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

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

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

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

[
'error' => 'OVERLOAD_LIMIT',
'error_description' => 'REST API is blocked due to overload.'
]

SDK CRest

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

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

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

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

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

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

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

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

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

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

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

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

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

.

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

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

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

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

Он выбирает порталы по группировке и создает новые функции: Код Отправки запросов (скрыты некоторые моменты) Логика такая: функция собирает N-e количество запросов из Базе данных; запросы собираются в batch, чтобыс количество хитов было минимальным для запроса в Битрикс24 и не превышало лимиты; batch забираются, отправляются. Функция получает результаты и сохраняет их в таблицу в Базе данных. Этот не слишком сложный код работает как отдельный микросервис. Если событий мало, а запросов много, нужно поднять количество функций отправки запросов и всё будет работать быстро. Код доступен на портале для разработчиков по адресу https://dev.bitrix24.ru/workgroups/group/51/ (Нужно будет авторизоваться). Там же подробная инструкция о том, как настроить работу с облаком - добавить функции, какие методы вызывать, на какие триггеры эти функции добавить. Там же прикреплен архив с первой версией этого SDK.

  Выводы

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

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

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

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