Använda API-gatewayer i mikrotjänster

  • Artikel
  • 5 minuter för att läsa

I en mikrotjänstarkitektur kan en klient interagera med fler än en klienttjänst. Med tanke på detta, hur vet en klient vilka slutpunkter som ska anropas? Vad händer när nya tjänster introduceras eller när befintliga tjänster omstruktureras? Hur hanterar tjänster SSL-avslutning, autentisering och andra problem? En API-gateway kan hjälpa dig att hantera dessa utmaningar.

Diagram över en API-gateway

Vad är en API-gateway?

En API-gateway finns mellan klienter och tjänster. Den fungerar som en omvänd proxy och dirigerar begäranden från klienter till tjänster. Den kan också utföra olika övergripande uppgifter, till exempel autentisering, SSL-avslutning och hastighetsbegränsning. Om du inte distribuerar en gateway måste klienterna skicka begäranden direkt till klienttjänster. Det finns dock vissa potentiella problem med att exponera tjänster direkt för klienter:

  • Det kan resultera i komplex klientkod. Klienten måste hålla reda på flera slutpunkter och hantera fel på ett motståndskraftigt sätt.
  • Den skapar en koppling mellan klienten och backend-datorn. Klienten måste veta hur de enskilda tjänsterna är indelade. Det gör det svårare att underhålla klienten och även svårare att omstrukturera tjänster.
  • En enda åtgärd kan kräva anrop till flera tjänster. Det kan leda till flera nätverksfördröjning mellan klienten och servern, vilket ger längre svarstider.
  • Varje offentlig tjänst måste hantera problem som autentisering, SSL och begränsning av klienthastighet.
  • Tjänster måste exponera ett klientvänligt protokoll som HTTP eller WebSocket. Detta begränsar valet av kommunikationsprotokoll.
  • Tjänster med offentliga slutpunkter är en potentiell angreppsyta och måste härdas.

En gateway hjälper till att åtgärda dessa problem genom att frikoppla klienter från tjänster. Gatewayer kan utföra ett antal olika funktioner och du kanske inte behöver alla. Funktionerna kan grupperas i följande designmönster:

Gateway-routning. Använd gatewayen som en omvänd proxy för att dirigera begäranden till en eller flera servertjänster med layer 7-routning. Gatewayen tillhandahåller en enda slutpunkt för klienter och hjälper till att frikoppla klienter från tjänster.

Gateway-aggregering. Använd gatewayen för att aggregera flera enskilda begäranden till en enda begäran. Det här mönstret gäller när en enskild åtgärd kräver anrop till flera backend-tjänster. Klienten skickar en begäran till gatewayen. Gatewayen skickar begäranden till de olika backend-tjänsterna och aggregerar sedan resultaten och skickar tillbaka dem till klienten. Detta bidrar till att minska trafikknackning mellan klienten och backend-klienten.

Gateway-avlastning. Använd gatewayen för att avlasta funktioner från enskilda tjänster till gatewayen, särskilt övergripande frågor. Det kan vara användbart att konsolidera dessa funktioner på en plats i stället för att göra varje tjänst ansvarig för att implementera dem. Detta gäller särskilt för funktioner som kräver särskilda kunskaper för att implementera korrekt, till exempel autentisering och auktorisering.

Här följer några exempel på funktioner som kan avlastas till en gateway:

  • SSL-avslutning
  • Autentisering
  • Lista över tillåtna/blockerade IP-adresser
  • Begränsning av klienthastighet (begränsning)
  • Loggning och övervakning
  • Cachelagring av svar
  • Brandvägg för webbaserade program
  • GZIP-komprimering
  • Underhåll av statiskt innehåll

Välja en gatewayteknik

Här är några alternativ för att implementera en API-gateway i ditt program.

  • Omvänd proxyserver. Nginx och HAProxy är populära omvända proxyservrar som stöder funktioner som belastningsutjämning, SSL och Layer 7-routning. De är båda kostnadsfria produkter med öppen källkod, med betalutgåva som innehåller ytterligare funktioner och supportalternativ. Nginx och HAProxy är båda mogna produkter med omfattande funktionsuppsättningar och höga prestanda. Du kan utöka dem med moduler från tredje part eller genom att skriva anpassade skript i Lua. Nginx stöder också en JavaScript-baserad skriptmodul som kallas NGINX JavaScript. Den här modulen hette formellt nginScript.

  • Ingress-kontrollant för tjänstnät. Om du använder ett tjänstnät, till exempel linkerd eller Istio, bör du överväga de funktioner som tillhandahålls av ingress-kontrollanten för det tjänstnätet. Till exempel stöder Istio ingress-kontrollanten Layer 7-routning, HTTP-omdirigeringar, återförsök och andra funktioner.

  • Azure Application Gateway. Application Gateway är en hanterad belastningsutjämningstjänst som kan utföra Layer-7-routning och SSL-avslutning. Den tillhandahåller också en brandvägg för webbaserade program (WAF).

  • Azure API Management. API Management är en nyckelfärdig lösning för publicering av API:er till externa och interna kunder. Den innehåller funktioner som är användbara för att hantera ett offentligt API, inklusive frekvensbegränsning, IP-begränsningar och autentisering med hjälp av Azure Active Directory eller andra identitetsproviders. API Management inte utför någon belastningsutjämning, så den bör användas tillsammans med en lastbalanserare som Application Gateway eller en omvänd proxy. Information om hur du använder API Management med Application Gateway finns i Integrera API Management i ett internt VNet med Application Gateway.

Tänk på följande när du väljer gatewayteknik:

Funktioner. Alternativen ovan stöder Layer 7-routning, men stödet för andra funktioner varierar. Beroende på vilka funktioner du behöver kan du distribuera fler än en gateway.

Distribution. Azure Application Gateway och API Management är hanterade tjänster. Nginx och HAProxy körs vanligtvis i containrar i klustret, men kan även distribueras till dedikerade virtuella datorer utanför klustret. Detta isolerar gatewayen från resten av arbetsbelastningen, men medför högre hanteringskostnader.

Hantering. När tjänster uppdateras eller nya tjänster läggs till kan gatewayens routningsregler behöva uppdateras. Fundera över hur den här processen ska hanteras. Liknande överväganden gäller för hantering av SSL-certifikat, listor över tillåtna IP-adresser och andra konfigurationsaspekter.

Distribuera Nginx eller HAProxy till Kubernetes

Du kan distribuera Nginx eller HAProxy till Kubernetes som en ReplicaSet eller DaemonSet som anger Nginx- eller HAProxy-containeravbildningen. Använd en ConfigMap för att lagra konfigurationsfilen för proxyn och montera ConfigMap som en volym. Skapa en tjänst av typen LoadBalancer för att exponera gatewayen via en Azure Load Balancer.

Ett alternativ är att skapa en ingress-kontrollant. En indatakontrollant är en Kubernetes-resurs som distribuerar en lastbalanserare eller en omvänd proxyserver. Det finns flera implementeringar, inklusive Nginx och HAProxy. En separat resurs som kallas ingress definierar inställningar för ingress-kontrollanten, till exempel routningsregler och TLS-certifikat. På så sätt behöver du inte hantera komplexa konfigurationsfiler som är specifika för en viss proxyserverteknik.

Gatewayen är en potentiell flaskhals eller en felpunkt i systemet, så distribuera alltid minst två repliker för hög tillgänglighet. Du kan behöva skala ut replikerna ytterligare, beroende på belastningen.

Överväg också att köra gatewayen på en dedikerad uppsättning noder i klustret. Fördelarna med den här metoden är:

  • Isolering. All inkommande trafik går till en fast uppsättning noder, som kan isoleras från backend-tjänster.

  • Stabil konfiguration. Om gatewayen är felkonfigurerad kan hela programmet bli otillgängligt.

  • Prestanda. Du kanske vill använda en specifik VM-konfiguration för gatewayen av prestandaskäl.

Nästa steg

I föregående artiklar har vi tittat på gränssnitten mellan mikrotjänster eller mellan mikrotjänster och klientprogram. Dessa gränssnitt behandlar varje tjänst som en täckande ruta. Mikrotjänster bör i synnerhet aldrig exponera implementeringsinformation om hur de hanterar data. Det här påverkar dataintegriteten och datakonsekvensen, som vi går vidare till i nästa artikel.

Dataöverväganden för mikrotjänster