In een microservicesarchitectuur kan een client communiceren met meer dan één front-endservice. Gezien dit feit, hoe weet een client welke eindpunten moeten worden aangeroepen? Wat gebeurt er wanneer nieuwe services worden geïntroduceerd of bestaande services worden geherstructureerd? Hoe verwerken services SSL-beëindiging, wederzijdse TLS, verificatie en andere problemen? Een API-gateway kan helpen deze uitdagingen aan te pakken.
Download een Visio-bestand van deze architectuur.
Wat is een API-gateway?
Een API-gateway biedt een gecentraliseerd toegangspunt voor het beheren van interacties tussen clients en toepassingsservices. Het fungeert als een omgekeerde proxy en stuurt clients aanvragen naar de juiste services. Het kan ook verschillende kruislingse taken uitvoeren, zoals verificatie, SSL-beëindiging, wederzijdse TLS en snelheidsbeperking.
Waarom een API-gateway gebruiken?
Een API-gateway vereenvoudigt de communicatie, verbetert clientinteracties en centraliseert het beheer van algemene verantwoordelijkheden op serviceniveau. Het fungeert als intermediair en voorkomt directe blootstelling van toepassingsservices aan clients. Zonder een API-gateway moeten clients rechtstreeks communiceren met afzonderlijke toepassingsservices, wat de volgende uitdagingen kan veroorzaken:
complexe clientcode: dit kan leiden tot complexe clientcode. Clients moeten meerdere eindpunten bijhouden en fouten tolerant afhandelen.
Strakke koppeling: er wordt een koppeling gemaakt tussen de client en de back-end. Clients moeten inzicht hebben in de ontleding van afzonderlijke services, het compliceren van serviceonderhoud en herstructurering.
Verhoogde latentie: voor één bewerking zijn mogelijk aanroepen naar meerdere services vereist. Het resultaat kan meerdere netwerkrondes tussen de client en de server zijn, waardoor aanzienlijke latentie wordt toegevoegd.
redundante verwerking van problemen: elke openbare service moet zorgen afhandelen, zoals verificatie, SSL en clientsnelheidsbeperking.
Protocolbeperkingen: Services moeten een clientvriendelijk protocol beschikbaar maken, zoals HTTP of WebSocket. Deze blootstelling beperkt communicatieprotocollen opties.
uitgebreide kwetsbaarheid voor aanvallen: openbare eindpunten vergroten de potentiële kwetsbaarheid voor aanvallen en vereisen beveiliging.
Een API-gateway gebruiken
Een API-gateway kan worden aangepast aan de vereisten van uw toepassing met behulp van specifieke ontwerppatronen. Deze ontwerppatronen hebben betrekking op belangrijke functionaliteit, zoals routering, aggregatie van aanvragen en kruislingse problemen:
gatewayroutering. U kunt een API-gateway gebruiken als een omgekeerde proxy om clientaanvragen naar verschillende toepassingsservices te routeren. De API-gateway maakt gebruik van laag-7-routering en biedt één eindpunt dat clients kunnen gebruiken. Gebruik API-gatewayroutering wanneer u clients wilt loskoppelen van toepassingsservices.
gatewayaggregatie. U kunt de API-gateway gebruiken om meerdere clientaanvragen samen te voegen in één aanvraag. Gebruik dit patroon wanneer voor één bewerking aanroepen naar meerdere toepassingsservices zijn vereist. In API-aggregatie verzendt de client één aanvraag naar de API-gateway. Vervolgens stuurt de API-gateway aanvragen naar de verschillende services die nodig zijn voor de bewerkingen. Ten slotte worden de resultaten door de API-gateway samengevoegd en teruggestuurd naar de client. De aggregatie helpt de chattiness tussen de client en de toepassingsservices te verminderen.
Gateway-offloading. U kunt een API-gateway gebruiken om geavanceerde functionaliteit te bieden, zodat afzonderlijke services deze niet hoeven te leveren. Het kan handig zijn om kruislingse functionaliteit op één plaats samen te voegen, in plaats van elke service verantwoordelijk te maken. Hier volgen enkele voorbeelden van functionaliteit die u kunt offloaden naar een API-gateway:
- SSL-beëindiging
- Wederzijdse TLS
- Authenticatie
- IP-acceptatielijst of blokkeringslijst
- Clientsnelheidsbeperking (beperking)
- Logboekregistratie en bewaking
- Antwoordcaching
- Web Application Firewall
- GZIP-compressie
- Statische inhoud onderhouden
API-gatewayopties
Hier volgen enkele opties voor het implementeren van een API-gateway in uw toepassing.
omgekeerde proxyserver. Nginx en HAProxy zijn opensource reverse proxy-aanbiedingen. Ze ondersteunen functies zoals taakverdeling, SSL-beëindiging en laag-7-routering. Ze hebben gratis versies en betaalde edities die extra functies en ondersteuningsopties bieden. Deze producten zijn volwassen met uitgebreide functiesets, hoge prestaties en uitbreidbaar.
voor inkomend verkeer van service-mesh. Als u een service-mesh gebruikt, evalueert u de functies van de ingangscontroller die specifiek zijn voor die service-mesh. Controleer op door AKS ondersteunde invoegtoepassingen, zoals Istio en Open Service Mesh. Zoek naar opensource-projecten van derden, zoals Linkerd of Consul Connect. De Istio-ingangscontroller ondersteunt bijvoorbeeld laag 7-routering, HTTP-omleidingen, nieuwe pogingen en andere functies.
Azure Application Gateway-. Application Gateway is een beheerde taakverdelingsservice. Het biedt laag-7-routering, SSL-beëindiging en een WAF (Web Application Firewall).
Azure Front Door. Azure Front Door is een netwerk voor contentlevering (CDN). Het maakt gebruik van wereldwijde en lokale aanwezigheidspunten (PoPs) voor snelle, betrouwbare en veilige toegang tot de statische en dynamische webinhoud van uw toepassingen wereldwijd.
Azure API Management-. API Management is een beheerde oplossing voor het publiceren van API's naar externe en interne klanten. Het biedt functies voor het beheren van openbare API's, waaronder snelheidsbeperking, IP-beperkingen en verificatie met behulp van Microsoft Entra ID of andere id-providers. API Management voert geen taakverdeling uit, dus u moet deze gebruiken met een load balancer, zoals Azure Application Gateway of een omgekeerde proxy. Zie API Management met Azure Application Gatewayvoor meer informatie.
Een API-gatewaytechnologie kiezen
Houd rekening met de volgende factoren bij het selecteren van een API-gateway:
Alle vereisten ondersteunen. Kies een API-gateway die ondersteuning biedt voor uw vereiste functies. Alle vorige API-gatewayopties ondersteuning bieden voor routering op laag 7. Maar hun ondersteuning voor andere functies, zoals verificatie, frequentiebeperking en SSL-beëindiging, kan variëren. Bepaal of één gateway aan uw behoeften voldoet of of er meerdere gateways nodig zijn.
Liever ingebouwde aanbiedingen. Gebruik ingebouwde API-gateway- en toegangsbeheeroplossingen die door uw platform worden geleverd, zoals Azure Container Apps en AKS, wanneer ze voldoen aan uw beveiligings- en controlevereisten. Gebruik alleen een aangepaste gateway als de ingebouwde opties niet over de nodige flexibiliteit beschikken. Aangepaste oplossingen vereisen een governancemodel, zoals GitOps, om de levenscyclus effectief te beheren.
Kies het juiste implementatiemodel. Gebruik beheerde services zoals Azure Application Gateway en Azure API Management voor verminderde operationele overhead. Als u algemene omgekeerde proxy's of load balancers gebruikt, implementeert u deze op een manier die overeenkomt met uw architectuur. U kunt API-gateways voor algemeen gebruik implementeren op toegewezen virtuele machines of in een AKS-cluster in hun aanbiedingen voor inkomend verkeer. Als u de API-gateway wilt isoleren van de workload, kunt u deze buiten het cluster implementeren, maar deze implementatie verhoogt de beheercomplexiteit.
Wijzigingen beheren. Wanneer u services bijwerkt of nieuwe services toevoegt, moet u mogelijk de regels voor gatewayroutering bijwerken. Implementeer processen of werkstromen om routeringsregels te beheren bij het toevoegen of wijzigen van services, SSL-certificaten, IP-acceptatielijsten en beveiligingsconfiguraties. Gebruik hulpprogramma's voor infrastructuur als code en automatisering om API-gatewaybeheer te stroomlijnen.
Volgende stappen
In eerdere artikelen zijn de interfaces tussen microservices en tussen microservices en clienttoepassingen verkend. Deze interfaces behandelen elke service als een zelfstandige, ondoorzichtige eenheid. Een essentieel principe van microservicesarchitectuur is dat services nooit interne details moeten weergeven over hoe ze gegevens beheren. Deze aanpak heeft aanzienlijke gevolgen voor het behouden van gegevensintegriteit en consistentie, wat het onderwerp van het volgende artikel is.
overwegingen voor gegevens voor microservices