Perché adottare Apache ZooKeeper
Doveste trovarvi a lavorare con un sistema distribuito, composto quindi da una multitudine di servizi ognuno con una sua responsabilità e task da eseguire, potrebbe quanto prima sorgere un problema: come gestire le risorse e il carico di lavoro di ognuno dei microservizi?
Il problema che sta alla base della scelta di ZooKeeper è quindi la seguente: dati n servizi, eleggere un leader. Ovviamente, se per qualsiasi motivo il servizio leader dovesse avere qualche malfunzionamento, un altro servizio dovrebbe subentrare come leader.
Questa però è soltanto una delle problematiche ricorrenti in un’applicazione distribuita. Altre problematiche ricorrenti sono le seguenti:
- Name Service, ovvero riuscire a trovare un servizio tra i tanti disponibili.
- Configuration, definire una configurazione condivisa.
- Group Membership, avere un’idea chiara di quali siano i servizi simili tra loro e quindi raggrupparli così da riconoscerli e classificarli.
- Message queues, cioè gestire la modalità di distribuzione di messaggi tra i servizi. Garantire ad esempio che il messaggio arrivi ad uno e un solo servizio.
- Locks, ovvero gestire l’accesso ad una risorsa limitata. Bloccare con un “lucchetto” la risorsa affinché un servizio alla volta possa accedervi, e rilasciarla al termine delle operazioni o comunque in caso di malfunzionamento del servizio stesso, per evitare di bloccare tutto il sistema.
- Two-phased Commit: in caso di transazione che coinvolge più servizi, assicurarsi che ognuno completi la transazione (“committi”) oppure che ogni servizio possa fare “rollback” ovvero tornare indietro ad una situazione di partenza pulita.
- Leader Election: il problema iniziale.
Perché non usare ZooKeeper?