Uge 40: Message brokers

Kenneth H Sørensen
Oct 4
4 min read

Updated: Oct 7

Grundlæggende forståelse for message brokers

Jeg vil gennemgå

Hvad er en Message broker
De to mønstre: point-to-point & pub-sub
Kafka
Kafka og forskellen fra traditionelle message brokers
Opsamling - broker, message queue & API
Refleksion om valg i vores projekt
Ressourcer

Hvad er en message broker

En message broker er middleware, der håndterer asynkron kommunikation mellem systemer.

Den modtager beskeder fra producers, gemmer dem i en intern kø eller log, og leverer dem til consumers baseret på konfigurerede regler.

Message broker

Sikrer løs kobling mellem systemkomponenter
Garanterer levering og korrekt rækkefølge af beskeder
Understøtter både point-to-point og publish/subscribe kommunikationsmønstre
Muliggør skalerbarhed, fault tolerance og load balancing
Danner grundlaget for event-drevne og distribuerede arkitekturer

De to mønstre: point-to-point & publish/subscribe

Message brokers understøtter typisk to grundlæggende kommunikationsmønstre, som definerer hvordan beskeder distribueres mellem afsendere (producers) og modtagere (consumers).

Point-to-Point (Queue-baseret)

En besked sendes til en specifik kø (queue)
Kun én consumer modtager og behandler hver besked
Når beskeden er leveret, fjernes den fra køen
Egnet til systemer hvor hver opgave kun skal udføres én gang

Eks.: betalinger, ordrer, e-mailafsendelser

Publish/Subscribe (Topic-baseret)

Producers publicerer beskeder til et topic
Flere consumers kan abonnere på det samme topic
Alle subscribers modtager en kopi af beskeden
Egnet til systemer hvor information skal distribueres bredt

Eks.: realtidsnotifikationer, loganalyse, event-drevne systemer

Kafka

Apache Kafka bruger publish/subscribe

Det er et distribueret event streaming-system designet til

høj gennemstrømning af data
lav latenstid
horisontal skalering

I stedet for traditionelle message queues anvender Kafka en append-only commit log, hvor beskeder persisteres i emner (topics) og opdeles i partitioner.

Jeg har tegnet, hvordan jeg forstår Kafka-arkitekturen

Producer

Sender data (f.eks events, logs, transaktioner eller brugeraktivitet ... )
Publisher beskeder til et specifikt topic i et Kafka cluster

Topic

Samling af beskeder af samme type (f.eks ImageUploaded i vores projekt)
Et cluster kan have mange topics, hver opdelt i partitioner

Kafka Cluster

En samling af brokers, der sammen håndterer alle topics
Fordeler partitioner mellem brokers for skalering og redundans

Partition - en del af den samlede log af beskeder

Underopdelinger af et topic
Partition (Leader) håndterer Read / Write (læsning og skrivning)
Partition (Follower) replikerer data fra leader i en anden broker for high availability (høj tilgængelighed)

Kafka Brokers

Host for / styrer partitioner
Hver broker kan være leader for nogle partitioner og follower for andre
Flere brokers giver failover og høj tilgængelighed

Consumer Groups

Subscriber til et Topic
En gruppe af consumers, der samarbejder om at læse fra et topic
Kafka fordeler partitioner mellem gruppens consumers

Consumer

Læser beskeder fra sin tildelte leader partition
Kun én consumer pr. partition ad gangen inden for samme group

Kafka og forskellen fra traditionelle message brokers

Kafka adskiller sig fra andre message brokers som RabbitMQ eller ActiveMQ.

I stedet for at sende beskeder til midlertidige køer gemmer Kafka dem i en vedvarende log (commit log)
Consumers læser beskeder ud fra deres egen offset, hvilket gør det muligt at genlæse historiske beskeder uden at påvirke andre consumers
Kafka håndterer højere datamængder gennem partitionering og replikering på tværs af brokers
Hvor traditionelle brokers fokuserer på message delivery, fokuserer Kafka på event streaming (en kontinuerlig strøm af data, der kan genlæses og analyseres)

Det gør Kafka mere velegnet til event-drevne og datatunge systemer, hvor beskeder behandles som tidsserier af hændelser i stedet for engangsopgaver

Opsamling - Broker, Message Queue & API

Opsamling på begreberne og forskellen på dem - OBS: GeeksforGeeks blander tingene

Message Broker

Overordnet begreb for Middleware der håndterer asynkron kommunikation ml. systemer
Bruges til event-drevne arkitekturer, hvor services kommunikerer via beskeder
Producer og consumer er uafhængige i tid og kendskab (behøver ikke kende hinanden)
Kan implementeres gennem forskellige mekanismer som
1. message queues (RabbitMQ) / point-to-point (via queues)
2. commit logs (Kafka) / publish-subscribe (via topics)

Message Queue

En mekanisme inden for message brokers, som følger point-to-point-mønstret
Hver besked leveres kun én gang til én consumer
Egnet til jobbaseret behandling eller task distribution, hvor rækkefølge og levering er vigtigere end historik

API (REST / HTTP)

Typisk synkron kommunikation - klienten venter på svar
Simpelt at implementere, men afhængig af at begge parter er online
Forespørgsel/svar-mønster (request/response) f.eks CRUD-operationer

Opsamling

En API kaldes direkte og kræver øjeblikkelig respons
En Message Queue (leveringsmetode) leverer en besked én gang til én consumer
En Message Broker (overordnet begreb) kan gemme, route og distribuere beskeder til mange consumers uafhængigt af tid og tilstand

Refleksion

projekt

I vores projekt ender vi sandsynligvis med at bruge Kafka, men jeg tænker ikke, det er fordi der reelt er et behov for det.

Til vores nuværende formål, hvor der kun sendes én besked fra Ingestion Service til AI Service, ville en simpel message queue formentlig have været nok.

Kafka kræver en del opsætning hvis det skal sættes op korrekt, men vi vil komme til at køre et meget simpelt setup med kun én broker, ét topic og én partition.

Når vi alligevel vælger Kafka, skyldes det primært to ting

Trackunit, som allerede anvender Kafka i deres infrastruktur
Læringsværdi, da vi får praktisk erfaring med et distribueret system, som er relevant i enterprise- og cloud-miljøer

På trods af at Kafka måeske er overkill i vores nuværende kontekst, giver det os et solidt teknisk fundament, vi kan bygge videre på i senere iterationer af systemet.

Videre plan

Fortsætte med implementeringen af “Vertical Slice – Use Case 1” i Storage Service
Læse videre om storage, Azure og alternativer
Undersøge, hvordan Kafka kan bruges i praksis til eventkommunikation mellem services