go-приложениях, для чего ?
Ранее я писал на пхп, и там я использовал их для выполнения «большой» работы, чтобы пользователь не ждал. В го, как мне кажется это можно разрулить на уровне рутин/каналов ( выделить канал, который будет «слушать» задания для такой «работы» и выполнять независимо от запроса )
Как правило, для распределения задач/сообщений между разными сервисами
Не всегда. Каналы хоть и выполняют функцию очередей, но не персистентны. А в моем случае, например, очень важно, чтобы сообщения не терялись при рестарте приложений
Масштабироваться легче когда есть отдельное веб-приложение которое кидает в очередь работы, а есть отдельный воркер который обрабатывает. Соответственно в зависимости от требований могут быть например 2 веб-приложения и 7 воркеров и одна очередь
Неправда что легче, в некоторых кейсах более правильно это да. А что будете делать если очередь не успевают обрабатывать? Надо прикрутить мониторинг очереди и скейлить воркеров когда в очереди много необработанных Легче убрать из уравнения очередь где она не нужна тогда твои сервисы будут сами скейлиться on demand
не очень понял насчет убрать очередь. Где задачи будут храниться?
скейлинг воркеров надо на стороне оркестрации решать где то наверное, если это возможно. неконтролируемый скейлинг может высосать много денег, надо быть аккуратнее с этим
Зависит от логики приложения. Сообщения, которые можно потерять, можно и на каналах сделать, а какие-то важные лучше через брокер. Тут важно думать: а что произойдёт, если моё приложение упадёт? Что будет, если я запущу два инстанса?
А неконтролируемого не бывает вообще, у любого клауд-провайдера при создании автоскейлинга есть обязательное поле max instances
Обсуждают сегодня