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

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

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

То есть kafka идеально вписывается при высокой нагрузке с долговременным храением сообщений и потоковой обработкой, но, очевидно, такие требования предъявляется не то, чтобы всегда 🙂
👍42🔥9😁5🤔3



tgoop.com/microservices_arch/571
Create:
Last Update:

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

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

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

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

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


Share with your friend now:
tgoop.com/microservices_arch/571

View MORE
Open in Telegram


Telegram News

Date: |

Hui said the messages, which included urging the disruption of airport operations, were attempts to incite followers to make use of poisonous, corrosive or flammable substances to vandalize police vehicles, and also called on others to make weapons to harm police. Clear There have been several contributions to the group with members posting voice notes of screaming, yelling, groaning, and wailing in different rhythms and pitches. Calling out the “degenerate” community or the crypto obsessives that engage in high-risk trading, Co-founder of NFT renting protocol Rentable World emiliano.eth shared this group on his Twitter. He wrote: “hey degen, are you stressed? Just let it out all out. Voice only tg channel for screaming”. ‘Ban’ on Telegram Administrators
from us


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