Gateway jämfört med traditionella mikrotjänster

I en mikrotjänstarkitektur delas applikationen upp i många mindre, fristående tjänster. Varje tjänst utför en specifik funktion.

Men hur kommunicerar klienter, till exempel en webbläsare eller en mobilapp, med alla dessa olika tjänster?

Till en början kanske klienter anropar varje mikrotjänst de behöver direkt.

Föreställ er att mobilappen behöver hämta användardata från en "User Service", orderhistorik från en "Order Service" och produktinformation från en "Product Service".

Det här tillvägagångssättet verkar enkelt vid första anblicken, men leder snabbt till problem.

Direkt kommunikation mellan klient och tjänst leder till flera problem:

• Ökad komplexitet hos klienten: Klienterna måste känna till alla tjänsteadresser och hantera olika API:er.
• Flera förfrågningar: En enda användaråtgärd kan kräva många nätverksanrop till olika tjänster.
• Säkerhetsproblem: Varje tjänst kan behöva sin egen logik för autentisering och auktorisering.
• Duplicering av tvärgående funktioner: Funktioner som loggning, hastighetsbegränsning och övervakning upprepas i varje tjänst eller klient.

För att lösa dessa problem introducerar vi en API Gateway. Se den som den enda ingångspunkten för alla klientförfrågningar.

I stället för att klienterna kommunicerar direkt med mikrotjänsterna kommunicerar de endast med API Gateway. Gatewayen vidarebefordrar sedan förfrågningarna till rätt backend-tjänst.

En API Gateway fungerar som en fasad för era mikrotjänster. En fasad förenklar ett komplext system genom att tillhandahålla ett enda, enhetligt gränssnitt.

Klienterna ser ett enkelt API, medan gatewayen hanterar komplexiteten i att dirigera förfrågningar till många interna tjänster.

Med en API Gateway blir klientapplikationerna mycket enklare.

• De behöver bara känna till gatewayens adress.
• Gatewayen kan slå samman svar från flera tjänster till ett enda klientsvar.
• Det minskar antalet nätverksresor och förbättrar prestandan, särskilt för mobila klienter.

En stor fördel är att centralisera tvärgående angelägenheter. Det är funktioner som behövs av många tjänster, till exempel:

• Autentisering och behörighetskontroll: Verifiera användarens identitet en gång.
• Begränsning av anropsfrekvens: Kontrollera hur många begäranden en klient får skicka.
• Loggning och övervakning: Fånga alla inkommande begäranden på ett ställe.
• SSL-terminering: Hantera kryptering och dekryptering för HTTPS.

Genom att implementera detta i gatewayen minskar ni dupliceringen av kod i de enskilda mikrotjänsterna.

API-gatewayen hjälper också till att frikoppla klienterna från mikrotjänsterna.

Om ni ändrar den interna strukturen i en mikrotjänst, till exempel genom att dela upp en tjänst i två, behöver klienten inte känna till det. Gatewayen kan uppdateras så att den hanterar den nya routningen, medan klientens gränssnitt förblir stabilt.

En API-gateway är särskilt användbar i:

• Komplexa mikrotjänstarkitekturer med många tjänster.
• Scenarier med olika typer av klienter, till exempel webb, mobil och tredje part.
• Situationer där ni behöver centraliserad säkerhet, övervakning eller begränsning av anropsfrekvens.

För mycket små applikationer med endast några få tjänster kan direkt kommunikation vara tillräcklig i början, men gateways skalar bättre.

Vi har lärt oss att en API-gateway fungerar som ett viktigt fasadlager i en mikrotjänstarkitektur.

Den förenklar klientinteraktionen, centraliserar gemensamma funktioner som säkerhet och övervakning och frikopplar klienterna från tjänsternas interna komplexitet.

Detta arkitekturmönster leder till robustare, mer lättunderhållna och mer skalbara mikrotjänstapplikationer.