Viestien välittäjien ymmärtäminen. Viestintämekaniikan oppiminen ActiveMQ:n ja Kafkan avulla. Luku 1

Hei kaikille!

Aloin kääntää pientä kirjaa:
«Viestivälittäjien ymmärtäminen",
kirjoittaja: Jakub Korab, kustantaja: O'Reilly Media, Inc., julkaisupäivä: kesäkuu 2017, ISBN: 9781492049296.

Kirjan johdannosta:
" ... Tämä kirja opettaa sinua ajattelemaan välittäjien viestintäjärjestelmiä ja vertailemaan kahta suosittua välittäjäteknologiaa: Apache ActiveMQ ja Apache Kafka. Siinä hahmotellaan käyttötapauksia ja kehityskannustimia, jotka saivat kehittäjät ottamaan hyvin erilaisia ​​lähestymistapoja samalle alueelle – viestittämään järjestelmien välillä välivälittäjällä. Tarkastelemme näitä teknologioita alusta alkaen ja korostamme eri suunnitteluvalintojen vaikutusta matkan varrella. Saat syvän ymmärryksen molemmista tuotteista, ymmärryksen siitä, miten niitä pitäisi ja ei pitäisi käyttää, ja ymmärryksen siitä, mitä sinun tulee ottaa huomioon, kun harkitset muita viestintätekniikoita tulevaisuudessa. ... "

Tähän mennessä käännetyt osat:
Luku 1. Johdanto
Luku 3. Kafka

Julkaisen valmiit luvut sitä mukaa kun ne käännetään.

LUKU 1

Esittely

Järjestelmien välinen viestintä on yksi IT:n vähiten ymmärretyistä alueista. Kehittäjänä tai arkkitehtina saatat tuntea hyvin erilaiset puitteet ja tietokannat. On kuitenkin todennäköistä, että sinulla on vain ohimenevä perehtyneisyys välittäjäpohjaisten viestintätekniikoiden toimintaan. Jos sinusta tuntuu siltä, ​​älä huoli, olet hyvässä seurassa.

Ihmisillä on tyypillisesti hyvin rajallinen yhteys viestintäinfrastruktuuriin. He muodostavat usein yhteyden kauan sitten luotuun järjestelmään tai lataavat jakelun Internetistä, asentavat sen PROM:iin ja alkavat kirjoittaa sille koodia. Infrastruktuurin ajettua PROM:ssa tulokset voivat olla ristiriitaisia: viestejä katoaa vikojen takia, lähetys ei toimi odotetulla tavalla tai välittäjät "rokkaavat" tuottajasi tai eivät lähetä viestejä kuluttajillesi.

Kuulostaa tutulta?

Yleinen skenaario on, että viestikoodisi toimii hyvin toistaiseksi. Kunnes lakkaa toimimasta. Tämä ajanjakso tuudittaa vartijan väärään turvallisuuden tunteeseen, mikä johtaa enemmän koodiin, jotka perustuvat vääriin uskomuksiin tekniikan peruskäyttäytymisestä. Kun asiat alkavat mennä pieleen, kohtaat epämiellyttävän totuuden: et ole oikein ymmärtänyt tuotteen taustalla olevaa käyttäytymistä tai tekijöiden valitsemia kompromisseja, kuten suorituskykyä vs. luotettavuus tai transaktiokyky vs. horisontaalinen skaalautuvuus. .

Ilman syvällistä ymmärrystä välittäjien toiminnasta ihmiset tekevät näennäisesti järkeviä lausuntoja viestintäjärjestelmistään, kuten:

  • Järjestelmä ei koskaan menetä viestejä
  • Viestit käsitellään peräkkäin
  • Kuluttajien lisääminen tekee järjestelmästä nopeamman
  • Viestit toimitetaan vain kerran

Valitettavasti jotkut näistä väitteistä perustuvat oletuksiin, jotka pätevät vain tietyissä olosuhteissa, kun taas toiset ovat yksinkertaisesti vääriä.

Tämä kirja opettaa sinua ajattelemaan välittäjäpohjaisia ​​viestintäjärjestelmiä, vertaamalla kahta suosittua välittäjäteknologiaa: Apache ActiveMQ ja Apache Kafka. Siinä hahmotellaan käyttötapauksia ja kehityskannustimia, jotka saivat kehittäjät ottamaan hyvin erilaisia ​​lähestymistapoja samalle alueelle – viestittämään järjestelmien välillä välivälittäjällä. Tarkastelemme näitä teknologioita alusta alkaen ja korostamme eri suunnitteluvalintojen vaikutusta matkan varrella. Saat syvän ymmärryksen molemmista tuotteista, ymmärryksen siitä, miten niitä pitäisi ja ei pitäisi käyttää, ja ymmärryksen siitä, mitä sinun tulee ottaa huomioon harkitessasi muita viestintätekniikoita tulevaisuudessa.

Ennen kuin aloitamme, käydään läpi perusasiat.

Mikä on viestintäjärjestelmä ja miksi sitä tarvitaan?

Jotta kaksi sovellusta voivat kommunikoida keskenään, niiden on ensin määritettävä käyttöliittymä. Tämän rajapinnan määrittelyyn kuuluu kuljetuksen tai protokollan, kuten HTTP, MQTT tai SMTP, valinta ja järjestelmien välillä vaihdettavien viestimuotojen neuvotteleminen. Tämä voi olla tiukka prosessi, kuten XML-skeeman määrittäminen viestin hyötykuorman kustannusvaatimuksilla, tai se voi olla paljon vähemmän muodollinen, kuten kahden kehittäjän välinen sopimus, jonka mukaan HTTP-pyynnön jokin osa sisältää asiakastunnisteen .

Niin kauan kuin viestien muoto ja lähetysjärjestys ovat yhdenmukaisia ​​järjestelmien välillä, ne voivat kommunikoida toistensa kanssa huolehtimatta toisen järjestelmän toteutuksesta. Näiden järjestelmien sisäosat, kuten ohjelmointikieli tai käytetty kehys, voivat muuttua ajan myötä. Niin kauan kuin itse sopimus säilyy, vuorovaikutus voi jatkua ilman muutoksia toiselta puolelta. Tämä rajapinta erottaa nämä kaksi järjestelmää tehokkaasti.

Viestintäjärjestelmiin kuuluu tyypillisesti välittäjä kahden järjestelmän välillä, jotka ovat vuorovaikutuksessa lähettäjän ja vastaanottajan tai vastaanottajien välisen yhteyden edelleen erottamiseksi. Tässä tapauksessa viestintäjärjestelmä sallii lähettäjän lähettää viestin tietämättä missä vastaanottaja on, onko hän aktiivinen tai kuinka monta tapausta on.

Katsotaanpa pari analogiaa sellaisille ongelmille, joita viestintäjärjestelmä ratkaisee, ja esitellään joitain perustermejä.

Pisteestä pisteeseen

Alexandra menee postiin lähettämään Adamille paketin. Hän menee ikkunan luo ja ojentaa paketin työntekijälle. Työntekijä noutaa paketin ja antaa Alexandralle kuitin. Adamin ei tarvitse olla kotona, kun paketti lähetetään. Alexandra luottaa siihen, että paketti toimitetaan Adamille jossain vaiheessa tulevaisuudessa ja voi jatkaa asioimista. Myöhemmin jossain vaiheessa Adam saa paketin.

Tämä on esimerkki viestintämallista pisteestä pisteeseen. Posti toimii täällä pakettien jakelumekanismina varmistaen, että jokainen paketti toimitetaan kerran. Postin käyttö erottaa paketin lähettämisen paketin toimituksesta.
Klassisissa viestintäjärjestelmissä point-to-point-malli toteutetaan kautta jono. Jono toimii FIFO-puskurina (first in, first out), jonka yksi tai useampi kuluttaja voi tilata. Jokainen viesti toimitetaan vain jollekin tilatuista kuluttajista. Jonot pyrkivät yleensä jakamaan viestejä oikeudenmukaisesti kuluttajien kesken. Vain yksi kuluttaja saa tämän viestin.

Termiä "kestävä" käytetään jonoihin. Luotettavuus on palveluominaisuus, joka varmistaa, että viestijärjestelmä säilyttää viestit aktiivisten tilaajien puuttuessa, kunnes kuluttaja tilaa viestin toimitusjonon.

Luotettavuus sekoitetaan usein sitkeys ja vaikka näitä kahta termiä käytetään vaihtokelpoisesti, ne palvelevat eri tehtäviä. Pysyvyys määrittää, kirjoittaako viestintäjärjestelmä viestin jonkinlaiseen muistiin sen vastaanottamisen ja kuluttajalle lähettämisen välillä. Jonoon lähetetyt viestit voivat olla pysyviä tai eivät.
Point-to-point-viestintää käytetään, kun käyttötapaus vaatii kertaluonteisen toimenpiteen viestiin. Esimerkkejä ovat varojen tallettaminen tilille tai toimitustilauksen viimeistely. Keskustelemme myöhemmin, miksi viestijärjestelmä ei yksinään pysty tarjoamaan kertatoimitusta ja miksi jonot voivat parhaimmillaan tarjota toimitustakuun ainakin kerran.

Kustantaja-tilaaja

Gabriella soittaa neuvottelunumeron. Kun hän on yhteydessä neuvotteluun, hän kuulee kaiken, mitä puhuja sanoo, sekä muut puhelun osallistujat. Kun hän virittyy, hän kaipaa sanojaan. Kun hän muodostaa yhteyden uudelleen, hän kuulee edelleen, mitä sanotaan.

Tämä on esimerkki viestintämallista julkaise-tilaa. Neuvottelupuhelu toimii lähetysmekanismina. Puhuva henkilö ei välitä, kuinka monta henkilöä puhelussa on tällä hetkellä - järjestelmä varmistaa, että kaikki tällä hetkellä yhteydessä olevat kuulevat, mitä sanotaan.
Klassisissa viestintäjärjestelmissä julkaisu-tilaa -viestintämalli toteutetaan kautta yläosat. Topic tarjoaa saman lähetysmenetelmän kuin neuvottelumekanismi. Kun viesti lähetetään aiheeseen, se jaetaan kaikille tilaajille.

Aiheet ovat yleensä epäluotettava (ei kestämätön). Aivan kuten kuuntelija, joka ei kuule, mitä neuvottelupuhelussa sanotaan, kun kuuntelija katkaisee yhteyden, aiheen tilaajat näkevät kaikki viestit, jotka lähetetään ollessaan offline-tilassa. Tästä syystä voimme sanoa, että aiheet antavat toimitustakuun ei useammin kuin kerran jokaiselle kuluttajalle.

Publish-subscribe -viestintää käytetään tyypillisesti silloin, kun viestit ovat luonteeltaan informatiivisia ja yhden viestin katoaminen ei ole erityisen merkittävää. Esimerkiksi aihe voi lähettää lämpötilalukemia anturiryhmästä kerran sekunnissa. Järjestelmä, joka on kiinnostunut nykyisestä lämpötilasta ja joka tilaa aiheen, ei huolehdi, jos se jättää viestin huomaamatta - uusi tulee lähitulevaisuudessa.

hybridi mallit

Kaupan verkkosivusto asettaa tilausviestit "viestijonoon". Näiden viestien pääasiallinen kuluttaja on toimeenpanojärjestelmä. Lisäksi valvontajärjestelmällä tulee olla kopiot näistä tilausviesteistä myöhempää seurantaa varten. Molemmat järjestelmät eivät voi päästää viestejä läpi, vaikka järjestelmät itse eivät ole käytettävissä jonkin aikaa. Sivusto ei saa olla tietoinen muista järjestelmistä.

Käyttötapaukset vaativat usein julkaisu-tilaa- ja point-to-point -viestintämallien yhdistelmän, esimerkiksi silloin, kun useat järjestelmät vaativat kopion viestistä ja sekä luotettavuus että pysyvyys vaaditaan viestin katoamisen estämiseksi.

Näissä tapauksissa tarvitaan kohde (yleinen termi jonoille ja aiheille), joka jakaa viestejä pohjimmiltaan aiheena niin, että jokainen viesti lähetetään erilliseen näistä viesteistä kiinnostuneeseen järjestelmään, mutta jossa kukin järjestelmä voi myös määritellä useita kuluttajia, jotka vastaanottavat saapuvia viestejä. viestejä, mikä on enemmän kuin jono. Lukutyyppi tässä tapauksessa on kerran kullekin sidosryhmälle. Nämä hybridikohteet vaativat usein kestävyyttä, joten jos kuluttaja siirtyy offline-tilaan, tuolloin lähetetyt viestit vastaanotetaan, kun kuluttaja muodostaa yhteyden uudelleen.

Hybridimallit eivät ole uusia, ja niitä voidaan käyttää useimmissa viestintäjärjestelmissä, mukaan lukien sekä ActiveMQ (virtuaali- tai yhdistelmäkohteet, jotka yhdistävät aiheita ja jonoja) että Kafka (implisiittisesti kohdesuunnittelun perustavanlaatuisena ominaisuutena).

Nyt kun meillä on perusterminologiaa ja ymmärrys siitä, mihin voisimme käyttää viestintäjärjestelmää, mennään yksityiskohtiin.

Käännös tehty: tele.gg/middle_java

Seuraava käännetty osa: Luku 3. Kafka

Jatkuu ...

Lähde: will.com

Lisää kommentti