Mikroserviceorienterte designmønstre har gjort applikasjonene våre mer skalerbare enn noen gang. RESTFUL API-servere, front-end og til og med databasene er nå horisontalt skalerbare. Horisontal skalering er handlingen med å legge til nye noder til applikasjonsklyngen din for å støtte ytterligere arbeidsmengde. Motsatt tillater det også å redusere ressursforbruket, når arbeidsmengden avtar, for å spare kostnader. Horisontalt skalerbare systemer må distribueres systemet. Disse systemene som kan overleve svikt i flere VM -er, containere eller nettverkskoblinger og fremdeles holde seg online og sunne for sluttbrukeren.

Når vi snakker om distribuerte systemer som ovenfor, får vi problemet med analyse og overvåking. Hver node genererer mye informasjon om sin egen helse (CPU -bruk, minne osv.) Og om applikasjonsstatus sammen med hva brukerne prøver å gjøre. Disse detaljene må registreres i:

1. Den samme rekkefølgen de er opprettet,
2. Separert når det gjelder haster (sanntidsanalyse eller parti av data), og viktigst av alt,
3. Mekanismen de blir samlet inn i må være en distribuert og skalerbar, ellers sitter vi igjen med et enkelt feilpunkt. Noe det distribuerte systemdesignet skulle unngå.

Hvorfor bruke Kafka?

Apache Kafka blir lagt opp som en distribuert streamingplattform. I Kafka Lingo, Produsenter Generer kontinuerlig data (bekker) og Forbrukere er ansvarlige for behandling, lagring og analyse av det. Kafka Meglere er ansvarlige for å sikre at dataene i et distribuert scenario kan nå fra produsenter til forbrukere uten inkonsekvens. Et sett med Kafka -meglere og et annet programvare som heter dyrepasser utgjør en typisk Kafka -distribusjon.

Strømmen av data fra mange produsenter må samles, partisjoneres og sendes til flere forbrukere, det er mye blanding involvert. Å unngå inkonsekvens er ikke en lett oppgave. Dette er grunnen til at vi trenger kafka.

Scenariene der kafka kan brukes er ganske mangfoldig. Alt fra IoT-enheter til klynge av VM-er til dine egne bare metallservere på stedet. Hvor som helst der mange 'ting' samtidig vil ha din oppmerksomhet .. .Det er ikke veldig vitenskapelig, er det? Vel, Kafka-arkitekturen er et eget kaninhull og fortjener en uavhengig behandling. La oss først se en veldig overflatenivå distribusjon av programvaren.

Bruke Docker -komponering

Uansett hvilken fantasifull måte du bestemmer deg for å bruke Kafka, er en ting sikkert - du vil ikke bruke den som en enkelt forekomst. Det er ikke ment å bli brukt på den måten, og selv om den distribuerte appen din bare trenger en forekomst (megler) for nå, vil den til slutt vokse, og du må sørge for at Kafka kan følge med.

Docker-Compose er den perfekte partneren for denne typen skalerbarhet. I stedet for å kjøre Kafka -meglere på forskjellige VM -er, beholder vi den og utnytter Docker komponerer for å automatisere distribusjonen og skaleringen. Docker -containere er svært skalerbare på både enkelt Docker -verter så vel som på tvers av en klynge hvis vi bruker Docker Swarm eller Kubernetes. Så det er fornuftig å utnytte det for å gjøre kafka skalerbar.

La oss starte med en enkelt meglerinstans. Lag en katalog som heter Apache-Kafka og inni den oppretter Docker-Compose.yml.

$ mkdir apache-kafka
$ CD Apache-Kafka
$ Vim Docker-Compose.yml

Følgende innhold kommer til å bli satt i Docker-komponering.YML -fil:

Versjon: '3'
tjenester:
dyrepasser:
Bilde: Wurstmeister/Zookeeper
Kafka:
Bilde: Wurstmeister/Kafka
Porter:
- "9092: 9092"
miljø:
KAFKA_ADVERTICED_HOST_NAME: Localhost
Kafka_Zookeeper_Connect: Zookeeper: 2181

Når du har lagret innholdet ovenfor i komponeringsfilen din, fra samme katalogkjøring:

$ docker -compose up -d

Ok, så hva gjorde vi her?

Forstå docker-komponering.yml

Komponere vil starte to tjenester som oppført i YML -filen. La oss se på filen litt nøye. Det første bildet er dyrehager som Kafka krever for å holde rede på forskjellige meglere, nettverkstopologien samt synkronisere annen informasjon. Siden både ZooKeeper og Kafka-tjenester kommer til å være en del av det samme bronettet (dette opprettes når vi kjører Docker-Compose Up) trenger vi ikke å eksponere noen porter. Kafka -megler kan snakke med dyrehager, og det er alle kommunikasjonsdyrkekonsernbehov.

Den andre tjenesten er Kafka i seg selv, og vi kjører bare en enkelt forekomst av den, det vil si en megler. Ideelt sett vil du bruke flere meglere for å utnytte den distribuerte arkitekturen til Kafka. Tjenesten lytter på port 9092 som er kartlagt på samme portnummer på Docker -verten, og det er slik tjenesten kommuniserer med omverdenen.

Den andre tjenesten har også et par miljøvariabler. Først er Kafka_AdDertised_host_name satt til localhost. Dette er adressen som Kafka kjører, og hvor produsenter og forbrukere kan finne den. Nok en gang bør dette være settet til Localhost, men snarere til IP -adressen eller vertsnavnet med dette serverne kan nås i nettverket ditt. For det andre er vertsnavnet og portnummeret til dyrepassetjenesten din. Siden vi kalte Zookeeper -tjenesten ... vel, dyrehager, det er det vertsnavnet kommer til å bli, innen Docker Bridge -nettverket nevnte vi.

Kjører en enkel meldingsflyt

For at Kafka skal begynne å jobbe, må vi lage et tema i det. Produsentklientene kan deretter publisere datastrømmer (meldinger) til nevnte emne, og forbrukere kan lese nevnte DataStream, hvis de er abonnert på det aktuelle emnet.

For å gjøre dette må vi starte en interaktiv terminal med Kafka -beholderen. Liste opp containerne for å hente Kafka -beholderens navn. I dette tilfellet heter for eksempel containeren

$ docker ps

Med Kafka -beholderens navn kan vi nå slippe inne i denne beholderen.

$ docker exec -it apache -kafka_kafka_1 bash
Bash-4.4#

Åpne to slike forskjellige terminaler for å bruke en som forbruker og en annen produsent.

Produsentsiden

I en av spørsmålene (den du velger å være produsent), skriv inn følgende kommandoer:

## For å lage et nytt emne som heter Test
Bash-4.4# Kafka-emner.SH-Create-Zookeeper Zookeeper: 2181-Replication-Factor 1
--Partisjoner 1 -tema test
## For å starte en produsent som publiserer DataStream fra Standard Input til Kafka
Bash-4.4# Kafka-Console-produsent.SH-BROKER-LIST LOCALHOST: 9092-TOPIK TEST
>

Produsenten er nå klar til å ta innspill fra tastaturet og publisere den.

Forbrukersiden

Gå videre til den andre terminalen som er koblet til Kafka -beholderen. Følgende kommando starter en forbruker som lever av testemne:

$ Kafka-Console-Consumer.sh --bootstrap-server localhost: 9092-tema test

Tilbake til produsent

Du kan nå skrive inn meldinger i den nye ledeteksten, og hver gang du treffer returnerer den nye linjen i forbrukerpromptet. For eksempel:

> Dette er en melding.

Denne meldingen blir overført til forbrukeren, gjennom Kafka, og du kan se den trykt på forbrukerprompt.

Oppsett i den virkelige verden

Du har nå et grovt bilde av hvordan Kafka -oppsettet fungerer. For din egen brukssak må du sette et vertsnavn som ikke er lokalhost, du trenger flere slike meglere for å være en del av Kafka -klyngen din, og til slutt må du sette opp forbruker- og produsentkunder.

Her er noen nyttige lenker:

1. Confluent's Python -klient
2. Offisiell dokumentasjon
3. En nyttig liste over demoer

Jeg håper du har det gøy å utforske Apache Kafka.