Ciao a tutti!
Ho iniziato a tradurre un piccolo libro:
««,
autore: Jakub Korab, editore: O’Reilly Media, Inc., data di pubblicazione: Giugno 2017, ISBN: 9781492049296.
Dall'introduzione del libro:
«… Questo libro ti insegnerà a riflettere sui sistemi di messaggistica basati su broker, confrontando e mettendo a confronto due tecnologie di broker popolari: Apache ActiveMQ e Apache Kafka. Saranno presentati esempi di utilizzo e motivazioni di sviluppo che hanno portato i loro sviluppatori a utilizzare approcci completamente diversi nello stesso campo — lo scambio di messaggi tra sistemi tramite un broker intermedio. Esamineremo queste tecnologie dal principio e metteremo in evidenza l'influenza delle diverse scelte architetturali lungo il percorso. Avrai una profonda comprensione di entrambi i prodotti, saprai come usarli e come non usarli, e stimare a cosa prestare attenzione quando considererai altre tecnologie di messaggistica in futuro. …»
Sezioni tradotte fino a questo momento:
Pubblicherò i capitoli completati man mano che procedo con la traduzione.
CAPITOLO 1
Introduzione
La messaggistica intersistemi è una delle aree meno comprese nell'IT. Come sviluppatore o architetto, potresti essere ben informato su vari framework e database. Tuttavia, è probabile che tu abbia solo una conoscenza superficiale di come funzionano le tecnologie di messaggistica basate su broker. Se ti senti così, non preoccuparti, sei in buona compagnia.
Le persone di solito interagiscono con l'infrastruttura di messaggistica in modo molto limitato. Spesso si connettono a un sistema creato molto tempo fa, oppure scaricano una distribuzione da Internet, la installano nel loro ambiente di produzione e iniziano a scrivere codice per essa. Dopo aver avviato l'infrastruttura in produzione, i risultati possono essere ambigui: perdita di messaggi in caso di guasti, l'invio non funziona come previsto, oppure i broker bloccano i tuoi produttori o non inviano messaggi ai tuoi consumatori.
Ti suona familiare?
È un comune scenario in cui il tuo codice di messaggistica funziona perfettamente, fino a quando non smette di farlo. Questo periodo inganna la vigilanza e crea un falso senso di sicurezza, portando a una quantità maggiore di codice basato su false convinzioni sul comportamento fondamentale della tecnologia. Quando qualcosa inizia ad andare male, ci si trova di fronte a un'amara verità: non hai realmente compreso il comportamento di base del prodotto o i compromessi scelti dagli autori, come le prestazioni contro l'affidabilità, o la transazionalità contro la scalabilità orizzontale.
Senza una profonda comprensione di come funzionano i broker, le persone fanno affermazioni apparentemente ragionevoli sui loro sistemi di messaggistica, come:
- Il sistema non perderà mai messaggi
- I messaggi saranno elaborati in modo sequenziale
- Aggiungere consumatori renderà il sistema più veloce
- I messaggi saranno consegnati solo una volta
Sfortunatamente, alcune di queste affermazioni si basano su assunzioni valide solo in determinate circostanze, mentre altre sono semplicemente false.
Questo libro ti insegnerà a ragionare sui sistemi di messaggistica basati su broker, confrontando e mettendo a confronto due tecnologie di broker popolari: Apache ActiveMQ e Apache Kafka. Verranno presentati esempi d'uso e motivazioni dello sviluppo che hanno portato i loro sviluppatori a utilizzare approcci completamente diversi nello stesso ambito—la messaggistica tra sistemi tramite un broker intermedio. Analizzeremo queste tecnologie dall'inizio e metteremo in evidenza l'impatto delle varie scelte di design lungo il percorso. Otterrai una comprensione profonda di entrambi i prodotti, una visione chiara di come dovrebbero e non dovrebbero essere utilizzati, e un'idea di cosa considerare quando esamini altre tecnologie di messaggistica in futuro.
Prima di iniziare, diamo un'occhiata alle basi.
Cos'è un sistema di messaggistica e a cosa serve?
Affinché due applicazioni possano comunicare tra loro, devono prima definire un'interfaccia. La definizione di questa interfaccia comprende la scelta di un trasporto o protocollo, come HTTP, MQTT o SMTP, e l'accordo sui formati dei messaggi che i sistemi scambieranno. Questo può essere un processo rigoroso, come la definizione di uno schema XML con requisiti sui costi per il payload del messaggio, oppure può essere molto meno formale, ad esempio un accordo tra due sviluppatori riguardo al fatto che una certa parte della richiesta HTTP conterrà un identificatore del cliente.
Finché il formato dei messaggi e l'ordine in cui vengono inviati tra i sistemi sono concordati, potranno interagire tra loro senza preoccuparsi dell'implementazione dell'altra sistema. I dettagli interni di questi sistemi, come il linguaggio di programmazione o il framework utilizzato, possono cambiare nel tempo. Finché il contratto stesso viene mantenuto, l'interazione può continuare senza modifiche dall'altra parte. Questi due sistemi sono efficacemente disaccoppiati (separati) da questa interfaccia.
I sistemi di messaggistica prevedono generalmente un intermediario tra due sistemi che interagiscono per disassociare (separare) il mittente dal destinatario o dai destinatari. In questo modo, il sistema di messaggistica consente al mittente di inviare un messaggio senza sapere dove si trovi il destinatario, se sia attivo o quanti siano i suoi esemplari.
Esaminiamo un paio di analogie su differenti problemi che risolve un sistema di messaggistica e introduciamo alcuni termini fondamentali.
Point-to-Point
Alexandra va all'ufficio postale per inviare un pacco ad Adam. Si avvicina allo sportello e consegna il pacco all'impiegato. L'impiegato prende il pacco e restituisce ad Alexandra una ricevuta. Adam non ha bisogno di essere a casa al momento dell'invio del pacco. Alexandra è sicura che il pacco arriverà ad Adam in un certo momento nel futuro e può continuare a occuparsi delle sue faccende. In un momento successivo, Adam riceve il pacco.
Questo è un esempio di modello di messaggistica point-to-point. L'ufficio postale agisce qui come un meccanismo di distribuzione dei pacchi, garantendo che ogni pacco venga consegnato una sola volta. L'utilizzo dell'ufficio postale separa l'atto di invio del pacco dalla consegna del pacco.
Nei sistemi di messaggistica classici, il modello "point-to-point" è implementato tramite code. La coda funge da buffer FIFO (primo arrivato, primo uscito), a cui possono iscriversi uno o più consumatori. Ogni messaggio viene consegnato solo a uno dei consumatori iscritti. Le code cercano di distribuire i messaggi in modo equo tra i consumatori. Solo un consumatore riceverà un determinato messaggio.
Il termine "affidabile" ("durable") viene applicato alle code. Affidabilità — è una proprietà del servizio che garantisce che il sistema di messaggistica conserverà i messaggi in assenza di iscritti attivi fino a quando un consumatore non si iscriverà alla coda per la consegna dei messaggi.
L'affidabilità viene spesso confusa con la persistenza E sebbene questi due termini siano intercambiabili, svolgono funzioni diverse. La persistenza determina se un messaggio viene registrato dal sistema di messaggistica in qualche tipo di archiviazione tra la ricezione e l'invio al consumatore. I messaggi inviati in coda possono essere o meno persistenti.
La messaggistica di tipo 'Punto a Punto' è utilizzata quando il caso d'uso richiede un'azione singola sul messaggio. Un esempio può essere l'accredito di fondi su un conto o l'esecuzione di un ordine di consegna. Discuteremo in seguito perché il sistema di messaggistica da solo non riesca a garantire una consegna unica e perché le code possano al massimo garantire la consegna. almeno una volta.
Publisher-Subscriber
Gabriella compone il numero della conferenza. Finché è connessa alla conferenza, ascolta tutto ciò che dice il relatore, insieme agli altri partecipanti alla chiamata. Quando si disconnette, perde ciò che viene detto. Quando si riconnette, continua a sentire ciò che dicono.
Questo è un esempio di modello di messaggistica pubblicazione-abbonamento. La conferenza telefonica funge da meccanismo di broadcasting. La persona che parla non si preoccupa di quante persone si siano unite alla chiamata — il sistema garantisce che chiunque si connetta in quel momento possa sentire ciò che viene detto.
Nei sistemi di messaggistica classici, il modello di scambio messaggi "pubblicazione-iscrizione" viene implementato tramite topic. Un topic offre uno stesso modo di broadcasting come il meccanismo della conferenza telefonica. Quando un messaggio viene inviato a un topic, esso viene distribuito a tutti gli utenti iscritti.
I topic sono generalmente non affidabili (nondurable). Così come un ascoltatore che non sente ciò che viene detto durante una chiamata in conferenza quando si disconnette, gli iscritti a un topic saltano eventuali messaggi inviati nel momento in cui sono offline. Per questo motivo, si può affermare che i topic forniscono una garanzia di consegna non superiore a una volta per ciascun consumatore.
Le messaggistica di tipo «pubblicazione-iscrizione» è generalmente utilizzata quando i messaggi hanno un carattere informativo e la perdita di un singolo messaggio non è particolarmente significativa. Ad esempio, un topic può trasmettere i dati della temperatura da un gruppo di sensori una volta al secondo. Un sistema che è interessato alla temperatura attuale e che si iscrive al topic non si preoccuperà se perde un messaggio: un altro arriverà a breve.
Modelli ibridi
Il sito web del negozio posiziona i messaggi sugli ordini in una «coda di messaggi». Il principale consumatore di questi messaggi è il sistema esecutivo. Inoltre, il sistema di audit deve avere delle copie di questi messaggi sugli ordini per un monitoraggio successivo. Entrambi i sistemi non possono perdere messaggi, anche se i sistemi stessi non sono disponibili per un certo periodo. Il sito web non deve conoscere gli altri sistemi.
Gli scenari d'uso spesso richiedono la combinazione dei modelli di messaggistica "pubblicazione-sottoscrizione" e "point-to-point". Ad esempio, quando più sistemi necessitano di una copia del messaggio, è necessaria sia l'affidabilità che la persistenza per evitare la perdita del messaggio.
In questi casi è necessario un destinatario (destination) (un termine generico per code e argomenti), che distribuisce i messaggi principalmente come un argomento, in modo tale che ogni messaggio venga inviato a un sistema separato interessato a questi messaggi, ma in cui ogni sistema può anche definire più consumatori che ricevono i messaggi in entrata, il che è più simile a una coda. Il tipo di lettura in questo caso è - una volta per ogni parte interessata. Questi destinatari ibridi richiedono spesso affidabilità (durability), quindi se un consumatore si disconnette, i messaggi inviati in quel periodo vengono ricevuti dopo la riconnessione del consumatore.
I modelli ibridi non sono una novità e possono essere utilizzati nella maggior parte dei sistemi di messaggistica, inclusi sia ActiveMQ (tramite destinatari virtuali o compositi che combinano argomenti e code) sia Kafka (implicitamente, come proprietà fondamentale del design del suo destinatario).
Ora che abbiamo una certa terminologia di base e una comprensione di come potrebbe servirci un sistema di messaggistica, passiamo ai dettagli.
Tradotto da:
La seguente parte tradotta:
Continua...
Fonte: habr.com
