Webhook что это

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

Leo Matyushkin

В сфере веб-разработки наряду с API распространилось понятие вебхук (англ. webhook). Рост популярности этого стандарта связан с тем, что всё больше действий в вебе можно описать в терминах событий. Триггерами, запускающими вебхук, могут служить, например, отправка кода в репозиторий или публикация комментария.

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

Чем вебхуки отличаются от API?

В типичных API для получения информации от сервера его необходимо постоянно опрашивать. В случае вебхуков сервер как бы говорит клиенту: «Теперь тебе не придется названивать. Я сам позвоню, когда появится что-то новое».

То есть с помощью вебхука клиент «подписывается» на получение оповещений в заранее определенных случаях. Такой подход удобнее и для провайдера информации, и для клиента. При этом вебхуки используют HTTP, то есть не требуется добавления какой-то дополнительной инфраструктуры.

Вебхук делает HTTP-запрос к вашему приложению (чаще всего POST-запрос в JSON-формате), а интерпретация запроса уже зависит от принимающей стороны. Вебхуки — это своеобразные «обратные API» – интерфейс взаимодействия с запросом должен быть построен на стороне клиента.

У большинства API необходимо вначале отправить запрос, за которым последует ответ системы. В случае вебхука вы заранее настраиваете, при каких событиях сервер отправляет данные. Рассмотрим на примере.

В случае API приложение сервера предоставляет приложению клиента адреса, которые может вызывать приложение на стороне клиента. Например, для доски сообщений запросы к API могут выглядеть следующим образом:

Для вебхуков ситуация обратная: уже приложение клиента предоставляет приложению сервера адреса для вызова. А приложение сервера в свою очередь использует эти URL, когда на стороне сервера происходит какое-либо интересующее клиента событие.

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

Примеры использования вебхуков

Оглянувшись вокруг, мы увидим, что многие компании внедрили вебхуки в своей практике. Несколько примеров:

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

Попробуйте свои силы

Лучший способ понять технологию применения вебхуков — это попробовать ее в деле. Давайте поэтапно рассмотрим процесс настройки и получения вебхука на реальном примере.

Даже если у вас нет приложения и соответствующих URL, можно попробовать технологию вебхуков в деле. Для таких задач создан ресурс webhook.site. Он генерирует уникальную ссылку для проверки входящих POST-запросов.

Скопируем сгенерированную ссылку, и, оставив страницу открытой, передадим URL провайдеру вебхука. Например, настроим вышеупомянутый вебхук в GitHub. Для этого перейдем в каком-либо из своих репозиториев в раздел Settings/Webhooks и нажмем кнопку Add webhook.

Заполнение открывшейся формы является процессом настройки вебхука. В поле Payload URL вставим запасенную ссылку с webhook.site. В качестве Content type выберем application/json. Далее отметим события, при которых GitHub будет отправлять запрос, например, комментарий коммита.

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

При этом GitHub в соответствии с вебхуком сразу же отправит POST-запрос на нашу ссылку. Вернувшись на страницу webhook.site, увидим, что в списке запросов добавился новый. В панели справа мы можем видеть детали запроса, заголовки и сам JSON-объект (для удобства чтения выберите пункт Format JSON).

Изучив JSON, вы заметите, что GitHub отправляет исчерпывающую информацию даже для такой простой операции, как комментарий коммита. Для сравнения в новой вкладке браузера перейдите по той же тестовой ссылке для приема запросов. Вы увидите, какую информацию дает «пустой» GET-запрос.

Аналогично можно протестировать другие интересные вам ресурсы. Например, подробное пособие есть у Slack. А Dropbox умеет высылать уведомления на универсальный идентификатор ресурса, когда пользователь вашего приложения вносит изменения в файл.

Отладка вебхуков

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

Безопасность использования вебхуков

Если вебхуки доставляют данные в приложение по публичным URL, кто-то может перехватить эти ссылки и подменить ложными данными? Чтобы этого не случилось, вы должны предпринять ряд мер. То, с чего нужно начать – использовать протокол HTTPS. Вы можете пойти дальше и еще больше обезопасить соединение:

Важные замечания

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

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

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

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

Источник

Реализация вебхуков на примере взаимодействия сторонних сервисов с онлайн-кассами

Я попросил нашу команду маркетинга нарисовать иллюстрацию и долго объяснял, что такое вебхуки

Не так давно передо мной встала задача реализовать работу вебхуков в Личном кабинете владельца кассы компании Дримкас. Как оказалось, в сети практически нет описания и туториалов, как это сделать. Я расскажу, как мы это реализовали без тяжелых кронов по БД.

Статья будет полезна для 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

Вебхук (webhook) – это способ отправки уведомлений пользователю сайта. Если данные на сайте меняются, сервер создает HTTP-вызов и отправляет информацию получателю через вебхук. В данных будет указан тип события и ссылка на объект.

Например, в товароучетную систему внесли новый продукт. Система сформирует уведомление и отправит его пользователю через вебхук.

Как выглядит

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

В чем разница между API и вебхуками

Информацию об изменениях в системе можно получать через API или вебхук. Оба способа помогают одной программе взаимодействовать с другой.
Принцип работы АПИ – отправка циклических запросов и получение данных в ответ. То есть пользователю нужно постоянно запрашивать информацию у сервера, чтобы получить новые данные.
Вебхук же работает по принципу подписки: вы однократно настраиваете оперативное уведомление для посетителей сайта, а система автоматически оповещает их о новых событиях в компании.

Когда нужно использовать API, а когда – вебхук

Вебхук только уведомляет об изменениях в системе. Он полезен, когда нужно:

Для работы с базами данных нужен API. Он позволяет создавать, читать, изменять и удалять информацию.
Чтобы оценить эффективность вашей рекламной кампании и оптимизировать бюджет на маркетинг, пользуйтесь специальными сервисами. Подключите сквозную аналитику Calltouch. Программа отследит все лиды, заявки и продажи, выведет на удобные дашборды статистику по рекламным доходам и расходам. Вы сможете скорректировать свою маркетинговую стратегию и отказаться от убыточных рекламных вложений.

Примеры использования webhook

Вебхуками пользуются на всех крупных площадках. Например:

Как создать тестовый вебхук

Для создания тестового вебхука иметь свою площадку необязательно. Воспользуйтесь сервисом Webhook.site. Действуйте следующим образом:

Безопасность использования

Вебхуки доставляют данные через публичные URL. Адреса могут перехватить, подменить в них данные.
Чтобы избежать подобных рисков, воспользуйтесь советами:

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

Ограничения при работе с вебхуками

Если вы решили использовать вебхуки, учтите:

Как проверить, что вебхук работает

Работоспособность вебхука можно проверить через специальный сервис. Он создаст тестовый URL и покажет нужный вам тип уведомлений.

Проверьте наличие уведомления по вашей уникальной ссылке.

Коротко о главном

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

Источник

Вебхук

Вебхук — это способ оповещения клиента о произошедшем в системе событии с помощью пользовательских обратных вызовов по HTTP.

Это термин из мира WEBа и программирования. Вебхук запускается, когда на вашем сайте, в CRM, чат-боте или иной системе происходит какое-то событие. Например, человек написал комментарий или в товароучетную систему добавили новый товар. Когда происходит такое событие, сервер создает HTTP-вызов и отправляет его на адрес, указанный клиентом для получения вебхуков. Клиент вовремя получает свежие данные — клиент доволен.

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

Зачем нужен вебхук, если есть API

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

Если простыми словами, вебхук — как бы подписка на обновления для определенных событий. Сервер будет оповещать клиента только о тех изменениях, которые ему по-настоящему важны. Он сам сообщит об этих событиях при настройке вебхука.

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

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

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

Вебхук работает в обратном порядке: URLы для отправки запроса формируется клиентом. А сервер, если на его стороне происходит важное для пользователя событие, использует эти URLы для отправки оповещения программному клиенту.

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

Как выглядит вебхук

По сути, вебхук — это программный код. Обычно он состоит из двух частей — переменной и самих данных. Например, как здесь. «First name» — это переменная, а «Anton» — это данные, которые передаются с помощью вебхука, которые постоянно меняются и подставляются системой. Количество переменных определяется софтом, на события в котором реагирует вебхук

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

Как используют вебхуки на практике

Сегодня вебхуки используются повсеместно. Вот несколько примеров на скорую руку:

Чтобы упростить работу с вебхуками, поставщики данных предоставляют пользователям готовые интерфейсные панели. На них можно создать новый вебхук, указать URL, на который будет отправлен вызов, выбрать событие и передаваемые параметры. Пользователю не нужно возиться с кодом — он заполняет простую форму, а за программную часть работы отвечает поставщик данных. Панель для создания и управления вебхуками от сервиса Callibri. Пользователь указывает адрес для отправки запроса, задает событие и его параметры. А все остальное делает сам сервис

Создаем тестовый вебхук

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

Чтобы создать тестовый вебхук, не нужен свой сайт или приложение. Проверить работоспособность входящего запроса можно с помощью специального сервиса — Webhook.site. Он генерирует для вас тестовый урл, который можно использовать для отправки POST-запроса и проверки его содержимого на этом же сайте. Показываем, как это работает. Для проверки будем использовать свой репозиторий на Github.

Если вы пользуетесь сервисом, который дает возможность отправлять уведомления с помощью вебхуков, протестируйте его похожим образом. Например, если используете Dropbox, можно протестировать отправку уведомлений для события «внесение изменения в файл».

Помощь в отладке вебхуков

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

Безопасно ли пользоваться вебхуками

Обычно механизм использования вебхуков предусматривает доставку данных программному клиенту через публичные адреса URL. Это небезопасно: любой может перехватить эти адреса и подменить передаваемые данные в своих корыстных целях. Но этого можно избежать. Есть несколько способов:

О чем нужно помнить, если используешь вебхуки

Возможна потеря данных. Бывает, что доставив запрос с данными программному клиенту, вебхук перестает отвечать. Обычно это связано с ошибкой на стороне сервиса. С чем бы это ни было связано, из-за такой ошибки всегд аесть риск потерять данные. Поэтому мы советуем заранее готовиться к тому, что приложение или сайт могут упасть. Узнайте заранее, как поставщик данных обрабатывает ответы и создает ли он резервные копии на случай, если сервис ляжет.

Приложение может не выдержать нагрузку. В зависимости от вида вашей деятельности и настроенных триггеров, события на стороне сервера могут происходить слишком часто. Чем больше триггеров для отправки вебхука вы задаете, тем чаще программный клиент будет получать POST-запросы. Убедитесь, что ваше приложение готово к получению запрашиваемого объема данных. Если на сервере возникнет высокая активность, клиентское приложение может не выдержать нагрузки. Так бывает, например, при DDoS-атаках.

Не стоит передавать через вебхуки данные. Технически технология вебхук позволяет передавать программному клиенту объемные массивы данных. Но делать этого не стоит. Используйте вебхуки лишь для уведомления об изменении состояния на сервере. А когда сигнал получен — вызывайте API,запрашивайте данные и получайте настоящую нагрузку. Такой способ позволяет надежнее обрабатывать данные и не перегружать систему.

Источник

Что такое вебхук и как он работает

Webhook — это технология передачи данных из одного сервиса в другой по определенным событиям. Благодаря вебхукам вы можете создавать различные интеграции между софтами и автоматизировать бизнес-процессы. Передача данных идет через API.

У программистов может быть разное описание вебхуков, но в этой статье я хочу рассказать это простым языком тем, кто ничего не понимает в программировании.

Во многих софтах вы увидите функции отправки вебхуков. Вот пример их сервиса для автоматизации маркетинга ActiveCampaign. В поле URL мы указываем место куда будут отправляться данные. А в разделе “Type” мы укажем trigger, по которому будут отправляться данные.

В разных сервисах по разному выглядят эти разделы, но принцип остается один и тот же. У нас есть причина, по которой отправляются данные (trigger), и место, куда они отправятся (URL). Также, в некоторых софтах вы можете указывать какие данные вы хотите отправлять. В некоторых, система отправляет все данные, которые есть. Вот пример с сервиса для Фэйсбук чат-бота ManyChat. Вы можете настраивать какие данные передавать.

Давайте представим сценарий, когда к нам в CRM попал лид, мы должны оповестить руководителя отдела продаж в Gmail.

Триггером для вебхука будет “Deal added”. Соответственно система отправит данные об этом лиде на указанный URL. Но то, что вы отправили данные на указанный URL вам не поможет уведомить руководителя. Нужно чтобы “кто-то” подхватил эти данные и отправил в Gmail. Именно этим и занимается наш сервис Apiway. Получается, что CRM система отправила нам данные, Apiway их принял и дал сигнал в Gmail, чтобы он отправил email с указанными данными.

Вебинар по рекламе «3 секрета работы с Google Ads»

Зачем софты делают вебхуки?

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

По сути софты говорят вам: “Укажите какие данные? После какого действия отправлять данные? (trigger) и куда отправлять данные?”. Они как бы отправляют данные в “космос”, а задача программистов эти данные уже поймать и передать в другие системы. К счастью, мы в Apiway уже сделали много интеграций и теперь вам не придется создавать эти интеграции.

У нас уже есть готовый функционал приема вебхуков. То есть, если вы в каком-то софте видите поле “Вубхуки”, это значит что вы уже можете их отправлять/принимать через Apiway без программирования.

Как выглядит вебхук

Тело вебхука состоит из двух частей. Переменной и самих данных.

Допустим “First name” — это переменная, а “Anton” это сами данные, которые подставляются и меняются. Количество вариантов переменных зависит от софта, из которого отправляется вебхук.

Вам не нужно понимать и тем более писать код. Система сама формирует код и отправляет его на указанный URL. Софты по типу Apiway могут ловить эти данные и передавать в другой сервис в своем графическом интерфейсе.

Маркетолог должен понимать что такое вебхук и как он работает, но кодить он не должен.

Источник

Вебхуки

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

Что такое вебхук?

Непосредственно сам вебхук содержит описание изменения (тип объекта и ссылку на изменившийся объект), которое отправляется на указанный url. Пример тела запроса вебхука:

В чем разница между АПИ и вебхуками

Есть 2 подхода для получения сведений об изменениях в системе: опрос через АПИ (polling) и подписка на вебхуки. Опрос через АПИ предполагает циклические запросы, чтобы получить изменения. Подписка на вебхуки предполагает получение уведомления об изменении в системе. Можно провести следующую аналогию. Предположим вы заказали товар, но его не оказалось в наличии, поэтому вы каждый день звоните в магазин, чтобы узнать о появлении товара, это похоже на опрос через АПИ. Но вы можете просто попросить менеджера в магазине позвонить вам по указанному номеру телефона, когда товар появится, это подписка на вебхуки. Очевидно, что подписка на вебхуки эффективнее и проще, так как гарантируется оперативное получение изменений в системе и меньшая нагрузка на клиентское приложение.

Когда нужно использовать АПИ, а когда вебхук

Несмотря на преимущество использования вебхуков, важно понимать, что подписка на вебхуки это всего лишь форма уведомления об изменениях в системе. Действия с сущностями (CRUD) необходимо выполнять с помощью АПИ.

Возможные сценарии, когда подписка на вебхуки выглядит предпочтительнее опросов через АПИ:

Как использовать вебхуки через JSON API

Вебхуки в JSON API

Работа с вебхуками в МоемСкладе возможна только через JSON API. Методы работы с вебхуками позволяют создать, удалить, обновить, получить и отключить вебхуки.

Ключевыми признаками вебхука являются адрес отправки (url), тип сущности (entityType) и тип события (action). Пара признаков (entityType и action) должна быть уникальной, т.е. не может повторяться в других вебхуках. Существуют следующие типы событий (action):

Данные типы событий могут быть применимы ко всем типам сущностей (базовые сущности и документы). Обратите внимание, что отчеты и аудит не являются сущностями.

Рассмотрим методы работы с вебхуками. Для создания вебхука достаточно указать url, entityType и action, как в примере ниже

В ответ должен придти json, содержащий описание вебхука

Как и в других запросах сущностей JSON API другие действия над вебхуками возможны только при указании идентификатора. В полученном json поле id. Пример получения вебхука по идентификатору.

У вебхука можно изменить поля, указанные при создании, а также включить/отключить его. Для этого выполняется PUT запрос с указанием идентификатора. Пример запроса с изменением события

Пример запроса с отключением вебхука.

Удаление вебхука выполняется по аналогии, но только используется метод DELETE.

Получить все вебхуки можно с помощью типичного GET запроса.

В ответ придет коллекция вебхуков.

Ограничения при работе с вебхуками

При работе с вебхуками есть ряд важных замечаний:

Отправка вебхука в клиентское приложение

МойСклад отправляет вебхук в клиентское приложение с помощью метода POST, указывая заголовок User-Agent со значением MoySklad webhook touch agent 1.0 (/https://www.moysklad.ru).

При отправке уведомления вебхука, МойСклад ожидает ответ от клиентского приложения со статусом 200 или 204, чтобы считать уведомление доставленным. При невалидном ответе от клиентского приложения наша система осуществляет еще 3 попытки отправки. Данные попытки осуществляются последовательно, без таймаутов между ними. Если все попытки закончились неудачно, то данное уведомление считается неотправленным и в дальнейшем удаляется, в клиентское приложение оно отправлено не будет, т.к. проблема на стороне клиентского приложения.

Как проверить, что вебхук работает?

Источник

Что такое вебхуки

Здравствуйте. На связи Людмила — маркетолог компании Altcraft. Расскажем, что такое вебхуки, как их использовать и в чём их преимущества.

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

Вебхук — это простой способ коммуникации для приложений. Метод отправки данных в реальном времени, когда происходит какое-то событие. Объясним на примере: представьте, что вы идёте домой с другом. Вы уже дошли до места назначения, а другу идти ещё пару километров. Вы просите его написать, когда он доберётся: хотите знать, что с ним всё в порядке. Друг приходит домой и пишет вам — это наглядный пример работы вебхука. Когда вы попросили написать сообщение, то отправили команду. Такая команда срабатывает, когда друг доходит до дома (происходит событие). Кроме того, сообщение приходит на ваш номер телефона с уникальным URL. Поэтому каждый раз, когда событие происходит, только вы видите уведомление.

Разберём ещё один пример: представим, что у вас есть банковская карта, на которую должны прислать деньги. Чтобы узнать о пополнении счёта, нужно зайти в приложение банка или настроить уведомления (push, SMS, email). Это тоже команда, потому что вы говорите системе: «Когда я получаю деньги, отправь мне сообщение». Если средства приходят, система регистрирует событие и отправляет уведомление на уникальный URL — адрес электронной почты, номер телефона или Push.

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

Причины, почему стоит использовать вебхуки:

Источник

API, WebSocket или WebHook: что выбрать?

В любом приложении нужен надежный механизм взаимодействия между его компонентами.

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

В этих и других ситуациях используются API, WebSocket и WebHook. Это три образцовых механизма передачи и синхронизации данных между различными частями приложения.

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

API предоставляет интерфейс и контракт для потребителей

API или интерфейс прикладного программирования — это контракт между потребителем и поставщиком сервиса, который обычно предоставляет API через HTTP.

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

Рассмотрим сценарий, в котором пользователи ищут товары в интернет-магазине. Отправив поисковый запрос на нужный товар, пользователь в считанные секунды получает ответ. Схема работы API предельно проста:

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

Если же серверу необходимо снова связаться с браузером, то при использовании API нет прямого способа это сделать (разве что браузер будет периодически проверять наличие обновлений).

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

Но маркерный доступ здесь неэффективен. Для решения таких задач есть методы получше.

WebSockets — когда нужно взаимодействовать в режиме реального времени

Такие задачи решает WebSocket, обеспечивающий постоянный и двунаправленный обмен данными между потребителем и поставщиком сервиса.

Наличие полнодуплексного канала связи позволяет поставщикам сервисов отправлять сообщения в любое время. И это лучшее решение для веб-приложений реального времени, ведь WebSocket поддерживают все современные браузеры.

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

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

Здесь нужен такой механизм, как WebHook.

WebHook — идеальный вариант для обратных вызовов бэкенда

WebHook (вебхук) решает проблемы, появляющиеся при использовании WebSocket. Каким образом? Задействуя механизм получения ответа от поставщика сервиса, причем этот механизм не требует соединения.

Технически это выглядит следующим образом. Потребитель регистрирует вебхук (URL-адрес обратного вызова) в поставщике сервиса, и этот URL-адрес будет местом для получения данных от вебхука.

Чаще всего этот URL-адрес принадлежит другому серверу. Вебхуки в основном и используются для взаимодействия между серверами или бэкенд-процессами.

Рассмотрим подробнее, как работает вебхук. Здесь различаются четыре части.

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

Подведем итоги

Вебхуки, WebSocket и API используются в различных ситуациях для осуществления обмена данными.

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

Если же веб-приложению нужно взаимодействовать с бэкендом в режиме реального времени, следует выбрать WebSocket. Он позволяет установить двусторонний канал связи между браузером и бэкендом.

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

Источник

Обзор веб-перехватчиков ASP.NET

Веб-перехватчики — это упрощенный шаблон HTTP, предоставляющий простую модель pub/sub для объединения веб-API и служб SaaS. Когда событие происходит в службе, уведомление отправляется в виде HTTP-запроса POST зарегистрированным подписчикам. Запрос POST содержит сведения о событии, которое позволяет получателю действовать соответствующим образом.

Благодаря простоте веб-перехватчики уже предоставляются большим количеством служб, включая Dropbox, GitHub, Bitbucket, MailChimp, PayPal, Slack, Stripe, Trello и многое другое. Например, веб-перехватчик может указать, что файл изменился в Dropbox, или изменение кода было зафиксировано в GitHub, или платеж был инициирован в PayPal, или карта была создана в Trello. Возможности бесконечны!

Веб-перехватчики Microsoft ASP.NET упрощают отправку и получение веб-перехватчиков в рамках приложения ASP.NET:

На принимающей стороне она предоставляет общую модель для получения и обработки веб-перехватчиков от любого количества поставщиков веб-перехватчиков. Он выходит из коробки с поддержкой Dropbox, GitHub, Bitbucket, MailChimp, PayPal, Pusher, Salesforce, Slack, Stripe, Trello,WordPress и Zendesk, но это легко добавить поддержку.

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

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

Код предназначен для веб-API ASP.NET 2 и ASP.NET MVC 5 и доступен как OSS на сайте GitHub.

Обзор веб-перехватчиков

Веб-перехватчики — это шаблон, который означает, что он зависит от того, как он используется от службы к службе, но основная идея одинакова. Веб-перехватчики можно рассматривать как простую модель pub/sub, где пользователь может подписаться на события, происходящие в другом месте. Уведомления о событиях распространяются как HTTP-запросы POST, содержащие сведения о самом событии.

Обычно HTTP-запрос POST содержит объект JSON или данные формы HTML, определяемые отправителем веб-перехватчика, включая сведения о событии, вызывающее активацию веб-перехватчика. Например, текст запроса POST веб-перехватчика из GitHub выглядит следующим образом в результате открытия новой проблемы в определенном репозитории:

Чтобы убедиться, что веб-перехватчик действительно от предполагаемого отправителя, запрос POST защищен каким-то образом, а затем проверяется получателем. Например, веб-перехватчики GitHub содержат заголовок HTTP X-Hub-Signature с хэшом текста запроса, который проверяется реализацией получателя, чтобы не беспокоиться об этом.

Поток веб-перехватчика обычно выглядит примерно так:

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

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

Универсальный код ресурса (URI) для отправки уведомления о событии в виде HTTP-запроса POST;

Набор фильтров, описывающих определенные события, для которых должен быть запущен веб-перехватчик;

Секретный ключ, который используется для подписывания HTTP-запроса POST;

Дополнительные данные, которые необходимо включить в HTTP-запрос POST. Например, это могут быть дополнительные поля заголовка HTTP или свойства, включенные в текст ЗАПРОСА HTTP POST.

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

Конвейер обработки веб-перехватчиков

Конвейер обработки веб-перехватчиков Майкрософт ASP.NET для входящих веб-перехватчиков выглядит следующим образом:

Ниже приведены два основных понятия : «Приемники » и «Обработчики«.

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

Обработчики обычно используются, когда пользовательский код выполняет обработку конкретного веб-перехватчика.

В следующих узлах эти понятия описаны более подробно.

Источник

Эволюция обработки вебхуков 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++ в апреле в Питере.

Источник

Что такое вебхуки

В этом материале расскажем про вебхуки: как они используются, где их можно настроить, дадим примеры использования в Mindbox.

Как используются

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

Где можно настроить вебхуки

Функционал вебхуков есть во многих системах: CRM, CDP, мессенджерах — например, в «Битрикс24», Slack или Mindbox. Когда в системе произойдет какое-то событие, настроенный вебхук оповестит об этом событии другую систему. Для этого у другой системы должно быть API, которое позволяет к ней обращаться.

Настройка в Zapier

Для автоматизации передачи данных между двумя системами можно использовать сторонние приложения. Например, Zapier. Оно позволяет настраивать обмен данными между различными приложениями по API с помощью вебхуков.

В CDP Mindbox

В Mindbox вебхуки нужны, чтобы оповещать сторонние системы о событии в платформе. Запросы в стороннюю систему настраиваются через интерфейс. Чтобы вебхук вызывался в нужный момент, достаточно указать его в триггере в качестве одного из шагов, которые выполняются при наступлении события. Примеры использования в Mindbox:

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

Интерфейс создания вебхука

Управление находится в меню Администрирование — Интеграции — Вебхуки. Вот пример создания или редактирования в интерфейсе:

После создания вебхук можно сразу использовать в операциях и триггерах:

Если вам интересно в деталях узнать как настроить вебхук в Mindbox, прочтите обучающую статью в нашей базе знаний.

Резюме

Для понимания вебхуков важно запомнить следующее:

Источник

Результаты поиска « код вставки виджета »

Описание 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 секунд ждет ответа о том, что вебхук обработан. Если вам этого времени может не хватать (много обработки, медленное соединение, высокая нагрузка), используйте механизм очередей — приняв вебхук, ставьте его обработку в очередь и отвечайте, что вебхук принят.

Источник

Что такое вебхук и как его создать

Например, его можно использовать для:

— отправки в call центр информации о новом заказе или его изменение
— оповещения персонала о негативной оценке клиента
— синхронизировать подписки
— и т.д.

Вариантов использования гораздо больше, инструмент достаточно гибкий.

Верхнеуровнево вебхук состоит из трех частей:

— адрес, к которому он обращается

— заголовки (отвечают за метод/авторизацию и тд.)

— тело (данные, которые мы передаем)

Создание вебхука

Управление вебхуками находится в меню Интеграции —> Вебхуки

Для создания нового вебхука нажмите кнопку «Добавить»:

пример итогового URL

Если добавить параметр $ в адрес, заголовок или тело запроса, то параметр будет присваивать ID запросу вебхука.
Вебхук будет повторно подключаться в течение 3 дней, пока не отработает успешно (код 200).
Если этого параметра нет — повторных попыток подключения не произойдет.

Например:в базу попал новый адрес почты и мы хотим передать его во внешнюю систему (id запроса = 1), но в момент передачи произошла ошибка и запрос не отработал.
Без TransactionalId внешняя система не знает, был ли такой запрос или нет. В итоге мы не можем его повторить (ведь все запросы без идентификаторов, как отличить один от другого), в итоге данные потеряны.
С TransactionalId внешняя система смотрит и видит, что вебхука с id 1 еще не было, а значит это новые данные, их нужно сохранить.
Итог — данные не потеряны

Доступна Справка по шаблонизатору, если есть сомнения в названии полей

Ошибки, где смотреть

При работе вебхука могу возникать ошибки, некоторые из них можно посмотреть в интерфейсе.

Нажимаем на значок «молнии» в нижнем левом углу:

В проблеме отображается название вебхука, ошибка с ID клиента и ссылка на ошибочные события.

Источник

Webhook что это

Webhooks – это уведомление сторонних приложений посредством отправки уведомлений о событиях, произошедших в amoCRM. Вы можете настроить HTTP адреса ваших приложений и связанные с ними рабочие правила в настройках digital pipeline, в amoCRM.

Список возможных событий

Чтобы создать webhook

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

Далее выберите «API: отправить webhook».

Выберите событие, при котором будет отправляться webhook.

Введите URL, по которому будет отправляться webhook.

Формат отправляемых данных

Webhook отправляет на стороннее приложение POST переменную, которая содержит массив вида <"entity":<"action":<массив полей сущности>>>.

Источник

Система уведомлений о событиях (Webhooks)

Webhook — механизм оповещения пользователей системы о событиях. События, о которых может уведомлять Webhook:

Webhook используют для отслеживания изменения статусов писем в реальном времени.

Модель, используемая в Webhook, работает следующим образом: при возникновении события установленный ранее обработчик отправляет JSON на URL, который был указан для этого Webhook. Используются стандартные порты: 80 порт для HTTP и 443 порт для HTTPS. Для установки Webhook на URL с указанным портом можно передавать URL в виде: http://11.111.111.11:80

Если URL, на который отправляется Webhook, недоступен (отвечает не HTTP 200 OK, таймаут — 3 секунды), попытки отправки Webhook на этот URL до получения ожидаемого 200 ОК будут продолжаться в течение 24 часов с интервалом в 10 минут с дополнительным параметром retry_count, значение которого будет увеличиваться на 1 с каждой повторной отправкой Webhook.

Если в течение 24 часов вебхук не удалось доставить, попытки отправки прекращаются, а статус вебхука меняется на stopped. На почту аккаунта отправляется уведомление об остановке вебхука с указанием последнего ответа. Чтобы активировать остановленный вебхук, исправьте ошибку, затем включите вебхук с помощью API метода setHook с параметром status=»active» или смените статус в личном кабинете.

Установить обработчик

setHook — установить/заменить обработчик оповещений о событиях определенного типа.

Пример вызова

Список обработчиков

listHooks — получить список всех обработчиков.

Удалить обработчик

removeHook — удалить обработчик оповещений.

Формат оповещений (JSON)

Пример возвращаемого оповещения

Описание параметров оповещения (для single_event = 0)

Данные оповещения — JSON-объект со следующими полями: