Opnå en forståelse for værktøjer, der kan bruges ved brug af microservices.

Opsøge og vurdere Apache Kafka som et værktøj, der kan anvendes i projektet.

Apache Kafka (daglig tale Kafka) er et distribueret system til håndtering af beskeder/streams, en såkaldt messagebroker.
Det består både af server- og klient-side og fungerer som et publisher-subscriber beskedsystem.

Kafka Brokers (server-side)
En Kafka-server kaldes for en broker. Man har typisk et cluster med mange brokers for at sikre høj tilgængelighed og mulighed for skalering.
Hver broker er ansvarlig for at gemme og håndtere data for en del af systemet. Data gemmes i det, man kalder for topics.

Klient-siden
På klientsiden findes producers, som er dem, der sender beskeder/data til et topic i Kafka.
Man har også consumers, som er dem, der læser beskeder. Consumers kan enten læse fra topics alene eller i grupper (consumer groups).

Events
Et event handler om, at noget er sket. Når man skriver eller læser data til Kafka, gøres dette i form af events.
Hvert event har en record med key, value, timestamp og headers (metadata).
Kafka bygger på et producer/consumer-mønster, hvor producers publicerer (skriver) events til Kafka, og consumers subscriber (læser og processerer) disse events.
Producers og consumers kender ikke hinanden direkte – de kobles kun via topics. Dette giver løs kobling og mulighed for at tilføje flere consumers uden at ændre procedurer.

Kafka Topic
Hvert event er organiseret og gemt i topics. Man kan sige, at et topic er en slags mappe i et filsystem, og events er filerne i den mappe.
Events i et topic kan læses så ofte, der er behov for det. Et event bliver ikke slettet, blot fordi det er læst – man kan selv bestemme, hvor længe et event skal gemmes.
Et topic er spredt ud over forskellige partitions, fordelt på forskellige Kafka brokers.
Events med samme nøgle bliver altid routet til den samme partition (for at bevare rækkefølgen).

Kilde: Apache Kafka – Introduction

I projektet kan Kafka bruges til at forbinde microservices uden at de behøver kende hinanden direkte.
Eksempelvis kan min AI-service lytte til events på Ingestion Service’s topic – fx når et nyt billede skal analyseres.
Dette er kendt som Event-Driven Architecture. Det kan sætte gang i en analyse af billedet, hvorefter AI-servicen har sit eget topic, hvor der oprettes et event med resultatet, som Ingestion Service kan lytte til.
På den måde kan AI-servicen både fungere som consumer og producer af events.