I det här scenariot konsoliderar en organisation flera API:er med hjälp av Azure API Management som distribueras i ett virtuellt nätverk.
Arkitektur
Ladda ned en Visio-fil med den här arkitekturen.
Föregående diagram omfattar en fullständig livscykel för interna API:er som används av externa användare.
Dataflöde
Dataflödena enligt följande:
- Utvecklare checkar in kod på en GitHub-lagringsplats som är ansluten till en CI/CD-pipelineagent som är installerad på en virtuell Azure-dator.
- Agenten push-överför bygget till API-programmet som finns på ILB ASE.
- Azure API Management använder föregående API:er via HOST-huvuden som anges i API Management princip.
- API Management använder App Service-miljön DNS-namn för alla API:er.
- Application Gateway exponerar API Management utvecklar- och API-portalen.
- Azure Privat DNS används för att dirigera trafiken internt mellan ASE, API Management och Application Gateway.
- Externa användare använder den exponerade utvecklarportalen för att använda API:erna via Application Gateway offentliga IP-adress.
Komponenter
- Med Azure Virtual Network kan Azure-resurser kommunicera säkert med varandra, Internet och lokala nätverk.
- Med Azure Privat DNS kan domännamn matchas i ett virtuellt nätverk utan att du behöver lägga till en anpassad DNS-lösning.
- Azure API Management hjälper organisationer att publicera API:er till externa utvecklare, partner och interna utvecklare för att använda sina data och tjänster.
- Application Gateway är en lastbalanserare för webbtrafik som hjälper dig att hantera trafik till dina webbprogram.
- Intern Load Balancer App Service-miljön är en Azure App Service funktion som ger en helt isolerad och dedikerad miljö för säker körning av App Service appar i hög skala.
- Azure DevOps är en tjänst för att hantera utvecklingslivscykeln och innehåller funktioner för planering och projekthantering, kodhantering, kompilering och lansering.
- Application Insights är en utökningsbar APM-tjänst (Application Performance Management) för webbutvecklare på flera plattformar.
- Azure Cosmos DB är Microsofts globalt distribuerade databastjänst för flera modeller.
Alternativ
- I ett Azure Lift and Shift-scenario som distribueras till en Azure-Virtual Network kan serverdelsservrar åtgärdas direkt via privata IP-adresser.
- Om du använder lokala resurser kan API Management-instansen nå tillbaka till den interna tjänsten privat via en Azure VPN-gateway och EN VPN-anslutning för plats-till-plats eller ExpressRoute som gör ett azure-hybridscenario och ett lokalt scenario.
- Befintliga DNS-providers eller DNS-leverantörer med öppen källkod kan användas i stället för den Azure-baserade DNS-tjänsten.
- Interna API:er som distribueras utanför Azure kan fortfarande dra nytta av att exponera API:erna via API Management Service.
Scenarioinformation
I det här scenariot är en organisation värd för flera API:er med hjälp av Azure Application Service Environment (ILB ASE), och de vill konsolidera dessa API:er internt med hjälp av Azure API Management (APIM) som distribuerats i en Virtual Network. Den interna API Management-instansen kan också exponeras för externa användare för att möjliggöra användning av API:ernas fulla potential. Den här externa exponeringen kan uppnås med hjälp av Azure Application Gateway vidarebefordringsbegäranden till den interna API Management-tjänsten, som i sin tur förbrukar de API:er som distribueras i ASE.
- Webb-API:erna finns över säkra HTTPS-protokoll och kommer att använda ett TLS-certifikat.
- Den Application Gateway är också konfigurerad via port 443 för säkra och tillförlitliga utgående anrop.
- Tjänsten API Management är konfigurerad för att använda anpassade domäner med hjälp av TLS-certifikat.
- Granska den föreslagna nätverkskonfigurationen för App Service-miljöer
- Det måste finnas ett uttryckligt omnämnande om port 3443 som gör det möjligt för API Management att hantera via Azure Portal eller PowerShell.
- Använd principer i APIM för att lägga till ett HOST-huvud för DET API som finns i ASE. Detta säkerställer att ASE:s lastbalanserare vidarebefordrar begäran korrekt.
- API Management accepterar ASE:s DNS-post för alla appar som finns under App Service-miljöer. Lägg till en APIM-princip för att uttryckligen ange HOST-huvudet så att ASE-lastbalanseraren kan skilja mellan appar under App Service-miljön.
- Överväg att integrera med Azure Application Insights, som även visar mått via Azure Monitor för övervakning.
- Om du använder CI/CD-pipelines för att distribuera interna API:er bör du överväga att skapa en egen värdbaserad agent på en virtuell dator i Virtual Network.
Potentiella användningsfall
- Synkronisera kundadressinformation internt när kunden har gjort en ändring.
- Locka utvecklare till din plattform genom att exponera unika datatillgångar.
Överväganden
Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.
Tillförlitlighet
Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över grundpelare för tillförlitlighet."
Tillgänglighet
Du kan distribuera Azure API Management-tjänsten som en distribution i flera regioner för högre tillgänglighet och för att minska svarstiderna. Den här funktionen är endast tillgänglig i Premium-läge. Den API Management tjänsten i det här specifika scenariot använder API:er från App Service-miljöer. Du kan också använda APIM för API:er som finns i den interna lokala infrastrukturen.
App Service Miljöer kan använda Traffic Manager-profiler för att distribuera trafiken i App Service miljöer för högre skala och tillgänglighet.
Återhämtning
Även om det här exempelscenariot handlar mer om konfiguration bör API:erna som finns på App Service Environments vara tillräckligt motståndskraftiga för att hantera fel i begäranden, som så småningom hanteras av API Management-tjänsten och Application Gateway. Överväg mönster för återförsök och kretsbrytare i API-designen. Allmän vägledning om hur du utformar motståndskraftiga lösningar finns i Designa elastiska program för Azure.
Säkerhet
Säkerhet ger garantier mot avsiktliga attacker och missbruk av värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.
Eftersom det föregående exempelscenariot finns helt i ett internt nätverk distribueras redan API Management och ASE i en skyddad infrastruktur (Azure VNet). Du kan integrera Application Gateways med Microsoft Defender för molnet för att tillhandahålla ett sömlöst sätt att förhindra, identifiera och reagera på hot mot miljön. Allmän vägledning om hur du utformar säkra lösningar finns i Dokumentation om Azure-säkerhet.
Kostnadsoptimering
Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra driftseffektiviteten. Mer information finns i Översikt över grundpelare för kostnadsoptimering.
API Management finns på fyra nivåer: utvecklare, basic, standard och premium. Du hittar detaljerad vägledning om skillnaden på dessa nivåer i prisvägledningen för Azure API Management här.
Kunder kan skala API Management genom att lägga till och ta bort enheter. Varje enhet har kapacitet som är beroende av dess nivå.
Anteckning
Du kan använda developer-nivån för utvärdering av API Management funktioner. Du bör inte använda developer-nivån för produktion.
Om du vill visa beräknade kostnader och anpassa efter dina distributionsbehov kan du ändra antalet skalningsenheter och App Service instanser i Priskalkylatorn för Azure.
På samma sätt hittar du prisvägledningen för App Service Environments.
Du kan konfigurera Application Gateway prissättning beroende på vilken nivå och vilka resurser som krävs.
Prestandaeffektivitet
Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.
Skalbarhet
Du kan skala ut API Management instanser beroende på ett antal faktorer, till exempel antal och frekvens för samtidiga anslutningar, typ och antal konfigurerade principer, storlekar för förfrågningar och svar samt svarsfördröjningar för API:erna. Alternativen för utskalning av instanser är tillgängliga på nivåerna Basic, Standard och Premium, men är bundna av en övre skalningsgräns på nivåerna Basic och Standard. Instanserna kallas enheter och kan skalas upp till högst två enheter på Basic-nivån, fyra enheter på standardnivån och valfritt antal enheter på Premium-nivån. Alternativ för automatisk skalning är också tillgängliga för att aktivera utskalning baserat på regler.
App Service Miljöer är utformade för skalning med gränser baserat på prisnivån. Du kan konfigurera appar som finns under App Service-miljöer för att skala ut (antal instanser) eller skala upp (instansstorlek) beroende på programmets krav.
Azure Application Gateway automatisk skalning är tillgängligt som en del av zonredundant SKU:n i alla globala Azure-regioner. Se funktionen för offentlig förhandsversion om automatisk skalning av App Gateway.
Distribuera det här scenariot
Förhandskrav och antaganden
- Du måste köpa ett anpassat domännamn.
- Du behöver ett TLS-certifikat (vi använde ett jokerteckencertifikat från Azure Certificates Service) för att använda ett för alla våra anpassade domäner. Du kan också skaffa ett självsignerat certifikat för Dev Test-scenarier.
- Den här specifika distributionen använder domännamnet contoso.org och ett jokertecken-TLS-certifikat för domänen.
- Distributionen använder resursnamnen och adressutrymmena som nämns i avsnittet Distribution. Du kan konfigurera resursnamn och adressutrymmen.
Distribuera och sätta ihop delarna
Du måste ytterligare konfigurera de komponenter som distribueras med hjälp av föregående Resource Manager mall enligt följande:
VNet med följande konfigurationer:
- Namn:
ase-internal-vnet
- Adressutrymme för VNet: 10.0.0.0/16
- Fyra undernät
backendSubnet
för DNS-tjänsten: 10.0.0.0/24apimsubnet
för intern API Management service: 10.0.1.0/28asesubnet
för ILB ASE: 10.0.2.0/24- VMSubnet for Test VMs and Internal DevOps Hosted Agent VM: 10.0.3.0/24
- Namn:
Privat DNS (offentlig förhandsversion) eftersom det virtuella nätverket måste vara tomt för att lägga till en DNS-tjänst.
- Mer information finns i riktlinjerna för distribution
App Service-miljön med alternativet Intern Load Balancer (ILB):
aseinternal
(DNS:aseinternal.contoso.org
). När distributionen är klar laddar du upp jokerteckencertifikatet för ILBApp Service planera med ASE som plats
En API-app (App Services för enkelhetens skull) –
srasprest
(URL:https://srasprest.contoso.org
) – ASP.NET MVC-baserat webb-API. Efter distributionen konfigurerar du:- Webbapp för att använda TLS-certifikatet
- Application Insights till föregående appar: api-insights
- Skapa en Azure Cosmos DB-tjänst för webb-API:er som finns internt i VNet:
noderestapidb
- Skapa DNS-poster i Privat DNS zon som skapats
- Du kan använda Azure Pipelines för att konfigurera agenterna på Virtual Machines för att distribuera koden för webbappen i det interna nätverket
- Om du vill testa API-appen internt skapar du en virtuell testdator i VNet-undernätet
Skapa API Management tjänst:
apim-internal
Konfigurera tjänsten för att ansluta till ett internt virtuellt nätverk i undernätet:
apimsubnet
. När distributionen är klar utför du följande ytterligare steg:- Konfigurera anpassade domäner för APIM-tjänster med hjälp av TLS
- API-portalen (api.contoso.org)
- Dev Portal (portal.contoso.org)
- I avsnittet API:er konfigurerar du ASE-appar med HJÄLP av ASE:s DNS-namn som lagts till Princip för VÄRDhuvud för webbappen
- Använd den tidigare skapade virtuella testdatorn för att testa den interna API Management-tjänsten på Virtual Network
Anteckning
Det går inte att testa APIM-API:erna från Azure Portal eftersom api.contoso.org inte kan lösas offentligt.*
- Konfigurera anpassade domäner för APIM-tjänster med hjälp av TLS
Konfigurera Application Gateway (WAF V1) för åtkomst till API-tjänsten: apim-gateway på port 80. Lägg till TLS-certifikat i Application Gateway och motsvarande hälsoavsökningar och http-inställningar. Konfigurera även regler och lyssnare för att använda TLS-certifikatet.
När föregående steg har slutförts konfigurerar du DNS-posterna i webbregistratorns CNAME-poster för api.contoso.org och portal.contoso.org med Application Gateway offentliga DNS-namn: ase-appgtwy.westus.cloudapp.azure.com
. Kontrollera att du kan nå Dev-portalen från offentlig och att du kan testa APIM-tjänst-API:erna med hjälp av Azure Portal.
Anteckning
Det är inte bra att använda samma URL för interna och externa slutpunkter för APIM-tjänsterna (men i den här demonstrationen är båda URL:erna desamma). Om du väljer att ha olika URL:er för interna och externa slutpunkter kan du använda Application Gateway WAF v2, som stöder http-omdirigering och mycket mer.
Deltagare
Den här artikeln underhålls av Microsoft. Den skrevs ursprungligen av följande deltagare.
Huvudförfattare:
- Srikant Sarwa | Senior kundtekniker
Andra deltagare:
- Shawn Kupfer | Teknisk författare
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.
Nästa steg
- Självstudie: Importera och publicera ditt första API
- Självstudie: Skapa och publicera en produkt
- Självstudie: Publicera flera versioner av ditt API