Microservice-orienterede designmønstre har gjort vores applikationer mere skalerbare end nogensinde. RESTful API-servere, frontend og endda databaser er nu skalerbare vandret. Horisontal skalering er handlingen med at tilføje nye noder til din applikationsklynge for at understøtte yderligere arbejdsbyrde. Omvendt tillader det også at reducere ressourceforbruget, når arbejdsbelastningen falder for at spare omkostninger. Horisontalt skalerbare systemer skal distribueres. Disse systemer, der kan overleve svigt af flere virtuelle computere, containere eller netværkslinks og stadig forbliver online og sunde for slutbrugeren.

Når vi taler om distribuerede systemer som ovenfor, løber vi ind i problemet med analyse og overvågning. Hver node genererer en masse information om sit eget helbred (CPU-brug, hukommelse osv.) Og om applikationsstatus sammen med hvad brugerne prøver at gøre. Disse detaljer skal registreres i:

1. Den samme rækkefølge, som de oprettes i,
2. Adskilt med hensyn til haster (realtidsanalyse eller batcher af data) og vigtigst af alt,
3. Mekanismen, som de samles med, skal i sig selv være en distribueret og skalerbar, ellers står vi tilbage med et enkelt fejlpunkt. Noget, som det distribuerede systemdesign skulle undgå.

Hvorfor bruge Kafka?

Apache Kafka er pitchet som en Distribueret Streaming Platform. I Kafka lingo, Producenter kontinuerligt generere data (vandløb) og Forbrugere er ansvarlige for behandling, opbevaring og analyse af det. Kafka Mæglere er ansvarlige for at sikre, at dataene i et distribueret scenario kan nå fra producenter til forbrugere uden inkonsekvens. Et sæt Kafka-mæglere og et andet software kaldet dyrepasser udgør en typisk Kafka-implementering.

Datastrømmen fra mange producenter skal aggregeres, fordeles og sendes til flere forbrugere, der er meget blanding involveret. Det er ikke let at undgå inkonsistens. Dette er grunden til, at vi har brug for Kafka.

Scenarierne, hvor Kafka kan bruges, er ret forskellige. Alt fra IOT-enheder til klynge af virtuelle computere til dine egne lokale metal-servere. Overalt hvor mange 'ting' samtidig ønsker din opmærksomhed .. .Det er ikke meget videnskabeligt? Nå er Kafka-arkitekturen et eget kaninhul og fortjener en uafhængig behandling. Lad os først se en meget overfladisk installation af softwaren.

Brug af Docker Compose

Uanset hvilken fantasifuld måde du beslutter at bruge Kafka, er en ting sikker - du bruger det ikke som en enkelt forekomst. Det er ikke meningen, at det skal bruges på den måde, og selvom din distribuerede app kun har brug for en forekomst (mægler) indtil videre, vil den til sidst vokse, og du skal sørge for, at Kafka kan følge med.

Docker-compose er den perfekte partner til denne form for skalerbarhed. I stedet for at køre Kafka-mæglere på forskellige virtuelle computere containeriserer vi det og udnytter Docker Compose til at automatisere implementering og skalering. Docker-containere er meget skalerbare på begge enkelt Docker-værter såvel som på tværs af en klynge, hvis vi bruger Docker Swarm eller Kubernetes. Så det giver mening at udnytte det for at gøre Kafka skalerbar.

Lad os starte med en enkelt mæglerinstans. Opret en mappe kaldet apache-kafka, og opret din docker-compose inde i den.yml.

$ mkdir apache-kafka
$ cd apache-kafka
$ vim docker-compose.yml

Følgende indhold placeres i din docker-compose.yml-fil:

version: '3'
tjenester:
dyrepasser:
billede: wurstmeister / zookeeper
 
kafka:
billede: wurstmeister / kafka
porte:
- "9092: 9092"
miljø:
KAFKA_ADVERTISED_HOST_NAME: lokal vært
KAFKA_ZOOKEEPER_CONNECT: zooeeper: 2181

Når du har gemt ovenstående indhold i din komponentfil, fra den samme katalogkørsel:

$ docker-compose op -d

Okay, så hvad gjorde vi her?

Forståelse af Docker-Compose.yml

Compose starter to tjenester som angivet i yml-filen. Lad os se lidt nøje på filen. Det første billede er zookeeper, som Kafka kræver for at holde styr på forskellige mæglere, netværkstopologien samt synkronisering af anden information. Da både zookeeper- og kafka-tjenester vil være en del af det samme bronetværk (dette oprettes, når vi kører docker-compose up), behøver vi ikke udsætte nogen porte. Kafka-mægler kan tale med zookeeper, og det er al den kommunikation, zookeeper har brug for.

Den anden tjeneste er kafka i sig selv, og vi kører bare en enkelt forekomst af det, det vil sige en mægler. Ideelt set vil du bruge flere mæglere for at udnytte den distribuerede arkitektur i Kafka. Tjenesten lytter på port 9092, som er kortlagt på det samme portnummer på Docker Host, og sådan kommunikerer tjenesten med omverdenen.

Den anden tjeneste har også et par miljøvariabler. For det første er KAFKA_ADVERTISED_HOST_NAME indstillet til localhost. Dette er adressen, hvor Kafka kører, og hvor producenter og forbrugere kan finde den. Endnu en gang skal dette være indstillet til localhost, men snarere til IP-adressen eller værtsnavnet med dette, serverne kan nås i dit netværk. For det andet er værtsnavnet og portnummeret på din zookeeper-tjeneste. Da vi navngav zookeeper-tjenesten ... godt, zookeeper, det er hvad værtsnavnet skal være inden for docker bridge-netværk, vi nævnte.

Kører et simpelt meddelelsesflow

For at Kafka kan begynde at arbejde, er vi nødt til at oprette et emne inden for det. Producentklienterne kan derefter offentliggøre datastrømme (meddelelser) til det nævnte emne, og forbrugerne kan læse den nævnte datastrøm, hvis de abonnerer på det pågældende emne.

For at gøre dette skal vi starte en interaktiv terminal med Kafka-containeren. Angiv containerne for at hente kafka-containerens navn. I dette tilfælde hedder vores container for eksempel apache-kafka_kafka_1

$ docker ps

Med kafka containerens navn kan vi nu falde inde i denne container.

$ docker udfører -it apache-kafka_kafka_1 bash
bash-4.4 #

Åbn to så forskellige terminaler for at bruge en som forbruger og en anden producent.

Producentside

I en af ​​instruktionerne (den, du vælger at være producent), skal du indtaste følgende kommandoer:

## For at oprette et nyt emne med navnet test
bash-4.4 # kafka-emner.sh --create - zookeeper zookeeper: 2181 - replikeringsfaktor 1
--partitioner 1 - emnetest
 
## At starte en producent, der udgiver datastream fra standardinput til kafka
bash-4.4 # kafka-konsol-producent.sh - mæglerliste localhost: 9092 - emnetest
>

Producenten er nu klar til at tage input fra tastaturet og offentliggøre det.

Forbrugerens side

Gå videre til den anden terminal, der er tilsluttet din kafka-container. Følgende kommando starter en forbruger, der lever af testemne:

$ kafka-konsol-forbruger.sh --bootstrap-server localhost: 9092 - emnetest

Tilbage til Producer

Du kan nu skrive meddelelser i den nye prompt, og hver gang du trykker på retur, udskrives den nye linje i forbrugerprompten. For eksempel:

> Dette er en besked.

Denne meddelelse overføres til forbrugeren gennem Kafka, og du kan se den udskrives ved forbrugerprompten.

Real-World opsætninger

Du har nu et groft billede af, hvordan Kafka-opsætningen fungerer. For din egen brugssag skal du indstille et værtsnavn, som ikke er localhost, du har brug for flere sådanne mæglere for at være en del af din kafka-klynge, og til sidst skal du oprette forbruger- og producentklienter.

Her er et par nyttige links:

1. Confluents Python-klient
2. Officiel dokumentation
3. En nyttig liste over demoer

Jeg håber, du har det sjovt med at udforske Apache Kafka.