Информация об изменениях

Сообщение Re[5]: Микросервисы маршрутизация от 11.08.2017 17:21

Изменено 11.08.2017 17:45 scf

Re[5]: Микросервисы маршрутизация
Здравствуйте, itslave, Вы писали:

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


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


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


Этой книге уже 5 лет, а текущий тренд микросервисных архитектур — http/rest, thrift, grpc. Правда, саму книжку не читал, исправлюсь.
Re[5]: Микросервисы маршрутизация
Здравствуйте, itslave, Вы писали:

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


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


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


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

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