У нас есть монолитный Rails API, который также обслуживал наши веб-сокеты.Недавно мы переросли ActionCable и решили перенести наши веб-сокеты в Phoenix Elixir.
В этой модели клиенты по-прежнему взаимодействуют с приложением Rails для HTTP-запросов, но Phoenix обрабатывает весь трафик Websocket.Rails сообщает Phoenix, какие данные отправлять и по какому каналу Phoenix действует, по сути, как проход для того, что Rails отправляет.
Я изначально настроил это с помощью Redis PubSub для связи от Rails к Phoenix.В нынешних масштабах это хорошо работает, но я начинаю думать, что это, возможно, был худший выбор.Вот мой список плюсов и минусов:
Redis
Плюсы:
- Заказанные сообщения (не важно в нашем случае)
- Действует как правильный механизм очередей
- Злая быстрая и мертвая простая публикация из Rails
Минусы:
- Нет конкурентных потребителей - я быприходится вручную балансировать, если у меня было несколько потребителей Phoenix (реальная возможность)
- Параллельность сложнее реализовать хорошо (что действительно действует против сильных сторон Эликсира)
HTTP
Плюсы:
- Параллелизм предоставляется бесплатно
- Балансировка нагрузки предоставляется бесплатно - запрос будет выполняться только одним потребителем Phoenix
- Чуть проще реализовать
Минусы:
- Неупорядоченные сообщения (не важно для нас)
- Намного медленнее отправлять сообщения из Rails
- Пришлось бы вручную выполнить повторные попытки и таймауты на HTTP запросов от Rails
- Если сообщение потеряно (из-за перезапуска сервера или аналогичного), оно пропало навсегда
Даже после взвешивания я все равно нахожу еготрудно претендовать на то, чтобы быть очевидным выбором.Существуют ли шаблоны для Redis или HTTP-связи между службами, которые облегчают некоторые из моих проблем?Если нет, то какой из этих двух предпочтительнее, учитывая минусы?
Есть ли еще одна простая альтернатива, которую я пропускаю?Я не хочу привлекать что-то вроде Rabbit MQ, если этого можно избежать.