Entendre els intermediaris de missatges. Aprendre la mecànica de la missatgeria amb ActiveMQ i Kafka. Capítol 1

Hola a tots!

Vaig començar a traduir un petit llibre:
«Entendre els corredors de missatges«,
autor: Jakub Korab, editor: O'Reilly Media, Inc., data de publicació: juny de 2017, ISBN: 9781492049296.

De la introducció al llibre:
"... Aquest llibre us ensenyarà a pensar en els sistemes de missatgeria de corredor, comparant i contrastant dues tecnologies de corredor populars: Apache ActiveMQ i Apache Kafka. Es descriurà els casos d'ús i els incentius de desenvolupament que van portar els seus desenvolupadors a adoptar enfocaments molt diferents a la mateixa àrea: missatgeria entre sistemes amb un corredor intermedi. Veurem aquestes tecnologies des de zero i destacarem l'impacte de diverses opcions de disseny al llarg del camí. Aconseguiràs una comprensió profunda d'ambdós productes, una comprensió de com s'han d'utilitzar i com no s'han d'utilitzar, i una comprensió de què cal buscar quan es consideri altres tecnologies de missatgeria en el futur. ... »

Parts traduïdes fins ara:
Capítol 1. Introducció
Capítol 3. Kafka

Publicaré els capítols completats a mesura que es tradueixin.

CAPÍTOL 1

Introducció

La missatgeria de sistema a sistema és una de les àrees menys enteses de les TI. Com a desenvolupador o arquitecte, és possible que estigueu molt familiaritzat amb diversos marcs i bases de dades. No obstant això, és probable que només tingueu una familiaritat passa amb el funcionament de les tecnologies de missatgeria basades en corredors. Si et sents així, no et preocupis, estàs en bona companyia.

Les persones solen tenir un contacte molt limitat amb la infraestructura de missatgeria. Sovint es connecten a un sistema creat fa molt de temps, o descarreguen una distribució d'Internet, l'instal·len a PROM i comencen a escriure-hi codi. Després d'executar la infraestructura a PROM, els resultats es poden barrejar: els missatges es perden a causa de fallades, l'enviament no funciona com esperàveu o els corredors "pengen" els vostres productors o no envien missatges als vostres consumidors.

Sona familiar?

Un escenari comú és quan el vostre codi de missatgeria funciona molt bé, de moment. Fins que deixi de funcionar. Aquest període calma la guàrdia en una falsa sensació de seguretat, donant lloc a més codi basat en falses creences sobre el comportament fonamental de la tecnologia. Quan les coses comencen a sortir malament, us trobeu davant d'una veritat incòmode: que no heu entès realment el comportament subjacent del producte o les compensacions escollides pels autors, com ara el rendiment versus la fiabilitat o la transaccionalitat versus l'escalabilitat horitzontal. .

Sense una comprensió profunda de com funcionen els corredors, la gent fa declaracions aparentment raonables sobre els seus sistemes de missatgeria, com ara:

  • El sistema mai perdrà missatges
  • Els missatges es processaran seqüencialment
  • Afegir consumidors farà que el sistema sigui més ràpid
  • Els missatges només es lliuraran una vegada

Malauradament, algunes d'aquestes afirmacions es basen en supòsits que només s'apliquen en determinades circumstàncies, mentre que altres són simplement incorrectes.

Aquest llibre us ensenyarà a pensar en sistemes de missatgeria basats en intermediaris comparant i contrastant dues tecnologies de corredor populars: Apache ActiveMQ i Apache Kafka. Es descriurà els casos d'ús i els incentius de desenvolupament que van portar els seus desenvolupadors a adoptar enfocaments molt diferents a la mateixa àrea: missatgeria entre sistemes amb un corredor intermedi. Veurem aquestes tecnologies des de zero i destacarem l'impacte de diverses opcions de disseny al llarg del camí. Aconseguiràs una comprensió profunda d'ambdós productes, una comprensió de com s'han d'utilitzar i de quina manera no s'han d'utilitzar, i una comprensió de què cal buscar quan es consideri altres tecnologies de missatgeria en el futur.

Abans de començar, repassem els conceptes bàsics.

Què és un sistema de missatgeria i per què es necessita?

Perquè dues aplicacions es comuniquin entre elles, primer han de definir una interfície. Definir aquesta interfície implica seleccionar un transport o protocol, com ara HTTP, MQTT o SMTP, i negociar els formats de missatge que s'intercanviaran entre els sistemes. Aquest pot ser un procés estricte, com ara definir un esquema XML amb requisits de cost de càrrega útil del missatge, o pot ser molt menys formal, com ara un acord entre dos desenvolupadors que alguna part de la sol·licitud HTTP contindrà l'identificador del client .

Sempre que el format dels missatges i l'ordre en què s'envien siguin coherents entre els sistemes, es poden comunicar entre ells sense preocupar-se de la implementació de l'altre sistema. Els elements interns d'aquests sistemes, com ara el llenguatge de programació o el marc utilitzat, poden canviar amb el temps. Mentre es mantingui el contracte en si, la interacció pot continuar sense canvis de l'altra banda. Els dos sistemes estan desacoblats (separats) de manera efectiva per aquesta interfície.

Els sistemes de missatgeria solen implicar un intermediari entre dos sistemes que interactuen per desacoblar (separar) encara més l'emissor del destinatari o els destinataris. En aquest cas, el sistema de missatgeria permet al remitent enviar un missatge sense saber on és el destinatari, si està actiu o quantes instàncies hi ha.

Vegem un parell d'analogies per als tipus de problemes que resol un sistema de missatgeria i introduïm alguns termes bàsics.

Punt a punt

L'Alexandra va a l'oficina de correus per enviar un paquet a l'Adam. Va a la finestra i lliura el paquet a l'empleat. L'empleat recull el paquet i li dóna un rebut a l'Alexandra. Adam no necessita ser a casa quan s'enviï el paquet. L'Alexandra confia que el paquet serà lliurat a l'Adam en algun moment del futur i que pugui continuar fent els seus negocis. Més tard, en algun moment, Adam rep un paquet.

Aquest és un exemple de model de missatgeria punt a punt. L'oficina de correus actua aquí com un mecanisme de distribució de paquets, assegurant que cada paquet es lliura una vegada. L'ús d'una oficina de correus separa l'acte d'enviar un paquet de l'entrega del paquet.
En els sistemes de missatgeria clàssics, s'implementa el model punt a punt cues. La cua actua com a memòria intermèdia FIFO (first in, first out) al qual un o més consumidors poden subscriure. Cada missatge només s'entrega a un dels consumidors subscrits. Les cues solen intentar distribuir els missatges de manera justa entre els consumidors. Només un consumidor rebrà aquest missatge.

El terme "durable" s'aplica a les cues. Fiabilitat és una propietat de servei que garanteix que el sistema de missatgeria mantindrà els missatges en absència de subscriptors actius fins que un consumidor es subscrigui a la cua per al lliurament de missatges.

Sovint es confon amb la fiabilitat persistència i encara que els dos termes s'utilitzen indistintament, tenen funcions diferents. La persistència determina si el sistema de missatgeria escriu un missatge a algun tipus d'emmagatzematge entre la recepció i l'enviament al consumidor. Els missatges enviats a la cua poden ser persistents o no.
La missatgeria punt a punt s'utilitza quan el cas d'ús requereix una acció única sobre el missatge. Alguns exemples inclouen dipositar fons en un compte o completar una comanda de lliurament. Més endavant parlarem de per què el sistema de missatgeria per si mateix no pot oferir un lliurament únic i per què les cues poden, en el millor dels casos, oferir una garantia de lliurament. al menys un cop.

Editor-subscriptor

La Gabriella marca el número de la conferència. Mentre està connectada a la conferència, escolta tot el que diu l'orador, juntament amb la resta de participants de la trucada. Quan s'apaga, troba a faltar el que s'ha dit. Quan es torna a connectar, segueix escoltant el que es diu.

Aquest és un exemple de model de missatgeria publicar-subscriure. La trucada de conferència actua com un mecanisme de difusió. A la persona que parla no li importa quantes persones estan a la trucada actualment; el sistema assegura que qualsevol persona connectada escoltarà el que es diu.
En els sistemes de missatgeria clàssics, s'implementa el model de missatgeria de publicació-subscripció cims. El tema proporciona el mateix mètode de difusió que el mecanisme de conferència. Quan s'envia un missatge a un tema, es distribueix per a tots els usuaris subscrits.

Els temes solen ser poc fiable (no durador). Igual que un oient que no pot escoltar el que es diu en una trucada de conferència quan l'oient es desconnecta, els subscriptors del tema perden els missatges que s'enviïn mentre estan fora de línia. Per aquest motiu, podem dir que els temes ofereixen una garantia de lliurament no més d'una vegada per a cada consumidor.

Els missatges de publicació i subscripció s'utilitzen normalment quan els missatges són de naturalesa informativa i la pèrdua d'un missatge no és especialment significativa. Per exemple, un tema pot transmetre lectures de temperatura d'un grup de sensors una vegada per segon. Un sistema que s'interessa per la temperatura actual i que es subscriu a un tema no es preocuparà si es perd un missatge: un altre en arribarà en un futur proper.

models híbrids

El lloc web de la botiga col·loca missatges de comanda en una "cua de missatges". El principal consumidor d'aquests missatges és el sistema executiu. A més, el sistema d'auditoria hauria de tenir còpies d'aquests missatges de comanda per al seguiment posterior. Tots dos sistemes no poden permetre que els missatges passin, encara que els mateixos sistemes no estiguin disponibles durant un temps. El lloc web no hauria de ser conscient d'altres sistemes.

Els casos d'ús sovint requereixen una combinació de models de missatgeria de publicació-subscripció i punt a punt, com ara quan diversos sistemes requereixen una còpia d'un missatge i es requereix fiabilitat i persistència per evitar la pèrdua de missatges.

Aquests casos requereixen una destinació (terme general per a cues i temes) que distribueixi els missatges bàsicament com a tema, de manera que cada missatge s'enviï a un sistema independent interessat en aquests missatges, però també en el qual cada sistema pugui definir diversos consumidors que reben entrants. missatges, que s'assembla més a una cua. El tipus de lectura en aquest cas és una vegada per a cada part interessada. Aquestes destinacions híbrides sovint requereixen durabilitat, de manera que si un consumidor es desconnecta, els missatges que s'envien en aquest moment es reben després que el consumidor es torni a connectar.

Els models híbrids no són nous i es poden utilitzar en la majoria de sistemes de missatgeria, incloent-hi tant ActiveMQ (mitjançant destinacions virtuals o compostes que combinen temes i cues) com Kafka (implícitament, com a propietat fonamental del disseny de la seva destinació).

Ara que tenim una mica de terminologia bàsica i una comprensió de per a què podríem utilitzar un sistema de missatgeria, anem als detalls.

Traducció feta: tele.gg/middle_java

La següent part traduïda: Capítol 3. Kafka

Continuar ...

Font: www.habr.com

Afegeix comentari