Создаем структуру простого мультиплатформенного бота

    Регистрация пользователей на мероприятия, автоматический поиск ответов в базе, общение с техподдержкой, обмен контактами — все это часть функций нашего бота Leader-ID. Он «живет» на трёх платформах: VK, Facebook Messenger и Telegram, при этом логика его работы пишется один раз на всех с использованием платформонезависимых абстракций. Такой подход позволяет быстро добавлять новые функции и шлифовать старые.



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

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

    Давайте познакомимся с нашим ботом. Его можно найти в Telegram, VK, FB, где он обслуживает одновременно до нескольких тысяч человек (как бывает на крупных мероприятиях). Кстати, о том, кто мы и чем занимаемся, можно узнать из нашей первой статьи. Если кратко, оперируем огромной сетью бесплатных коворкингов и пространств для презентаций по всей России и одновременно поддерживаем коммуникационную платформу Leader-ID, являющуюся ядром всей системы. И бот играет во всей этой истории немаловажную роль.

    Double gun — double fun


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



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

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

    Структура самого простого бота


    В базовом варианте бот будет состоять из одного лишь сервиса, отправляющего и принимающего сообщения через API нужного нам мессенджера (платформы), например Telegram.



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



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

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

    Организуем общение коннекторов и ядра (поллинг БД, или Как делать не надо)


    Итак, перед нами стоит задача организовать обмен данными между коннекторами и ядром. Первый вариант — передавать новые сообщения через БД. Мы с этого начинали. Соответственно, в нашей схеме появляется сама БД, а структура становится вот такой: ядро, написанное на Python, плюс база на MongoDB (причины такого выбора исключительно исторические), плюс коннекторы.



    Эта схема проработала у нас относительно недолго. Когда количество сообщений перевалило за 700 тыс., а частота в пиках достигала до 120 обращений в секунду, индексы стали тяжелее, поллинг БД стал ощутимо дороже. Пришлось подключить сюда брокер RabbitMQ. Основная его роль – генерить уведомления, что компоненту (ядру/коннектору) следует обработать сообщение с конкретным айдишником. Эти айдишники и передаются через него. RabbitMQ разгрузил нам базу и компоненты, которым теперь не нужно все время проверять БД на наличие новой информации для обработки.

    В итоге наша базовая структура стала выглядеть так:



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

    Добавляем администраторов


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



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

    Сам интерфейс для администраторов у нас выглядит так:



    Подключаем операторов через второго бота


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

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


    Фраза «Тестовый вопрос» на скриншоте является текстом вопроса для техподдержки

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



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

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



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

    Что еще умеет наш бот


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

    Обмен контактами

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



    Распознавание QR-кодов также используется для выдачи пользователю дополнительной информации или файлов с семинаров. Выглядит это так:



    Рассылка уведомлений



    Через панель управления в модуле web мы можем рассылать уведомления участникам тех или иных мероприятий.

    Проведение опросов

    Аналогичным образом проводятся опросы во время лекций. Но для них мы пока вручную формируем JSON-файл с логикой, который подгружаем в web.





    Вопросы могут быть как с вариантами ответов, так и открытые. А структура опроса может меняться в зависимости от ответов.





    Автоматические ответы

    Бот может самостоятельно подбирать ответы на часто задаваемые вопросы.



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

    В целом, пока это вся наша ботоистория. В данный момент мы работаем над расширением функций нетворкигна и ожидаем, что в скором времени наш бот еще немного «потолстеет», при этом его структура останется прежней.
    Leader-ID
    Компания

    Комментарии 3

      0
      О, а у вас нет случайно бота, помогающего посчитать кто по сколько скидывается в баре? А-то кто-то пиво глушит, кто-то абсент, а кто-то за рулём и соком балуется, но зато креветок навораичвает, а счет один=)
        0
        :) В Точках кипения запрещен алкоголь, поэтому готового нет. Но его нетрудно написать. Барный бот проще бота поддержки. А как вы представляете интерфейс такого бота? Каждый, кто делает заказ, кидает в бот сумму заказа со своего аккаунта?
          0

          Обычно тусовка отправляясь в бар уже сидит в каком-то чатике. Осталось туда и бота подключить. Боту можно сказать, что собантуй начался и что Ваня и Петя сегодня не с нами, а Васи тут нет, но он хипстер из вайбера, так что за него будут самые трезвые через @вася постить сожранное.
          Заказанные блюда, шоты и прочее именуем и декларируем в условно-сокращенном виде по нажатию спец кнопки или "+креветки2/10" — два блюда креветок по десять штук или типа того. "+гиннес3л/6" — трёхлитровая башня гиннеса, а бокалы поллитровые.
          Для каждой такой порции появляется по кнопке. Едокам и выпивохам остаётся по мере возлияний жать на кнопки, а бот будет вести журнал и помнить кто что пожрал.
          Можно как-то (хз как) жать за "Васю", который не в чате.
          По факту пьянки каждый кто платит по отдельному чеку (а чеков-то может быть несколько) жмёт кнопку "оплата" и вводит проплаченную сумму. На утро все выгребают из карманов чеки и проставляют у бота цены добавленным вчера блюдам. Потом бот считает кто чего сожрал, показывает не разобранное. Тут можно еще понажимать кнопки кто чего жрал. Все бурно вспоминают кто слопал три шота абсента и прописывают их на @васю.
          В итоге бот выдаёт каждому кто сколько кому должен.


          Всё и так на доверии, просто с таким ботом проще расслабиться и не утруждаться меркантильными подсчетами.


          Это я постарался неформально написать, но где-то в загашниках и ТЗ валялось. Но руки до этого пет-проджекта, наверно, не дойдут. Слишком много всяких таких идей.
          А у этой еще и потенциал прикольный. Можно в баре своего бота поднять. который цены на ассортимент знает и заказы умеет принимать, чтобы официанта взглядом сквозь орущую музыку не гипнотизировать призывая.
          Этот же бот может потом сра… сразу или позже гадить в чат скидками и акциями бара, пока его (бота) не выпнут из чатика или не замьютят отдельной командой=)
          Можно прикольной статистики всякой потом показать с количеством выпитого и прочего.
          Также боту полезно уметь устраивать голосования по поводу того где и когда собираться. А-то когда человек 5-6 уже трудно всем максимально состыковаться. У всех появляется куча условий и вариантов… Но это отдельная тема, хотя про то же самое=)

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

      Самое читаемое