Razumijevanje brokera poruka. Učenje mehanike slanja poruka s ActiveMQ i Kafkom. Poglavlje 1

Pozdrav!

Počeo prevoditi malu knjigu:
«Razumijevanje brokera poruka
autor: Jakub Korab, izdavač: O'Reilly Media, Inc., datum izdanja: lipanj 2017., ISBN: 9781492049296.

Iz uvoda u knjigu:
”... Ova će vas knjiga naučiti kako razmišljati o posredničkim sustavima slanja poruka uspoređujući i kontrastirajući dvije popularne brokerske tehnologije: Apache ActiveMQ i Apache Kafka. Prikazat će slučajeve uporabe i razvojne poticaje koji su naveli njihove programere da zauzmu znatno različite pristupe istom području posredovanog slanja poruka između sustava. Bacit ćemo pogled na te tehnologije iz temelja i usput istaknuti utjecaj različitih dizajnerskih izbora. Steći ćete duboko razumijevanje oba proizvoda, razumijevanje toga kako se trebaju, a kako ne bi trebali koristiti, i razumijevanje na što trebate paziti kada razmatrate druge tehnologije slanja poruka u budućnosti. … »

Do sada prevedeni dijelovi:
1. poglavlje Uvod
Poglavlje 3. Kafka

Objavit ću dovršena poglavlja kako budu prevedena.

POGLAVLJE 1

Uvod

Međusistemska razmjena poruka jedno je od područja IT-a koje se najmanje razumije. Kao programer ili arhitekt, možda ste dobro upoznati s raznim okvirima i bazama podataka. Međutim, vjerojatno imate samo djelić uvida u to kako funkcioniraju tehnologije slanja poruka temeljene na brokeru. Ako se tako osjećate, ne brinite, u dobrom ste društvu.

Ljudi obično imaju vrlo ograničen kontakt s infrastrukturom za razmjenu poruka. Često se spajaju na sustav koji je davno kreiran ili preuzmu distribucijski komplet s interneta, instaliraju ga u PROM i počnu pisati kod za njega. Nakon što se infrastruktura pokrene i radi u PROM-u, rezultati mogu biti mješoviti: poruke se gube pri rušenjima, slanja ne rade kako očekujete ili brokeri ometaju vaše proizvođače ili ne šalju poruke vašim potrošačima.

Zvuči poznato?

Uobičajeni scenarij u kojem vaš kod za razmjenu poruka radi dobro, za sada. Sve dok ne prestane raditi. Ovo razdoblje uspavljuje budnost i daje lažan osjećaj sigurnosti, što dovodi do još većeg broja koda temeljenog na lažnim idejama o temeljnom ponašanju tehnologije. Kada stvari počnu ići po zlu, suočeni ste s neugodnom istinom: da stvarno niste razumjeli temeljno ponašanje proizvoda ili kompromise koje su odabrali autori, kao što su performanse nasuprot robusnosti ili transakcijski nasuprot horizontalna skalabilnost.

Bez dubokog razumijevanja načina rada brokera, ljudi iznose naizgled razumne tvrdnje o svojim sustavima za slanje poruka, kao što su:

  • Sustav nikada neće izgubiti poruke
  • Poruke će se obrađivati ​​sekvencijalno
  • Dodavanjem potrošača sustav će biti brži
  • Poruke će biti isporučene samo jednom

Nažalost, neke od ovih izjava temelje se na pretpostavkama koje vrijede samo pod određenim okolnostima, dok druge jednostavno nisu istinite.

Ova će vas knjiga naučiti kako razmišljati o posredničkim sustavima za razmjenu poruka uspoređujući dvije popularne brokerske tehnologije: Apache ActiveMQ i Apache Kafka. Prikazat će slučajeve uporabe i razvojne poticaje koji su naveli njihove programere da zauzmu znatno različite pristupe istom području posredovanog slanja poruka između sustava. Bacit ćemo pogled na te tehnologije iz temelja i usput istaknuti utjecaj različitih dizajnerskih izbora. Steći ćete duboko razumijevanje oba proizvoda, razumijevanje toga kako se trebaju, a kako ne bi trebali koristiti, i razumijevanje na što trebate paziti kada razmatrate druge tehnologije slanja poruka u budućnosti.

Prije nego što počnemo, prođimo kroz osnove.

Što je sustav razmjene poruka i zašto je potreban

Da bi dvije aplikacije mogle međusobno komunicirati, prvo moraju definirati sučelje. Definicija ovog sučelja uključuje izbor prijenosa ili protokola kao što su HTTP, MQTT ili SMTP i pregovaranje formata poruka koje će sustavi razmjenjivati. To može biti striktan proces, kao što je definiranje XML sheme sa zahtjevima za trošak korisnog opterećenja za poruku, ili može biti mnogo manje formalan, kao što je dogovor između dva programera da će neki dio HTTP zahtjeva sadržavati identifikator klijenta.

Sve dok su format poruka i redoslijed kojim se šalju dosljedni između sustava, oni će moći međusobno komunicirati bez brige o implementaciji drugog sustava. Unutrašnjost ovih sustava, kao što je programski jezik ili okvir koji se koristi, može se promijeniti tijekom vremena. Sve dok se sam ugovor održava, interakcija se može nastaviti nepromijenjena s druge strane. Ova su dva sustava učinkovito razdvojena (razdvojena) ovim sučeljem.

Sustavi za razmjenu poruka obično uključuju posrednika između dva sustava koji međusobno djeluju kako bi dodatno razdvojili (odvojili) pošiljatelja od primatelja ili primatelja. U tom slučaju sustav za razmjenu poruka omogućuje pošiljatelju da pošalje poruku bez da zna gdje se primatelj nalazi, je li aktivan ili koliko ima svojih instanci.

Pogledajmo nekoliko analogija za vrste problema koje sustav za razmjenu poruka rješava i uvedimo neke osnovne pojmove.

Od točke do točke

Alexandra odlazi u poštu poslati paket Adamu. Prilazi prozoru i predaje paket zaposlenici. Zaposlenica preuzima paket i daje Aleksandri račun. Adam ne mora biti kod kuće kada se paket šalje. Alexandra je uvjerena da će paket biti dostavljen Adamu u nekom trenutku u budućnosti i da može nastaviti sa svojim poslom. Kasnije, u nekom trenutku, Adam prima paket.

Ovo je primjer modela slanja poruka od točke do točke. Pošta ovdje djeluje kao mehanizam za distribuciju paketa, osiguravajući da se svaki paket isporuči jednom. Korištenje pošte odvaja čin slanja paketa od dostave paketa.
U klasičnim sustavima za razmjenu poruka, model od točke do točke implementiran je kroz redovi. Red čekanja djeluje kao međuspremnik FIFO (prvi ušao, prvi izašao) na koji se mogu pretplatiti jedan ili više potrošača. Svaka poruka se isporučuje samo jedan od pretplaćenih potrošača. Redovi obično pokušavaju pravedno distribuirati poruke među korisnicima. Samo jedan potrošač će primiti ovu poruku.

Izraz "izdržljiv" primjenjuje se na redove. Pouzdanost je svojstvo usluge koje jamči da će sustav za razmjenu poruka čuvati poruke u nedostatku aktivnih pretplatnika sve dok se potrošač ne pretplati na red čekanja za isporuku poruka.

Pouzdanost se često brka s upornost i, iako su dva pojma međusobno zamjenjiva, imaju različite funkcije. Postojanost određuje hoće li sustav za razmjenu poruka napisati poruku u neku vrstu pohrane između primanja i slanja potrošaču. Poruke poslane u red čekanja mogu, ali i ne moraju biti trajne.
Razmjena poruka od točke do točke koristi se kada slučaj upotrebe zahtijeva jednu radnju na poruci. Primjeri uključuju polaganje sredstava na račun ili ispunjavanje naloga za dostavu. Kasnije ćemo raspraviti zašto sustav za razmjenu poruka sam po sebi nije u stanju pružiti jednokratnu isporuku i zašto redovi u najboljem slučaju mogu pružiti jamstvo isporuke. barem jednom.

Izdavač-Pretplatnik

Gabriella bira konferencijski broj. Dok je spojena na konferenciju, čuje sve što govori govornik, kao i ostali sudionici poziva. Kad se onesvijesti, nedostaje joj ono što je rečeno. Kad se ponovno poveže, nastavlja čuti što se govori.

Ovo je primjer modela slanja poruka objavi-pretplati se. Konferencijski poziv djeluje kao mehanizam emitiranja. Osobu koja razgovara ne zanima koliko ljudi trenutno razgovara - sustav osigurava da svatko tko je trenutno povezan čuje što se govori.
U klasičnim sustavima za razmjenu poruka model objave-pretplate implementiran je putem vrhovi. Tema pruža istu metodu emitiranja kao i mehanizam konferencije. Kada se poruka postavi na temu, ona se distribuira za sve pretplaćene korisnike.

Teme obično nepouzdan (neizdržljiv). Poput slušatelja koji ne može čuti što se govori tijekom konferencijskog poziva, kada slušatelj ode s mreže, pretplatnici na temu propuštaju sve poruke koje su poslane dok su izvan mreže. Iz tog razloga možemo reći da vrhovi daju jamstvo isporuke. ne više od jednom za svakog potrošača.

Poruke Objavi-Pretplati se obično koriste kada su poruke informativne prirode i kada gubitak jedne poruke nije osobito značajan. Na primjer, tema može prenijeti očitanja temperature iz grupe senzora jednom u sekundi. Sustav kojeg zanima trenutna temperatura i koji se pretplati na temu neće brinuti ako propusti poruku – uskoro će stići druga.

hibridni modeli

Web stranica trgovine stavlja poruke o narudžbama u "red poruka". Glavni potrošač ovih poruka je izvršni sustav. Osim toga, sustav revizije mora imati kopije ovih poruka o narudžbi za kasnije praćenje. Oba sustava ne mogu propustiti poruke, čak i ako su sami sustavi neko vrijeme nedostupni. Web stranica ne bi trebala biti svjesna drugih sustava.

Slučajevi korištenja često zahtijevaju kombinaciju modela objavljivanja-pretplate i razmjene poruka od točke do točke, primjerice kada više sustava treba kopiju poruke, a potrebni su i pouzdanost i postojanost kako bi se spriječio gubitak poruke.

U tim slučajevima potrebno je odredište (opći termin za redove i teme) koje distribuira poruke u osnovi kao tema, tako da se svaka poruka šalje zasebnom sustavu koji je zainteresiran za te poruke, ali i u kojem svaki sustav može definirati nekoliko potrošača koji primaju dolazne poruke, što je više poput reda čekanja. Vrsta čitanja u ovom slučaju je − jednom za svakog dionika. Ta hibridna odredišta često zahtijevaju trajnost, tako da ako se potrošač prekine, poruke koje su poslane u to vrijeme prihvaćaju se kada se potrošač ponovno poveže.

Hibridni modeli nisu novi i mogu se primijeniti na većinu sustava za razmjenu poruka, uključujući i ActiveMQ (putem virtualnih ili kompozitnih odredišta koja kombiniraju teme i redove) i Kafku (implicitno, kao temeljno svojstvo dizajna odredišta).

Sada kada imamo osnovnu terminologiju i razumijevanje za što bi sustav za razmjenu poruka mogao biti koristan, uđimo u detalje.

Prijevod završen: tele.gg/srednja_java

Sljedeći prevedeni dio: Poglavlje 3. Kafka

Da bi se nastavio ...

Izvor: www.habr.com

Dodajte komentar