I en arkitektur för mikrotjänster kan en klient interagera med mer än en klientdelstjänst. Med tanke på detta, hur vet en klient vilka slutpunkter som ska anropas? Vad händer när nya tjänster introduceras eller 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.
Ladda ned en Visio-fil med den här arkitekturen.
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 som autentisering, SSL-avslutning och hastighetsbegränsning. Om du inte distribuerar en gateway måste klienter skicka begäranden direkt till klientdelstjä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 koppling mellan klienten och serverdelen. Klienten behöver veta hur de enskilda tjänsterna bryts ned. 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 resultera i flera nätverksresor mellan klienten och servern, vilket ger betydande svarstid.
- Varje offentlig tjänst måste hantera problem som autentisering, SSL och klientfrekvensbegränsning.
- Tjänsterna måste exponera ett klientvänligt protokoll, till exempel HTTP eller WebSocket. Detta begränsar valet av kommunikationsprotokoll.
- Tjänster med offentliga slutpunkter är en potentiell attackyta och måste härdas.
En gateway hjälper till att lösa dessa problem genom att frånkoppla 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:
Gatewayroutning. Använd gatewayen som en omvänd proxy för att dirigera begäranden till en eller flera serverdelstjä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-sammansättning. 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 serverdelstjänster. Klienten skickar en begäran till gatewayen. Gatewayen skickar begäranden till de olika serverdelstjänsterna och sammanställer sedan resultaten och skickar dem tillbaka till klienten. Detta bidrar till att minska chattigheten mellan klienten och serverdelen.
Gateway-avlastning. Använd gatewayen för att avlasta funktioner från enskilda tjänster till gatewayen, särskilt övergripande problem. 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 implementeras korrekt, till exempel autentisering och auktorisering.
Här är några exempel på funktioner som kan avlastas till en gateway:
- SSL-avslutning
- Autentisering
- IP-lista eller blocklista
- Begränsning av klientfrekvens (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 gateway-teknik
Här följer 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 betalda utgåvor som ger 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 fick formellt namnet nginScript.
Service mesh-ingresskontrollant. Om du använder ett tjänstnät, till exempel Linkerd eller Istio, bör du överväga de funktioner som tillhandahålls av ingresskontrollanten för det tjänstnätet. Till exempel stöder Istio-ingresskontrollanten 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 webbprogram (WAF).
Azure Front Door är Microsofts moderna nätverk för innehållsleverans i molnet (CDN) som ger snabb, tillförlitlig och säker åtkomst mellan dina användare och dina programs statiska och dynamiska webbinnehåll över hela världen. Azure Front Door levererar ditt innehåll med hjälp av Microsofts globala gränsnätverk med hundratals globala och lokala närvaropunkter (POP:er) som distribueras runt om i världen nära både företags- och konsumentanvändare.
Azure API Management. API Management är en nyckelfärdig lösning för att publicera API:er till externa och interna kunder. Den innehåller funktioner som är användbara för att hantera ett offentligt API, inklusive hastighetsbegränsning, IP-begränsningar och autentisering med hjälp av Microsoft Entra-ID eller andra identitetsprovidrar. API Management utför ingen belastningsutjämning, så den bör användas tillsammans med en lastbalanserare, till exempel 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.
När du väljer en gateway-teknik bör du tänka på följande:
Features. Alternativen som anges 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 också 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änsterna uppdateras eller nya tjänster läggs till kan reglerna för gatewayroutning behöva uppdateras. Överväg hur den här processen ska hanteras. Liknande överväganden gäller för hantering av SSL-certifikat, IP-tillåtna listor och andra aspekter av konfigurationen.
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 ingresskontrollant. En ingresskontrollant är en Kubernetes-resurs som distribuerar en lastbalanserare eller omvänd proxyserver. Det finns flera implementeringar, inklusive Nginx och HAProxy. En separat resurs som kallas ingress definierar inställningar för ingresskontrollanten, 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 serverdelstjä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
De tidigare artiklarna har tittat på gränssnitten mellan mikrotjänster eller mellan mikrotjänster och klientprogram. De här gränssnitten behandlar varje tjänst som en ogenomskinlig ruta. I synnerhet bör mikrotjänster aldrig exponera implementeringsinformation om hur de hanterar data. Det får konsekvenser för dataintegritet och datakonsekvens, som utforskas i nästa artikel.