Delen via

Azure API Management gebruiken in een multitenant-oplossing

  • Artikel

Azure API Management is een uitgebreide API-gateway en omgekeerde proxy voor API's. Het biedt veel functies, waaronder caching, antwoordsimuleerde en een ontwikkelaarsportal, die handig zijn voor api-gerichte toepassingen. In dit artikel vindt u een overzicht van enkele van de belangrijkste functies van API Management die nuttig zijn voor multitenant-oplossingen.

Notitie

In dit artikel wordt uitgelegd hoe u API Management kunt gebruiken wanneer u uw eigen multitenant-toepassingen hebt die API's hosten voor intern of extern gebruik.

Een andere vorm van multitenancy is het leveren van de API Management-gateway als een service aan andere teams. Een organisatie kan bijvoorbeeld een gedeeld API Management-exemplaar hebben dat meerdere toepassingsteams implementeren en gebruiken. In dit artikel wordt deze vorm van multitenancy niet besproken. Overweeg het gebruik van werkruimten, waarmee u een API Management-exemplaar kunt delen in meerdere teams die mogelijk verschillende toegangsniveaus hebben.

Isolatiemodellen

API Management wordt doorgaans geïmplementeerd als een gedeeld onderdeel met één exemplaar dat aanvragen voor meerdere tenants verwerkt. Op basis van uw tenancymodel zijn er echter veel manieren waarop u API Management kunt implementeren. In dit artikel wordt ervan uitgegaan dat u uw oplossing implementeert met behulp van implementatiestempels.

Normaal gesproken is de manier waarop u API Management gebruikt, vergelijkbaar, ongeacht het isolatiemodel. Deze sectie is gericht op de verschillen in kosten en complexiteit tussen de isolatiemodellen en hoe aanvragen worden gerouteerd naar uw back-end-API-toepassingen.

Overweging Gedeeld exemplaar met back-ends met één tenant Gedeeld exemplaar met gedeelde back-end met meerdere tenants Exemplaar voor elke tenant
Aantal ondersteunde tenants Veel Bijna niet-gebonden Eén voor elk exemplaar
Kosten Lower Lower Hoger
Implementatiecomplexiteit Laag: Eén exemplaar dat moet worden beheerd voor elke stempel Laag: Eén exemplaar dat moet worden beheerd voor elke stempel Hoog: meerdere exemplaren die moeten worden beheerd
Complexiteit van routeringsconfiguratie Hoger Lower Lower
Gevoeligheid voor problemen met ruis Ja Ja Nr.
Netwerkisolatie op tenantniveau Nee No Ja
Voorbeeldscenario Aangepaste domeinnamen voor elke tenant Grote multitenant-oplossing met een gedeelde toepassingslaag Tenantspecifieke implementatiestempels

Isolatiemodellen voor gedeelde exemplaren

Het is gebruikelijk om een API Management-exemplaar te delen tussen meerdere tenants, wat helpt kosten en implementatie en beheercomplexiteit te verminderen. De details van hoe u een API Management-exemplaar kunt delen, is afhankelijk van hoe u tenants toewijst aan back-end-API-toepassingen.

Back-endtoepassing met één tenant

Als u afzonderlijke back-endtoepassingen voor elke tenant implementeert, kunt u één API Management-exemplaar implementeren en verkeer routeren naar de juiste tenantback-end voor elke aanvraag. Voor deze aanpak moet u API Management configureren met de back-endhostnamen voor elke tenant of een andere manier hebben om een binnenkomende aanvraag toe te wijzen aan de juiste back-end van de tenant.

Omdat hiervoor een extra zoekopdracht is vereist, kan deze benadering mogelijk niet worden geschaald naar grote aantallen tenants die één API Management-exemplaar delen. Er kan ook enige prestatieoverhead optreden wanneer u de back-end van de tenant opzoekt. De grootte van deze prestatieoverhead is echter afhankelijk van hoe u een dergelijke zoekactie ontwerpt.

Gedeelde back-endtoepassing met meerdere tenants

In scenario's waarin uw tenants een gemeenschappelijke back-endtoepassing delen, wordt het API Management-routeringsproces vereenvoudigd omdat u alle aanvragen naar één back-end kunt routeren. Als u jokertekendomeinen of door de provider uitgegeven domeinen gebruikt, kunt u met deze methode mogelijk bijna niet-gebonden schaal bereiken. Omdat aanvragen niet hoeven te worden toegewezen aan de back-end van een tenant, is er geen invloed op de prestaties van aangepaste routeringsbeslissingen.

Exemplaar voor elke tenant

In sommige gevallen kunt u voor elke tenant een exemplaar van API Management implementeren. We raden deze aanpak alleen aan als u een klein aantal tenants hebt of als u strikte nalevingsvereisten hebt waarmee u geen infrastructuur tussen tenants kunt delen. Als u bijvoorbeeld een toegewezen virtueel netwerk voor elke tenant implementeert, moet u waarschijnlijk ook een toegewezen API Management-exemplaar voor elke tenant implementeren.

Tip

Als uw enige reden voor het implementeren van meerdere exemplaren is om gebruikers in verschillende geografische regio's te ondersteunen, kunt u overwegen of de functie voor meerdere regio's in API Management voldoet aan uw vereisten.

Wanneer u een exemplaar van API Management implementeert, moet u rekening houden met de servicelimieten, inclusief eventuele limieten die van toepassing kunnen zijn op het aantal API Management-exemplaren binnen een Azure-abonnement of -regio.

Exemplaren met één tenant hebben doorgaans een minimale routeringsconfiguratie, omdat u alle aanvragen naar één back-end kunt routeren. Voor dit scenario zijn geen aangepaste routeringsbeslissingen vereist, dus er is geen extra invloed op de prestaties. Er worden echter doorgaans hogere resourcekosten in rekening gebracht dan wanneer u een gedeeld exemplaar implementeert. Als u exemplaren met één tenant wilt implementeren, kunt u overwegen of u met zelf-hostende gateways tenantspecifieke rekenresources die u al implementeert, opnieuw kunt gebruiken.

API Management-functies die ondersteuning bieden voor multitenancy

API Management maakt gebruik van beleid om flexibiliteit mogelijk te maken. U kunt aanpassen hoe aanvragen worden gevalideerd, gerouteerd en verwerkt wanneer u beleid gebruikt. En wanneer u een multitenant-oplossing ontwerpt met API Management, gebruikt u beleid om veel van de mogelijkheden ervan te implementeren.

Tenants identificeren voor binnenkomende aanvragen

Overweeg hoe u de juiste tenant binnen elke binnenkomende aanvraag kunt identificeren. In een multitenant-oplossing is het belangrijk dat u duidelijk weet wie elke aanvraag indient, zodat u de gegevens voor die specifieke tenant en niemand anders retourneert.

API Management biedt abonnementen die u kunt gebruiken om aanvragen te verifiëren. Deze abonnementen gebruiken een unieke abonnementssleutel waarmee de abonnee kan worden geïdentificeerd die de aanvraag doet. Als u ervoor kiest om abonnementen te gebruiken, kunt u overwegen hoe u de API Management-abonnementen kunt toewijzen aan uw eigen tenant- of klant-id's. Abonnementen zijn nauw geïntegreerd in de ontwikkelaarsportal. Voor de meeste oplossingen is het een goede gewoonte om abonnementen te gebruiken om tenants te identificeren.

U kunt de tenant ook identificeren met behulp van andere methoden. Hier volgen enkele voorbeelden van benaderingen die worden uitgevoerd binnen een aangepast beleid dat u definieert:

  • Gebruik een aangepast onderdeel van de URL, zoals een subdomein, pad of querytekenreeks. In de URL https://api.contoso.com/tenant1/productskunt u bijvoorbeeld het eerste deel van het pad tenant1extraheren en behandelen als een tenant-id. Op dezelfde manier kunt u, gezien de binnenkomende URLhttps://tenant1.contoso.com/products, het subdomein extraheren. tenant1 Als u deze methode wilt gebruiken, kunt u het pad of de querytekenreeks van de Context.Request.Url eigenschap parseren.

  • Gebruik een aanvraagheader. Uw clienttoepassingen kunnen bijvoorbeeld een aangepaste TenantID header toevoegen aan aanvragen. Als u deze methode wilt gebruiken, kunt u overwegen om te lezen uit de Context.Request.Headers verzameling.

  • Claims extraheren uit een JSON-webtoken (JWT). U hebt bijvoorbeeld een aangepaste tenantId claim in een JWT die is uitgegeven door uw id-provider. Als u deze methode wilt gebruiken, gebruikt u het beleid validate-jwt en stelt u de output-token-variable-name eigenschap in, zodat de beleidsdefinitie de waarden van het token kan lezen.

  • Zoek dynamisch tenant-id's op. U kunt communiceren met een externe database of service terwijl de aanvraag wordt verwerkt. Door deze aanpak te volgen, kunt u aangepaste tenanttoewijzingslogica maken om een logische tenant-id toe te wijzen aan een specifieke URL of om aanvullende informatie over een tenant te verkrijgen. Als u deze methode wilt gebruiken, gebruikt u het beleid voor verzenden-aanvragen .

    Deze benadering verhoogt waarschijnlijk de latentie van uw aanvragen. Om dit effect te beperken, is het een goed idee om caching te gebruiken om het aantal aanroepen naar de externe API te verminderen. U kunt het cache-store-waarde - en cache-zoekwaardebeleid gebruiken om een cachebenadering te implementeren. Zorg ervoor dat u uw cache ongeldig maakt met elke toegevoegde, verwijderde of verplaatste tenant die van invloed is op de back-endzoekactie.

Benoemde waarden

API Management ondersteunt benoemde waarden. Dit zijn aangepaste configuratie-instellingen die u in uw beleid kunt gebruiken. U kunt bijvoorbeeld een benoemde waarde gebruiken om de back-end-URL van een tenant op te slaan en diezelfde waarde vervolgens opnieuw te gebruiken op verschillende plaatsen binnen uw beleid. Als u de URL wilt bijwerken, kunt u deze op één plaats bijwerken.

Waarschuwing

In een multitenant-oplossing is het belangrijk om voorzichtig te zijn wanneer u de namen van uw benoemde waarden instelt. Als de instellingen per tenant verschillen, moet u de tenant-id in de naam opnemen. U kunt bijvoorbeeld een patroon gebruiken, bijvoorbeeld nadat tenantId-key:value u hebt bevestigd dat tenantId deze geschikt is voor de aanvraag.

Neem de id op om de kans te verminderen dat er per ongeluk wordt verwezen naar of wordt gemanipuleerd om te verwijzen naar de waarde van een andere tenant wanneer u een aanvraag voor een andere tenant verwerkt.

Binnenkomende aanvragen verifiëren

API-aanvragen die naar de API Management-gateway worden gedaan, moeten meestal worden geverifieerd. API Management biedt verschillende methoden voor het verifiëren van binnenkomende aanvragen voor de gateway, waaronder OAuth 2.0- en clientcertificaten. Houd rekening met de typen referenties die u moet ondersteunen en waar ze moeten worden gevalideerd. Denk bijvoorbeeld na of de validatie moet plaatsvinden in API Management, in uw back-endtoepassingen of op beide locaties.

Zie Verificatie en autorisatie voor API's in Azure API Management voor meer informatie.

Notitie

Als u een abonnementssleutel of API-sleutel gebruikt, is het een goed idee om ook een andere verificatiemethode te gebruiken.

Een abonnementssleutel alleen is geen sterke vorm van verificatie, maar het is handig voor andere scenario's, zoals voor het bijhouden van het API-gebruik van een afzonderlijke tenant.

Route naar tenantspecifieke back-ends

Wanneer u API Management als een gedeeld onderdeel gebruikt, moet u mogelijk binnenkomende API-aanvragen routeren naar verschillende tenantspecifieke back-ends. Deze back-ends bevinden zich mogelijk in verschillende implementatiestempels of zijn mogelijk verschillende toepassingen binnen één stempel. Als u de routering in een beleidsdefinitie wilt aanpassen, gebruikt u het set-backend-servicebeleid . U moet de nieuwe basis-URL opgeven waarnaar de aanvraag moet worden omgeleid.

Reacties of andere gegevens in de cache opslaan

API Management heeft een krachtige cachefunctie die u kunt gebruiken om volledige HTTP-antwoorden of andere gegevens in de cache op te cachen. U kunt bijvoorbeeld de cache voor tenanttoewijzingen gebruiken als u aangepaste logica gebruikt of als u de toewijzing van een externe service opzoekt.

Gebruik het cache-store-waarde - en cache-zoekwaardebeleid om een cachebenadering te implementeren.

Waarschuwing

In een multitenant-oplossing is het belangrijk om voorzichtig te zijn bij het instellen van uw cachesleutels. Als de gegevens in de cache kunnen variëren tussen tenants, moet u ervoor zorgen dat u de tenant-id in de cachesleutel opneemt.

Neem de id op om de kans te verminderen dat per ongeluk wordt verwezen naar een verwijzing naar de waarde van een andere tenant wanneer u een aanvraag voor een andere tenant verwerkt.

Aangepaste domeinen

Gebruik API Management om uw eigen aangepaste domeinen te configureren voor de API-gateway en de ontwikkelaarsportal. In sommige lagen kunt u jokertekendomeinen of meerdere FQDN's (Fully Qualified Domain Names) configureren.

U kunt API Management ook samen met een service zoals Azure Front Door gebruiken. In dit soort configuratie verwerkt Azure Front Door vaak aangepaste domeinen en TLS-certificaten (Transport Layer Security) en communiceert met API Management met behulp van één domeinnaam. Als de oorspronkelijke URL van de client tenantgegevens bevat die u moet verzenden naar het API Management-exemplaar voor latere verwerking, kunt u overwegen om de X-Forwarded-Host aanvraagheader te gebruiken of Azure Front Door-regels te gebruiken om de informatie als een HTTP-header door te geven.

Frequentielimieten

Het is gebruikelijk om quota of frequentielimieten toe te passen in een multitenant-oplossing. Frequentielimieten kunnen u helpen het probleem met lawaaierige buren te beperken. U kunt ook frequentielimieten gebruiken om de kwaliteit van de service af te dwingen en onderscheid te maken tussen verschillende prijscategorieën.

Gebruik API Management om tenantspecifieke frequentielimieten af te dwingen. Als u tenantspecifieke abonnementen gebruikt, kunt u overwegen het quotumbeleid te gebruiken om een quotum voor elk abonnement af te dwingen. U kunt ook het quota-by-key-beleid gebruiken om quota af te dwingen met behulp van een andere frequentielimietsleutel, zoals een tenant-id die u hebt verkregen via de aanvraag-URL of een JWT.

Inkomsten genereren

De API Management-documentatie biedt uitgebreide richtlijnen voor het genereren van inkomsten uit API's, waaronder een voorbeeldimplementatie. De methoden voor het genereren van inkomsten combineren veel van de functies van API Management, zodat ontwikkelaars een API kunnen publiceren, abonnementen kunnen beheren en kosten kunnen betalen op basis van verschillende gebruiksmodellen.

Capaciteitsbeheer

Een API Management-exemplaar ondersteunt een bepaalde hoeveelheid capaciteit, die de resources vertegenwoordigt die beschikbaar zijn om uw aanvragen te verwerken. Wanneer u complexe beleidsregels gebruikt of meer API's implementeert op het exemplaar, verbruikt u meer capaciteit. U kunt de capaciteit van een exemplaar op verschillende manieren beheren, bijvoorbeeld door meer eenheden aan te schaffen. U kunt de capaciteit van uw exemplaar ook dynamisch schalen.

Sommige multitenant-exemplaren verbruiken mogelijk meer capaciteit dan exemplaren met één tenant, bijvoorbeeld als u veel beleidsregels gebruikt voor het routeren van aanvragen naar verschillende tenantback-ends. Overweeg capaciteitsplanning zorgvuldig en plan om de capaciteit van uw exemplaar te schalen als u ziet dat uw gebruik toeneemt. U moet ook de prestaties van uw oplossing testen om inzicht te hebben in uw capaciteitsbehoeften van tevoren.

Zie Een Azure API Management-exemplaar upgraden en schalen voor meer informatie over het schalen van API Management.

Implementaties met meerdere regio's

API Management ondersteunt implementaties met meerdere regio's, wat betekent dat u één logische API Management-resource in meerdere Azure-regio's kunt implementeren zonder dat u de configuratie hoeft te repliceren naar afzonderlijke resources. Deze mogelijkheid is vooral handig wanneer u uw oplossing wereldwijd distribueert of repliceert. U kunt effectief een reeks API Management-exemplaren implementeren in meerdere regio's, waardoor aanvragen met lage latentie kunnen worden verwerkt en als één logisch exemplaar kunnen worden beheerd.

Als u echter volledig geïsoleerde API Management-exemplaren nodig hebt, kunt u er ook voor kiezen om onafhankelijke API Management-resources in verschillende regio's te implementeren. Deze benadering scheidt het beheervlak voor elk API Management-exemplaar.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Andere inzender:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Bekijk de architectuurbenaderingen voor integratie in multitenant-oplossingen.