Здравствуйте, itslave, Вы писали:

I>Здравствуйте, scf, Вы писали:

scf>>Моё мнение — что очереди нужны только там где есть необходимость данные буферизировать — к примеру, если апстрим хочет отдать и коммитить данные быстрее, чем даунстрим способен их обработать.

I>Твое мнение канечна интересно, но есть чуваки, которые с тобой не согласны. В чем я их поддерживаю чуть боле чем полностью.

Этой книге уже 5 лет, а текущий тренд микросервисных архитектур — http/rest, thrift, grpc. Правда, саму книжку не читал, исправлюсь.

edit: прочитал подглаву "Why Use Messaging?". Судя по набору доводов, книжка и правда устарела. Часть доводов применима и к RPC, часть упирает на отсутствие асинхронности и троттлинга в RPC(давно сделано), часть исходит из надежности железа и ненадежности сети (в современном виртуализованном мире железо ненадежно!), а остальные входят в категорию "нам действительно нужно хранить данные т.к. скорость отправителя выше скорости получателя".

RPC крут именно тем, что он stateless — нам не нужно ничего хранить. Сервис очередей требует внимания DBA, как и база данных. Очередь может переполниться, данные из очереди могут быть потеряны (кто делает бэкапы очередей?), при проблемах в системе нужно смотреть содержимое очередей (для большей части систем такой возможности нет).