- PVSM.RU - https://www.pvsm.ru -
Регистрация пользователей на мероприятия, автоматический поиск ответов в базе, общение с техподдержкой, обмен контактами — все это часть функций нашего бота Leader-ID. Он «живет» на трёх платформах: VK, Facebook Messenger и Telegram, при этом логика его работы пишется один раз на всех с использованием платформонезависимых абстракций. Такой подход позволяет быстро добавлять новые функции и шлифовать старые.
Структура системы делает единым процесс разработки функций под разные платформы и на порядок упрощает процессы в сравнении с вариантом их ручного переписывания в каждом платформозависимом API. При этом, чтобы завести бота на новой платформе, достаточно лишь написать соответствующий адаптер (коннектор).
Про эту структуру и хотелось кратко рассказать. Возможно, это окажется полезным тем, кто хочет написать своего кроссплатформенного бота, но еще не погружался глубоко в тему и пока изучает чужой опыт.
Давайте познакомимся с нашим ботом. Его можно найти в Telegram [1], VK [2], FB [3], где он обслуживает одновременно до нескольких тысяч человек (как бывает на крупных мероприятиях). Кстати, о том, кто мы и чем занимаемся, можно узнать из нашей первой статьи [4]. Если кратко, оперируем огромной сетью бесплатных коворкингов и пространств для презентаций по всей России и одновременно поддерживаем коммуникационную платформу Leader-ID [5], являющуюся ядром всей системы. И бот играет во всей этой истории немаловажную роль.
На самом деле бота у нас два. Первый – основной, отвечает за взаимодействие с пользователями. Он является удобным средством мобильной регистрации пользователей на мероприятия, взаимодействия с поддержкой и получения дополнительной информации с лекций и семинаров, а также обмена контактами в рамках одной экосистемы.
Второй бот — по сути интерфейс для операторов поддержки. Работают боты в связке, но базы и интерфейсы у них разнесены.
На их примере мы покажем, как может выглядеть структура такой системы. Однако начнем раскручивать этот клубок постепенно, с простых кейсов.
В базовом варианте бот будет состоять из одного лишь сервиса, отправляющего и принимающего сообщения через API нужного нам мессенджера (платформы), например Telegram.
Если у нас несколько мессенджеров, через которые мы хотим общаться с пользователями, разумным будет вариант написания логики в платформонезависимом стиле с добавлением в структуру коннекторов, транслирующих команды и данные из внутреннего формата в формат соответствующей платформы (мессенджера).
Это даст возможность добавлять новые функции в одном месте, а не дублировать их для каждой платформы отдельно.
Коннекторы представляют собой сервисы, принимающие сообщения от платформы для пересылки ядру и наоборот. В целом это относительно независимые компоненты системы, которые могут при необходимости располагаться на отдельном сервере, иметь несколько реплик и так далее.
Итак, перед нами стоит задача организовать обмен данными между коннекторами и ядром. Первый вариант — передавать новые сообщения через БД. Мы с этого начинали. Соответственно, в нашей схеме появляется сама БД, а структура становится вот такой: ядро, написанное на Python, плюс база на MongoDB (причины такого выбора исключительно исторические), плюс коннекторы.
Эта схема проработала у нас относительно недолго. Когда количество сообщений перевалило за 700 тыс., а частота в пиках достигала до 120 обращений в секунду, индексы стали тяжелее, поллинг БД стал ощутимо дороже. Пришлось подключить сюда брокер RabbitMQ. Основная его роль – генерить уведомления, что компоненту (ядру/коннектору) следует обработать сообщение с конкретным айдишником. Эти айдишники и передаются через него. RabbitMQ разгрузил нам базу и компоненты, которым теперь не нужно все время проверять БД на наличие новой информации для обработки.
В итоге наша базовая структура стала выглядеть так:
У работы коннекторов через БД есть минус — это снижает их независимость и увеличивает связность системы. Однако если данные передавать напрямую с помощью диспетчера очередей, то вся ответственность за их сохранность и доступность ложится на этого брокера. Насколько это удовлетворяет запросам к надежности и прозрачности, вопрос открытый. Для себя лично мы решили, что поэкспериментируем над этим в процессе дальнейшего развития системы.
Для управления всей кухней нужен интерфейс администратора. С его помощью мы находим нужную информацию в переписке, редактируем данные, делаем опросы и рассылки. Следовательно, на нашей схеме появляется компонент web. Кроме вышеперечисленного он предоставляет веб-интерфейс для аутентификации пользователей и API ботов.
Web общается с БД и ядром посредством специальных системных сообщений. Они маршрутизируются как текстовые, только содержат информацию не о новом сообщении от пользователя, а о каком-то другом событии в системе в целом, на которое ядро должно отреагировать. Например, получение авторизационных кодов.
Сам интерфейс для администраторов у нас выглядит так:
.
Для реализации полноценной поддержки пользователей мы подключили к системе операторов. Чтобы сохранить быстроту коммуникаций с ними, в отсутствие устраивающих альтернатив в качестве основного диалогового интерфейса выбрали Telegram. Операторы получают вопросы пользователей через него и тут же отправляют ответы.
Вот так выглядит диалог пользователя с основным ботом при отправке вопроса в поддержку:
Фраза «Тестовый вопрос» на скриншоте является текстом вопроса для техподдержки
В итоге на нашей схеме появляется второй бот (Support Bot) со своим ядром и Telegram-коннектором. Он общается с основным ядром и организует пересылку вопросов и ответов между чатами с пользователями и чатами, в которых сидят агенты поддержки.
Также у него своя БД. Но общение с конечным пользователем идет через ядро основного бота, которое управляет общим потоком сообщений.
Вот как выглядит диалог оператора с ботом поддержки, который переадресовывает сообщения пользователей:
В нашем случае операторы делятся на две категории: тех, кто занимается общей поддержкой пользователей, и тех, кто отвечает за поддержку отдельных Точек кипения или мероприятий. Впрочем, на структуру это не оказывает никакого влияния.
Эта информация касается лишь нашей практики, но, возможно, она будет интересна в качестве подборки простых идей, которые можно взять на заметку.
Обмен контактами
Осуществляется он через сканирование и распознавание личных QR-кодов из бота. Для этого в ядро добавляется дефолтный обработчик картинок. Пересылкой изображений занимаются коннекторы, которые сохраняют их в БД вместе с сообщением.
Распознавание QR-кодов также используется для выдачи пользователю дополнительной информации или файлов с семинаров. Выглядит это так:
Рассылка уведомлений
Через панель управления в модуле web мы можем рассылать уведомления участникам тех или иных мероприятий.
Проведение опросов
Аналогичным образом проводятся опросы во время лекций. Но для них мы пока вручную формируем JSON-файл с логикой, который подгружаем в web.
Вопросы могут быть как с вариантами ответов, так и открытые. А структура опроса может меняться в зависимости от ответов.
Автоматические ответы
Бот может самостоятельно подбирать ответы на часто задаваемые вопросы.
Для этого у нас имеется специальная база, пополняемая вручную. Если там ничего подходящего найдено не было или пользователя не устроил подобранный ответ, его обращение через бота поддержки переадресовывается операторам.
В целом, пока это вся наша ботоистория. В данный момент мы работаем над расширением функций нетворкигна и ожидаем, что в скором времени наш бот еще немного «потолстеет», при этом его структура останется прежней.
Автор: Elizaveta
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/python/340046
Ссылки в тексте:
[1] Telegram: http://t.me/leaderid_bot
[2] VK: https://vk.me/tboil_people
[3] FB: https://m.me/youngprofs
[4] первой статьи: https://habr.com/ru/company/leader-id/blog/477976/
[5] Leader-ID: https://leader-id.ru/
[6] Источник: https://habr.com/ru/post/479562/?utm_source=habrahabr&utm_medium=rss&utm_campaign=479562
Нажмите здесь для печати.