Översikt över gateway med egen värd
Den här artikeln förklarar hur en gateway med egen värd i Azure API Management möjliggör API-hantering för hybrider och flera moln, presenterar dess avancerade arkitektur och visar dess funktioner.
API-hantering för hybrider och flera moln
Gatewayfunktionen med egen värd utökar API Management-stöd för hybridmiljöer och miljöer med flera moln och gör det möjligt för organisationer att effektivt och säkert hantera API:er som finns lokalt och i moln från en enda API Management-tjänst i Azure.
Med den egen värdbaserade gatewayen har kunderna flexibiliteten att distribuera en containerversion av API Management-gatewaykomponenten till samma miljöer där de är värdar för sina API:er. Alla gatewayer med egen värd hanteras från den API Management-tjänst som de är federerade med, vilket ger kunderna synlighet och enhetlig hantering över alla interna och externa API:er. Genom att placera gatewayerna nära API:erna kan kunderna optimera API-trafikflöden och uppfylla säkerhets- och efterlevnadskrav.
Varje API Management-tjänst består av följande viktiga komponenter:
- Hanteringsplanet exponeras som ett API och används för att konfigurera tjänsten via Azure Portal, PowerShell och andra mekanismer som stöds.
- Gateway (eller dataplanet) ansvarar för proxying av API-begäranden, tillämpning av principer och insamling av telemetri
- Utvecklarportalen används av utvecklare för att identifiera, lära sig och publicera för att använda API:erna
Som standard distribueras alla dessa komponenter i Azure, vilket gör att all API-trafik (visas som svarta pilar på bilden nedan) flödar genom Azure oavsett var backends som implementerar API:erna finns. Den här modellens enkelhet i drift sker på bekostnad av längre svarstider, efterlevnadsproblem och i vissa fall ytterligare avgifter för dataöverföring.

Genom att distribuera lokala gatewayer i samma miljöer där api-implementeringarna för backend-API:et finns kan API-trafiken flöda direkt till backend-API:erna, vilket förbättrar svarstiden, optimerar kostnaderna för dataöverföring och möjliggör efterlevnad samtidigt som fördelarna med en enda hanterings-, observerbarhets- och identifieringspunkt för alla API:er i organisationen bibehålls, oavsett var implementeringarna finns.

Paketering och funktioner
Den lokala gatewayen är en containeriserad, funktionellt motsvarande version av den hanterade gatewayen som distribueras till Azure som en del av varje API Management tjänst. Gatewayen med egen värd är tillgänglig som en Linux-baserad Docker-container från Microsoft Container Registry. Den kan distribueras till Docker, Kubernetes eller någon annan containerorkestreringslösning som körs på ett serverkluster lokalt, i molninfrastrukturen eller i utvärderings- och utvecklingssyfte på en personlig dator. Du kan också distribuera gatewayen med egen värd som ett klustertillägg till ett Azure Arc kubernetes-kluster.
Följande funktioner i de hanterade gatewayerna är inte tillgängliga i gatewayer med egen värd:
- Azure Monitor-loggar
- Överordnad (backend-sida) TLS-version och chifferhantering
- Validering av server- och klientcertifikat med hjälp av CA-rotcertifikat som laddats upp API Management tjänsten. Du kan konfigurera anpassade certifikatutfärdare för gatewayer med egen värd och verifieringsprinciper för klientcertifikat för att tillämpa dem.
- Integrering med Service Fabric
- Återupptagande av TLS-session
- Omförhandling av klientcertifikat. Det innebär att för att klientcertifikatautentisering ska fungera måste API-konsumenter presentera sina certifikat som en del av den första TLS-handskakningen. För att säkerställa det aktiverar du inställningen förhandla om klientcertifikat när du konfigurerar ett anpassat värdnamn för en gateway med egen värd.
- Inbyggd cache. Se det här dokumentet om du vill veta mer om hur du använder extern cache i gatewayer med egen värd.
Anslutningar till Azure SQL
Gatewayer med egen värd kräver utgående TCP/IP-anslutning till Azure på port 443. Varje gateway med egen värd måste vara associerad med en API Management och konfigureras via hanteringsplanet. Gateway med egen värd använder anslutning till Azure för:
- Rapportera statusen genom att skicka pulsslagsmeddelanden varje minut
- Regelbundet söka efter (var 10:e sekund) och tillämpa konfigurationsuppdateringar när de är tillgängliga
- Skicka begärandeloggar och mått till Azure Monitor om de har konfigurerats för att göra det
- Skicka händelser till Application Insights, om det är inställt på att göra det
När anslutningen till Azure går förlorad kan den lokala gatewayen inte ta emot konfigurationsuppdateringar, rapportera dess status eller ladda upp telemetri.
Den lokala gatewayen är utformad för att "misslyckas statiskt" och kan överleva tillfällig förlust av anslutning till Azure. Den kan distribueras med eller utan lokal konfigurationssäkerhetskopiering. I det första fallet sparar gatewayer med egen värd regelbundet en säkerhetskopia av den senaste nedladdade konfigurationen på en beständig volym som är kopplad till containern eller podden.
När konfigurationssäkerhetskopiering stängs av och anslutningen till Azure avbryts:
- Om du kör gatewayer med egen värd fortsätter funktionen att fungera med en minnes minneskopia av konfigurationen
- Stoppade gatewayer med egen värd kan inte starta
När konfigurationssäkerhetskopiering är aktiverat och anslutningen till Azure avbryts:
- Om du kör gatewayer med egen värd fortsätter funktionen att fungera med en minnes minneskopia av konfigurationen
- Stoppade gatewayer med egen värd kan börja använda en säkerhetskopia av konfigurationen
När anslutningen återställs återansluter varje gateway med egen värd som påverkas av avbrottet automatiskt med den associerade API Management-tjänsten och laddar ned alla konfigurationsuppdateringar som inträffade när gatewayen var "offline".