Mønstre for kommunikation mellem services

I en mikrotjenestearkitektur er din applikation opdelt i mange små, uafhængige tjenester. For at disse tjenester kan arbejde sammen og levere en komplet brugeroplevelse, skal de kommunikere med hinanden.

Denne kommunikation kaldes kommunikation mellem tjenester. Det er sådan, én tjeneste anmoder om data fra eller udløser handlinger i en anden tjeneste.

Synkron kommunikation minder om et direkte telefonopkald. Når Tjeneste A har brug for data fra Tjeneste B, sender den en forespørgsel og venter derefter på, at Tjeneste B svarer, før den fortsætter sit eget arbejde.

• Forespørgsel-svar-modellen: Tjeneste A venter på et svar fra Tjeneste B.
• Blokering: Tjeneste A er blokeret (og kan ikke udføre andet arbejde), indtil svaret ankommer.

Den mest almindelige måde at opnå synkron kommunikation mellem mikrotjenester på er at bruge HTTP (Hypertext Transfer Protocol) og RESTful API'er.

En REST API definerer et sæt regler for, hvordan tjenester kan interagere ved hjælp af standardiserede HTTP-metoder (som GET, POST, PUT og DELETE) via URL'er.

Selvom synkron kommunikation er enkel, har den ulemper:

• Tæt kobling: Tjenester bliver afhængige af hinandens tilgængelighed. Hvis Tjeneste B er nede, kan Tjeneste A fejle.
• Forsinkelse: Den samlede svartid omfatter summen af alle individuelle tjenestekalds varigheder.
• Kaskaderende fejl: En fejl i én tjeneste kan hurtigt sprede sig til andre.

Asynkron kommunikation minder om at sende et brev eller en e-mail. Tjeneste A sender en meddelelse til Tjeneste B og venter ikke på et øjeblikkeligt svar.

Tjeneste A kan fortsætte sit eget arbejde, og Tjeneste B behandler meddelelsen, når den er klar, og svarer måske senere eller udløser en anden handling.

En almindelig måde at implementere asynkron kommunikation på er at bruge en meddelelseskø eller en meddelelsesmægler. Forestil dig den som et postkontor for dine tjenester.

• Tjeneste A sender en meddelelse til køen.
• Køen gemmer meddelelsen på en pålidelig måde.
• Tjeneste B henter og behandler meddelelsen, når den er tilgængelig.

Asynkrone mønstre giver betydelige fordele:

• løs kobling: Tjenester er mindre afhængige af hinanden. Hvis Tjeneste B midlertidigt er nede, venter meddelelserne i køen.
• Forbedret reaktionsevne: Tjeneste A venter ikke, så den kan svare klienter hurtigere.
• Skalerbarhed: Du kan tilføje flere instanser af Tjeneste B, så meddelelser fra køen behandles parallelt.

Valget mellem synkron og asynkron kommunikation afhænger af dit anvendelsesområde:

• Synkron: Bedst til øjeblikkelige forespørgsler, hvor en klient har brug for et straks-svar (f.eks. hentning af brugerprofiloplysninger).
• Asynkron: Ideel til baggrundsopgaver, langvarige processer eller situationer, hvor høj fejltolerance og afkobling er afgørende (f.eks. behandling af en ordre eller afsendelse af e-mailnotifikationer).

Selvom HTTP/REST og meddelelseskøer er de primære teknologier, findes der også andre:

• gRPC: Et højtydende, sproguafhængigt RPC-framework (Remote Procedure Call). Det bruger ofte Protocol Buffers til effektiv serialisering af data.
• Hændelsesdrevne arkitekturer: Tjenester kommunikerer ved at publicere og abonnere på hændelser, ofte ved hjælp af meddelelsesbrokere.

Vi har undersøgt, hvordan mikrotjenester kommunikerer. Synkron kommunikation omfatter direkte, blokerende kald, ofte ved hjælp af HTTP/REST, men kan føre til tæt kobling og kaskaderende fejl.

Asynkron kommunikation bruger indirekte metoder som meddelelseskøer og giver løs kobling, bedre reaktionsevne og større robusthed. Det er afgørende for en robust mikrotjenestearkitektur at vælge det rigtige mønster.