Azure Functions Flex konsumtionsplan-värdtjänst

Flex Consumption är en Linux-baserad Azure Functions-värdplan som bygger på en serverlös faktureringsmodell där du betalar för det du använder. Det ger dig mer flexibilitet och anpassningsbarhet genom att introducera privata nätverk, val av minnesstorlek för instanser och snabba eller stora utskalningsfunktioner medan du fortfarande använder en serverlös modell. Flex Consumption är den rekommenderade serverlösa värdplanen för Azure Functions.

Du kan granska fullständiga exempel som innehåller Flex Consumption-planen på exempellagringsplatsen för Flex Consumption-planen.

Benefits

Flex Consumption-planen bygger på styrkan i den serverlösa förbrukningsplanen, som omfattar dynamisk skalning och körningsbaserad fakturering. Genom att använda Flex Consumption får du även följande extra funktioner:

• Kortare starttider för kallstart: Aktivera alltid redo instanser för att uppnå snabbare kallstartstider jämfört med förbrukningsplanen.
• Stöd för virtuellt nätverk: Integrering av virtuellt nätverk gör att din serverlösa app kan köras i ett virtuellt nätverk.
• End-to-end TLS-kryptering (förhandsgranskning): Kryptera trafiken mellan plattformens frontends och de arbetare som kör dina funktioner. För mer information, se Konfigurera end-to-end TLS-kryptering.
• Skalning per funktion: Varje funktion i din app skalas separat baserat på dess arbetsbelastning, vilket kan leda till effektivare resursallokering.
• Förbättrad samtidighetshantering: Bättre hantering av samtidiga körningar med konfigurerbara samtidighetsinställningar per funktion.
• Flexibel minneskonfiguration: Flex Consumption erbjuder storleksalternativ för flera instansstorlekar , så att du kan optimera för dina specifika arbetsbelastningskrav.
• Azure Files-lagringsmonteringar: Montera Azure Files-resurser direkt till funktionsappen så att koden kan komma åt stora binärfiler, ML-modeller och delade data utan att paketera dem i distributionen.

Den här tabellen hjälper dig att direkt jämföra funktionerna i Flex Consumption med värdplanen för förbrukning.

En fullständig jämförelse av Flex Consumption-planen mot förbrukningsplanen och alla andra plan- och värdtyper finns i funktionsskala och värdalternativ.

Integrering av virtuellt nätverk

Flex Consumption utökar de traditionella fördelarna med förbrukningsplanen genom att lägga till stöd för integrering av virtuella nätverk. När dina appar körs i en Flex Consumption-plan kan de ansluta till andra Azure-tjänster som skyddas i ett virtuellt nätverk. Du drar fortfarande nytta av serverlös fakturering och skalning, tillsammans med skalnings- och dataflödesfördelarna med Flex Consumption-planen. Mer information finns i Konfigurera integrering av virtuella nätverk.

Instansstorlekar

När du skapar din funktionsapp i en Flex Consumption-plan kan du välja minnesstorleken för de instanser som appen körs på. Se Fakturering för att lära dig hur minnesstorlekar för instanser påverkar kostnaderna för din funktionsapp.

För närvarande erbjuder Flex Consumption följande alternativ för instansstorlek:

När du bestämmer vilken minnesstorlek för instansen som ska användas med dina appar bör du tänka på följande faktorer:

• Använd minnesstorleken på 2 048 MB som standard för de flesta scenarier. Använd minnesstorlekarna 512 MB och 4 096 MB för scenarier som bäst passar programmets krav på samtidighet eller bearbetningskraft. Mer information finns i Konfigurera instansminne.
• Du kan ändra minnesstorleken för instansen när som helst. Mer information finns i Konfigurera instansminne.
• Din funktionskod och Functions-värd delar instansresurser.
• Ju större minnesstorlek för instansen, desto mer kan varje instans hantera samtidiga körningar eller mer intensiva CPU- eller minnesarbetsbelastningar. Specifika skalningsbeslut är arbetsbelastningsspecifika.
• Standardkonkurrensen för HTTP-utlösare beror på instansens minnesstorlek. Mer information finns i HTTP-utlösarens samtidighet.
• Tillgängliga processorer och nätverksbandbredd är proportionella mot en specifik instansstorlek.

Skalning per funktion

Samtidighet är en nyckelfaktor som avgör hur Flex Consumption-funktionsappar skalar. För att förbättra skalningsprestanda för appar med olika utlösartyper ger Flex Consumption-planen ett mer deterministiskt sätt att skala din app per funktion.

Det här skalningsbeteendet per funktion är en del av värdplattformen, så du behöver inte konfigurera din app eller ändra koden. Mer information finns i Artikeln om skalning per funktion i artikeln Händelsedriven skalning.

I skalning per funktion fattar plattformen beslut för vissa funktionsutlösare baserat på gruppaggregeringar. Den här tabellen visar den definierade uppsättningen funktionsskalningsgrupper:

Plattformen skalar alla andra funktioner i appen individuellt i sina egna instansuppsättningar. Plattformen refererar till dessa instanser med hjälp av konventionen function:<NAMED_FUNCTION>.

Alltid redo enheter

Flex Consumption innehåller en alltid redo funktion som du kan använda för att välja instanser som alltid körs och tilldelas till var och en av dina skalningsgrupper eller funktioner per funktion. Alltid redo är ett bra alternativ för scenarier där du måste ha ett minsta antal instanser som alltid är redo att hantera begäranden. Det minskar till exempel programmets svarstid för kallstart. Standardvärdet är 0 (noll).

Om du till exempel alltid ställer in redo till 2 för din HTTP-grupp med funktioner, behåller plattformen två instanser som alltid körs för dessa funktioner. Dessa instanser bearbetar dina funktionskörningar först. Beroende på samtidighetsinställningar skalas plattformen bortom dessa två instanser med hjälp av instanser på begäran.

Du kan konfigurera inte mindre än två alltid redo instanser per funktion eller funktionsgrupp medan zonredundans är aktiverat.

Alltid redo instanser är separata från on-demand-instanser: det maximala antalet instanser begränsar endast on-demand-instanser och gäller inte alltid redo instanser.

Information om hur du konfigurerar alltid redo-instanser finns i Ange antal alltid redo-instanser.

Concurrency

Samtidighet avser antalet parallella körningar av en funktion på en instans av din app. Du kan ange ett maximalt antal samtidiga körningar som varje instans hanterar vid en viss tidpunkt. Samtidighet påverkar direkt hur appen skalar. På lägre samtidighetsnivåer behöver du fler instanser för att hantera den händelsedrivna efterfrågan på en funktion. Även om du kan styra och finjustera samtidigheten tillhandahåller plattformen standardinställningar som fungerar i de flesta fall.

Information om hur du anger samtidighetsgränser för HTTP-utlösarfunktioner finns i Ange HTTP-samtidighetsgränser. Information om hur du anger samtidighetsgränser för icke-HTTP-utlösarfunktioner finns i Målbasskalning.

Skalningshastighet

Antalet önskade instanser för appen utvärderas och definieras kontinuerligt av inställningen för samtidighet per instans.

När efterfrågan på evenemang ökar skalar Flex Consumption-plattformen automatiskt ut din app. Plattformen utvärderar ständigt hur många instanser din app behöver – önskat antal instanser – utifrån volymen av inkommande händelser och din samtidighetsinställning per instans , som styr hur många händelser varje instans bearbetar samtidigt. Att höja samtidigheten låter varje instans göra mer arbete, så din app behöver färre instanser för att hantera samma belastning.

Två separata plattformsgränser formar sedan hur din app når det önskade antalet, och det hjälper att tänka på dem oberoende av varandra:

• Skalningstakten styr hur snabbt nya instanser läggs till.
• Det maximala antalet instanser styr hur många instanser din app kan nå.

Du konfigurerar inte skalningshastigheten – plattformen hanterar den åt dig. Du konfigurerar det maximala antalet instanser och samtidigheten per instans. Att förstå dessa hjälper dig att designa arbetsbelastningar som skalar smidigt och förutsägbart.

Hur skalkurvan fungerar

Istället för att lägga till varje efterfrågad instans på en gång lägger plattformen till nya instanser i korta, upprepade burstar och bestämmer hur många en app får lägga till under varje kort intervall. Storleken på den per-intervall-tillåtelsen följer en skalkurva som beror på hur många instanser appen redan kör:

• När en app bara kör några få instanser är tillåtelsen som störst, så en liten app skalar upp mycket snabbt och kan lägga till många instanser per minut.
• När en app växer för att köra fler och fler instanser ger plattformen varje ytterligare omgång mer gradvis. Denna inbromsning håller mycket stora skalningsutbyggnader stabila och hindrar en enskild app från att destabilisera den region den delar med andra appar.

Skalkurvan gäller endast för instanser på begäran. Den exakta formen och hastigheten styrs av plattformen och kan ändras över tid, så designa inte utifrån specifika tal per intervall – designa efter mönstret: snabbt till en början, sedan successivt mer mätt vid mycket höga instansantal.

Alltid redo instanser omfattas inte av denna on-demand scale-out-hastighet. Om du behöver kapacitet före en förutsägbar burst, konfigurera alltid redo instanser så att kapaciteten redan finns på plats innan belastningen anländer.

Maximalt antal instanser (taket)

Oavsett hastighet skalar din app aldrig över sitt maximala antal instanser. När en app når det taket slutar plattformen att lägga till on-demand-instanser oavsett hur mycket efterfrågan som återstår, tills körande instanser blir lediga. Det maximala antalet instanser begränsar endast instanser på begäran. Alltid redo instanser räknas inte mot detta tak, så din app kan köra sina alltid redo instanser utöver det maximala antalet on-demand-instanser.

Du konfigurerar det maximala antalet instanser i appen, men plattformen tillämpar det på varje oberoende skalande funktionsgrupp istället för på appens kombinerade instanser. En funktionsgrupp är en mängd funktioner som skalar tillsammans på samma instanser, enligt beskrivning i per-funktionsskalning. Många appar skalar som en enda grupp, så taket fungerar som en gräns per app. En app som skalar vissa funktioner på egna instanser har mer än en funktionsgrupp, och det maximala antalet instanser gäller för varje grupp.

Ett högt maxantal instanser garanterar inte att din app når det: den regionala prenumerationsminneskvoten kan begränsa total skalning för alla appar i en region under summan av deras konfigurerade maxgränser. Om din app behöver skalas till ett stort antal instanser, bekräfta att prenumerationskvoten är tillräckligt hög och begär en ökning om det behövs.

Strypningsresponser

När som helst ger plattformen det minsta tillåtet över alla dessa gränser – skalkurvan, det maximala antalet instanser och den regionala minneskvoten. När någon av dessa begränsningar tillfälligt håller tillbaka skalningsutskalningen, stryper plattformen individuella skalningsförfrågningar kortvarigt. En strypt skalning är en tillfällig, förväntad del av höghastighetsskalning: plattformen försöker automatiskt igen och din app fortsätter att skala mot efterfrågan. Du behöver inte vidta några åtgärder för att då och då gasa på gasen.

Design för mjuk skalning vid höga hastigheter

• Använd alltid redo instanser för att försäkra kapacitet för kända burstar och för att minska kallstarter, eftersom de kringgår skalningshastigheten på begäran.
• Rätt storlek på samtidighet så att varje instans gör mer arbete, vilket minskar antalet instanser du behöver för en given belastning.
• Sätt ett maximalt antal instanser som är tillräckligt högt för din topp och bekräfta att din prenumerationsminneskvot kan stödja det målet.

Montera fildelningar

Med Flex Consumption kan du montera Azure Files-resurser som lokala kataloger i funktionsappen. Du kan montera när du behöver:

• Håll stora binärfiler borta från distributionen: Montera körbara filer som ffmpeg i stället för att paketera dem, så att distributionerna blir små och kalla startar snabbt.
• Dela referensdata mellan instanser: Alla instanser läser ML-modeller, uppslagstabeller eller corpus-data från samma resurs utan nedladdningar per begäran.
• Dela filer mellan appar: En producentapp skriver och en konsumentapp läser från samma montering.

Endast SMB-delningar (Server Message Block) stöds (NFS är inte tillgängligt). Monterar autentisera med hjälp av en åtkomstnyckel för lagringskontot. Mer information finns i Välj en strategi för filåtkomst.

För information om hur du konfigurerar lagringsmonteringspunkter, se Montera filresurser.

Deployment

Distributioner i Flex Consumption-planen följer en enda sökväg. Du behöver inte längre appinställningar för att påverka driftsättningens beteende. Du skapar och zippar in projektkoden i ett programpaket och distribuerar den sedan till en bloblagringscontainer. Vid start hämtar appen paketet och kör funktionskoden från det här paketet. Som standard fungerar samma lagringskonto som används för att lagra intern värdmetadata (AzureWebJobsStorage) också som distributionscontainer. Du kan dock använda ett alternativt lagringskonto eller välja önskad autentiseringsmetod genom att konfigurera appens distributionsinställningar.

Distributioner med noll stilleståndstid

Flex Consumption tillhandahåller distributioner med noll stilleståndstid via progressiva uppdateringar som webbplatsuppdateringsstrategi. Med den här strategin kan du tillämpa koddistributioner och konfigurationsändringar gradvis över instanser utan att avbryta funktionskörningen. Andra värdplaner använder distributionsplatser för att minimera driftstopp under distributioner. Distributionsalternativ för alla värdplaner finns i optimera distributioner.

Billing

Det finns två lägen där dina kostnader bestäms när du kör dina appar i Flex Consumption-planen. Varje läge bestäms per instans.

Den mest uppdaterade informationen om exekveringspriser, alltid förberedda baslinjekostnader och gratis tilldelningar för körningar på begäran finns på sidan med priser för Azure Functions.

Den minsta fakturerbara körningsperioden för båda körningslägena är 1 000 ms. Efter det avrundar faktureringen upp till närmaste 100 ms. Du hittar information om faktureringsmätare för Flex Consumption Plan i övervakningsreferensen.

Mer information om hur kostnader beräknas när du kör en Flex Consumption-plan, inklusive exempel, finns i Förbrukningsbaserade kostnader och Visa kostnadsrelaterade data.

Språkstackversioner som stöds

Den här tabellen visar de språkstackversioner som för närvarande stöds för Flex Consumption-appar:

1. Den processbaserade C#-modellen stöds inte. Du måste migrera ditt .NET-projekt till den isolerade arbetsmodellen.

Minneskvoter för regionala prenumerationer

Alla Flex Consumption-appar i en prenumeration och region delar en beräkningskvot, till exempel en delad bucket med resurser. Den här kvoten gäller endast för Flex Consumption-appar. Andra värdplaner (Förbrukning, Premium och Dedikerad) räknas inte mot det. Kvoten begränsar hur mycket total beräkning dina Flex Consumption-appar kan använda samtidigt. Om dina appar försöker överskrida kvoten kan vissa körningar och distributioner fördröjas eller misslyckas och skalningen begränsas. Du kan dock fortfarande skapa nya appar.

Standardkvot

Varje region i en prenumeration har en standardkvot på 250 kärnor (motsvarande 512 000 MB) för alla Flex Consumption-appinstanser tillsammans. Du kan använda valfri kombination av instansstorlekar och antal, så länge de totala kärnorna är kvar under kvoten.

Om du vill beräkna de kärnor som används multiplicerar du kärnorna per instans med antalet instanser:

Kvotexempel

Var och en av dessa scenarier når kvotgränsen på 250 kärnor. När kvoten har nåtts slutar appar i regionen att skala:

Viktiga anteckningar

• Flex Consumption skalas snabbt baserat på samtidighetsinställningar , så appar hämtar och släpper ofta kärnor från kvoten när efterfrågan ändras.
• Flex Consumption-appar som skalas till noll eller instanser som har markerats för att skala in och ta bort räknas inte mot kvoten.
• Alltid redo instanser räknas mot kvoten.
• Azure-portalen innehåller ett flexförbrukningskvotverktyg. Öppna valfri Flex Consumption-app i din prenumeration, välj Diagnostisera och lösa problem, sök Flex Consumption Quotaefter och välj sedan en region. Verktyget visar rekommendationer, aktuell kvotinformation och historiska användningsvyer.
• Du kan öka denna kvot efter en kapacitetsgranskning, till exempel från 250 kärnor till 1 000 kärnor eller mer. Om du vill begära en större kvot skapar du ett supportärende eller kontaktar ditt Microsoft-kontoteam.

Inaktuella egenskaper och inställningar

I Flex Consumption-planen är många standardprograminställningar och platskonfigurationsegenskaper inaktuella eller flyttade. Använd inte de här inställningarna när du automatiserar resursskapandet av funktionsappar. Mer information finns i Utfasningar av flexförbrukningsplan.

Considerations

Tänk på följande när du använder Flex Consumption-planen:

• Appar per plan: Du kan bara ha en app per Flex Consumption-plan.
• Värd: Appens initialisering tidsgränsen överskrids efter 30 sekunder. När funktionsappen tar mer än 30 sekunder att starta kan du se gRPC-relaterade System.TimeoutException-poster loggas. Du kan för närvarande inte konfigurera den här tidsgränsen. Mer information finns i det här värdarbetsobjektet.
• Durable Functions: Azure Storage och Durable Task Scheduler är de enda lagringsprovidrar som stöds för Durable Functions när de finns i Flex Consumption-planen. Se rekommendationer när du är värd för Durable Functions i Flex Consumption-planen.
• Registrering av virtuell nätverksintegrering och resursprovider: Du måste ha Microsoft.App Azure-resursprovidern registrerad i din prenumeration för att integreras i ett virtuellt nätverk, vilket behövs för delegering av undernät. Azure-portalen och Azure CLI framtvingar registrering när appen skapas eftersom du kan aktivera integrering av virtuella nätverk när som helst efter att appen har skapats. Följ dessa instruktioner för att registrera den här providern. Delegeringen av undernät som krävs för Flex Consumption-appar är Microsoft.App/environments.
• Utlösare: Alla utlösare stöds fullt ut i en Flex Consumption-plan, men Blob Storage-utlösaren stöder endast Event Grid-källan. Icke-C#-funktionsappar måste använda versionen [4.0.0, 5.0.0) av tilläggspaketet eller en senare version.
• Regioner: Flex Consumption-planen är tillgänglig i många Azure-regioner, men den stöder för närvarande inte alla regioner. Mer information finns i Visa regioner som stöds för närvarande.
• Distributioner: Distributionsplatser stöds inte för närvarande. Om du vill ha distributioner utan driftstopp med Flex Consumption kan du läsa Site update strategies in Flex Consumption (Strategier för platsuppdatering i Flex Consumption). Information om hur du återställer från en felaktig distribution finns i Återställa från en felaktig Flex Consumption Plan-distribution.
• Azure Storage som en lokal delning: NFS-fildelningar (Network File System) är inte tillgängliga för Flex Consumption. Endast SMB (Server Message Block) och Azure Blobs (skrivskyddat) stöds. Mer information finns i Montera filresurser.
• Skala: Den lägsta maximala skalan är för närvarande 1. Det högsta värdet som stöds för närvarande är 1000.
• PowerShell-hanterade beroenden: Flex Consumption stöder inte hanterade beroenden i PowerShell. Du måste i stället ladda upp moduler med appinnehåll.
• Certifikat (förhandsversion): Flex Consumption introducerar platsomfattande certifikat, en ny modell där certifikat är begränsade till din enskilda app i stället för att delas över en webbyta. Hanterade certifikat och App Service-certifikat stöds i förhandsversionen. Mer information finns i Konfigurera platsomfattande certifikat.
• Tidszoner: WEBSITE_TIME_ZONE och TZ appinställningar stöds för närvarande inte när de körs i Flex Consumption Plan.
• Azure Functions-körningsversion och proxyservrar: Flex Consumption stöder endast version 4.x och senare av Azure Functions-körningen. Azure Functions-proxyservrar var en funktion i versionerna 1.x till 3.x av Azure Functions-körningen och är inte tillgänglig i Flex Consumption.
• Planera migrering: Migrering på plats av en befintlig funktionsapp från en annan värdplan till Flex Consumption-planen stöds inte. Du kan inte heller migrera din app från Flex Consumption till en annan plan. Om du vill flytta till Flex Consumption måste du skapa en ny funktionsapp i en Flex Consumption-plan och distribuera om koden.

Relaterade artiklar

Värdalternativ för Azure FunctionsSkapa och hantera funktionsappar i Flex Consumption-planen