что такое вебхуки и как их использовать
Пользователей известного мессенджера часто интересует, что такое Discord Webhook php, и для чего используется эта опция. Простыми словами, после включения функции можно получать сообщения и информацию об обновлении данных по текстовому каналу в автоматическом режиме. Ниже рассмотрим, в чем особенности вебхуков в Дискорде, как их создать и пользоваться. Рассмотрим, с какими серверами может взаимодействовать Discord Webhook php.
Назначение и особенности
Для начала рассмотрим, что такое вебхуки в Дискорде, и для чего они нужны. Если говорить в целом, этом метод увеличения функциональности приложения с помощью обратных вызовов. Последние могут обслуживаться разработчикам или пользователями, которые не обязательно связаны с программой. Сам термин «вебхук» придуман Джеффом Линдсеем в 2007 году.
Discord Webhook php представляет собой дополнительную опцию. С ее помощью участник программы получает автоматические оповещения об обновлении данных по текстовому каналу.
Грамотное управление вебхуками позволяет получать данные с других платформ. При создании конечного сервера Webhook php на Discord пользователь генерирует адрес Webhook, который можно отправить на разные сервисы и связать их с Дискордом.
Как пользоваться
Применение Discord Webhook php требует подключения другого интернет-ресурса. Но нужно учесть, что не все сервисы способны передавать данные по этому каналу. Перед тем как пользоваться вебхуками, важно разобраться, на каком сервисе они поддерживаются.
Webhook PHP работает на таких сайтах:
Выделяется ряд сервисов, которые не могут работать с Webhook:
Эти моменты необходимо учесть, перед тем как использовать Discord Webhook php для обновления сервера.
Если вы решили сделать обновление Дискорд-сервера с помощью поручений или pull-запросов ГитХаб, ДатаДог или других сервисов, сделайте следующие шаги:
После этого в списке появляется созданный Discord Webhook php с названием, информацией о сервере и датой создания. С правой стороны доступна кнопка Изменить. При ее нажатии можно внести правки в имя, канал или установленную ранее картинку.
Как интегрировать Дискорд с другим сервисом
Выше мы рассмотрели, как сделать Discord Webhook php в приложении и внести необходимые параметры. Но нужно понимать, что вебхук не способен работать сам по себе. Ему требуется взаимодействие с другим сайтом. При правильной настройке инструмент можно использовать для отправки любого кода или обновления на текстовый канал сервера.
Алгоритм действий такой:
Очень важно, чтобы вебхук показывал ссылку корректно. Это крайне важный параметр, от которого зависит работоспособность инструмента. Обратите внимание, что к концу ссылки URL обязательно прикрепляется надпись github после слеша. Учтите, что ее нет при копировании непосредственно с программы Discord.
В разделе Content Type установите application/json. В следующей секции можно выбрать ивент-тригеры, которые будут использоваться при передаче информации в сообщениях. Здесь можно выбрать один из трех вариантов:
На завершающем этапе жмите на кнопку Add Webhook под опцией настройки извещения. После этого любые обновления в репозитарии, в том числе изменение информации в redmi, отображается в текстовом канале. В результате получается такая ссылка — discordapp.com/api/webhooks/698070180693278780/XG1VRZQ8cGnCEG9wNjbvpSk605AugbK3HQ9Hxk8aJ9bm1MCfsL6gFSqV3U-SZkdxY0a8/github.
Учтите, что выше мы рассмотрели один из вариантов — как настроить вебхуки в Дискорде для Github. При выборе другого сервиса принцип остается неизменным.
Итоги
Теперь вы знаете, что такое Discord Webhook php, для чего необходима эта опция, и как ей правильно пользоваться. Помните, что инструмент работает не на всех сервисах, поэтому с его настройкой необходимо быть внимательным. Если все сделать правильно, вы получаете свой club со своевременной передачей информации в текстовом канале.
Реализация вебхуков на примере взаимодействия сторонних сервисов с онлайн-кассами
Я попросил нашу команду маркетинга нарисовать иллюстрацию и долго объяснял, что такое вебхуки
Не так давно передо мной встала задача реализовать работу вебхуков в Личном кабинете владельца кассы компании Дримкас. Как оказалось, в сети практически нет описания и туториалов, как это сделать. Я расскажу, как мы это реализовали без тяжелых кронов по БД.
Статья будет полезна для middle node.js-разработчиков.
Где используем вебхуки
Для понимания специфики, придется начать издалека.
Дримкас производит онлайн-кассы и облачный сервис Кабинет Дримкас. Все кассовые аппараты в реальном времени отправляют данные о продажах по интернету в налоговую — это требование нового закона. Подключаясь к Кабинету, владелец кассы получает удаленный доступ к этой статистике продаж и другие инструменты.
Кабинет Дримкас позволяет владельцу кассы из веб-интерфейса следить за продажами, работать с отчетами, создавать, редактировать и автоматически загружать на все кассы товарную базу, подключать внешние товароучетные системы.
Вебхуки нам понадобились, когда мы подключали к Кабинету интернет-магазины. Для онлайн-торговли тоже нужна касса, только бумажный чек не печатается. Мы решили создать для них инструмент, чтобы они могли из обычного json-а с данными о покупке записать данные о продаже в ФН и передать их в ОФД.
Так как операция фискализации может затянуться на длительное время, превышающее обычный HTTP запрос, нам потребовалось дать возможность узнавать статус этого чека. Каждый раз стучаться в Кабинет за статусом чека не выгодно ни нам, ни Интернет магазину. А с вебхуками убиваем сразу двух зайцев: Кабинет делает запрос только один раз, а интернет-магазин получит чек, как только он будет готов.
Когда мы начали их внедрять, решили дать доступ к этому функционалу сервисам интеграторов. С их помощью сторонние сервисы, которые подключены к Кабинету, получают уведомления о продажах, открытии/закрытии смен, создании и редактировании товаров, внесении и изъятии денег. Мы не остановились до сих пор, и все важные события мы сразу переводим на вебхуки.
Наши требования к вебхукам
Текущий стэк бэкенда
Мы пишем на node.js. В качестве веб фреймворка выбран koa. У нас две базы данных. Postrges с sequelize, где хранятся сильно связанные данные, например, кассы и пользователи. Для хранения несвязанных и неизменяемых данных — чеков, смен — мы используем MongoDB. Ещё повсеместно используются очереди на rabbitMQ, для сглаживания скачкообразных нагрузок. Плюс redis для кэша.
Реализация вебхуков
Определяем события для вызова вебхуков
Для начала определим места, где хотим вызывать вебхуки. На уровне модели мы можем пользоваться хуками в mongoose и в большинстве случаев в sequelize.
Исторически так сложилось, что в нашей sequelize-модели нельзя создать товар сразу с данными. Мы создаем пустой товар и сразу его изменяем, поэтому пришлось руками во всех контроллерах добавить обработчики вызовов вебхуков.
Когда нет такой проблемы, всё достаточно просто. Пример из модели mongoose:
Подписки на события
Чтобы определить понятие подписки на определенные события, мы используем битовые маски.
В бэкэнде мы храним всю информацию о типах событий одним числом, а фронту отправляем готовый json объект:
Чтобы упаковать число в json и извлечь его обратно, мы создаем виртуальные атрибуты в sequelize. В них устанавливаем геттеры и сеттеры. Виртуальные поля вычисляются на лету, изменяют на поля в таблице, но при этом не хранятся БД.
CRUD для управления вебхуками
Пользователь управляет вебхуками из веб-интерфейса или через API. Поэтому нам нужны стандартные CRUD для этой модели.
Подготовка к вызовам
Мы не вызываем вебхуки в статическом методе класса Webhook — это позволяет сберечь ресурсы основного сайта. Это работа воркеров — делать фоновые задачи, не мешая работе с REST-API.
Когда на сайте генерируется событие, мы оповещаем воркеров об этом:
Вкратце, что мы делаем: ищем в БД все вебхуки у данного пользователя, у которого есть подписка на текущее событие. Кэшируем их, даже если ничего не нашли — если пользователь загружает кучу товаров, будут лишние запросы в БД. Когда есть вебхук, кидаем в очередь задачу с временной меткой, ссылкой, идентификатором и типом события.
Тут есть нюанс: мы экономим ресурсы сайта, и кидаем в очередь только идентификатор объекта. Если есть возможность, лучше кидать сам объект. Когда создают объект и сразу удаляют его, в очередь падает два задания. Первое задание при выполнении не сможет вытащить из базы тело объекта. Если кидать всё тело объекта, таких проблем не будет.
Вызовы и повторные вызовы вебхуков
У нас в стеке используется очереди сообщений. Мы выбрали 5 временных промежутков, и на каждый создали очередь. Если вызов не удался при первой попытке, вебхук переходит в следующую очередь. Когда воркер получает на вход задачу, он откладывает его выполнение на требуемое количество времени от 0 миллисекунд до суток. Через 24 часа мы вызываем вебхук в последний раз и удаляем.
Пример вебхука, который не могут принять в течение суток.
Каждая следующая задача в очереди не может быть вызвана раньше текущей, так как добавилась туда позже. Поэтому когда мы взяли из очереди задачу и увидели, что вызывать вебхук ещё рано, мы не завершаем эту задачу, чтобы не получить следующую.
Еще 4 факта
Что такое Webhook?
Если вы уже занимаетесь автоматизацией вашего бизнеса или только планируете, то вам наверняка уже приходилось сталкиваться с этим малопонятным термином. Итак, многие задаются вопросом, что такое Webhooks? В данном материале мы максимально простыми словами расскажем о том, что это Webhook означает.
Сегодня уже многие знают про API – под этим термином скрывается то, что можно охарактеризовать как специальный язык, который программы используют для общения друг с другом. Используя API, одно приложение может отправить запрос другому для того, чтобы получить в ответ (также при помощи API) какую-либо требуемую информацию.
Для чего используется Webhook
Webhook также используется для того, чтобы различные системы могли обмениваться друг с другом информацией. Вот только «общение» тут происходит по иному принципу. Этот механизм специально создавался для того, чтобы упростить процедуру уведомления о разных событиях – изменении настроек, добавлении нового пользователя, удалении сообщения и т.п.
Принцип работы Webhooks
Принцип работы вебхуки заключается в том, что как только какое-либо событие произошло, об этом сразу же отсылается соответствующее уведомление. И, если в случае с API приложение, которому нужна информация, должно постоянно отправлять запросы типа «это уже случилось?», то при использовании Webhook оно просто ждёт соответствующего уведомления. Единственно что требуется – указать, какие именно сообщения нужно отправлять и куда.
Иными словами, разницу в работе API и Webhook можно описать фразой «не надо постоянно спрашивать меня, произошло ли данное событие, как только оно произойдёт, я сам об этом сообщу». Естественно, что это очень простое описание, но оно хорошо передаёт общий принцип работы «вебхуков».
Осталось только добавить, что термин Webhook появился относительно недавно. Его впервые использовал в 2007 году программист Джефф Линдсей, который и разработал данную технологию. Создавая новое слово, он взял за основу термин «Hook», который программисты используют для описания технологии внесения изменений в стандартное поведение системы.
Вебхуки и Apix-Drive
Налаживая интеграции между системами, мы активно используем, как API, так и Webhooks. Классический пример – интеграция с конструктором сайтов Tilda была реализована именно посредством «вебхуков». Благодаря этому вы можете получать уведомления о самых разных действиях посетителей созданного вами сайта. Например, как только новый покупатель оставит заявку через форму, его контакты будут автоматически внесены в вашу CRM-систему. Применяются «вебхуки» и для интеграции с другими конструкторами сайтов, вроде Bloxy, Landingi и Nethouse.
Ещё примеры использования Webhook – сервис телефонии Telphin, конструктор маркетинговых квизов Enquiz и конструктор чат-ботов Chatra. На самом деле подобных примеров можно привести ещё множество. Но главное тут не в количестве систем, а в простоте их подключения для конечного пользователя.
Для того чтобы наладить интеграцию с любым из подобных сервисов, не нужно понимать глубинные принципы работы технологии Webhook. Отсутствие таких знаний никак не помешает вам наладить связи между самыми разными системами, сделав это просто в несколько кликов мышкой. И никаких сторонних разработчиков, никаких специализированных знаний не потребуется.
Не верите что всё так просто? Зарегистрируйтесь и проверьте на практике!
Результаты поиска « код вставки виджета »
Описание API
Инструменты
Методы API — Webhooks
Примеры
Методы API — Пользователи
Методы API — События
Методы API — Оплаты от юрлиц
Методы API — Заказы
Методы API — Словари
Методы API — Организации
Коллбэки и webhooks
Что такое webhook
Webhook — механизм получения уведомлений об определённых событиях на TimePad (в основном о действиях пользователей) на свой собственный сайт.
Например, на TimePad есть webhook, который позволяет отслеживать изменения статусов регистрации пользователей. Он вызывается каждый раз при изменении любого билета вашей организации. По сути происходит вот что: данные регистрации кладутся в JSON и отправляются на URL, указаный в настройках организации.
Как настроить webhook
Для использования достаточно прописать в настройках организации URL, на который будет отправляться POST-запрос.
В поле Ссылка для уведомления нужно оставить адрес, к которому TimePad будет обращаться в случае смены статусов билетов, а в поле Секретная фраза — ключ, которым будет подписано сообщение от TimePad. И не забудьте нажать «Сохранить».
После этого при любой смене статуса билета в вашей организации — например, при регистрации или оплате — будет выполняться POST-запрос на адрес, который вы указали в настройках.
Как прочитать webhook
Пример чтения webhook’а в PHP
Типы вебхуков
Сейчас существует 3 типа вебхуков:
Использование вебхуков по изменению статуса заказа и билета
Вебхуки по заказу и билетам связаны между собой. При любом измении заказа посылается вебхук по заказу и вебхуки по каждому из билетов в заказе.
Данные вебхуки посылаются в случаях:
Содержание JSON запроса для хука изменения статусов заказа
Структура аналогична ответу API по заказам OAuth2. Пример такого json’a:
Содержание JSON запроса для хука изменения статусов билетов
Список возможных статусов билетов
Поля status:name / status_raw в запросе могут содержать следующие значения (в скобках указаны соответствующие значения поля status:title / status )
Как отвечать на webhook
В таких случаях запрос будет отправлен на этот же адрес с теми же данными через час. Если эта попытка тоже не удалась, следующая состоится через сутки. После этого запрос будет удалён из очереди, даже если доставка так и не состоялась. Следите за своими серверами 😉
Проектирование системы, принимающей вебхуки
Разрабатывая систему, принимающую вебхуки, лучше снадбите её логами — какие вебхуки приходили.
Обязательно предусмотрите у себя следующие свойства вебхуков (кстати, все это относится к вебхукам абсолютно любых систем):
Порядок прихода вебхуков не обязательно хронологический
Вебхуки отправляются в множество потоков. Совершенно не исключен тот факт, что какой-то из потоков отправит более поздний вебхук быстрее, чем соседий поток — более ранний. Если нарушение хронологии может вам что-то сильно сломать — проверяйте дату хука (поле hook_generated_at ), сравнивайте её с датой последнего хука по той же сущности, который вы приняли.
Вебхук может не прийти вовсе
Когда отправитель вебхука видит, что отправленный запрос не завершился корректно (HTTP статусом 200 OK), он его обычно переотправляет (еще одно место где может сбиться хронология). Вторая отправка чаще всего завершается успехом.
Один и тот же вебхук может прийти несколько раз
Достаточно часто бывает так, что принимающая сторона на самом деле обработала вебхук и ответила корректным статусом, но отправитель этого ответа не дождался или интерпретировал его неверно (например, при проблемах сети).
В этом случае отправитель сделает повторную попытку отправки вебхука и принимающая сторона будет обязана обработать его корректно – т.е. проигнорировать, но отправить ответ HTTP 200 OK. Вы можете проверять GUID вебхука (поле hook_guid ).
При отправке вебхука есть таймаут
Наш сервер 5 секунд ждет ответа о том, что вебхук обработан. Если вам этого времени может не хватать (много обработки, медленное соединение, высокая нагрузка), используйте механизм очередей — приняв вебхук, ставьте его обработку в очередь и отвечайте, что вебхук принят.
Эволюция обработки вебхуков Facebook: с нуля до 25 000 в секунду
Скорее всего, рассказывать, что такое вебхуки (webhooks) — никому не нужно. Но на всякий случай: вебхуки — это механизм оповещения о событиях во внешней системе. Например, о покупке в интернет-магазине через онлайн-кассу, отправке кода в GitHub-репозиторий или действиях пользователей в чатах. В типичном API нужно постоянно опрашивать сервер, написал ли пользователь что-нибудь в чате. С помощью механизма вебхуков можно «подписаться» на оповещения, и сервер сам отправит HTTP-запрос, когда произойдет событие. Это удобнее и быстрее, чем постоянно запрашивать новые данные на сервере.
ManyChat — это платформа, которая помогает бизнесу общаться со своими клиентами через чаты в мессенджерах. Вебхуки — одна из важных частей ManyChat, потому что именно через них бизнес общается с клиентами. А общаются они много — например, через систему бизнесы отправляют своим клиентам миллиарды сообщений в месяц.
Основная масса сообщений отправляется через Facebook Messenger. У него есть особенность — медленный API. Когда клиент пишет сообщение, чтобы заказать пиццу, Facebook отправляет в ManyChat вебхук. Платформа его обрабатывает, отправляет запрос обратно и пользователь получает сообщение. Из-за медленного API некоторые запросы идут несколько секунд. Но когда платформа долго не отвечает, бизнес теряет клиента, а Facebook может отключить приложение от вебхуков.
Поэтому обработка вебхуков — это одна из главных инженерных задач платформы. Чтобы решить проблему, в ManyChat за три года работы несколько раз меняли архитектуру обработки с простого контроллера в Yii до распределенной системы с «Галактиками». Подробнее об этом под катом расскажет Дмитрий Кушников (@cancellarius).
Дмитрий Кушников руководит разработкой в ManyChat и профессионально программирует на PHP с 2001 года. Дмитрий расскажет, как менялась архитектура вместе с ростом сервиса и нагрузкой, какие решения и технологии применялись на разных этапах, как эволюционировала обработка вебхуков и как платформе удается справляться с огромной нагрузкой с помощью скромных ресурсов на PHP.
Примечание. Статья основана на докладе Дмитрия «Эволюция обработки вебхука Facebook: с нуля до 12 500 в секунду» на PHP Russia 2019. Но пока он готовился, показатели выросли до 25 000.
Что такое ManyChat
Для начала введу в контекст наших задач. ManyChat — это сервис, который помогает бизнесу использовать мессенджеры для маркетинга, продаж и поддержки. Основной продукт — это платформа для Messenger Marketing в Facebook Messenger. За три года сервисом воспользовалось больше 1 миллион бизнесов из 100 стран мира, чтобы пообщаться с 700 миллионов своих клиентов.
Со стороны клиента это выглядит так.
Кнопки, картинки и галереи в диалогах в Facebook Messenger.
Это интерфейс Facebook Messenger. Кроме текстовых сообщений, в нем можно отправлять интерактивные элементы, чтобы взаимодействовать с клиентами, вовлекать в диалог, повышать интерес к своим продуктам и продавать.
Со стороны бизнеса все выглядит иначе. Это интерфейс нашего веб-приложения, где с помощью визуального интерфейса представители бизнеса создают и программируют сценарии диалогов. На картинке один из примеров сценария.
Сердце нашей системы — компонент Flow Builder.
Совокупность сценариев и правил автоматизации мы называем ботом. Поэтому, если упростить, то можно сказать, что ManyChat — это конструктор ботов.
Пример бота.
Клиент бизнеса, который участвует в диалоге, называется подписчиком, потому что для взаимодействия клиент подписывается на бота.
Почему Facebook
Почему Facebook Messenger, мы же страна выжившего Telegram? На это есть причины.
Взаимодействие с Facebook
Взаимодействие с Facebook устроено примерно так:
Бизнес использует веб-приложение для настройки логики бота. Когда клиент взаимодействует с ботом через телефон, Facebook получает об этом информацию и отправляет нам вебхук. ManyChat его обрабатывает, в зависимости от логики, которая запрограммирована бизнесом, и отправляет запрос обратно. Дальше Facebook доставляет сообщение в телефон пользователя.
Технологический стек
Все это мы делаем на скромном стеке. В основе, конечно, PHP. Веб-сервером работает Nginx, основная база данных — PostgreSQL, а еще есть Redis и Elasticsearch. Все это крутится в облаках Amazon Web Services.
Обработка Facebook Webhook
Примерно так выглядит вебкух Facebook’а: это запрос с payload в формате JSON.
Вебхуки — это всего 10% нашей нагрузки, но важнейшая часть системы. Через них бизнес общается с пользователями. Если сообщения тормозят или не отправляются, то пользователь отказывается взаимодействовать с ботом, а бизнес теряет клиента.
Давайте посмотрим на эволюцию нашей архитектуры с момента запуска продукта.
Май 2016 года. Мы только запустили наш сервис: 20 ботов, из которых 10 тестовые, и 20 подписчиков. Нагрузка составляла 0 RPS.
Схема взаимодействия выглядела так:
Связка Nginx и PHP-FPM
Июнь 2016. Через месяц мы анонсировали ManyChat на ProductHunt и количество ботов выросло до 2 тысяч. Число подписчиков увеличилось до 7 тысяч.
В этот момент появилась первая проблема в системе. API Facebook не очень быстрый: некоторые запросы могут длиться несколько секунд, а несколько запросов десятки секунд. Но сервер вебхуков хочет, чтобы мы отвечали быстро. Из-за медленного API мы долго не отвечаем: сервер сначала ругается, а потом может вообще отключить приложение от вебхуков.
Пользователей мало, мы еще разрабатываем приложение, ищем наш рынок, аудиторию, а уже появилась проблема нагрузки. Но нас спасло простое решение: в тот момент, когда запускается контроллер, прерываем обращение к Facebook. Мы говорим Facebook, что все хорошо, а сами в фоне обрабатываем запросы и вебхук.
Очереди на PostgreSQL
Декабрь 2016. Сервис вырос в 5-10 раз: 10 тысяч ботов и 700 тысяч подписчиков.
Параллельно мы работали над новыми задачами: отображение статистики, доставляемость сообщений,, конверсии показов и переходов. Также реализовали Live Chat. Кроме автоматизации взаимодействий он дает бизнесу возможность писать сообщения своему подписчику напрямую.
Решение этих задач увеличило количество отслеживаемых хуков в 4 раза. На каждое отправляемое сообщение мы получали 3 дополнительных вебхука. Систему обработки снова требовалось улучшать. Мы маленькая платформа, на бэкенде работало всего два человека, поэтому выбрали самое простое решение — очереди на PostgreSQL.
Мы пока еще не хотим реализовывать сложные системы, поэтому просто разделяем потоки обработки. Вебхуки, которые нужно обрабатывать быстро, чтобы пользователь получил ответ, обрабатываем синхронно. Все остальные отправляем в очереди для асинхронных запросов.
Очереди на Redis
Июнь 2017. Сервис растет: 75 тысяч ботов, 7 миллионов подписчиков.
Мы реализуем еще одну новую функцию. Все вебхуки, которые мы обрабатывали, касались только коммуникаций в мессенджере. Но теперь мы решили дать бизнесам возможность общаться с подписчиками бизнес-страниц и начали обрабатывать новые типы вебхуков — те, что касаются ленты самой страницы.
Ленты бизнес-страниц обновляются не так редко. Маркетологи часто что-то постят, потом следят за каждый лайком и считают их. Огромного трафика на бизнеса-страницах нет. Но бывают обратные ситуации, например, «день Кэти Перри».
Кэти Перри — знаменитая американская певица с огромным количеством фанатов по всему миру. Только в ее группе на Facebook 64 миллиона подписчиков. В какой-то момент маркетологи певицы решили сделать бота на Facebook Messenger и выбрали нашу платформу. В тот момент, когда они опубликовали сообщение с призывом подписаться на бот, наша нагрузка выросла в 3-4 раза.
Эта ситуация помогла нам понять, что без нормальной реализации очередей мы ничего не можем сделать. Как решение выбрали Redis.
Выбрать Redis для очередей — фантастически удачное решение.
Он помог решить огромное количество задач. Сейчас каждую секунду через наш Redis-кластер проходит 1 миллион разных запросов. Мы используем его не только для всех каскадных очередей, но и для других задач, например, мониторинга.
Очереди на Redis реализовали не с первой попытки. Когда мы начали просто складывать вебхуки в Redis и обрабатывать их одним процессом, то расширили воронку наверху: входящих вебхуков стало больше, обработанных тоже, но сам процесс все равно занимал какое-то время. Это первое решение было неудачным.
Когда же попробовали масштабировать количество этих запросов, случился небольшой коллапс. В очереди могут скапливаться запросы от разных страниц, но могут идти подряд запросы от одной страницы. Если один обработчик медлит, то запросы от одного подписчика и от одного бота будут обработаны в неправильном порядке. Пользователь отправляет сообщения, выполняет какие-то действия с ботом, но получит ответ вразнобой.
Кажется, что это редкий случай, но тестирование на наших нагрузках показало, что это будет происходить часто.
Мы начали искать другое решение. Здесь на помощь пришла простота и мощь Redis — мы решили сделать очередь на каждого бота.
Как это работает? Сообщения, которые касаются каждого бота, складываем в очередь. Чтобы не поднимать обработчик на каждую очередь, сделали контрольную очередь. Она работает так. Каждый раз, когда приходит запрос от бота, в Redis публикуются два сообщения: одно в очередь бота, второе в контрольную. Обработчик следит за контрольной и каждый раз запускает демона, когда там есть задача обработать бота. Демон разгребает очередь соответствующего бота.
Дополнительно к основной задаче мы решили проблему «шумных соседей». Это когда один бот сгенерировал огромную массу вебхуков и она тормозит систему, потому что другие страницы ждут обработку. Для решения проблемы достаточно масштабироваться: когда контрольная очередь наполняется мы добавляем новых обработчиков.
Кроме того, очереди виртуальные. Это всего лишь ячейки в памяти Redis. Когда в очереди ничего нет, её не существует, она не занимает ничего.
ReactPHP
Январь 2018 года. Мы достигли отметки в 1 миллиард сообщений в месяц.
Нагрузка составляла 5 тысяч RPS на систему. Это не пиковая нагрузка, а стандартная. Когда появляются боты знаменитых певиц все растет в несколько раз уже от этой цифры. Но это не проблема. Проблема в PHP-FPM: он уже не выдерживает нагрузку в 5 тысяч RPS.
Все в то время говорили о модном асинхронном процессинге. Мы к нему присмотрелись, увидели ReactPHP, провели быстрые тесты, заменили им PHP-FPM и мгновенно получили прирост в 4 раза.
Мы не стали переписывать обработку нашего процессинга — ReactPHP поднимал фреймворк Yii. Сначала мы подняли 4 ReactPHP-сервиса, а позже дошли до 30. Достаточно долго мы жили именно на них, а фреймворк справлялся с нагрузкой.
Как только мы расширили воронку, случился еще один коллапс: после запуска воронки на приёме опять начал страдать процессинг. Чтобы решить уже эту проблему, решили выделить процессинг в кластеры.
Кластеры
Взяли ботов, распределили их по кластерам и выстроили логические цепочки из Redis, Postgres и обработчика.
В итоге у нас сформировалось понятие «Галактика» — логически физическая абстракция над процессингом. Она состоит из инстансов: Redis, PostgreSQL и набора PHP-сервисов. Каждый бот принадлежит какому-то кластеру, и ReactPHP знает о том, в какой кластер нужно поместить сообщение для данного бота. Дальше работает схема выше.
Вселенная расширяется, Вселенная наших систем тоже, и мы добавляем новую «Галактику» когда это происходит.
«Галактики» — это наш способ масштабирования.
Заменяем ReactPHP на связку Nginx и Lua
Следующие полгода мы продолжали расти: 200 миллионов подписчиков и 3 миллиарда сообщений в месяц. Представьте сайт на 200 миллионов зарегистрированных пользователей — те же нагрузки.
Возникла новая проблема. Вебхуки — это небольшие однотипные задачи, а PHP не подходит для их решения. Даже ReactPHP уже не помогал.
Мы вспомнили, что у Nginx есть модули и заметили библиотеку OpenResty. Кроме поддержки языка программирования Lua у нее был модуль работы с Redis. Написанный за 3 часа тест показал, что всю работу 30 сервисов на ReactPHP можно выполнить прямо на стороне nginx.
Так выглядит то, что у нас получилось: обрабатываем какой-то endpoint, забираем тело запроса и складываем его напрямую в Redis.
OpenResty и Lua помогли увеличить пропускную способность. Мы продолжаем справляться с нашей нагрузкой, сервис живет, все счастливы.
Улучшаем решение на Lua
Последний этап (прим: на момент доклада) — февраль 2019. 500 миллионов подписчиков отправляют и получают от миллиона ботов 7 миллионов сообщений каждый месяц.
Это этап улучшения нашего решения на Lua. Постепенно откусываем некоторую логику из очередей, а первичный процессинг распределения вебхуков между системами переносим на Lua. Теперь наши системы производительнее и менее зависимы.
Мы сохраняем по отдельности процессинг и асинхронную обработку. Обработка касается статистики и прочего — теперь это совершенно другая система.
Система кажется простой, но это не так. Под капотом крутится 500 сервисов, которые обрабатывают свои запросы. Вся система работает на 50 инстансах Амазона: Redis, PostgreSQL и сами обработчики PHP.
Эволюция процессинга
Highload можно классно делать на PHP.
Кратко вспомним как мы это делали в процессе развития системы.
На своем опыте мы выяснили, что можно расти и строить архитектуру последовательно меняя уязвимые части, применять простые известные подходы и при этом не расширять стек.
В этом рассказе мы проследили за решением технической задачи, а как тем временем эволюционировали процессы в компании, Дмитрий Кушников расскажет уже 11 февраля на TeamLead Conf. Из доклада узнаем, когда эффективно внедрение LeSS, а когда от этой методологии лучше отказаться.
А в календаре на весну у нас PHP Russia и Saint HighLoad++, и для этих конференций мы еще только формируем программу. Если в вашем стеке PHP занимает достойное место, вы научились готовить с ним сложные проекты и готовы поделится рецептами — приходите выступать на PHP Russia 13 мая. А если у вас highload без PHP, то ждём на Saint HighLoad++ в апреле в Питере.