Микросервисы / распределенные системы

Давно не писал, накину холивар.

Архитектура – это про решения, про выбор. Когда kafka не просто не нужна, но может быть плохим выбором и источником костылей?)

- например, в логировании или когда сообщения приходят редко, то есть нет потребности в в высокой пропускной способности; тут можно посмотреть на rabbit, redis.
- нужная очень низкая latency (1-5ms), например в чатах, на биржах, – здесь альтернативами могут быть nats, zeromq, rabbit
- не нужно долго хранить сообщения (например, для истории), например, в уведомлениях, – можно тот же redis streams взять (но тут есть нюансы)
- одно из моих любимых – когда нет (и не предвидится) квалифицированых кадров для настройки и поддержки, тоже можно взять попроще – nats, redis; часто следствие этой проблемы – это попытка закрыть не оптимальные настройки и инфраструктуру техническими решениями в сервисах, в коде приложений
- нужна динамическая маршрутизация (и вообще реализация EIP из коробки для снижения уровня сложности реализации всей системы), здесь rabbit или nats подходят лучше. приходилось видеть и в живую и на выступлениях, как брали кафку, а потом сообщения проходили через несколько «служебных» сервисов, которые в себе содержали реализацию тех самых интеграционных шаблонов и это сильно сильно повышает сложность всей системы в целом

То есть kafka идеально вписывается при высокой нагрузке с долговременным храением сообщений и потоковой обработкой, но, очевидно, такие требования предъявляется не то, чтобы всегда 🙂

👍42🔥9😁5🤔3

www.tgoop.com/microservices_arch/571

4.77K viewsСергей Баранов, May 11 at 13:12

Давно не писал, накину холивар.

Архитектура – это про решения, про выбор. Когда kafka не просто не нужна, но может быть плохим выбором и источником костылей?)

- например, в логировании или когда сообщения приходят редко, то есть нет потребности в в высокой пропускной способности; тут можно посмотреть на rabbit, redis.
- нужная очень низкая latency (1-5ms), например в чатах, на биржах, – здесь альтернативами могут быть nats, zeromq, rabbit
- не нужно долго хранить сообщения (например, для истории), например, в уведомлениях, – можно тот же redis streams взять (но тут есть нюансы)
- одно из моих любимых – когда нет (и не предвидится) квалифицированых кадров для настройки и поддержки, тоже можно взять попроще – nats, redis; часто следствие этой проблемы – это попытка закрыть не оптимальные настройки и инфраструктуру техническими решениями в сервисах, в коде приложений
- нужна динамическая маршрутизация (и вообще реализация EIP из коробки для снижения уровня сложности реализации всей системы), здесь rabbit или nats подходят лучше. приходилось видеть и в живую и на выступлениях, как брали кафку, а потом сообщения проходили через несколько «служебных» сервисов, которые в себе содержали реализацию тех самых интеграционных шаблонов и это сильно сильно повышает сложность всей системы в целом

То есть kafka идеально вписывается при высокой нагрузке с долговременным храением сообщений и потоковой обработкой, но, очевидно, такие требования предъявляется не то, чтобы всегда 🙂

BY Микросервисы / распределенные системы