API-gateways gebruiken in microservices

In een microservicesarchitectuur kan een client communiceren met meer dan één front-endservice. Hoe weet een client welke eindpunten moeten worden aanroepen? Wat gebeurt er wanneer er nieuwe services worden geïntroduceerd of bestaande services worden gefactoreerd? Hoe verwerken services SSL-beëindiging, verificatie en andere problemen? Een API-gateway kan helpen bij het aanpakken van deze uitdagingen.

Wat is een API-gateway?

Een API-gateway bevindt zich tussen clients en services. Het fungeert als een omgekeerde proxy en routert aanvragen van clients naar services. Er kunnen ook verschillende verschillende taken worden uitgevoerd, zoals verificatie, SSL-beëindiging en snelheidsbeperking. Als u geen gateway implementeert, moeten clients aanvragen rechtstreeks naar front-endservices verzenden. Er zijn echter enkele potentiële problemen met het rechtstreeks blootstellen van services aan clients:

• Dit kan resulteren in complexe clientcode. De client moet meerdere eindpunten bijhouden en fouten op een flexibele manier afhandelen.
• Er ontstaat koppeling tussen de client en de back-en-back-en. De client moet weten hoe de afzonderlijke services zijn ontled. Dat maakt het moeilijker om de client te onderhouden en ook om services te herfactoring.
• Voor één bewerking zijn mogelijk aanroepen naar meerdere services vereist. Dit kan leiden tot meerdere netwerkrondes tussen de client en de server, wat een aanzienlijke latentie tot gevolg kan hebben.
• Elke openbare service moet problemen afhandelen, zoals verificatie, SSL en beperking van de clientsnelheid.
• Services moeten een clientvriendelijk protocol, zoals HTTP of WebSocket, blootstellen. Dit beperkt de keuze van communicatieprotocollen.
• Services met openbare eindpunten zijn een potentieel aanvalsoppervlak en moeten worden gehard.

Een gateway helpt bij het oplossen van deze problemen door clients los te koppelen van services. Gateways kunnen een aantal verschillende functies uitvoeren en u hebt ze mogelijk niet allemaal nodig. De functies kunnen worden gegroepeerd in de volgende ontwerppatronen:

Gatewayroutering. Gebruik de gateway als een omgekeerde proxy om aanvragen naar een of meer back-endservices te routeren met behulp van laag 7-routering. De gateway biedt één eindpunt voor clients en helpt bij het loskoppelen van clients van services.

Gatewayaggregatie. Gebruik de gateway om meerdere afzonderlijke aanvragen te aggregeren in één aanvraag. Dit patroon is van toepassing wanneer voor één bewerking aanroepen naar meerdere back-endservices zijn vereist. De client verzendt één aanvraag naar de gateway. De gateway verzendt aanvragen naar de verschillende back-endservices en aggregeert vervolgens de resultaten en stuurt deze terug naar de client. Dit helpt om de chattiteit tussen de client en de back-end te verminderen.

Gateway offloading. Gebruik de gateway om de functionaliteit van afzonderlijke services naar de gateway te offloaden, met name bij veelgebruikte problemen. Het kan handig zijn om deze functies op één plek te consolideren, in plaats van elke service verantwoordelijk te maken voor het implementeren ervan. Dit geldt met name voor functies die gespecialiseerde vaardigheden nodig hebben om correct te implementeren, zoals verificatie en autorisatie.

Hier zijn enkele voorbeelden van functionaliteit die kan worden ge-offload naar een gateway:

• SSL-beëindiging
• Verificatie
• Lijst met toegestane/geblokkeerde IP-adressen
• Beperking van clientsnelheid (beperking)
• Logboekregistratie en bewaking
• Antwoord in de caching
• Web Application Firewall
• GZIP-compressie
• Statische inhoud onderhouden

Een gatewaytechnologie kiezen

Hier zijn enkele opties voor het implementeren van een API-gateway in uw toepassing.

• Omgekeerde proxyserver. Nginx en HAProxy zijn populaire omgekeerde proxyservers die ondersteuning bieden voor functies zoals taakverdeling, SSL en layer 7-routering. Het zijn beide gratis opensource-producten, met betaalde edities die extra functies en ondersteuningsopties bieden. Nginx en HAProxy zijn beide volwassen producten met uitgebreide functiesets en hoge prestaties. U kunt deze uitbreiden met modules van derden of door aangepaste scripts te schrijven in Lua. Nginx biedt ook ondersteuning voor een scriptmodule op basis van JavaScript, ook welNGINX JavaScript genoemd. Deze module heet formeel nginScript.

• Controller voor service mesh-ingress. Als u een service-mesh zoals linkerd of Istio gebruikt, moet u rekening houden met de functies die worden geleverd door de controller voor ingress voor die service-mesh. De Istio-controller voor ingress ondersteunt bijvoorbeeld routering op laag 7, HTTP-omleidingen, nieuwe proberen en andere functies.

• Azure Application Gateway. Application Gateway is een beheerde taakverdelingsservice die layer-7-routering en SSL-beëindiging kan uitvoeren. Het biedt ook een Web Application Firewall (WAF).

• Azure API Management. API Management is een gebruiksklare oplossing voor het publiceren van API's naar externe en interne klanten. Het biedt functies die nuttig zijn voor het beheren van een openbare API, waaronder snelheidsbeperking, IP-beperkingen en verificatie met Azure Active Directory of andere id-providers. API Management voert geen taakverdeling uit, dus moet deze worden gebruikt in combinatie met een load balancer zoals Application Gateway of een omgekeerde proxy. Zie Integrate API Management API Management in an internal VNet withApplication Gateway (Integratie van API Management in een intern VNet met Application Gateway) voor meer informatie over het gebruik van Application Gateway.

Houd bij het kiezen van een gatewaytechnologie rekening met het volgende:

Functies. De bovenstaande opties ondersteunen laag 7-routering, maar de ondersteuning voor andere functies varieert. Afhankelijk van de functies die u nodig hebt, kunt u meer dan één gateway implementeren.

Implementatie. Azure Application Gateway en API Management zijn beheerde services. Nginx en HAProxy worden doorgaans uitgevoerd in containers in het cluster, maar kunnen ook worden geïmplementeerd op toegewezen VM's buiten het cluster. Hiermee wordt de gateway geïsoleerd van de rest van de workload, maar wordt er meer beheeroverhead in de weg staat.

Beheer. Wanneer services worden bijgewerkt of nieuwe services worden toegevoegd, moeten de regels voor gatewayroutering mogelijk worden bijgewerkt. Denk na over hoe dit proces wordt beheerd. Soortgelijke overwegingen zijn van toepassing op het beheren van SSL-certificaten, IP-lijsten met toegestane adressen en andere aspecten van de configuratie.

Nginx of HAProxy implementeren in Kubernetes

U kunt Nginx of HAProxy implementeren in Kubernetes als een ReplicaSet of DaemonSet die de Nginx- of HAProxy-containerafbeelding specificeert. Gebruik een ConfigMap om het configuratiebestand voor de proxy op te slaan en de ConfigMap als een volume te mounten. Maak een service van het type LoadBalancer om de gateway via een Azure Load Balancer.

Een alternatief is het maken van een controller voor ingress. Een controller voor ingress is een Kubernetes-resource die een load balancer of omgekeerde proxyserver implementeert. Er bestaan verschillende implementaties, waaronder Nginx en HAProxy. Een afzonderlijke resource met de naam Ingress definieert instellingen voor de controller voor ingress, zoals routeringsregels en TLS-certificaten. Op die manier hoeft u geen complexe configuratiebestanden te beheren die specifiek zijn voor een bepaalde proxyservertechnologie.

De gateway is een potentieel knelpunt of single point of failure in het systeem, dus implementeer altijd ten minste twee replica's voor hoge beschikbaarheid. Afhankelijk van de belasting moet u de replica's mogelijk verder uitschalen.

U kunt de gateway ook uitvoeren op een toegewezen set knooppunten in het cluster. Voordelen van deze benadering zijn onder andere:

• Isolatie. Al het binnenkomende verkeer gaat naar een vaste set knooppunten, die kunnen worden geïsoleerd van back-endservices.

• Stabiele configuratie. Als de gateway onjuist is geconfigureerd, is de hele toepassing mogelijk niet meer beschikbaar.

• Prestaties. U kunt uit prestatieoverwegingen een specifieke VM-configuratie voor de gateway gebruiken.

Volgende stappen

In de vorige artikelen is gekeken naar de interfaces tussen microservices of tussen microservices en clienttoepassingen. Deze interfaces behandelen elke service als een ondoorzichtig vak. Met name microservices mogen nooit implementatiedetails beschikbaar maken over hoe ze gegevens beheren. Dit heeft gevolgen voor de gegevensintegriteit en gegevensconsistentie, zoals beschreven in het volgende artikel.