Как масштабировать Slack-бота до тысяч команд

Чтобы реализовать Slack-бот, мне нужно иметь дело с Slack «API обмена сообщениями в реальном времени». Это API на основе WebSocket, который позволяет получать события от Slack в реальном времени и отправлять сообщения от имени пользователя. дополнительная информация: https://api.slack.com/rtm

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

Сделать Slack-бот доступным для другой команды. Мне нужно открыть новое соединение с веб-сокетом. Так,

  • 1 команда => 1 подключение к веб-сокету
  • 2 команды => 2 подключения к веб-сокету
  • N команд => N подключений к веб-сокетам

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

Какая архитектура может обрабатывать автомасштабирование тысяч подключений к веб-сокетам?


node.js websocket autoscaling slack slack-api
person Kerem    schedule 04.04.2016    source источник

Ответы (1)


arrow_upward
8
arrow_downward

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

  • Количество розеток. Это легко, потому что даже дешевые серверы могут обрабатывать тысячи сокетов, например, более 50k. Но каждый сокет представляет собой пару других типов нагрузки, перечисленных далее.
  • Объем памяти, используемый каждой командой, зависит от реализации вашего собственного сервера. Если вы пытаетесь сохранить в памяти большой объем истории сообщений, вы достигнете предела своего сервера быстрее, чем если бы ваш код обработки сообщений не имел состояния.
  • Количество операций ввода-вывода, из-за которого вы можете захотеть выгрузить любое изображение, обслуживающее отдельный балансировщик нагрузки.

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

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

person Peter Brandt    schedule 05.04.2016
comment
Это правда, что Node может управлять множеством одновременных сокетов, но задержка становится более непредсказуемой при масштабировании. Если у вас есть код, чувствительный к производительности, стоит использовать какую-то систему кластеризации, чтобы выровнять нагрузку по нескольким процессам, чтобы кратковременный всплеск в одном из них не застопорился. - person tadman; 05.04.2016