Questo blog fa parte della serie in cui discutiamo 101 concetti di Ground Zero per un pubblico che ha una conoscenza iniziale limitata. Questo articolo fa parte della serie di livello intermedio poiché implica la comprensione delle basi dei principi di progettazione della messaggistica, principalmente il caso d'uso dell'architettura basata su editore-abbonato utilizzata nella comunicazione asincrona.

Alcuni dei blog precedenti nella serie 101 sono i seguenti:

API 101
Comunicazione asincrona 101 Database 101 Progettazione di database 101

Che cos'è Pub-Sub?

In caso di architettura distribuita, per disaccoppiare l'origine di generazione degli eventi dall'origine di ricezione dell'evento e per sbloccare i sistemi end-2-end in esecuzione su larga scala, è progettato il modello di messaggistica editore-abbonato . Il mittente chiamato anche editore trasmette i messaggi come eventi come formato di messaggio predefinito in un broker di livello intermedio ( Kafka, EventHub, Service Bus ecc ) a cui possono ascoltare abbonati singoli o multipli a seconda della politica di abbonamento scelta.

Il modello Pub-Sub supporta casi d'uso sia Unicast che Broadcast , a differenza di un modello di coda di messaggi che supporta solo casi d'uso basati su Unicast .

Termini comuni

• Editore : client che generano il messaggio e lo accodano nell'infrastruttura di messaggistica.
• Abbonato : i client che ricevono il messaggio e li mettono in coda nell'infrastruttura di messaggistica.
• Message Broker: il livello intermedio che gestisce la pubblicazione dei messaggi e le richieste di lettura da vari client. Mantiene i dati replicati all'interno di un cluster sotto forma di argomenti tra repliche e partizioni.
• Argomento — Categorie logiche univoche all'interno del broker che fornisce messaggi/eventi relativi a una particolare applicazione/caso d'uso aziendale.
• Partizione: gli argomenti possono essere ulteriormente suddivisi in unità logiche denominate partizioni per consentire l'elaborazione parallela dei messaggi. Ogni partizione contiene record univoci identificati da offset.
• QOS- Un accordo tra l'editore e l'abbonato che dice quante volte deve essere consegnato un messaggio effettivo , almeno una, al massimo una volta, esattamente una volta.

Il modello Publisher-Subscriber viene utilizzato per casi d'uso applicativi che richiedono un grande volume di eventi generati e la garanzia immediata dei messaggi non è di primaria importanza. Le applicazioni che rientrano nei bucket indicati sono buoni candidati per questo modello.

• Le applicazioni in cui non è necessaria una forte coerenza per gli eventi tra mittente e destinatario e l'ordinamento di dati/eventi non ha un impatto sul business. Questo è un modello di progettazione alla fine coerente.
• Applicazioni in cui la risposta in tempo reale degli abbonati non ha un impatto sull'effettivo flusso aziendale.
• Gli abbonati appartenenti a diversi argomenti sono indipendenti e possono avere diverse metriche di disponibilità e tempo di attività.

Per scalare un editore-abbonato agli SLA corretti di affidabilità e disponibilità per servire i casi d'uso aziendali end-2-end, si consigliano le seguenti considerazioni di progettazione.

• Abbonati idempotenti: a seconda del QOS complessivo impostato e in caso di errori, più abbonati possono inviare lo stesso messaggio più di una volta. Quindi gli abbonati sono obbligati a mantenere l' idempotenza , cioè a non elaborare messaggi ripetuti più di una volta e ad avere una gestione dei messaggi duplicati.
• Ordinazione e priorità dei messaggi: i messaggi possono essere elaborati in una sequenza temporale diversa rispetto alla loro creazione a seconda di molteplici fattori come partizioni, gruppi di consumatori. Quindi ogni messaggio dovrebbe essere indipendente nel flusso aziendale/applicativo generale.
• Coda messaggi non recapitabili: a seconda dell'impostazione TTL sui messaggi e della disponibilità/gestione degli errori dei consumatori, alcuni dei messaggi potrebbero finire in Coda messaggi non recapitabili . Questi messaggi devono essere rielaborati dagli editori per evitare qualsiasi impatto sul business.
• Sicurezza: argomenti diversi sui broker di messaggi devono essere criteri di autorizzazione indipendenti per garantire che i client non scambino accidentalmente informazioni da un argomento diverso. I certificati client e il TLS reciproco sono alcune buone politiche di sicurezza.

Sommario

Pub-Sub è un modello di progettazione semplice e comune che viene utilizzato nei sistemi distribuiti basati su Aysnc poiché aiuta a scalare per milioni di clienti senza la necessità di mantenere una semantica di consegna complessa. Tuttavia, per casi d'uso complessi in cui i messaggi/eventi devono avere modelli di instradamento dinamici, altri modelli di progettazione come il livellamento del carico basato sulla coda, basato su richiesta-risposta, ecc . Cercheremo di trattarli nei prossimi 101 blog sull'apprendimento dell'architettura funzionale.

Per feedback, invia un messaggio a amit[dot]894[at]gmail[dot]com o contatta uno qualsiasi dei link su https://about.me/amit_raj .