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 al libro:
"... Questo libro ti insegnerà come pensare ai sistemi di messaggistica dei broker, confrontando e contrapponendo due tecnologie di broker popolari: Apache ActiveMQ e Apache Kafka. Illustrerà i casi d'uso e gli incentivi allo sviluppo che hanno portato gli sviluppatori ad adottare approcci molto diversi nella stessa area: la messaggistica tra sistemi con un broker intermedio. Esamineremo queste tecnologie da zero ed evidenzieremo l'impatto delle varie scelte di progettazione lungo il percorso. Acquisirai una conoscenza approfondita di entrambi i prodotti, una comprensione di come dovrebbero e non dovrebbero essere utilizzati e una comprensione di cosa cercare quando si prendono in considerazione altre tecnologie di messaggistica in futuro ... »
Parti tradotte finora:
Pubblicherò i capitoli completati man mano che vengono tradotti.
CAPITOLO 1
Introduzione
La messaggistica da sistema a sistema è una delle aree meno comprese dell'IT. In qualità di sviluppatore o architetto, potresti avere molta familiarità con vari framework e database. Tuttavia, è probabile che tu abbia solo una familiarità superficiale con il funzionamento delle tecnologie di messaggistica basate su broker. Se ti senti così, non preoccuparti, sei in buona compagnia.
Le persone in genere hanno un contatto molto limitato con l'infrastruttura di messaggistica. Spesso si connettono a un sistema creato molto tempo fa, oppure scaricano una distribuzione da Internet, la installano nella PROM e iniziano a scrivere il codice per essa. Dopo aver eseguito l'infrastruttura in PROM, i risultati possono essere contrastanti: i messaggi vengono persi a causa di errori, l'invio non funziona come previsto o i broker "bloccano" i produttori o non inviano messaggi ai consumatori.
Suona familiare?
Uno scenario comune è quello in cui il codice di messaggistica funziona alla grande, per il momento. Fino a quando non smette di funzionare. Questo periodo induce la guardia in un falso senso di sicurezza, portando a più codici basati su false credenze sul comportamento fondamentale della tecnologia. Quando le cose iniziano ad andare male, ti trovi di fronte a una scomoda verità: non hai veramente compreso il comportamento di fondo del prodotto o i compromessi scelti dagli autori, come prestazioni contro affidabilità, o transazionalità contro scalabilità orizzontale. .
Senza una profonda comprensione di come funzionano i broker, le persone fanno affermazioni apparentemente ragionevoli sui loro sistemi di messaggistica, come ad esempio:
- Il sistema non perderà mai i messaggi
- I messaggi verranno elaborati in sequenza
- L’aggiunta di consumatori renderà il sistema più veloce
- I messaggi verranno consegnati una sola volta
Sfortunatamente, alcune di queste affermazioni si basano su presupposti che si applicano solo in determinate circostanze, mentre altre sono semplicemente errate.
Questo libro ti insegnerà a pensare ai sistemi di messaggistica basati su broker, confrontando e contrapponendo due popolari tecnologie di broker: Apache ActiveMQ e Apache Kafka. Illustrerà i casi d'uso e gli incentivi allo sviluppo che hanno portato gli sviluppatori ad adottare approcci molto diversi nella stessa area: la messaggistica tra sistemi con un broker intermedio. Esamineremo queste tecnologie da zero ed evidenzieremo l'impatto delle varie scelte di progettazione lungo il percorso. Acquisirai una conoscenza approfondita di entrambi i prodotti, una comprensione di come dovrebbero e non dovrebbero essere utilizzati e una comprensione di cosa cercare quando si prendono in considerazione altre tecnologie di messaggistica in futuro.
Prima di iniziare, esaminiamo le nozioni di base.
Cos'è un sistema di messaggistica e perché è necessario?
Affinché due applicazioni possano comunicare tra loro, devono prima definire un'interfaccia. La definizione di questa interfaccia implica la selezione di un trasporto o protocollo, come HTTP, MQTT o SMTP, e la negoziazione dei formati dei messaggi che verranno scambiati tra i sistemi. Potrebbe trattarsi di un processo rigoroso, come la definizione di uno schema XML con requisiti di costo del carico utile del messaggio, oppure potrebbe essere molto meno formale, come un accordo tra due sviluppatori secondo cui una parte della richiesta HTTP conterrà l'identificatore del client.
Finché il formato dei messaggi e l'ordine in cui vengono inviati sono coerenti tra i sistemi, questi possono comunicare tra loro senza preoccuparsi dell'implementazione dell'altro sistema. Le parti interne di questi sistemi, come il linguaggio di programmazione o il framework utilizzato, possono cambiare nel tempo. Finché viene mantenuto il contratto stesso, l’interazione può continuare senza modifiche dall’altra parte. I due sistemi sono effettivamente disaccoppiati (separati) da questa interfaccia.
I sistemi di messaggistica in genere coinvolgono un intermediario tra due sistemi che interagiscono per disaccoppiare (separare) ulteriormente il mittente dal destinatario o dai destinatari. In questo caso il sistema di messaggistica permette al mittente di inviare un messaggio senza sapere dove si trova il destinatario, se è attivo o quante istanze ci sono.
Diamo un'occhiata ad un paio di analogie per i tipi di problemi che un sistema di messaggistica risolve e introduciamo alcuni termini di base.
Point-to-Point
Alexandra va all'ufficio postale per inviare un pacco ad Adam. Si avvicina allo sportello e porge il pacco al dipendente. L'impiegato ritira il pacco e consegna ad Alexandra una ricevuta. Non è necessario che Adam sia a casa quando viene spedito il pacco. Alexandra è fiduciosa che il pacco verrà consegnato ad Adam in futuro e potrà continuare a svolgere i suoi affari. Più tardi ad un certo punto Adam riceve un pacco.
Questo è un esempio di modello di messaggistica punto a punto. L'ufficio postale qui funge da meccanismo di distribuzione dei pacchi, garantendo che ogni pacco venga consegnato una volta. L'utilizzo di un ufficio postale separa l'atto di spedizione di un pacco dalla consegna del pacco.
Nei sistemi di messaggistica classici il modello punto-punto viene implementato tramite очереди. La coda funge da buffer FIFO (first in, first out) a cui possono essere iscritti uno o più consumatori. Ogni messaggio viene consegnato solo a uno dei consumatori iscritti. Le code in genere tentano di distribuire equamente i messaggi tra i consumatori. Solo un consumatore riceverà questo messaggio.
Il termine “durevole” viene applicato alle code. Affidabilità è una proprietà del servizio che garantisce che il sistema di messaggistica persista i messaggi in assenza di abbonati attivi finché un consumatore non si iscrive alla coda per la consegna dei messaggi.
L'affidabilità viene spesso confusa con persistenza e sebbene i due termini siano usati in modo intercambiabile, svolgono funzioni diverse. La persistenza determina se il sistema di messaggistica scrive un messaggio in qualche tipo di archivio tra la ricezione e l'invio al consumatore. I messaggi inviati alla coda possono essere persistenti o meno.
La messaggistica punto a punto viene utilizzata quando il caso d'uso richiede un'azione una tantum sul messaggio. Gli esempi includono il deposito di fondi su un conto o il completamento di un ordine di consegna. Discuteremo più avanti del motivo per cui il sistema di messaggistica da solo non è in grado di fornire una consegna una tantum e perché le code possono al massimo fornire una garanzia di consegna almeno una volta.
Editore-Abbonato
Gabriella compone il numero della conferenza. Mentre è connessa alla conferenza, sente tutto ciò che dice l'oratore, insieme al resto dei partecipanti alla chiamata. Quando si distrae, le manca ciò che viene detto. Una volta ricollegata, continua a sentire ciò che viene detto.
Questo è un esempio di modello di messaggistica pubblicare-sottoscrivere. La teleconferenza funge da meccanismo di trasmissione. Alla persona che parla non importa quante persone sono attualmente coinvolte nella chiamata: il sistema garantisce che chiunque sia attualmente connesso ascolterà ciò che viene detto.
Nei sistemi di messaggistica classici, il modello di messaggistica di pubblicazione-sottoscrizione viene implementato tramite top. L'argomento fornisce lo stesso metodo di trasmissione del meccanismo di conferenza. Quando un messaggio viene inviato a un argomento, viene distribuito per tutti gli utenti iscritti.
Gli argomenti sono solitamente inaffidabile (non durevole). Proprio come un ascoltatore che non riesce a sentire ciò che viene detto durante una chiamata in conferenza quando si disconnette, gli abbonati all'argomento perdono tutti i messaggi inviati mentre sono offline. Per questo motivo possiamo dire che gli argomenti forniscono una garanzia di consegna non più di una volta per ciascun consumatore.
La messaggistica di pubblicazione-sottoscrizione viene in genere utilizzata quando i messaggi sono di natura informativa e la perdita di un messaggio non è particolarmente significativa. Ad esempio, un argomento può trasmettere le letture della temperatura da un gruppo di sensori una volta al secondo. Un sistema interessato alla temperatura attuale e che si iscrive a un argomento non si preoccuperà se perde un messaggio: ne arriverà un altro nel prossimo futuro.
modelli ibridi
Il sito web del negozio inserisce i messaggi degli ordini in una "coda di messaggi". Il principale consumatore di questi messaggi è il sistema esecutivo. Inoltre, il sistema di audit dovrebbe disporre di copie di questi messaggi d'ordine per il successivo monitoraggio. Entrambi i sistemi non possono consentire il passaggio dei messaggi, anche se i sistemi stessi non sono disponibili per un certo periodo. Il sito web non dovrebbe essere a conoscenza di altri sistemi.
I casi d'uso spesso richiedono una combinazione di modelli di messaggistica pubblicazione-sottoscrizione e punto-punto, ad esempio quando più sistemi richiedono una copia di un messaggio e sono necessarie sia affidabilità che persistenza per prevenire la perdita del messaggio.
Questi casi richiedono una destinazione (termine generale per code e argomenti) che distribuisca i messaggi fondamentalmente come un argomento, in modo che ogni messaggio venga inviato a un sistema separato interessato a quei messaggi, ma anche in cui ciascun sistema può definire diversi consumatori che ricevono messaggi, che è più simile a una coda. Il tipo di lettura in questo caso è una volta per ogni stakeholder. Queste destinazioni ibride spesso richiedono durabilità in modo che se un consumatore va offline, i messaggi inviati in quel momento vengono ricevuti dopo che il consumatore si è ricollegato.
I modelli ibridi non sono nuovi e possono essere utilizzati nella maggior parte dei sistemi di messaggistica, inclusi sia ActiveMQ (tramite destinazioni virtuali o composite che combinano argomenti e code) sia Kafka (implicitamente, come proprietà fondamentale della progettazione della destinazione).
Ora che abbiamo un po' di terminologia di base e una comprensione dello scopo per cui potremmo utilizzare un sistema di messaggistica, passiamo ai dettagli.
Traduzione fatta:
La seguente parte tradotta:
To be continued ...
Fonte: habr.com