Dela via

Metodtips för arkitektur för Azure API Management

Azure API Management är en hanteringsplattform och gateway för API:er i alla miljöer, inklusive hybrid och multimoln. Som paaS-lösning (plattform som en tjänst) hjälper API Management till att stödja din arbetsbelastnings API-livscykel.

Den här artikeln förutsätter att du som arkitekt har granskat beslutsträdet för integrationstjänster och valt API Management som integrationstjänst för din arbetsbelastning. Vägledningen i den här artikeln innehåller arkitektoniska rekommendationer som mappas till principerna för Well-Architected Framework-pelarna.

Viktigt!

Använda den här guiden

Varje avsnitt har en checklista för design som presenterar arkitekturområden som är viktiga tillsammans med designstrategier som är lokaliserade till teknikomfånget.

Dessutom ingår rekommendationer för de teknikfunktioner som kan hjälpa till att materialisera dessa strategier. Rekommendationerna representerar inte en fullständig lista över alla konfigurationer som är tillgängliga för API Management eller serverdelens API-servrar för din arbetsbelastning. I stället listar de de viktigaste rekommendationerna som mappats till designperspektiven. Använd rekommendationerna för att skapa ditt konceptbevis eller för att optimera dina befintliga miljöer.

Grundläggande arkitektur som visar de viktigaste rekommendationerna: API Management-arkitektur för landningszoner.

Teknikomfång

Den här granskningen fokuserar på de relaterade besluten för följande Azure-resurs:

  • Azure API Management

Omfånget för den här guiden är API Management-tjänsten, främst gatewaykomponenten (dataplanet), som proxyför API-begäranden från klientprogram till back-end-API:er som finns på olika plattformar eller över olika platsers gränser. Arbetsbelastningens arkitektur bör ta hänsyn till API Management-kontrollplanet och relaterade komponenter, till exempel klientprogram som har åtkomst till gatewayen och de serverdels-API:er som bearbetar dirigerade begäranden. Den integrerar även stöd för Azure-tjänster, inklusive nätverk, övervakning, identitetshantering och andra funktioner.

Den här guiden omfattar inte Azure API Center. Den tar upp ämnen på API-nivå eftersom de relaterar till API Management i stället för att ge ett väldesignat perspektiv på API-designöverväganden.

Anmärkning

Alla rekommendationer gäller inte för alla tjänstnivåer i API Management. Många rekommendationer i den här guiden fokuserar på nivåerna Standard v2 och klassiska Premium i API Management, som är de rekommenderade produktionsnivåerna för de flesta företagsarbetsbelastningar.

Viktigt!

Premium v2-nivån med företagsfunktioner finns i förhandsversion. För att avgöra om din design ska förlita sig på funktioner för tidig åtkomst eller allmänt tillgängliga funktioner utvärderar du tidslinjerna för design och implementering i förhållande till den tillgängliga informationen om Premium v2:s lanserings- och migreringsvägar.

Tillförlitlighet

Syftet med grundpelarna för tillförlitlighet är att tillhandahålla fortsatt funktionalitet genom att bygga upp tillräckligt med motståndskraft och möjlighet att snabbt återhämta sig från fel.

Principer för tillförlitlighetsdesign tillhandahålla en övergripande designstrategi som tillämpas för enskilda komponenter, systemflöden och systemet som helhet.

Checklista för design

Påbörja din designstrategi baserat på checklistan för designgranskning för tillförlitlighet. Fastställ dess relevans för dina affärskrav samtidigt som du tänker på nivåerna och funktionerna i API Management och dess beroenden. Utöka strategin till att omfatta fler metoder efter behov.

  • Utvärdera gatewayfunktioner för tillförlitlighet och redundans: Fastställa den API Management-nivå och de funktioner som behövs för att uppfylla arbetsbelastningens tillförlitlighetskrav för varje miljö.

    Utvärdera funktioner för gatewayredundans, inklusive tillgänglighetszoner, flera gatewayenheter, flera regioner och arbetsytor. Alla dessa funktioner stöds på Premium-nivån. Nivån Utvecklare, som inte innehåller ett serviceavtal (SLA), är inte lämplig för produktionsarbetsbelastningar. Överväg nackdelarna med att införa funktioner som extern cachelagring som kan introducera potentiella fel- och prestandaflaskhalsar.

  • Granska observerbarhetsfunktioner: Överväg tjänstens observerbarhetsfunktioner, inklusive Azure Monitor-loggar och -mätvärden, Application Insights, inbyggd analys och inbyggd diagnostik. Använd dessa funktioner för att övervaka tillförlitlighetssignalerna för din arbetsbelastning.

    Överväg till exempel att använda Azure Monitor-aviseringar för att meddela dig om potentiella problem med API Management-gatewayen eller dess beroenden.

  • Granska skalningsstrategier: Definiera kriterier för att skala ut gatewayen genom att lägga till enheter för att upprätthålla tjänstens tillförlitlighet. Fundera på om du vill skala baserat på begäranden, undantag eller båda. Utvärdera effekten av att skala gatewaykomponenten på andra komponenter i arbetsbelastningen. Till exempel dess effekt på nätverksadressutrymmet och skalningsfunktionerna i back-enddelarna.

  • Isolera kritiska arbetsbelastningar: Kontrollera om beräkningsisolering krävs för att uppfylla arbetsbelastningskrav, till exempel datasuveränitet eller prestandaoptimering, i dina API:er. Använd dedikerade gatewayer för kritiska API:er och delade gatewayer för mindre kritiska API:er.

    Välj en isoleringsmetod, som att använda en dedikerad arbetsplatsgateway eller en separat API Management-instans. För flera användningstillfällen, som en del av dina säkra distributionsmetoder, håll miljöerna synkroniserade.

  • Justering av servicenivåmål (SLO): Ta hänsyn till gatewayens SLA-omfång när du ställer in arbetsbelastningens SLO:n. Tjänsten tillhandahåller ett eget serviceavtal, men du måste också ta hänsyn till den förväntade tillförlitligheten för andra arbetsbelastningskomponenter, till exempel API-serverdelarna.

  • Åtgärda backend-fel: Planera för både förväntade och oväntade backend-fel. Testa klientupplevelser i dessa scenarier. Utvärdera gatewayprinciper för att förbättra återhämtning och förbättra klientupplevelsen. Fokusera på kvoter, hastighetsbegränsningar, återförsöksprinciper, backend-kretsbrytare, belastningsutjämning och undantagshantering enligt dina API-specifikationer.

  • Definiera teststrategier: Använd en testlösning som Azure Load Testing inifrån nätverket för att återspegla faktiska produktionsarbetsbelastningar. Förlita dig inte på publicerat dataflöde eller andra uppskattningar som kanske inte gäller för din arbetsbelastning.

  • Planera för haveriberedskap (DR): Granska alternativen för att säkerhetskopiera och återställa gatewayinfrastrukturen och API:erna. Inbyggda funktioner för säkerhetskopiering och återställning kan vara användbara i vissa scenarier. Men kundhanterade alternativ som APIOps-verktyg och IaC-lösningar (infrastruktur som kod) kan också övervägas. Utveckla strategier för att underhålla andra systemdata, inklusive användarprenumerationer.

Rekommendationer

Dessa tillförlitlighetsrekommendationer kan gälla antingen för själva tjänsten eller för den trafik som flödar via API:er och deras principer. (Tjänsten) eller (API)-designern anger om en rekommendation riktar sig mot tjänsten eller API:erna.

Rekommendation Förmån
(Tjänst) Aktivera zonredundans på Premium-nivån och ha minst tre distribuerade enheter.

I den här konfigurationen är alla skalningsenheter i alla konfigurerade zoner aktiva och hanterar gatewaytrafik under normala driftsförhållanden.

I ett aktivt-aktivt scenario planerar du att stödja utskalning i återstående aktiva zoner för att hantera trafik som enheter som ursprungligen bearbetades i den felande zonen.		 Återhämtning säkerställs vid ett datacenterstopp i en region. Under en fullständig datacenterförlust fortsätter API-trafiken att flöda genom de återstående enheter som distribueras i andra zoner.
(Tjänst) Aktivera automatisk utskalning baserat på trafikkrav.

I distributioner i flera regioner har sekundära regioner inte automatiska utskalnings- eller inskalningsfunktioner. Du måste implementera en anpassad funktion eller logikapp som aktiveras som svar på Azure Monitor-måttaviseringar för att hantera enhetsjusteringar baserat på efterfrågan.		 Tillräckliga resurser garanteras för att möta efterfrågan från API-klienter, vilket förhindrar fel på grund av otillräcklig kapacitet.
(Tjänst) Använd en topologi för flera regioner för att stödja återhämtning mot ett fullständigt regionalt fel.

Den här metoden kräver att du samordnar med andra komponenter i arbetsbelastningen och förstår deras planerade redundansegenskaper. I alla aktiva-aktiva situationer bör du planera för att skala ut i de återstående aktiva regionerna för att hantera den trafik som den nu inaktiva regionen tidigare bearbetade.

Se till att topologin för flera regioner överensstämmer med alla efterlevnadskrav för data under överföring eller data i cachelagring.		 Robust återhämtning tillhandahålls under ett fullständigt regionalt avbrott, vilket hjälper till att säkerställa oavbruten API-trafik via enheter som distribueras i andra regioner.
(Tjänst) Isolera orelaterade API:er med arbetsytor eller ytterligare API Management-instanser. Effekten av fel som orsakas av felkonfigurationer eller avbrott minimeras genom att API:er separeras mellan olika beräkningsinstanser.
(API) Testa principuttryck och logik noggrant och para ihop dem med motståndskraftiga felhanteringstekniker i API-hanteringsprinciper. Klientupplevelsen förbättras genom att förhindra nya felkällor vid gatewayen och tillhandahålla en graciös nedgradering eller säker tillfällig felhantering.
(Tjänst och API) Samla in tillförlitlighetsmått.

Vanliga API-tillförlitlighetsmått är:

– Frekvensgränser och kvotöverträdelser.
– Felfrekvens baserat på HTTP-statuskoder.
– Begära frekvensavvikelser från baslinjen.
- Hälsokontroller, inklusive beroendehälsa.		 Avvikelser från förväntat beteende och tidigare baslinjer identifieras. Dessa uppgifter kan användas för att spåra rotorsaker såsom ändrat användarbeteende, störningar från rutinoperationer, oväntade effekter från nya funktioner eller oplanerade fel i arbetsbelastningen.
(Tjänst och API) Använd inbyggda funktioner för säkerhetskopiering och återställning som är inbyggda i API Management som en del av dr-spelboken. Komplettera dessa funktioner med dina IaC-artefakter och APIOps-processer för en robust lösning som kan hantera olika scenarier, inklusive återställningssamordning med beroenden och bakändar. Affärskontinuitet säkerställs genom att tillåta återställning av API-gatewayen och återställning av definierade API:er efter en fullständig systemförlust.

Säkerhet

Syftet med säkerhetspelaren är att tillhandahålla garantier för konfidentialitet, integritet och tillgänglighet för arbetet.

Principerna för säkerhetsdesign ger en övergripande designstrategi för att uppnå dessa mål genom att tillämpa metoder för den tekniska designen för att skydda API Management-gatewayen.

Anmärkning

Checklistan och rekommendationerna i det här avsnittet fokuserar på att skydda API Management-gatewayresursen. Säkringen av själva API:erna behandlas bara kort. Mer information finns i Minimera OWASP API-säkerhet topp 10 i API Management.

Checklista för design

Påbörja din designstrategi baserad på checklistan för designgranskning för säkerhet och identifiera sårbarheter och kontroller för att förbättra säkerhetsläget. Utöka strategin till att omfatta fler metoder efter behov.

  • Upprätta en säkerhetsbaslinje: Granska säkerhetsbaslinjen för API Management och införliva tillämpliga mått i baslinjen.

  • Skydda distributionspipelinen: Identifiera de enskilda och rollbaserade åtkomstkontrollroller som krävs för att hantera tjänstplattformen, ci/CD-pipelines (kontinuerlig integrering och kontinuerlig distribution) och enskilda API:er. Se till att endast behöriga personer har åtkomst till att hantera tjänsten och dess API:er.

  • Utvärdera datakänslighet: Om känsliga data flödar via API-begäranden och svar i API Management-gatewayen ska du se till att de skyddas under hela livscykeln. Ta hänsyn till olika dataskyddskrav i olika regioner. Utvärdera tjänstfunktioner som flera regioner för att isolera specifika data. Kontrollera också om din cachelagringsstrategi överensstämmer med dessa isoleringskrav.

  • Utveckla segmenteringsstrategier på delade gatewayer: Om API Management-instansen är värd för API:er för flera arbetsbelastningsteam använder du arbetsytor för att separera roller, nätverk och eventuellt gatewayer. Den här metoden säkerställer att varje team har lämplig åtkomst och kontroll över de API:er som de hanterar samtidigt som åtkomsten till API:erna för andra team begränsas.

  • Överväg nätverkskontroller: Identifiera krav och alternativ för att isolera eller filtrera inkommande och utgående gatewaytrafik med hjälp av virtuella nätverk. Avgör om åtkomsten till gatewayen kan begränsas via Azure Private Link eller om offentlig åtkomst till gatewayen är nödvändig. Utvärdera om arkitekturen ska innehålla en brandvägg för webbprogram, till exempel Azure Web Application Firewall i Azure Application Gateway eller Azure Front Door, för att uppnå nödvändig nätverksisolering och filtrera nätverkstrafik.

  • Överväg funktioner för API-autentisering och auktorisering: Utvärdera användningen av identitetsprovidrar som Microsoft Entra ID, som innehåller inbyggda grupper, eller Microsoft Entra External ID för att skärma gatewaybegäranden och aktivera OAuth-auktorisering för serverdels-API:er.

  • Kryptera nätverkstrafik: Identifiera de säkraste TLS-protokollversionerna (Transport Layer Security) och chiffer som dina arbetsbelastningar kan stödja. Kräver inte osäkra TLS-versioner. Använd TLS 1.3 när det stöds av dina klienter.

  • Utför hotmodellering på API Management och minska dess yta: Avgör om specifika API Management-komponenter, till exempel API för direkthantering eller offentlig åtkomst till utvecklarportalen, kan inaktiveras, begränsas eller tas bort.

  • Identifiera hemligheter som arbetsbelastningar kräver: Gatewayåtgärden kan kräva certifikat, API-nycklar eller andra hemliga värden. Granska kraven och funktionerna i Azure Key Vault för att lagra hemligheter och certifikat. Eller granska de inbyggda API Management-funktionerna, till exempel namngivna värden och hanterade certifikat.

Rekommendationer

Dessa säkerhetsrekommendationer kan gälla antingen för själva tjänsten eller för den trafik som flödar via API:er och deras principer. (Tjänsten) eller (API)-designern anger om en rekommendation riktar sig mot tjänsten eller API:erna.

Rekommendation Förmån
(Tjänst) Inaktivera API:et för direkthantering, som är inaktuellt. Använd Azure Resource Manager som kontrollplan. Tjänstens yta minskas genom att en åtkomstpunkt för kontrollplanen tas bort.
(Tjänst) Begränsa gatewayens exponering baserat uteslutande på var legitima klienter ansluter från.

– Använd virtuell nätverksinmatning utan en offentlig IP-adress när alla klienter kan dirigera trafik via ett virtuellt nätverk. Använd en nätverkssäkerhetsgrupp (NSG) för att ytterligare begränsa trafiken till endast de förväntade IP-adresserna för klientens ursprung.

– Använd integrering av virtuella nätverk med Application Gateway eller Azure Front Door om någon trafik måste komma från Internet. Konfigurera NSG:n så att den endast accepterar trafik från den enda startpunkten.		 Konfidentialiteten för nätverkstrafik skyddas genom att begränsa exponeringen för källans IP-adressintervall som förväntas innehålla legitima klienter. Dessa begränsningar blockerar åtkomst från källor som inte bör initiera legitim klientkommunikation. Att begränsa exponeringen för legitima trafikkällor förbättrar tjänstens konfidentialitet, integritet och tillgänglighet.
(Tjänst) Inaktivera utvecklarportalen om den inte används. Om portalen används inaktiverar du registreringsupplevelsen, inaktiverar anonym åtkomst och begränsar åtkomsten till endast betrodda nätverksplatser. Tjänstens yta och risken för felkonfiguration eller försummelse minskar.
(Tjänst) Ange uttryckligen de smalaste TLS-versioner, protokoll och chiffer som stöds för dina klienter och dina serverdelar. Versioner och chiffer som stöds reduceras till endast de alternativ som klienter och serverdelar stöder. Den här metoden hjälper till att säkerställa att anslutningar prioriterar anslutningar med högsta möjliga kvalitet för konfidentialitet.
(Tjänst) Lagra anpassade certifikat i Key Vault. Funktioner för certifikathantering tillhandahålls med hjälp av Key Vault, som stöder rutinmässig rotation och granskar åtkomst till certifikat.
(Tjänst) Serverdelar bör endast acceptera trafik från API-gatewayerna och bör blockera all annan trafik. Skadlig trafik hindras från att kringgå säkerhets- och andra korsdelningsproblem som avlastas till gatewayen.
(Tjänst) För API Management-instanser som är värdar för API:er för flera team eller segmenterade arbetsbelastningar måste du utforma en robust strategi för isolering av åtkomstkontroll. Använd arbetsytor eller implementera en rigorös APIOps-process för att uppnå den här strategin.

Teams får bara ha åtkomst till de API:er som de äger. De bör inte ha åtkomst till andra API:er som kan finnas i samma instans.		 Lateral förflyttning av angripare från en komprometterad API-uppsättning till andra orelaterade API:er minskas.
(API) Lagra hemligheter i Key Vault och exponera dem för principer via namngivna värden. Använd inte Key Vault för att lagra icke-sekreter. Använd namngivna värdeegenskaper direkt för dessa värden. Hemlig rotation uppmuntras via ett enda hanteringsplan i Key Vault, liknande den metod som används för certifikat. Den här processen säkerställer att API Management uppdateras i enlighet med detta. Namngivna värden säkerställer också en konsekvent upplevelse för principkonfiguration för både hemligheter och icke-säkerhetsobjekt. All hemlig åtkomst granskas också i Key Vault för att tillhandahålla en åtkomsthistorik. Att bara lagra hemligheter i Key Vault minimerar beroendet av Key Vault och omvandlar inte Key Vault till en programkonfigurationstjänst.
(API) Använd olika användartilldelade hanterade identiteter för olika API:er med hjälp av autentiseringshanterad identitetsprincip . Varje API har aktiverats för att ha en oberoende identitet, som stöder segmenteringsmål genom åtkomst med minst privilegier för varje API. Det ger också bättre granskningsbarhet i back-end-systemen.
(API) När det är möjligt måste klienter autentisera med OAuth 2.0-flöden i stället för att bara använda i förväg delade nycklar, inklusive prenumerationsnycklar eller klientcertifikat. Klientidentifieringen i granskningssyfte förbättras, nyckelrotationen elimineras och belastningen på klienter att skydda hemligheter minskar jämfört med att använda i förväg delade nycklar.
(API) Ignorera HTTP-huvuden från API-svar med hjälp av principen set-header som kan exponera implementeringsinformation. Kostnaden för angripare ökar genom att undanhålla implementeringsinformation.
(API) Använd inte API-spårning i produktion. Känsliga data hindras från att exponeras i begärandespårningar.
(API) Använd Defender för API:er. API-säkerhetsinsikter, rekommendationer och hotidentifiering tillhandahålls.
(API) Skydda serverdelsresurser genom att delegera nyckelsäkerhetskontroller i API-principen, till exempel validate-jwt, ip-filter, validate-headers, validate-content. Mängden icke-legitierad trafik som når serverdelstjänster minskas genom att utföra säkerhetskontroller på gatewayen. Den här avlastningsmetoden hjälper till att skydda resursernas integritet och tillgänglighet.
(API) Tillämpa SDL-metoder (Security Development Lifecycle) på API-principändringar på samma sätt som du tillämpar föreslagna ändringar i programkoden i din arbetsbelastning. Policyer tillämpas med en mycket privilegierad vy av API-trafiken. Att kringgå backend-skydd för konfidentialitet, integritet och tillgänglighet av en komprometterad API-gateway förhindras.
(Tjänst och API) Använd hanterade identiteter för tjänst- och API-beroenden. Anslutningar till Key Vault, Azure Event Hubs och andra beroenden, till exempel certifikat och namngivna värden, upprättas utan att förlita sig på i förväg delade hemligheter.
(Tjänst och API) Anslut till beroenden som Key Vault, Event Hubs och serverdelar via privata nätverksanslutningar när det är möjligt. Trafiksekretessen skyddas genom att inte exponera trafiken utanför det privata nätverket.
(Tjänst och API) Klienttrafik som riktar sig mot Internetexponerade API:er bör först passera genom en brandvägg för webbprogram, till exempel Brandvägg för webbprogram, innan den når API Management. Skydda även offentliga slutpunkter med hjälp av Azure DDoS Protection. Mängden icke-legitierad trafik som når gateway- och serverdelstjänsterna minskas genom att utföra säkerhetskontroller med en brandvägg för webbprogram. Genom att minska den här trafiken kan du skydda resursernas integritet och tillgänglighet.
(Tjänst och API) Utvärdera och aktivera alla Azure Policy Regulatory Compliance-kontroller som är relevanta för din arbetsbelastning. API Management-instansen överensstämmer med önskad hållning och förblir justerad när arbetsbelastningen utvecklas genom att ha säkerhetsprinciper på plats.

Kostnadsoptimering

Kostnadsoptimering fokuserar på identifiera utgiftsmönster, prioritera investeringar inom kritiska områden och optimera i andra för att uppfylla organisationens budget samtidigt som affärskraven uppfylls.

Designprinciperna för kostnadsoptimering ger en övergripande designstrategi för att uppnå dessa mål och göra avvägningar vid behov i den tekniska designen som rör API Management och dess miljö.

Checklista för design

  • Överväg kostnadsmodellen för API Management: Använd Priskalkylatorn för Azure med din organisations kontofördelar och kriterier för serviceavtal och skalbarhet för att utveckla korrekta kostnadsuppskattningar för att använda en API Management-tjänstnivå. Avgör om en återbetalningsmodell är nödvändig och bestäm hur den ska beräknas baserat på mått, taggar och token.

    Tjänstkostnadsmodellen påverkas främst av tjänstnivån, antalet enheter och antalet gatewayer. Utvärdera de extra kostnader som är associerade med att underhålla en reservenhet eller implementera en aktiv-passiv DR-konfiguration.

    Om du implementerar arbetsytor utvärderar du kostnaderna för att använda separata eller delade arbetsytegatewayer för att uppfylla de distinkta API-flödeskraven för olika API-team eller intressenter.

  • Beräkna skalningskostnader: Utveckla skalningsvillkor för att upprätthålla hög användning av gatewayresurserna. Utvärdera baslinjekostnader i en förproduktionsmiljö och utför testning för att modellera kostnader för utskalning baserat på förväntad arbetsbelastningstrafik.

    Utforma en åtgärdsstrategi för att förhindra missbruk av dina gatewayer, vilket kan orsaka dyr skalning utöver den predikaterade användningen.

  • Utvärdera tjänstkonfigurationer och principer: Funktioner som hastighetsbegränsning och samtidighet kan användas som tekniker för kostnadsoptimering för att hantera begärandebelastningar.

  • Optimera logikplacering: Utvärdera huruvida backendservrar är mer kostnadseffektiva för bearbetning av logik eller gatewayen ska hantera resursanvändningen. Gatewayen är en stark komponent för att implementera övergripande problem, men den kan utföra överdrivna funktioner i vissa scenarier. Identifiera resursintensiva bearbetningsuppgifter som utförs av gatewayen, och avgör om att flytta den logiken till back-end-servrar kan minska kostnaderna.

Rekommendationer

Dessa rekommendationer för kostnadsoptimering kan gälla antingen för själva tjänsten eller för den trafik som flödar via API:er och deras principer. (Tjänsten) eller (API)-designern anger om en rekommendation riktar sig mot tjänsten eller API:erna.

Rekommendation Förmån
(Tjänst) Använd den billigaste nivån som stöder arbetsbelastningens krav. Välj till exempel en Standard-nivå i stället för en Premium-nivå om din arbetsbelastning inte drar nytta av den tillagda funktionen på ett sätt som motiverar avkastningen på investeringen (ROI). Köp av oanvända eller underanvända funktioner undviks.
(Tjänst) Använd icke-produktionsnivåer eller tillfällig infrastruktur i lägre miljöer, till exempel utvecklingsmiljöer, konceptbevisdistributioner och inledande kostnadsmodelleringsaktiviteter. Resurskostnader sparas för miljöer som kan förbli användbara utan att helt spegla produktionens exakta konfigurations- eller drifttidskrav.
(Tjänst) Skala in när efterfrågan minskar. Konfigurera regler för automatisk skalning eller andra automatiserade processer för att minska enheter när gatewaykapaciteten sjunker under de definierade tröskelvärdena. Onödiga kostnader minskas genom matchning av kapacitet mot efterfrågan.
(Tjänst) Beräkna eventuella kostnadsfördelar med en federerad modell för API-hantering med hjälp av arbetsytor för att hantera API:er samtidigt som teamisolering tillhandahålls. Ytan för distribution och hantering minskas. Den här metoden syftar till att uppnå stordriftsfördelar från tids- och resursköp.
(Tjänst) Inaktivera arbetsytor när de inte längre används. Utgifter för oanvända resurser undviks.
(Tjänst) Använd den inbyggda cachen om din arbetsbelastnings cachelagrade data passar inom begränsningarna för den inbyggda cachen på din nivå. Kostnader för att köpa och underhålla en extern Redis-kompatibel cache undviks.
(Tjänst) Blockera skadlig trafik innan den når gatewayen med hjälp av nätverkskontroller, DDoS-skydd och brandväggar för webbprogram. Specifika nivåer av API Management debiteras baserat på antalet HTTP-begärandeåtgärder som gatewayen bearbetar. Därför kan oönskad trafik, till exempel robotgenererade begäranden, öka kostnaderna.

Utvärdera kostnaden för blockeringsmekanismen jämfört med den uppskattade kostnaden för minskning av HTTP-åtgärder för att utvärdera om den här metoden har en ROI.		 Avgifter som uppstår på grund av överdrivet skadliga eller störande HTTP-åtgärder mot gatewayen minskas.
(API) Optimera principuttrycken och bearbetningen och koden för att undvika överdriven användning av beräkningsresurser, till exempel processor, nätverk eller minne. Onödig distribution av fler enheter för att tillhandahålla kapacitet för icke-optimerade principimplementeringar och kod undviks.
(API) Utvärdera kostnaden för logikplacering mellan din gateway, din serverdel eller din offentliga startpunkt, till exempel Azure Front Door. Samma bearbetning kan ofta ske i något av dessa lager, var och en med sina egna kompromisser. Vissa lager kan dock ge kostnadsbesparingar tack vare tillgången på outnyttjad kapacitet. Cachelagringslogik som ursprungligen implementerades i serverdelen kan till exempel vara mer kostnadseffektivt implementerad på gatewaynivå med hjälp av den inbyggda cachen. Den här metoden minskar extra nätverks- och beräkningskostnader för backend-tjänster. Belastningen på högkostnadsresurser minimeras genom att funktioner placeras i det mest kostnadseffektiva lagret. Den här metoden flyttar arbetsbelastningar till lager som har extra kapacitet eller beräkningsalternativ med lägre kostnad.

Operativ skicklighet

Operational Excellence fokuserar främst på procedurer för utvecklingsmetoder, observerbarhet och versionshantering.

Designprinciperna för Operational Excellence tillhandahåller en övergripande designstrategi för att uppnå dessa mål när det gäller arbetsbelastningens driftskrav.

Starta din designstrategi baserat på checklistan för designgranskning för operational excellence för att definiera processer för observerbarhet, testning och distribution som rör API Management.

Checklista för design

  • Granska viktiga kunskaper och färdigheter som krävs för att driva tjänsten: Områden omfattar API-livscykel, DevOps-processer, nätverk och anslutning, övervakning och observerbarhet samt programvaruutveckling. Den här metoden omfattar principkonfiguration, enhetstestning och skapandet av CI/CD-pipelines.

  • Överväg dokumentationsbehov: Organisationer bör åta sig att dokumentera processer för konfiguration på tjänstnivå och API-nivå, livscykelåtgärder och de olika åtkomstmönstren för API-team.

  • Utvärdera standardverktyg för att stödja tjänståtgärder. Anta till exempel APIOps-metoder , till exempel GitOps och CI/CD, för att publicera API:er och hantera API-konfigurationer. Använd IaC-verktyg för konfigurationsändringar på servicenivå. Utforma återanvändbara artefakter som sömlöst kan övergå från utvecklingsmiljöer till produktion. Överväg att integrera en linter som Spectral, antingen självhanterad eller som integrerad i en Azure-tjänst som Azure API Center, i API-godkännandeprocesser.

  • Fastställa viktiga operativa mått och loggar: Granska måtten för produktion. Dessa mått omfattar gatewaykapacitet, CPU-användning, minnesanvändning och antalet begäranden. Granska loggar och observerbarhetsverktyg, till exempel Azure Monitor och Application Insights. Fastställ de strategier och verktyg som behövs för att effektivt hantera stora mängder observationsdata i produktionsmiljöer. Fastställ frågor som ger användbara insikter för både gatewayoperatorn och intressenterna som övervakar specifika värdbaserade API:er.

  • Planera regelbunden testning av produktionsarbetsbelastningar med hjälp av belastningstestning.

  • Identifiera operativa uppgifter utöver CI/CD- eller IaC-processer som kräver automatisering. Planera automatisering inom områden som källhantering av API Management-principer, Azure-principer och specifika konfigurationer av utvecklarportalen.

Rekommendationer

Dessa rekommendationer för driftskvalitet kan gälla antingen för själva tjänsten eller för den trafik som flödar via API:er och deras principer. (Tjänsten) eller (API)-designern anger om en rekommendation riktar sig mot tjänsten eller API:erna.

Rekommendation Förmån
(Tjänst) Konfigurera Azure-diagnostikens resursloggar för API Management. Plattformsgenererade loggar är tillgängliga för att fråga efter rutinåtgärder, behov på begäran eller brådskande scenarier, till exempel säkerhetsgranskningar.
(Tjänst) Använd Azure Event Grid för automatisering baserat på meningsfulla händelser som din API Management-instans genererar, till exempel APICreated. Automatiserings- eller meddelandeuppgifter kan byggas kring viktiga livscykelhändelser som inträffar i API Management-instansen.
(Tjänst) Undvik att använda en gateway med egen värd om en Microsoft-värdbaserad gatewayenhet fungerar i ditt scenario. Automatiserings- eller meddelandeuppgifter kan byggas kring viktiga livscykelhändelser som inträffar i API Management-instansen.
(Tjänst) Tillämpa alla inbyggda Azure Policy-principer som hjälper dig att styra din instans och begränsa den så att den överensstämmer med arbetsbelastningskraven, inklusive säkerhetskrav. Använd till exempel neka-principer för att förhindra att API:er exponeras via HTTP eller för att förhindra aktivering av REST-API:et för direkthantering. Använd granskningsprinciper om neka-principer inte är tillgängliga eller skapa anpassade neka-principer om det är viktigt för din arbetsbelastning. API Management-instansen överensstämmer med designen och förblir justerad när arbetsbelastningen utvecklas.
(Tjänst) Bekanta dig med funktionen Diagnostisera och lösa problem i Azure-portalen.

Använd bladet Nätverksstatus i portalen för att felsöka nätverksanslutningen.		 Användare av platstillförlitlighetstekniker kan identifiera och felsöka gatewayprestanda, tjänsttillgänglighet och nätverksanslutningsproblem i alla miljöer.
(API) Använd Event Hubs för att hantera logg- eller händelseströmmar från API-anrop som kräver reaktioner i nära realtid eller fönsteråtgärder med kort tidsram. Nästan realtidstillgänglighet för loggposter tillhandahålls. Den fördröjning av loggdatainmatning som inträffar när loggning till Azure Monitor i API:er undviks.
(API) Stöd för användning av API-spårning under utveckling för att hjälpa utvecklare att förstå sin principimplementering. Utvecklarproduktivitet optimeras genom att ge insikt i implementeringen av principer i ett API. Utan den här funktionen måste utvecklare införa hack i principimplementeringen för att få insikt.
(API) Definiera alltid backends med hjälp av backend-funktionen i API Management. Referera till dessa backend-tjänster med ID i policyn med hjälp av set-backend-service. Belastningsutjämning av serverdelar ska definieras som en serverdelspool. Serverdelsanslutningsändringar gäller för alla API:er som använder serverdelen utan att kräva uppdateringar av enskild principkod. Risken för felkonfigurationer eller förbisedda API-principändringar minskar och scenarier där flera API:er delar samma serverdel lämpar sig genom det här lagret av konfigurationsabstraktion.
(API) Utforma versionsmetoden för dina API:er så att de överensstämmer med API Managements versions- och revisionsfunktioner. Ta med den här metoden i dina API-distributionsåtgärder. En API-versionshanteringsstrategi som stöds direkt av API Management används för att dra nytta av inbyggda funktioner i stället för att skapa anpassade lösningar.
(Tjänst och API) Definiera en konsekvent och hållbar driftsprocess för att lägga till, ändra och ta bort API:er. Ta reda på om du vill hantera den här upplevelsen manuellt via portalen eller implementera den via en APIOps-process. Föredrar att använda en IaC-baserad metod i stället för en portalbaserad metod.

API Managements representation i Resource Manager-API:et består av många underordnade resurser, så det är viktigt att använda en metod i flera lager för IaC-baserad hantering av den här resurssamlingen.		 API-specifikationer och deras gatewayimplementeringar är integrerade i arbetsbelastningens ändringskontrollprocesser. Den här metoden förhindrar att ändringar i serverdels-API:er hanteras på ett annat sätt än hur de exponeras för API-klienter via gatewayen.

Prestandaeffektivitet

Prestandaeffektivitet handlar om upprätthålla användarupplevelsen även när belastningen ökar genom att hantera kapaciteten. Strategin omfattar skalning av resurser, identifiering och optimering av potentiella flaskhalsar och optimering för högsta prestanda.

Designprinciperna för prestandaeffektivitet tillhandahåller en designstrategi på hög nivå för att uppnå dessa kapacitetsmål med hänsyn till den förväntade användningen.

Starta din designstrategi baserat på checklistan för designgranskning för prestandaeffektivitet för att definiera en baslinje baserat på viktiga prestandaindikatorer för API Management.

Checklista för design

  • Definiera prestandamål: Viktiga mått för att utvärdera prestanda för API Management-gatewayen inkluderar kapacitetsmått, till exempel processor- och minnesanvändningsprocent för gatewayinfrastruktur, varaktighet för begäran och dataflöde för begäranden. Definiera prestandamål för varje region i distributioner med flera regioner. Kunden måste definiera lämpliga skalningströsklar baserat på trafikmönster, API-arbetsbelastningar och skalningstider.

  • Samla in prestandadata: Granska funktionerna i inbyggd analys, Azure Monitor-mått, Azure Monitor-loggar, Application Insights och Event Hubs för att samla in och analysera prestanda på olika detaljnivåer.

  • Läs om hur du identifierar problem med liveprestanda: Indikatorer för liveprestandaproblem är bland annat Tillgänglighet för Azure-tjänster, HTTP-svarsfel och fel som uppstår i avsnittet Diagnostisera och lösa problem i portalen. Felsöka prestanda- och tillgänglighetsproblem med hjälp av Application Insights, Kusto-frågor och rekommendationer från API Management Diagnostics i Azure-portalen.

  • Testprestanda: Testa prestanda under produktionsförhållanden med hjälp av belastningstestning.

  • Utvärdera närliggande tjänster som kan förbättra prestanda: Cachelagringsprinciper eller en extern cache kan förbättra prestanda för specifika API-åtgärder. Azure Front Door och Application Gateway är vanliga alternativ för TLS-avlastning.

  • Granska de dokumenterade gränserna och begränsningarna:API Management har begränsningar och begränsningar. Granska de dokumenterade begränsningarna och jämför dem med arbetsbelastningens krav för att se om du behöver utforma en lösning som undviker dessa begränsningar.

Rekommendationer

Dessa rekommendationer för prestandaeffektivitet kan gälla antingen för själva tjänsten eller för den trafik som flödar via API:er och deras principer. (Tjänsten) eller (API)-designern anger om en rekommendation riktar sig mot tjänsten eller API:erna.

Rekommendation Förmån
(Tjänst) Skala dynamiskt för att matcha efterfrågan. Konfigurera regler för automatisk skalning eller andra automatiserade processer för att justera gatewayenheter så att de matchar en målanvändningskapacitet. Elasticitet uppnås baserat på samtidig användning, vilket förhindrar resursutarmning av för närvarande distribuerade enheter eller överallokering av kapacitet.
(API) Minimera dyra bearbetningsuppgifter, till exempel att generera stora buffrade nyttolaststorlekar, genom att använda principen för valideringsinnehåll i stora begärandeorgan eller genom att upprätthålla ett stort antal aktiva WebSockets. Belastningen på skalningsenheter minskar, vilket gör att de kan bearbeta fler begäranden samtidigt innan de behöver skala ut.
(Tjänst och API) Samla in prestandamått.

Vanliga API-prestandamått är:

– Begär behandlingstid för själva gatewayen och för den fullständiga operationen.
– Användningsstatistik för gatewayenhetsresurser.
– Dataflödesmätningar som begäranden per sekund eller megabitar per sekund.
cacheträffsförhållande		 Faktiska prestanda mäts mot arbetsbelastningens mål.
(Tjänst och API) Definiera en samplingsprocent för Application Insights som ger tillräcklig synlighet utan att påverka prestanda. Behovet av observerbarhetsdata uppfylls utan att den övergripande prestandan påverkas.
(Tjänst och API) Utvärdera prestandapåverkan av logikplacering mellan din gateway, serverdelen eller din offentliga startpunkt, till exempel Azure Front Door. Samma bearbetningsuppgifter kan ofta utföras i något av dessa lager, med prestandaavvägningar och begränsningar i optimeringsmöjligheter för var och en. Om en uppgift, till exempel en API-hanterings-API-princip, ger för mycket svarstid bör du överväga om aktiviteten kan köras någon annanstans på ett mer optimerat sätt. Uppgifter som lägger till latens till API:er körs på beräkningsoptimerade resurser för att uppfylla arbetsbelastningskraven.

Azure-riktlinjer

Azure tillhandahåller en omfattande uppsättning inbyggda principer som rör API Management och dess beroenden. Några av föregående rekommendationer kan granskas via Azure Policy. Du kan till exempel kontrollera om:

  • Gatewayen är konfigurerad för zonredundans.
  • Rätt nätverkskontroller finns för API Management-gatewayen, till exempel distribution i ett virtuellt nätverk.
  • Tjänstkonfigurationsslutpunkterna är inte offentligt tillgängliga.
  • REST API:et för direkthantering är inaktiverat.

För en omfattande styrning, granska de inbyggda definitionerna för Azure Policy och andra policyer som kan påverka säkerheten i API Management-gatewayen.

Azure Advisor-rekommendationer

Azure Advisor är en anpassad molnkonsult som hjälper dig att följa metodtipsen för att optimera dina Azure-distributioner.

Mer information finns på sidan om Azure Advisor.

Advisor kan även visa andra rekommendationer i produktionssystemet, till exempel:

  • Misslyckande med att kräva långa JWT-nyckelstorlekar i validate-jwt-regeln.
  • Du använde en äldre Resource Manager API-version för att distribuera resursen.
  • API-nyckeltoken ligger nära deras förfallodatum.
  • Misslyckande i en certifikatrotationsoperation.

Avvägningar

Du kan behöva göra designavvägningar om du använder metoderna i checklistorna för pelare. Här är några exempel på fördelar och nackdelar.

Hög tillgänglighet genom redundans och isolering

  • Hög tillgänglighet. Att lägga till redundans i en arkitektur påverkar kostnaderna. Till exempel kanske etablering av minst tre enheter för att undvika zonindeliga avbrott kanske inte är ekonomiskt genomförbart för din arbetsbelastning. Kostnaderna ökar ytterligare med en arkitektur för flera regioner, som kräver minst sex enheter eller tre enheter per region. En installation i flera regioner lägger också till operativa kostnader för att samordna säkra utplaceringar, tillförlitlig skalning och redundanssamordning med backend-system.

  • Isolering. Att isolera arbetsbelastningar mellan arbetsytor eller API Management-instanser ökar driftskomplexiteten eftersom det omfattar hantering av ett system med flera klientorganisationer som har beräkningsisolering.

Skala för att matcha efterfrågan

  • När du automatiskt skalar ut för att möta efterfrågan från väluppfostrade klienter räknas dessa kostnader redan in i dina kostnadsmodeller. Men den här skalningsfunktionen gör det också möjligt för tjänsten att skala för att hantera trafik från olägenheter och skadlig trafik.

  • Att minimera oöndrad trafik medför kostnader. Om du lägger till tjänster som en brandvägg för webbprogram och DDoS-skydd ökar kostnaderna. Om du skalar din tjänst för att hantera trafik ökar kostnaderna på grund av tillagda enheter. Att ange övre skalningsgränser kan begränsa utgifterna, men kan leda till tillförlitlighetsproblem för legitima användare om skadlig eller skadlig trafik överbelastar ditt API.

Federerad kontra distribuerad metod

Ett grundläggande beslut i API Management är om du ska samlokalisera olika arbetsbelastningar i en enda API Management-instans eller isolera arbetsbelastningar över flera instanser i en helt autonom topologi.

API Management-arbetsytor möjliggör effektiv drift som en multitenant colokationsplattform för flera API-team. De nivåindelade prismodellerna är utformade för att tillåta att tjänstkostnader delas mellan alla klienter som använder gatewayerna. Men precis som alla samlokaliseringsplattformar kan avbrott eller felkonfigurationer leda till omfattande effekter på orelaterade arbetsbelastningar som delar samma infrastruktur.

En fullständigt distribuerad modell, där varje arbetsbelastningsteam hanterar sina egna instanser, introducerar duplicerande kostnader och redundans i rutinåtgärder. Det ger dock en inbyggd minskning av explosionsradie för tillförlitlighet, säkerhet och prestandarelaterade incidenter.

Nästa steg

API Management kombineras ofta med följande tjänster. Se till att granska deras tjänstguider eller produktdokumentation om din arbetsbelastning innehåller följande tjänster.

Följande artiklar visar några av rekommendationerna som beskrivs i den här artikeln.