Pozdrav svima!
Počeo sam prevoditi malu knjigu:
««
autor: Jakub Korab, izdavač: O'Reilly Media, Inc., datum izdanja: jun 2017, ISBN: 9781492049296.
Iz uvoda u knjigu:
"... Ova knjiga će vas naučiti kako razmišljati o brokerskim sistemima za razmjenu poruka, upoređujući i suprotstavljajući dvije popularne brokerske tehnologije: Apache ActiveMQ i Apache Kafka. U njemu će se opisati slučajevi upotrebe i razvojni poticaji koji su naveli njihove programere da zauzmu vrlo različite pristupe istoj oblasti – razmjenu poruka između sistema sa posrednim brokerom. Pogledat ćemo ove tehnologije od temelja i naglasiti utjecaj različitih dizajnerskih izbora na putu. Steći ćete duboko razumijevanje oba proizvoda, razumijevanje kako bi se trebali, a kako ne bi trebali koristiti, i razumijevanje onoga što treba tražiti kada razmatrate druge tehnologije za razmjenu poruka u budućnosti ... "
Do sada prevedeni dijelovi:
Objavljivaću završena poglavlja kako budu prevedena.
POGLAVLJE 1
Uvod
Razmjena poruka od sistema do sistema jedna je od oblasti IT-a koje se najmanje razumije. Kao programer ili arhitekta, možda ste dobro upoznati sa različitim okvirima i bazama podataka. Međutim, vjerovatno je da imate samo prolazno poznavanje načina na koji funkcionišu tehnologije za razmjenu poruka zasnovane na brokerima. 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 povežu na sistem koji je davno kreiran, ili preuzmu distribuciju sa interneta, instaliraju je u PROM i počnu pisati kod za nju. Nakon pokretanja infrastrukture u PROM-u, rezultati mogu biti mješoviti: poruke se gube zbog kvarova, slanje ne funkcionira kako ste očekivali, ili brokeri "okače" vaše proizvođače ili ne šalju poruke vašim potrošačima.
Zvuči poznato?
Uobičajeni scenario je u kojem vaš kod za razmjenu poruka za sada odlično funkcionira. Sve dok ne prestane da radi. Ovaj period uljuljkava gard u lažni osjećaj sigurnosti, što dovodi do više koda zasnovanog na lažnim uvjerenjima o fundamentalnom ponašanju tehnologije. Kada stvari počnu ići naopako, suočeni ste s nezgodnom istinom: da niste stvarno razumjeli osnovno ponašanje proizvoda ili kompromise koje su odabrali autori, kao što su performanse naspram pouzdanosti ili transakcija nasuprot horizontalnoj skalabilnosti .
Bez dubokog razumijevanja načina na koji brokeri rade, ljudi daju naizgled razumne izjave o svojim sistemima za razmjenu poruka, kao što su:
- Sistem nikada neće izgubiti poruke
- Poruke će se obrađivati uzastopno
- Dodavanje potrošača će učiniti sistem bržim
- Poruke će biti isporučene samo jednom
Nažalost, neke od ovih izjava su zasnovane na pretpostavkama koje se primjenjuju samo pod određenim okolnostima, dok su druge jednostavno netačne.
Ova knjiga će vas naučiti kako razmišljati o sistemima za razmjenu poruka zasnovanim na brokerima, upoređujući i suprotstavljajući dvije popularne brokerske tehnologije: Apache ActiveMQ i Apache Kafka. U njemu će se opisati slučajevi upotrebe i razvojni poticaji koji su naveli njihove programere da zauzmu vrlo različite pristupe istoj oblasti – razmjenu poruka između sistema sa posrednim brokerom. Pogledat ćemo ove tehnologije od temelja i naglasiti utjecaj različitih dizajnerskih izbora na putu. Steći ćete duboko razumijevanje oba proizvoda, razumijevanje kako bi se trebali, a kako ne bi trebali koristiti, i razumijevanje onoga što treba tražiti kada razmatrate druge tehnologije za razmjenu poruka u budućnosti.
Prije nego što počnemo, prijeđimo na osnove.
Šta je sistem za razmenu poruka i zašto je potreban?
Da bi dvije aplikacije komunicirale jedna s drugom, prvo moraju definirati interfejs. Definiranje ovog interfejsa uključuje odabir transporta ili protokola, kao što su HTTP, MQTT ili SMTP, i pregovaranje o formatima poruka koji će se razmjenjivati između sistema. Ovo može biti strog proces, kao što je definiranje XML sheme sa zahtjevima za troškove korisnog učitavanja poruka, ili može biti mnogo manje formalan, kao što je sporazum između dva programera da će neki dio HTTP zahtjeva sadržavati identifikator klijenta.
Sve dok su format poruka i redosled kojim se šalju konzistentni između sistema, oni mogu međusobno komunicirati bez brige o implementaciji drugog sistema. Unutrašnjost ovih sistema, kao što je programski jezik ili okvir koji se koristi, može se promeniti tokom vremena. Sve dok se održava sam ugovor, interakcija se može nastaviti bez promjena s druge strane. Ova dva sistema su efektivno odvojena (razdvojena) ovim interfejsom.
Sistemi za razmenu poruka obično uključuju posrednika između dva sistema koji međusobno deluju kako bi dalje odvojili (odvojili) pošiljaoca od primaoca ili primaoca. U ovom slučaju, sistem za razmjenu poruka omogućava pošiljaocu da pošalje poruku bez da zna gdje se primalac nalazi, da li je aktivan ili koliko ima instanci.
Pogledajmo nekoliko analogija za vrste problema koje sistem razmjene poruka rješava i uvedemo neke osnovne pojmove.
Od točke do točke
Aleksandra odlazi u poštu da pošalje Adamu paket. Odlazi do prozora i predaje zaposleniku paket. Zaposlenik preuzima paket i daje Aleksandri račun. Adam ne mora biti kod kuće kada se paket pošalje. Aleksandra je uvjerena da će paket biti isporučen Adamu u nekom trenutku u budućnosti i da može nastaviti da se bavi svojim poslom. Kasnije u nekom trenutku Adam prima paket.
Ovo je primjer modela razmjene poruka tačka do tačke. Pošta ovdje djeluje kao mehanizam distribucije paketa, osiguravajući da se svaka pošiljka uruči jednom. Korištenje pošte odvaja čin slanja paketa od dostave paketa.
U klasičnim sistemima za razmenu poruka, model od tačke do tačke se implementira kroz redovi. Red se ponaša kao FIFO (prvi ušao, prvi izašao) bafer na koji se može pretplatiti jedan ili više potrošača. Svaka poruka se isporučuje samo jednom od pretplaćenih potrošača. Redovi obično pokušavaju da pošteno distribuiraju poruke među potrošačima. Samo jedan potrošač će primiti ovu poruku.
Termin „trajan“ se primjenjuje na redove čekanja. Pouzdanost je svojstvo usluge koje osigurava da će sistem za razmjenu poruka zadržati poruke u odsustvu aktivnih pretplatnika sve dok se potrošač ne pretplati na red za isporuku poruka.
Pouzdanost se često brka sa upornost i iako se dva termina koriste naizmjenično, oni služe različitim funkcijama. Postojanost određuje da li sistem za razmenu poruka zapisuje poruku u neku vrstu skladišta između njenog prijema i slanja potrošaču. Poruke poslane u red čekanja mogu ili ne moraju biti trajne.
Poruke od tačke do tačke se koriste kada slučaj upotrebe zahteva jednokratnu radnju na poruci. Primjeri uključuju polaganje sredstava na račun ili dovršavanje naloga za isporuku. Kasnije ćemo razgovarati o tome zašto sam sistem za razmjenu poruka nije u mogućnosti da pruži jednokratnu isporuku i zašto redovi u najboljem slučaju mogu pružiti garanciju isporuke barem jednom.
Izdavač-Pretplatnik
Gabriella bira konferencijski broj. Dok je spojena na konferenciju, čuje sve što govornik govori, zajedno sa ostalim učesnicima poziva. Kada se isključi, propušta ono što je rečeno. Kada se ponovo poveže, nastavlja da čuje šta se govori.
Ovo je primjer modela razmjene poruka objavi-pretplati se. Konferencijski pozivi djeluju kao mehanizam emitiranja. Osoba koja govori ne brine koliko je ljudi trenutno na pozivu - sistem osigurava da će svako ko je trenutno povezan čuti šta se govori.
U klasičnim sistemima za razmjenu poruka, model razmjene poruka objavi-pretplati se implementira kroz vrhovi. Topic pruža isti način emitiranja kao i mehanizam konferencije. Kada se poruka pošalje na temu, ona se distribuira za sve pretplaćene korisnike.
Teme su obično nepouzdan (neizdržljiv). Baš kao i slušalac koji ne može čuti šta je rečeno na konferencijskom pozivu kada slušalac prekine vezu, pretplatnici na temu propuštaju sve poruke koje su poslane dok su van mreže. Iz tog razloga možemo reći da teme daju garanciju isporuke ne više od jednom za svakog potrošača.
Objavljivanje-pretplata poruka se obično koristi kada su poruke informativne prirode i gubitak jedne poruke nije posebno značajan. Na primjer, tema može prenositi očitanja temperature iz grupe senzora jednom u sekundi. Sistem koji je zainteresovan za trenutnu temperaturu i koji je pretplaćen na temu neće se brinuti ako propusti neku poruku - druga će stići u bliskoj budućnosti.
hibridni modeli
Web lokacija trgovine postavlja poruke o narudžbi u "red poruka". Glavni potrošač ovih poruka je izvršni sistem. Pored toga, sistem revizije treba da ima kopije ovih poruka naloga za naknadno praćenje. Oba sistema ne mogu dozvoliti prolazak poruka, čak i ako su sami sistemi nedostupni neko vrijeme. Web stranica ne bi trebala biti svjesna drugih sistema.
Slučajevi korištenja često zahtijevaju kombinaciju modela objavljivanja-pretplate i razmjene poruka od tačke do tačke, kao što je kada više sistema zahtijeva kopiju poruke, a pouzdanost i postojanost su potrebni da bi se spriječio gubitak poruke.
Ovi slučajevi zahtijevaju odredište (opći termin za redove i teme) koje distribuira poruke u osnovi kao temu, tako da se svaka poruka šalje zasebnom sistemu zainteresiranom za te poruke, ali i u kojem svaki sistem može definirati nekoliko potrošača koji primaju dolazne poruke, što više liči na red čekanja. Vrsta čitanja u ovom slučaju je jednom za svaku zainteresovanu stranu. Ova hibridna odredišta često zahtijevaju trajnost, tako da ako potrošač ode van mreže, poruke koje se šalju u to vrijeme primaju se nakon što se potrošač ponovo poveže.
Hibridni modeli nisu novi i mogu se koristiti u većini sistema za razmenu poruka, uključujući i ActiveMQ (preko virtuelnih ili kompozitnih odredišta koja kombinuju teme i redove) i Kafku (implicitno, kao osnovno svojstvo njegovog dizajna odredišta).
Sada kada imamo neku osnovnu terminologiju i razumijevanje za šta bismo mogli koristiti sistem za razmjenu poruka, pređimo na detalje.
Prevod urađen:
Sljedeći prevedeni dio:
Da se nastavi ...
izvor: www.habr.com