RabbitMQ, MessageBroker i en microservice arkitektur

Ressourser:
RabbitMQ Docs

RabbitMQ – Kommunikation i min Microservice-løsning

I udviklingen af mit 4. semester projekt har RabbitMQ været en central del af infrastrukturen for at håndtere kommunikationen mellem mine forskellige microservices. RabbitMQ er en messaging-broker, som gør det muligt for services at sende og modtage beskeder på en pålidelig og struktureret måde.

Hvorfor bruge RabbitMQ?

RabbitMQ er en kraftfuld løsning til kommunikation mellem microservices, fordi:

• Det understøtter asynkron kommunikation, hvilket betyder, at services ikke behøver at vente på hinanden for at kunne arbejde videre.
• Det sikrer pålidelig levering af beskeder, også selvom en service midlertidigt ikke er tilgængelig.
• Det understøtter forskellige kommunikationsmønstre som direct, fanout, topic, og headers exchanges, hvilket gør det fleksibelt at designe kommunikationsflows.
• RabbitMQ har indbygget understøttelse af sikkerhed via TLS, som sikrer, at kommunikationen mellem services er krypteret.

Synkron vs. Asynkron Kommunikation

I en microservice-arkitektur er der to primære kommunikationsformer:

Asynkron Kommunikation

Her kan en service sende en besked og fortsætte sit arbejde uden at vente på svar.

Eksempel: Når en ny bruger oprettes, kan UserService sende en besked om dette til AuthenticationService via RabbitMQ. AuthenticationService kan derefter opdatere sin readmodel uden at UserService behøver at vente. Mega smart!

Synkron Kommunikation

Her skal en service vente på et svar fra en anden service, før den kan arbejde videre.

Eksempel: Ved login validerer SecurityTokenService (STS) brugeren ved at sende loginoplysninger til UserService og vente på svar. Dette er synkron kommunikation, fordi STS har brug for svaret, før den kan udstede en JWT-token.

RabbitMQ i min løsning

mTLS mellem services

For at sikre, at kommunikationen mellem mine services er krypteret og autentificeret, har jeg brugt mutual TLS (mTLS). Dette sikrer, at både klienten (den service, der sender beskeden) og serveren (RabbitMQ) stoler på hinanden.

Direct Exchanges

Jeg har brugt direct exchanges til at sikre, at beskeder sendes til den rigtige kø. Dette er især nyttigt, når en service kun skal kommunikere med en specifik modtager, som det er tilfældet med STS og UserService.

CorrelationId for synkron kommunikation

Ved login bruger STS en correlationId til at spore forespørgslen, når den venter på svar fra UserService. Dette sikrer, at STS kan matche det korrekte svar til den oprindelige forespørgsel. Denne teknik er afgørende for synkron kommunikation via RabbitMQ.

Flowet ser således ud:

1. STS sender en besked til UserService via RabbitMQ med en correlationId.
2. UserService behandler forespørgslen og sender svaret tilbage til en dedikeret kø, hvor correlationId er vedhæftet.
3. STS matcher svaret til den oprindelige forespørgsel og afslutter loginprocessen.

Fordele ved RabbitMQ i min løsning

• Decoupling: Services er uafhængige af hinanden og kommunikerer kun via RabbitMQ.
• Skalerbarhed: RabbitMQ håndterer let stigende trafik og kan skaleres på tværs af flere noder.
• Sikkerhed: Ved brug af mTLS er kommunikationen mellem mine services og RabbitMQ både krypteret og autentificeret.
• Fleksibilitet: RabbitMQ understøtter både synkron og asynkron kommunikation, afhængigt af behovet.

Hvad jeg har lært

RabbitMQ har været en øjenåbner for, hvordan messaging kan bruges til at skabe robuste, sikre og skalerbare systemer. Ved at kombinere RabbitMQ med mTLS og correlationId har jeg fået en dybere forståelse for, hvordan man designer kommunikationsmønstre i en microservice-arkitektur.

I fremtiden planlægger jeg at undersøge yderligere avancerede features som message priorities og delayed queues, samt hvordan RabbitMQ kan optimeres til endnu større skala.