Názory k článku Komunikace v distribuovaných systémech: synchronní komunikace typu požadavek a odpověď

Tak toto je ina zverina....
Nebolo by lepsie pouzit message brokera resp. nejaku streamovaciun platformu v spojeni napr. s kappa architekturou ?
Preco by sa na Req/Resp komunikaciu toto malo pouzivat? Nevidim problem komunikovat medzi suvisiacimi modulmi RESTom a spojit to s async komunikaciou cez MQ alebo Kafku,samozrejme tomu zodpoveda vhodny navrh architektury a spravania sa systemu.

kafka/MQ jsou centrální prvky, přidávají nemalé zpoždění, Kafka je FIFO, ani jeden z nich neumí multicast/res, což je pattern, který někdy může být užitečný, stejně tak mít distribuovanou mesh síť aplikačních workerů, což je pattern, který funguje běžně v distribuovaných systémech.

Pokud děláš koncovou aplikaci, async komunikace je často něco, co nevadí, pokud děláš ale platformu, kde musíš pracovat s transakčnostní, definovanou latencí, chceš se async frontám většinou vyhnout.

Tak ale otazka neznela...otazka bola,ze preco namiesto RESTu pri req/resp pristupu pouzivat nieco take ako JMS pre req/resp. Tranzakcnost jedine cez diskugabilne XA,ziadnu inu pridanu hodnotu to nema... MQ,Kafka a ine neriesim.maju svoj ucel,treba tomu prisposobit architekturu a biznis case,jasme ratat s eventualnou konzistenciou by design...ale tak moj dotaz neznel....

na to musí odpovědět autor článku, ale osobně bych řekl, že nosná vrstva může být jakákoliv (REST, grpc, thrift, jax-rpc) a šlo o to vysvětlit princip bez zabředávání se do dalších knihoven.

Zdravím všechny,
Je pochopitelně mnoho způsobů, jak spolu mohou distribuované systémy komunikovat. V článku je popsán jeden možný způsob, vy jste zmínili další.
Vždy záleží na tom, co konkrétně řešíte, a podle toho také zvolit vzhodný způsob komunikace. To je to obecné prohlášení. A teď konkrétněji.

V článcích se pokouším nastínit řešení problému, kdy spolu komunikují desíty nebo i stovky systémů od různých provozovatelů. Jednou z požadovaných služeb, kterou chci podporovat, jsou "vyhledávací služby". To jsou takové, kdy žadatel chce zjistit u všech/zvolených zapojených systémů, jestli požadovanou informací mají, a pak si jí případně vyžádat.
Pokud bych to dělal např. pomocí REST a chtěl oslovit desítky systémů, musel bych udělat odpovídající počet dotazů, to je desítky TCP spojení na různé systémy. V případě, že komunikuji přes broker, mám TCP spojení jedno (nebo několik) již navázaných ...
Pokud bych se všemi komunikoval např. přes REST, pak by každý provozovatel systému musel "vystrčit" své rozhraní ven (tedy pokud bych nekomunikoval v nějaké vyhrazené síti). No a s tím mají provozovatelé obvykle problém. Neradi vystavují své porty na internetu.
V případě použití brokeru se navazuje TCP spojení mezi klientem a brokerem. Iniciátorem TCP spojení je v tom případě klient, a jediný port dostupný na internetu musí být broker (ten je pochopitelně potřeba dobře chránit proti útoku).