K čemu jsou message brokers?

K čemu jsou message brokers?
« kdy: 11. 07. 2017, 20:21:34 »
Vysvětlete mi někdo k čemu se hodí ty všude oblíbené message brokers? Třeba rabbit nebo zeromq. Přijde mi že věci spíš komplikují, než zjednodušují. Třeba teď mi byl předhozen zeromq a potřebuji od něj asynchronní req/rep a to po jednom spojení neumi, přičemž sám si to nad TCP stackem naprogramuju za odpoledne, bohužel klient na použitém mq trvá. Na jaký usecase bych měl tenhle typ komponenty použít, když to evidentně někteří nepoužívají správně. (Někdy mi přijde že výběr technologie manažeři provádí podle toho kolik jejich kamarádů danou technologií mají v portfoliu nebo jak moc je cool, free a in aniž by se někdo zamyslel nad tím, zda se na problém hodí)

PS: subscriber publisher pattern zvládnu do toho dopsat za druhé odpoledne
« Poslední změna: 12. 07. 2017, 08:38:34 od Petr Krčmář »


UF

Re:Message brokers
« Odpověď #1 kdy: 11. 07. 2017, 21:45:06 »
Vysvětlete mi někdo k čemu se hodí ty všude oblíbené message brokers? Třeba rabbit nebo zeromq. Přijde mi že věci spíš komplikují, než zjednodušují. Třeba teď mi byl předhozen zeromq a potřebuji od něj asynchronní req/rep a to po jednom spojení neumi, přičemž sám si to nad TCP stackem naprogramuju za odpoledne, bohužel klient na použitém mq trvá. Na jaký usecase bych měl tenhle typ komponenty použít, když to evidentně někteří nepoužívají správně. (Někdy mi přijde že výběr technologie manažeři provádí podle toho kolik jejich kamarádů danou technologií mají v portfoliu nebo jak moc je cool, free a in aniž by se někdo zamyslel nad tím, zda se na problém hodí)

PS: subscriber publisher pattern zvládnu do toho dopsat za druhé odpoledne

... tam zadnej broker neni a nikdy nebyl ...

robotron

Re:Message brokers
« Odpověď #2 kdy: 11. 07. 2017, 22:05:34 »
Vysvětlete mi někdo k čemu se hodí ty všude oblíbené message brokers? Třeba rabbit nebo zeromq. Přijde mi že věci spíš komplikují, než zjednodušují. Třeba teď mi byl předhozen zeromq a potřebuji od něj asynchronní req/rep a to po jednom spojení neumi, přičemž sám si to nad TCP stackem naprogramuju za odpoledne, bohužel klient na použitém mq trvá. Na jaký usecase bych měl tenhle typ komponenty použít, když to evidentně někteří nepoužívají správně. (Někdy mi přijde že výběr technologie manažeři provádí podle toho kolik jejich kamarádů danou technologií mají v portfoliu nebo jak moc je cool, free a in aniž by se někdo zamyslel nad tím, zda se na problém hodí)

PS: subscriber publisher pattern zvládnu do toho dopsat za druhé odpoledne

Pouzivam MQTT zcela dobrovolne, hlavnim duvodem je jednoduchost a podpora napric ruznymi programovacimi jazyky. (Konkretne u MQTT me stve, ze neumi jezdit nad UDP a bez memcpy() nad sdilenou pameti, ale zas je to vyvazeno naprosto stupidni jednoduchosti pouziti.) Vynikajici je, ze to ma osetreny ruzny chybovy stavy, znovunavazovani spojeni, bridging (! super vec!)... nic takovyho bych si nechtel psat sam a uz vubec ne v mnoha (pro moje ucely potrebnejch) programovacich jazycich.

ttt

Re:Message brokers
« Odpověď #3 kdy: 12. 07. 2017, 00:28:32 »
Citace
Třeba teď mi byl předhozen zeromq a potřebuji od něj asynchronní req/rep a to po jednom spojení neumi

Už je to nějakou chvíli, co jsem to pročítal, ale jsem přesvědčený, že tam má být "neumím" místo "neumí". To zní jako DEALER to ROUTER, ne? Případně nějaká jiná kombinace těchto dvou.

Standa jhple...

Re:Message brokers
« Odpověď #4 kdy: 12. 07. 2017, 06:30:41 »
K te prvni otazce - messaging - primarne asynchronni komunikace. Decoupling zdroj a prijemce zprav, zdroj a prijemce nemusi ve stejnou dobu bezet i presto po nastartovani prijemce mu budou vsechny zpravy dorucene, msg by mel mit jednoduche api tak aplikace mohou rel korektne komunikovat po siti jen s vyuzitim jednoducheho api aniz by kazda musela resit vsechny stavy site; zdroj nemusi vedet kde a kolik prijemcu zprav je nebo bude; kdyz se prijemce zmeni, tak se pripadne upravi routovani v msg bez potreby zasahu do konfigurace aplikaci; moznost na msg nastavit logovani nebo audit komunikace, spolecne pro vsechny apps ktere msg vyuzivaji; msg poskytuje ruzne vzory pro komunikaci - bod-bod, pub-sub, konfigurovatelna spolehlivost doruceni a jak se chovat k tem zpravam pri ruznych problemech - napr. cilova app nebezi, msg kam se te aplikaci posilaji zpravy je kumuluje ale dochazi misto na disku - co ted? Pokracovat v kumulovani? Nebo je muze msg zahazovat? Opakuju vsechny tuhle moznosti komunikace jen s vyuzitim jednoducheho api. To mi prijde jako docela zajimavy prinos ktery pri spravnem pouziti ma docela hodnotu.


borekz

  • ****
  • 492
    • Zobrazit profil
    • E-mail
Re:Message brokers
« Odpověď #5 kdy: 12. 07. 2017, 07:32:49 »
zdroj a prijemce nemusi ve stejnou dobu bezet i presto po nastartovani prijemce mu budou vsechny zpravy dorucene
Toto zdůvodnění beru, jenže se netýká zeromq. Ten funguje jen jako socket a výhody v něm žádné nevidím. Aby příjemce získal zprávy odeslané v době kdy neběžel, musel by je broker někam odkládat a to zeromq neumí.

stilett

Re:K čemu jsou message brokers?
« Odpověď #6 kdy: 12. 07. 2017, 09:56:09 »
ZeroMQ není broker, ale protokol a knihovna. Jako jiné knihovny vám dává tu výhodu, že někdo udělal kus práce za vás. Pomocí TCP socketů sice můžete dosáhnout téhož, ale musíte vyřešit spoustu věcí. Stačí už jen ta drobnost, že nemusíte řešit pořadí, v jakém pořadí příjemce a odesílatel otevřou komuninační kanál, když je spustíte najednou.

Message broker lze pomocí ZeroMQ snadno naprogramovat. Broker se hodí v dyamickém prostředí, kdy komunikujíící komponenty neznají všechny ostatní. Všechny nakonfigurujete jen vůči brokeru a mohou komunikovat. Uděláte tak jednoduše aplikační multicast (zpráva je doručena všem subscriberům). Broker také může držet zprávy, když příjemce chvíli nepřijímá.

ZeroMQ také umožňuje autentizaci i variantu se silným kryptografickým protokolem.

Pokud ale vaše požadavky jsou velmi malé, tak to může být příslovečný kanón na vrabce

m.

Re:K čemu jsou message brokers?
« Odpověď #7 kdy: 12. 07. 2017, 17:40:45 »

Re:K čemu jsou message brokers?
« Odpověď #8 kdy: 12. 07. 2017, 19:25:49 »
přičemž sám si to nad TCP stackem naprogramuju za odpoledne
Brokery a různé spešl fronty (Kafka) má smysl používat na věci, které si sám za odpoledne nenaprogramuješ.

Jsi si např. jistý, že bys dokázal naprogramovat exactly once delivery pro paralelně běžící servery (škálovatelnost), které můžou kdykoli spadnout? Nebo aspoň ve stejném prostředí udělat opravdu robustní replay (jak ho má např. ta Kafka)? Já si tím teda za sebe jistý nejsem vůbec - přestože to z uživatelského hlediska jakžtakž znám, k tomu, abych to naimplementoval, bych si musel pár věcí pořádně nastudovat a i tak předpokládám, že první dvě až tři implementace bych napsal blbě.

Místo zeromq bych fakt doporučil podívat se na Kafku, pochopit, jak pomocí pár chytrých základních primitiv můžeš postavit službu se zajímavými vlastnostmi.

Konkretne u MQTT me stve, ze neumi jezdit nad UDP
Asi to budeš vědět: existuje MQTT-SN, které po UDP provozovat jde, specifikace je hezká (speciálně se mi moc líbí podpora tunelování) ale bohužel se skoro vůbec neuchytilo a množství software je žalostné.

Jinak teď si z hlavy úplně neumím vybavit důvod, proč by MQTT nemohlo principiálně nad UDP fungovat. Mám pocit, že by mohlo, od spodnější vrstvy IIRC potřebuje jenom jasnou identifikaci endpointů, což IP+UDP porty zabezpečí dostatečně.

Re:K čemu jsou message brokers?
« Odpověď #9 kdy: 12. 07. 2017, 19:31:59 »
Jinak teď si z hlavy úplně neumím vybavit důvod, proč by MQTT nemohlo principiálně nad UDP fungovat. Mám pocit, že by mohlo, od spodnější vrstvy IIRC potřebuje jenom jasnou identifikaci endpointů, což IP+UDP porty zabezpečí dostatečně.
Jo, tak jsem si ho právě vybavil, jak jsem to odeslal ;) Nad UDP by bylo dost nepraktický mít QOS=0, protože by server nepoznal, že klient umřel, a dál by mu jak divej posílal subscribnutý data. Ale řešitelný by to bylo snadno: aspoň čas od času by se musel poslat nějaký QOS>0 paket pro ověření živosti.

tnr

Re:K čemu jsou message brokers?
« Odpověď #10 kdy: 13. 07. 2017, 09:21:49 »
Vysvětlete mi někdo k čemu se hodí ty všude oblíbené message brokers? Třeba rabbit nebo zeromq. Přijde mi že věci spíš komplikují, než zjednodušují. Třeba teď mi byl předhozen zeromq a potřebuji od něj asynchronní req/rep a to po jednom spojení neumi, přičemž sám si to nad TCP stackem naprogramuju za odpoledne, bohužel klient na použitém mq trvá. Na jaký usecase bych měl tenhle typ komponenty použít, když to evidentně někteří nepoužívají správně. (Někdy mi přijde že výběr technologie manažeři provádí podle toho kolik jejich kamarádů danou technologií mají v portfoliu nebo jak moc je cool, free a in aniž by se někdo zamyslel nad tím, zda se na problém hodí)

PS: subscriber publisher pattern zvládnu do toho dopsat za druhé odpoledne

Jo? A rozpady spojeni,neomezeny pocet klientu, broadcasting zprav, persistenci, transakcni zpravy takt zvladnes za odpoledne? To vse samozrejme s podporou temer neomezeneho poctu klientu?)

No ale zpatky k puvodni otazce - pouzit nejaky mb je otazka peti minut, takze i kdyby jsi to zvladl za odpoledne, tak se to nevyplati)

A aspon se naucis neco noveho:)