Как построить масштабируемую архитектуру чатбота с нуля в 2020

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

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

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

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

Фактически, диалоговый интерфейс как, например, мобильное приложение, мессенджер или даже отдельный интернет чат является одним из потенциальных решений, которое обеспечит комфортное взаимодействие пользователю. Представьте себе ситуацию, когда вы определили все в одном единственном модуле? Как вы масштабируете и отделите бизнес-логику, когда она смешивается с процессом ведения диалога? В таком случае, важно разделить модули REST API и NLU/NLP, чтобы предоставить архитектуре чат бота большую гибкость, как показано в примере ниже:

Как вы видите, довольно просто добавить новые интерфейсы, если вы заметили, что проект можно разделить на 3 или более крупных модуля: Rest API, весь блок диалогов и NLP/NLU. Теперь давайте поговорим об архитектуре каждого модуля более детально.

Интерфейсы чат ботов (фронт енд)

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

Кастомизация

Безусловно, широко применяются такие платформы, как Facebook, WhatsApp, Slack и другие, но они все характеризуются множеством ограничений по уровням управления, которые вы можете использовать. Итак, пользователь увидит только предварительно определенные, ограниченные и стандартные для платформ календари, кнопки, уведомления, программы импорта файлов, а также просмотра файлов.

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

Динамическое взаимодействие

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

AWS Lambda + AWS API Gateway

В нашей системе эти понятия означают основной API интерфейс этой системы.

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

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

AWS ElasticCache Redis

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

AWS DynamoDB

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

Основные причины использования нами этой базы данных:

  • Минимальная задержка в доступе к данным длительностью в одну миллисекунду
  • Интеграция с большинством сервисов AWS, таких как IAM, CloudWatch и т.д.
  • Автоматическое масштабирование
  • Практически неограниченный объем хранения

AWS EC2

Находясь в процессе максимального сокращения использования из-за ограничений в AWS Lambda, AWS EC2 все еще применяется для создания статичных картинок. Основной способ применения основан на таблицах FusionCharts и на выгрузке картинок, а также на создании инфографики. Однако, это момент указан в следующей главе.

В первой версии таблицы, нацеленной на создание статических картинок, мы применили сервис экспорта и импорта, разработанный командой FusionExport. Копия экрана предоставленного HTML фактически снимается, выгружается в сервис AWS S3, который лучше своих конкурентов, благодаря безопасности, низкой стоимости и масштабируемости. По тем же причинам AWS S3 использовался для хранения надстроек виджетов и административных страниц для нашего проекта.

Давайте подведем определенный итог выше сказанного:

До определенной степени, использование сервисов AWS меняет мышление разработчика, который не должен теперь волноватся о работе сервера.

Размышления о правильной архитектуре заблаговременно, играют решающую роль в разработке проекта.

Применение Lambda + API Gateway точно выше серверов EC2, поскольку AWS автоматически определяет новые платформы, когда это необходимо, поэтому приложение является бесконечным.

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