In un’architettura a microservizi può nascere l’esigenza di dover gestire la scalabilità e la coordinazione tra microservizi che gestiscono dei comandi piuttosto che dati.
L’obiettivo è gestire la scalabilità dei microservizi con ZooKeeper, definendo un nodo master che esegue alcune operazioni per permettere ad un processo di scalare o semplicemente definendo come i vari nodi debbano suddividersi il lavoro.
La situazione: i concetti principali dell’architettura Kafka.
- topic: una sorta di categoria per raggruppare messaggi, composto da una o più partizioni
- partizione: contenitore di un certo numero di messaggi. Possono avere dimensioni differenti; permette di rendere scalabile il sistema
- record: l’insieme messaggio + key + timestamp; un record è inviato alla partizione, identificata da un offset
- producer: processo responsabile dell’invio dei messaggi; diverse logiche di invio messaggi:
- invio ad una precisa partizione tramite una precisa key; i messaggi con questa key saranno processati da uno più consumer
- randomico, i messaggi vengono assegnati con una logica round-robin decisa dal broker
- consumer: processo che legge il messaggio
- gruppo: insieme di consumer
- broker: processo che gestisce ricezione e salvataggio dei messaggi
- cluster: insieme di broker
- zookeeper: processo che monitora lo stato del sistema
- Bilanciamento: sistema che garantisce l’equilibrio tra numero di partizioni e numero di consumer.
Ad esempio: sistema 4 consumer, 3 partizioni. Quando un consumer si disconnette, Kafka riassegna le sue partizioni ad un consumer scarico. E’ importante gestire le partizioni. Ogni consumatore può avere minimo 1 partizione. Non ci possono essere un numero di partizioni superiore al numero di consumatori. Questo perché ci sarebbero consumatori che non ricevono messaggi.
Il problema: gestire microservizi che eseguono dei comandi.
Attualmente si ha un database che storicizza un certo numero di dispositivi, gestiti da un unico microservizio che non riesce a gestire tutto il carico.
Kafka non può essere d’aiuto perché non si hanno code di messaggi, ma appunto un database.
Utilizzando ZooKeeper si potrebbe trarre vantaggio dal suo sistema di gestione delle ripartizioni che si basa sul concetto di master – slave. All’avvio i vari microservizi (sempre dispari come totale) si registrano e ZooKeeper stabilisce chi è master; tutti gli altri saranno slave.
Il master ha il controllo e prende l’iniziativa sui comandi da gestire, e gli slave eseguono. Il microservizio master può essere anche slave.
Qualora un microservizio crashi, i restanti accedono a ZooKeeper che eleggerà un nuovo master.