I modelli di progettazione orientati al microservizio hanno reso le nostre applicazioni più scalabili che mai. Server API RESTful, front-end e persino i database sono ora scalabili orizzontalmente. Il ridimensionamento orizzontale è l'atto di aggiungere nuovi nodi al cluster dell'applicazione per supportare il carico di lavoro aggiuntivo. Al contrario, consente anche di ridurre il consumo di risorse, quando il carico di lavoro diminuisce, al fine di risparmiare i costi. I sistemi scalabili orizzontalmente devono essere distribuiti. Questi sistemi che possono sopravvivere al fallimento di più macchine virtuali, contenitori o collegamenti di rete e rimangono comunque online e sani per l'utente finale.

Quando parliamo di sistemi distribuiti come sopra, incontriamo il problema dell'analisi e del monitoraggio. Ogni nodo sta generando molte informazioni sulla propria salute (utilizzo della CPU, memoria, ecc.) E sullo stato dell'applicazione insieme a ciò che gli utenti stanno cercando di fare. Questi dettagli devono essere registrati in:

1. Lo stesso ordine in cui vengono creati,
2. Separato in termini di urgenza (analisi in tempo reale o lotti di dati) e, soprattutto,,
3. Il meccanismo con cui vengono raccolti deve essere a sé. Qualcosa che il design del sistema distribuito avrebbe dovuto evitare.

Perché usare Kafka?

Apache Kafka è lanciata come una piattaforma di streaming distribuita. In lingo kafka, Produttori generare continuamente dati (flussi) E Consumatori sono responsabili dell'elaborazione, archiviare e analizzarlo. Kafka Broker sono responsabili di garantire che in uno scenario distribuito i dati possano raggiungere dai produttori ai consumatori senza alcuna incoerenza. Un set di broker Kafka e un altro software chiamato Zookeeper costituire un tipico implementazione di Kafka.

Il flusso di dati di molti produttori deve essere aggregato, partizionato e inviato a più consumatori, c'è un sacco di mescolamento coinvolto. Evitare l'incoerenza non è un compito facile. Questo è il motivo per cui abbiamo bisogno di kafka.

Gli scenari in cui può essere utilizzato kafka è piuttosto diversificato. Qualsiasi cosa, dai dispositivi IoT al cluster di macchine virtuali ai tuoi server in metallo nudo on-premise. Ovunque dove molte "cose" vogliono contemporaneamente la tua attenzione .. .Non è molto scientifico, vero? Bene, l'architettura Kafka è una buca di coniglio e merita un trattamento indipendente. Vediamo innanzitutto una distribuzione del software a livello di superficie molto.

Utilizzo di Docker Compose

In qualunque modo fantasioso decidi di usare Kafka, una cosa è certa: non la userai come un singolo istanza. Non è pensato per essere usato in questo modo, e anche se la tua app distribuita ha bisogno di solo un'istanza (broker) per ora, alla fine crescerà e devi assicurarti che Kafka possa tenere il passo.

Docker-compose è il partner perfetto per questo tipo di scalabilità. Invece per l'esecuzione di broker Kafka su macchine virtuali diverse, lo containering e sfruttare la compori Docker per automatizzare la distribuzione e il ridimensionamento. I contenitori Docker sono altamente scalabili sia su host Docker singoli che su un cluster se utilizziamo Docker Swarm o Kubernetes. Quindi ha senso sfruttarlo per rendere Kafka scalabile.

Cominciamo con una singola istanza del broker. Crea una directory chiamata apache-kafka e al suo interno crea il tuo docker composti.YML.

$ mkdir apache-kafka
$ CD Apache-Kafka
$ vim docker-compose.YML

I seguenti contenuti saranno messi nel tuo docker.File YML:

Versione: '3'
Servizi:
Zookeeper:
Immagine: Wurstmeister/Zookeeper
Kafka:
Immagine: Wurstmeister/Kafka
Porte:
- "9092: 9092"
ambiente:
Kafka_adverted_host_name: localhost
Kafka_zookeeper_connect: zookeeper: 2181

Dopo aver salvato il contenuto di cui sopra nel file di composizione, dalla stessa directory eseguita:

$ Docker -Opse Up -D

Ok, quindi cosa abbiamo fatto qui?

Comprensione della composizione del docker.YML

Compose inizierà due servizi come elencato nel file YML. Diamo un'occhiata al file un po 'da vicino. La prima immagine è Zookeeper che Kafka richiede per tenere traccia di vari broker, la topologia di rete e sincronizzare altre informazioni. Dal momento che entrambi i servizi di Zookeeper e Kafka faranno parte della stessa rete di bridge (questo viene creato quando eseguiamo un documento di composizione) non abbiamo bisogno di esporre alcuna porte. Il broker Kafka può parlare con lo zookeeper ed è tutta la comunicazione che lo zookeeper ha bisogno.

Il secondo servizio è Kafka stesso e ne stiamo solo eseguendo una singola istanza, vale a dire un broker. Idealmente, vorresti utilizzare più broker per sfruttare l'architettura distribuita di Kafka. Il servizio ascolta la porta 9092 che è mappata sullo stesso numero di porta sull'host Docker ed è così che il servizio comunica con il mondo esterno.

Il secondo servizio ha anche un paio di variabili di ambiente. Innanzitutto, è kafka_adverted_host_name impostato su localhost. Questo è l'indirizzo in cui Kafka è in esecuzione e in cui produttori e consumatori possono trovarlo. Ancora una volta, questo dovrebbe essere il set su localhost ma piuttosto all'indirizzo IP o il nome host con questo è possibile raggiungere i server nella rete. Il secondo è il nome host e il numero di porta del tuo servizio Zookeeper. Da quando abbiamo chiamato il servizio Zookeeper ... beh, Zookeeper è quello che sarà il nome host, all'interno della rete Docker Bridge che abbiamo menzionato.

Esecuzione di un semplice flusso di messaggi

Affinché Kafka inizi a lavorare, dobbiamo creare un argomento al suo interno. I clienti del produttore possono quindi pubblicare flussi di dati (messaggi) su detto argomento e i consumatori possono leggere detto Datastream, se sono iscritti a quel particolare argomento.

Per fare ciò dobbiamo avviare un terminale interattivo con il contenitore Kafka. Elenca i contenitori per recuperare il nome del contenitore Kafka. Ad esempio, in questo caso il nostro contenitore è chiamato apache-kafka_kafka_1

$ Docker PS

Con il nome del contenitore Kafka, ora possiamo entrare in questo contenitore.

$ Docker Exec -it Apache -Kafka_Kafka_1 Bash
Bash-4.4#

Apri due terminali così diversi per usarne uno come consumatore e un altro produttore.

Lato produttore

In uno dei prompt (quello che scegli di essere produttore), inserisci i seguenti comandi:

## per creare un nuovo argomento denominato test
Bash-4.4# Kafka-Topics.SH --Create --Zookeeper Zookeeper: 2181-Factor di replicazione 1
--Partizioni 1 -Test di topio
## per avviare un produttore che pubblica DataStream dall'input standard a Kafka
Bash-4.4# kafka-tumole-produttore.SH-Locale-list-list: 9092-Test-tema
>

Il produttore è ora pronto a prendere input dalla tastiera e pubblicarlo.

Lato consumatore

Spostati sul secondo terminale collegato al contenitore Kafka. Il seguente comando avvia un consumatore che si nutre dell'argomento del test:

$ kafka-consumatore-consumatore.sh --bootstrap-server localhost: 9092-Test-tema

Torna al produttore

Ora puoi digitare i messaggi nel nuovo prompt e ogni volta che si prevede restituire la nuova riga viene stampata nel prompt dei consumatori. Per esempio:

> Questo è un messaggio.

Questo messaggio viene trasmesso al consumatore, tramite Kafka, e puoi vederlo stampato sul prompt del consumatore.

Configurazioni del mondo reale

Ora hai una foto approssimativa di come funziona la configurazione kafka. Per il tuo caso d'uso, è necessario impostare un nome host che non è locale, hai bisogno di più broker per far parte del tuo cluster Kafka e infine è necessario impostare clienti di consumo e produttori.

Ecco alcuni link utili:

1. Confluent's Python Client
2. Documentazione ufficiale
3. Un utile elenco di demo

Spero che ti diverta ad esplorare Apache Kafka.