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à a riflettere sui sistemi di scambio di messaggi con broker, confrontando e mettendo a confronto due tecnologie di broker popolari: Apache ActiveMQ e Apache Kafka. Saranno presentati esempi di utilizzo e motivazioni dello sviluppo che hanno portato i loro progettisti ad utilizzare approcci completamente diversi nello stesso campo: lo scambio di messaggi tra sistemi attraverso un broker intermedio. Esamineremo queste tecnologie dal principio e metteremo in evidenza l'influenza delle diverse opzioni di design lungo il percorso. Ottieni una comprensione approfondita di entrambi i prodotti, come dovrebbero e non dovrebbero essere usati, e cosa considerare quando si esaminano altre tecnologie di scambio di messaggi nel futuro. …»
Parti tradotte fino ad oggi:
Pubblicherò i capitoli completati man mano che traduco.
CAPITOLO 1
Introduzione
Lo scambio di messaggi tra sistemi è uno dei settori meno compresi nell'IT. Come sviluppatore o architetto, potresti essere ben consapevole di diversi framework e database. Tuttavia, è probabile che tu abbia solo una conoscenza superficiale di come funzionano le tecnologie di scambio di messaggi basate su broker. Se ti senti in questo modo, non preoccuparti, sei in buona compagnia.
Le persone di solito interagiscono con l'infrastruttura di scambio di messaggi in modo molto limitato. Spesso ci si connette a un sistema creato molto tempo fa, oppure si scarica una distribuzione da internet, la si installa nell'ambiente di produzione e si inizia a scrivere codice per esso. 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.
Suona familiare?
Uno scenario comune è quando il tuo codice di messaggistica funziona perfettamente, fino a quando non smette di farlo. Questo periodo può accecare la vigilanza e creare una falsa sensazione di sicurezza, portando a un codice sempre più grande basato su errate convinzioni sul comportamento fondamentale della tecnologia. Quando qualcosa inizia ad andare storto, ti trovi di fronte a una scomoda verità: che in realtà non hai compreso il comportamento di base del prodotto o i compromessi scelti dagli autori, come prestazioni versus affidabilità o transazionalità versus 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 verranno elaborati in modo sequenziale
- Aggiungere consumatori renderà il sistema più veloce
- I messaggi verranno consegnati solo una volta
Sfortunatamente, alcune di queste affermazioni si basano su assunzioni che si applicano solo in determinate circostanze, mentre altre sono semplicemente false.
Questo libro ti insegnerà a ragionare sui sistemi di messaggistica basati su broker, confrontando e contrapporendo due tecnologie di broker popolari: Apache ActiveMQ e Apache Kafka. Verranno forniti esempi di utilizzo e incentivi allo sviluppo che hanno portato i loro sviluppatori ad adottare approcci completamente diversi nello stesso campo: la messaggistica tra sistemi tramite un broker intermedio. Esamineremo queste tecnologie da zero e evidenzieremo l'impatto delle diverse opzioni di design lungo il percorso. Acquisirai una comprensione profonda di entrambi i prodotti, comprendendo come e non come utilizzarli, e cosa considerare quando si guardano altre tecnologie di messaggistica in futuro.
Prima di iniziare, diamo un'occhiata alle basi.
Che cos'è un sistema di messaggistica e a cosa serve
Affinché due applicazioni possano comunicare tra loro, devono prima definire un'interfaccia. La definizione di quest'interfaccia comprende la scelta di un trasporto o protocollo come HTTP, MQTT o SMTP e l'accordo sui formati dei messaggi che verranno scambiati tra i sistemi. Questo può essere un processo rigoroso, come la definizione di uno schema XML con requisiti per il payload del messaggio, oppure può essere molto meno formale, ad esempio un accordo tra due sviluppatori sul fatto che una certa parte della richiesta HTTP conterrà un identificativo del cliente.
Fintanto che il formato dei messaggi e l'ordine in cui vengono inviati tra i sistemi sono concordati, potranno interagire tra loro senza preoccuparsi dell'implementazione di un altro sistema. Le parti interne di questi sistemi, come il linguaggio di programmazione o il framework utilizzato, possono cambiare nel tempo. Finché il contratto stesso è mantenuto, l'interazione può continuare senza modifiche dall'altra parte. Questi due sistemi sono efficacemente disaccoppiati (separati) da quest'interfaccia.
I sistemi di messaggistica generalmente prevedono un intermediario tra due sistemi che interagiscono per ulteriormente disaccoppiare (separare) il mittente 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 sono i loro esemplari.
Prendiamo in considerazione un paio di analogie riguardanti i tipi di problemi che un sistema di messaggistica può risolvere e introduciamo alcuni termini di base.
Point-to-Point
Alessandra va all'ufficio postale per inviare un pacco ad Adamo. Si avvicina allo sportello e consegna il pacco all'impiegato. L'impiegato ritira il pacco e fornisce ad Alessandra una ricevuta. Adamo non ha bisogno di essere a casa al momento della spedizione del pacco. Alessandra è certa che il pacco sarà consegnato ad Adamo in un momento futuro e può continuare a occuparsi delle sue cose. Più tardi, ad un certo punto, Adamo riceve il pacco.
Questo è un esempio di modello di messaggistica point-to-point. L'ufficio postale qui funge da meccanismo di distribuzione dei pacchi, garantendo che ciascun pacco venga consegnato una sola volta. L'uso dell'ufficio postale separa l'atto di invio del pacco dalla consegna del pacco.
Nei sistemi di messaggistica classici, il modello "point-to-point" viene implementato tramite di coda. La coda funge da buffer FIFO (primo arrivato, primo servito), a cui possono iscriversi uno o più consumatori. Ogni messaggio viene consegnato solo a uno degli abbonati. Le code cercano di distribuire i messaggi in modo equo tra i consumatori. Solo un consumatore riceverà il messaggio.
Il termine "affidabili" ("durable") si applica alle code. Affidabilità — è una proprietà del servizio che garantisce che il sistema di messaggistica conserverà i messaggi in assenza di abbonati attivi fino a quando un consumatore non si iscriva alla coda per ricevere i messaggi.
L'affidabilità viene spesso confusa con la persistenza e, sebbene questi due termini siano intercambiabili, svolgono funzioni diverse. La persistenza determina se il sistema di messaggistica registra un messaggio in qualche tipo di archiviazione tra la ricezione e l'invio al consumatore. I messaggi inviati a una coda possono essere o meno persistenti.
La messaggistica "point-to-point" viene utilizzata quando il caso d'uso richiede un'azione unica sul messaggio. Per esempio, il deposito di fondi su un conto o l'effettuazione di un ordine di consegna. Discuteremo più avanti perché il sistema di messaggistica da solo non può garantire la consegna unica e perché le code possono al massimo garantire la consegna almeno una volta.
Pubblicazione-Iscrizione
Gabriella compone il numero della conferenza. Mentre è connessa alla conferenza, sente tutto ciò che dice il relatore, insieme agli altri partecipanti alla chiamata. Quando si disconnette, perde ciò che è stato detto. Riconnettendosi, continua a sentire ciò che viene detto.
Questo è un esempio di modello di messaggistica pubblicazione-iscrizione. La videoconferenza funge da meccanismo di broadcasting. Il relatore non si preoccupa di quante persone siano attualmente collegate 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 messaggistica "pubblicazione-iscrizione" viene implementato tramite argomentiIl topic fornisce un metodo di broadcasting simile a quello del meccanismo di conferenza. Quando un messaggio viene inviato a un topic, esso viene distribuito a tutti gli utenti iscritti.
I topic sono generalmente non affidabili (nondurable). Come per l'ascoltatore che non sente ciò che viene detto durante una chiamata in conferenza quando si disconnette, gli abbonati al topic saltano qualsiasi messaggio inviato mentre sono offline. Per questo motivo, si può dire che i topic offrono una garanzia di consegna non più di una volta per ogni consumatore.
La messaggistica di tipo "pubblica-iscrivi" viene utilizzata solitamente quando i messaggi sono di natura informativa e la perdita di un messaggio non è particolarmente significativa. Ad esempio, un topic può trasmettere i dati sulla temperatura da un gruppo di sensori una volta al secondo. Un sistema che si interessa 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 inserisce 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 copie di questi messaggi sugli ordini per il monitoraggio successivo. Entrambi i sistemi non possono perdere messaggi, anche se gli stessi sistemi sono non disponibili per un certo periodo. Il sito web non deve essere a conoscenza degli altri sistemi.
Gli scenari d'uso richiedono spesso la combinazione dei modelli di messaggistica "pubblica-iscrivi" e "point-to-point", ad esempio quando più sistemi necessitano di una copia del messaggio, e per prevenire la perdita del messaggio sono richiesti affidabilità e persistenza.
In questi casi è necessario un destinatario (destination) (termine generale per code e topic), che distribuisce i messaggi principalmente come un topic, in modo che ogni messaggio venga inviato a un sistema separato interessato a tali messaggi, ma in cui ogni sistema può anche determinare più consumatori che ricevono i messaggi in arrivo, che assomiglia di più a una coda. Il tipo di lettura in questo caso è una volta per ogni parte interessataQuesti destinatari ibridi richiedono spesso affidabilità, quindi se il consumatore si disconnette, i messaggi inviati in quel momento vengono ricevuti dopo la riconnessione del consumatore.
I modelli ibridi non sono nuovi e possono essere utilizzati nella maggior parte dei sistemi di messaggistica, inclusi sia ActiveMQ (attraverso destinatari virtuali o composti che uniscono 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.
Traduzione eseguita:
La prossima parte tradotta:
Continua…
Fonte: habr.com
