Serverlöst webbprogram

Microsoft Entra ID

Azure API Management

Azure Blob Storage

Azure Content Delivery Network

Azure Functions

Azure Monitor

Den här referensarkitekturen visar ett serverlöst webbprogram. Programmet hanterar statiskt innehåll från Azure Blob Storage och implementerar ett API med hjälp av Azure Functions. API:et läser data från Azure Cosmos DB och returnerar resultatet till webbappen.

GitHub-logotyp Två referensimplementeringar för den här arkitekturen finns på GitHub: Drone Delivery App (ARM & Azure Pipelines) och To Do App (Bicep & GitHub Actions).

Arkitektur

Diagram som visar referensarkitektur för ett serverlöst webbprogram.

Ladda ned en Visio-fil med den här arkitekturen.

Termen serverlös har två distinkta men relaterade betydelser:

Serverdel som en tjänst (BaaS). Serverdelsmolntjänster, till exempel databaser och lagring, tillhandahåller API:er som gör det möjligt för klientprogram att ansluta direkt till dessa tjänster.
Funktioner som en tjänst (FaaS). I den här modellen är en "funktion" en kod som distribueras till molnet och körs i en värdmiljö som helt abstraherar de servrar som kör koden.

Båda definitionerna har gemensamt tanken att utvecklare och DevOps-personal inte behöver distribuera, konfigurera eller hantera servrar. Den här referensarkitekturen fokuserar på FaaS med Hjälp av Azure Functions, men att hantera webbinnehåll från Azure Blob Storage kan vara ett exempel på BaaS. Några viktiga egenskaper hos FaaS är:

Beräkningsresurser allokeras dynamiskt efter behov av plattformen.
Förbrukningsbaserad prissättning: Du debiteras endast för de beräkningsresurser som används för att köra koden.
Beräkningsresurserna skalas på begäran baserat på trafik, utan att utvecklaren behöver göra någon konfiguration.

Funktioner körs när en extern utlösare inträffar, till exempel en HTTP-begäran eller ett meddelande som anländer till en kö. Detta gör en händelsedriven arkitekturstil naturlig för serverlösa arkitekturer. Om du vill samordna arbetet mellan komponenter i arkitekturen bör du överväga att använda meddelandeköer eller pub-/undermönster. Hjälp med att välja mellan meddelandetekniker i Azure finns i Välj mellan Azure-tjänster som levererar meddelanden.

Komponenter

Arkitekturen består av följande komponenter:

Blob Storage. Statiskt webbinnehåll, till exempel HTML-, CSS- och JavaScript-filer, lagras i Azure Blob Storage och hanteras av klienter med hjälp av statiska webbplatsvärdar. All dynamisk interaktion sker via JavaScript-kod som anropar serverdels-API:er. Det finns ingen kod på serversidan för att återge webbsidan. Värd för statiska webbplatser stöder indexdokument och anpassade 404-felsidor.

CDN. Använd Azure Content Delivery Network (CDN) för att cachelagrar innehåll för kortare svarstid och snabbare leverans av innehåll, samt för att tillhandahålla en HTTPS-slutpunkt.

Funktionsappar. Azure Functions är ett serverlöst beräkningsalternativ. Den använder en händelsedriven modell, där en koddel (en "funktion") anropas av en utlösare. I den här arkitekturen anropas funktionen när en klient gör en HTTP-begäran. Begäran dirigeras alltid via en API-gateway, som beskrivs nedan.

API Management. Azure API Management tillhandahåller en API-gateway som finns framför HTTP-funktionen. Du kan använda API Management för att publicera och hantera API:er som används av klientprogram. Genom att använda en gateway kan du frikoppla klientdelsprogrammet från serverdels-API:erna. API Management kan till exempel skriva om URL:er, transformera begäranden innan de når serverdelen, ange begärande- eller svarshuvuden och så vidare.

API Management kan också användas för att implementera övergripande problem som:

Framtvinga användningskvoter och hastighetsgränser
Validera OAuth-token för autentisering
Aktivera korsande begäranden (CORS)
Cachelagring svar
Övervaknings- och loggningsbegäranden

Om du inte behöver alla funktioner som tillhandahålls av API Management är ett annat alternativ att använda Functions-proxyservrar. Med den här funktionen i Azure Functions kan du definiera en enda API-yta för flera funktionsappar genom att skapa vägar till serverdelsfunktioner. Funktionsproxy kan också utföra begränsade transformeringar på HTTP-begäran och -svaret. De tillhandahåller dock inte samma omfattande principbaserade funktioner i API Management.

Azure Cosmos DB. Azure Cosmos DB är en databastjänst med flera modeller. I det här scenariot hämtar funktionsprogrammet dokument från Azure Cosmos DB som svar på HTTP GET-begäranden från klienten.

Microsoft Entra-ID (Microsoft Entra-ID). Användare loggar in på webbprogrammet med sina autentiseringsuppgifter för Microsoft Entra-ID . Microsoft Entra-ID returnerar en åtkomsttoken för API:et, som webbprogrammet använder för att autentisera API-begäranden (se Autentisering).

Azure Monitor. Azure Monitor samlar in prestandamått om de Azure-tjänster som distribueras i lösningen. Genom att visualisera dessa på en instrumentpanel kan du få insyn i lösningens hälsotillstånd. Den samlade också in programloggar.

Azure Pipelines. Azure Pipelines är en tjänst för kontinuerlig integrering (CI) och kontinuerlig leverans (CD) som skapar, testar och distribuerar programmet.

GitHub Actions. Arbetsflödet är en automatiserad process (CI/CD) som du har konfigurerat på din GitHub-lagringsplats. Du kan skapa, testa, paketera, släppa eller distribuera valfritt projekt på GitHub med ett arbetsflöde.

Information om scenario

Potentiella användningsfall

Den här drönarleveranslösningen är idealisk för flygplans-, flyg-, flyg- och robotindustrin.

Rekommendationer

Funktionsappplaner

Azure Functions stöder två värdmodeller. Med förbrukningsplanen allokeras beräkningskraft automatiskt när koden körs. Med App Service-planen allokeras en uppsättning virtuella datorer för din kod. App Service-planen definierar antalet virtuella datorer och storleken på den virtuella datorn.

Observera att App Service-planen inte är strikt serverlös, enligt definitionen ovan. Programmeringsmodellen är dock densamma – samma funktionskod kan köras i både en förbrukningsplan och en App Service-plan.

Här följer några faktorer att tänka på när du väljer vilken typ av plan som ska användas:

Kallstart. Med förbrukningsplanen kommer en funktion som inte har anropats nyligen att medföra ytterligare svarstider nästa gång den körs. Den här ytterligare svarstiden beror på att du allokerar och förbereder körningsmiljön. Det är vanligtvis i sekunders ordning men beror på flera faktorer, inklusive antalet beroenden som måste läsas in. Mer information finns i Förstå serverlös kallstart. Kallstart är vanligtvis mer ett problem för interaktiva arbetsbelastningar (HTTP-utlösare) än asynkrona meddelandedrivna arbetsbelastningar (kö- eller händelsehubbarutlösare), eftersom den ytterligare svarstiden observeras direkt av användarna.
Tidsgräns. I förbrukningsplanen överskrider en funktionskörning tidsgränsen efter en konfigurerbar tidsperiod (till högst 10 minuter)
Isolering av virtuellt nätverk. Med hjälp av en App Service-plan kan funktioner köras i en App Service-miljön, som är en dedikerad och isolerad värdmiljö.
Prismodell. Förbrukningsplanen debiteras av antalet körningar och resursförbrukning (minne × körningstid). App Service-planen faktureras varje timme baserat på VM-instansens SKU. Ofta kan förbrukningsplanen vara billigare än en App Service-plan, eftersom du bara betalar för de beräkningsresurser som du använder. Detta gäller särskilt om dina trafikupplevelser toppar och dalar. Men om ett program har konstant dataflöde med hög volym kan en App Service-plan kosta mindre än förbrukningsplanen.
Skalning. En stor fördel med förbrukningsmodellen är att den skalar dynamiskt efter behov, baserat på inkommande trafik. Även om den här skalningen sker snabbt finns det fortfarande en upptrappningsperiod. För vissa arbetsbelastningar kanske du vill överetablera de virtuella datorerna avsiktligt, så att du kan hantera trafiktoppar med noll ramp-up-tid. I så fall bör du överväga en App Service-plan.

Gränser för funktionsapp

En funktionsapp är värd för körningen av en eller flera funktioner. Du kan använda en funktionsapp för att gruppera flera funktioner som en logisk enhet. I en funktionsapp delar funktionerna samma programinställningar, värdplan och distributionslivscykel. Varje funktionsapp har sitt eget värdnamn.

Använd funktionsappar för att gruppera funktioner som delar samma livscykel och inställningar. Funktioner som inte delar samma livscykel ska finnas i olika funktionsappar.

Överväg att använda en mikrotjänstmetod, där varje funktionsapp representerar en mikrotjänst, eventuellt bestående av flera relaterade funktioner. I en arkitektur för mikrotjänster bör tjänsterna ha lös koppling och hög funktionell sammanhållning. Löst kopplade innebär att du kan ändra en tjänst utan att kräva att andra tjänster uppdateras samtidigt. Sammanhängande innebär att en tjänst har ett enda, väldefinierat syfte. Mer information om dessa idéer finns i Designa mikrotjänster: Domänanalys.

Funktionsbindningar

Använd Functions-bindningar när det är möjligt. Bindningar är ett deklarativt sätt att ansluta koden till data och integrera med andra Azure-tjänster. En indatabindning fyller i en indataparameter från en extern datakälla. En utdatabindning skickar funktionens returvärde till en datamottagare, till exempel en kö eller databas.

Funktionen i referensimplementeringen använder till exempel GetStatus Azure Cosmos DB-indatabindningen. Den här bindningen är konfigurerad för att slå upp ett dokument i Azure Cosmos DB med hjälp av frågeparametrar som hämtas från frågesträngen i HTTP-begäran. Om dokumentet hittas skickas det till funktionen som en parameter.

[Function("GetStatusFunction")]
public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req,
        [CosmosDBInput(
           databaseName: "%COSMOSDB_DATABASE_NAME%",
           containerName:"%COSMOSDB_DATABASE_COL%",
           Connection  = "COSMOSDB_CONNECTION_STRING",
           Id = "{Query.deviceId}",
           PartitionKey = "{Query.deviceId}")] DeviceState? deviceStatus)
{
  ...
}

Genom att använda bindningar behöver du inte skriva kod som talar direkt till tjänsten, vilket gör funktionskoden enklare och även abstraherar information om datakällan eller mottagaren. I vissa fall kan du dock behöva mer komplex logik än vad bindningen ger. I så fall använder du Azure-klient-SDK:erna direkt.

Att tänka på

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.

Skalbarhet

Functions. För förbrukningsplanen skalar HTTP-utlösaren baserat på trafiken. Det finns en gräns för antalet samtidiga funktionsinstanser, men varje instans kan bearbeta mer än en begäran i taget. För en App Service-plan skalar HTTP-utlösaren enligt antalet vm-instanser, som kan vara ett fast värde eller kan skalas automatiskt baserat på en uppsättning regler för automatisk skalning. Mer information finns i Skala och hantera Azure Functions.

Azure Cosmos DB. Dataflödeskapaciteten för Azure Cosmos DB mäts i RU (Request Units ). Ett 1 RU-dataflöde motsvarar det dataflöde som behöver hämta ett 1 KB-dokument. För att kunna skala en Azure Cosmos DB-container efter 10 000 RU måste du ange en partitionsnyckel när du skapar containern och inkludera partitionsnyckeln i varje dokument som du skapar. Mer information om partitionsnycklar finns i Partition och skalning i Azure Cosmos DB.

API Management. API Management kan skala ut och stöder regelbaserad autoskalning. Skalningsprocessen tar minst 20 minuter. Om trafiken är hög bör du etablera för den maximala trafik som du förväntar dig. Automatisk skalning är dock användbart för att hantera variationer i trafiken varje timme eller varje dag. Mer information finns i Skala automatiskt en Azure API Management-instans.

Haveriberedskap

Distributionen som visas här finns i en enda Azure-region. Om du vill ha en mer flexibel metod för haveriberedskap kan du dra nytta av geo-distributionsfunktionerna i de olika tjänsterna:

API Management stöder distribution i flera regioner, som kan användas för att distribuera en enda API Management-instans över valfritt antal Azure-regioner. Mer information finns i Distribuera en Azure API Management-tjänstinstans till flera Azure-regioner.
Använd Traffic Manager för att dirigera HTTP-begäranden till den primära regionen. Om funktionsappen som körs i den regionen blir otillgänglig kan Traffic Manager redundansväxla till en sekundär region.
Azure Cosmos DB stöder flera skrivregioner, vilket gör det möjligt att skriva till alla regioner som du lägger till i ditt Azure Cosmos DB-konto. Om du inte aktiverar flera skrivningar kan du fortfarande redundansväxla den primära skrivregionen. Azure Cosmos DB-klient-SDK:er och Azure-funktionsbindningar hanterar automatiskt redundansen, så du behöver inte uppdatera några inställningar för programkonfiguration.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

Autentisering

GetStatus API:et i referensimplementeringen använder Microsoft Entra-ID för att autentisera begäranden. Microsoft Entra ID stöder OpenID Anslut-protokollet, som är ett autentiseringsprotokoll som bygger på OAuth 2-protokollet.

I den här arkitekturen är klientprogrammet ett ensidesprogram (SPA) som körs i webbläsaren. Den här typen av klientprogram kan inte hålla en klienthemlighet eller en auktoriseringskod dold, så det implicita beviljandeflödet är lämpligt. (Se Vilket OAuth 2.0-flöde ska jag använda?). Här är det övergripande flödet:

Användaren klickar på länken "Logga in" i webbprogrammet.
Webbläsaren omdirigeras till microsoft Entra-inloggningssidan.
Användaren loggar in.
Microsoft Entra ID omdirigerar tillbaka till klientprogrammet, inklusive en åtkomsttoken i URL-fragmentet.
När webbprogrammet anropar API:et innehåller det åtkomsttoken i autentiseringshuvudet. Program-ID:t skickas som målgruppsanspråk ("aud") i åtkomsttoken.
Serverdels-API:et verifierar åtkomsttoken.

Så här konfigurerar du autentisering:

Registrera ett program i din Microsoft Entra-klientorganisation. Detta genererar ett program-ID som klienten inkluderar med inloggnings-URL:en.
Aktivera Microsoft Entra-autentisering i funktionsappen. Mer information finns i Autentisering och auktorisering i Azure App Service.
Lägg till policyn validate-jwt i API Management för att förauktorisera begäran genom att validera åtkomsttoken.

Mer information finns i GitHub-läsningen.

Vi rekommenderar att du skapar separata appregistreringar i Microsoft Entra-ID för klientprogrammet och serverdels-API:et. Ge klientprogrammet behörighet att anropa API:et. Den här metoden ger dig flexibiliteten att definiera flera API:er och klienter och styra behörigheterna för var och en.

I ett API använder du omfång för att ge program detaljerad kontroll över vilka behörigheter de begär från en användare. Ett API kan till exempel ha Read och Write omfång, och en viss klientapp kan be användaren att endast auktorisera Read behörigheter.

Auktorisering

I många program måste serverdels-API:et kontrollera om en användare har behörighet att utföra en viss åtgärd. Vi rekommenderar att du använder anspråksbaserad auktorisering, där information om användaren förmedlas av identitetsprovidern (i det här fallet Microsoft Entra-ID) och används för att fatta auktoriseringsbeslut. När du till exempel registrerar ett program i Microsoft Entra-ID kan du definiera en uppsättning programroller. När en användare loggar in i programmet innehåller Microsoft Entra-ID ett roles anspråk för varje roll som användaren har beviljats, inklusive roller som ärvs genom gruppmedlemskap.

Den ID-token som Microsoft Entra-ID returnerar till klienten innehåller några av användarens anspråk. I funktionsappen är dessa anspråk tillgängliga i rubriken X-MS-CLIENT-PRINCIPAL i begäran. Det är dock enklare att läsa den här informationen från bindningsdata. För andra anspråk använder du Microsoft Graph för att fråga Microsoft Entra-ID. (Användaren måste godkänna den här åtgärden när han eller hon loggar in.)

Mer information finns i Arbeta med klientidentiteter.

CORS

I den här referensarkitekturen delar webbprogrammet och API:et inte samma ursprung. Det innebär att när programmet anropar API:et är det en begäran om korsande ursprung. Webbläsarskydd förhindrar att en webbsida gör AJAX-begäranden till en annan domän. Den här begränsningen kallas principen för samma ursprung och förhindrar att en skadlig webbplats läser känsliga data från en annan webbplats. Om du vill aktivera en begäran om korsande ursprung lägger du till en CORS-princip (Cross-Origin Resource Sharing) i API Management-gatewayen:

<cors allow-credentials="true">
    <allowed-origins>
        <origin>[Website URL]</origin>
    </allowed-origins>
    <allowed-methods>
        <method>GET</method>
    </allowed-methods>
    <allowed-headers>
        <header>*</header>
    </allowed-headers>
</cors>

I det här exemplet är attributet allow-credentials sant. Detta tillåter webbläsaren att skicka autentiseringsuppgifter (inklusive cookies) med begäran. Annars skickar webbläsaren som standard inte autentiseringsuppgifter med en begäran om korsande ursprung.

Kommentar

Var mycket försiktig med att ange tillåtna autentiseringsuppgifter till sant, eftersom det innebär att en webbplats kan skicka användarens autentiseringsuppgifter till ditt API för användarens räkning, utan att användaren är medveten om det. Du måste lita på det tillåtna ursprunget.

Använda HTTPS

För maximal säkerhet kräver du HTTPS i hela pipelinen för begäran:

CDN. Azure CDN stöder HTTPS på underdomänen *.azureedge.net som standard. Om du vill aktivera HTTPS i CDN för anpassade domännamn läser du Självstudie: Konfigurera HTTPS på en anpassad Azure CDN-domän.
Värd för statisk webbplats. Aktivera alternativet "Säker överföring krävs" på lagringskontot. När det här alternativet är aktiverat tillåter lagringskontot endast begäranden från säkra HTTPS-anslutningar.

API Management. Konfigurera API:erna så att de endast använder HTTPS-protokoll. Du kan konfigurera detta i Azure-portalen eller via en Resource Manager-mall:

{
    "apiVersion": "2018-01-01",
    "type": "apis",
    "name": "dronedeliveryapi",
    "dependsOn": [
        "[concat('Microsoft.ApiManagement/service/', variables('apiManagementServiceName'))]"
    ],
    "properties": {
        "displayName": "Drone Delivery API",
        "description": "Drone Delivery API",
        "path": "api",
        "protocols": [ "HTTPS" ]
    },
    ...
}

Azure Functions. Aktivera inställningen "ENDAST HTTPS".

Lås funktionsappen

Alla anrop till funktionen ska gå via API-gatewayen. Du kan uppnå detta på följande sätt:

Konfigurera funktionsappen så att den kräver en funktionsnyckel. API Management-gatewayen innehåller funktionsnyckeln när den anropar funktionsappen. Detta förhindrar att klienter anropar funktionen direkt och kringgår gatewayen.
API Management-gatewayen har en statisk IP-adress. Begränsa Azure-funktionen så att endast anrop från den statiska IP-adressen tillåts. Mer information finns i Statiska IP-begränsningar för Azure App Service. (Den här funktionen är endast tillgänglig för tjänster på standardnivå.)

Skydda programhemligheter

Lagra inte programhemligheter, till exempel databasautentiseringsuppgifter, i koden eller konfigurationsfilerna. Använd i stället Appinställningar som lagras krypterade i Azure. Mer information finns i Säkerhet i Azure App Service och Azure Functions.

Du kan också lagra programhemligheter i Key Vault. På så sätt kan du centralisera lagringen av hemligheter, kontrollera deras distribution och övervaka hur och när hemligheter används. Mer information finns i Konfigurera ett Azure-webbprogram för att läsa en hemlighet från Key Vault. Observera dock att Functions-utlösare och bindningar läser in sina konfigurationsinställningar från appinställningar. Det finns inget inbyggt sätt att konfigurera utlösare och bindningar för att använda Key Vault-hemligheter.

DevOps

Klientdelsdistribution

Klientdelen av den här referensarkitekturen är ett ensidesprogram med JavaScript som har åtkomst till serverlösa serverdels-API:er och statiskt innehåll som ger en snabb användarupplevelse. Följande är några viktiga överväganden för ett sådant program:

Distribuera programmet enhetligt till användare över ett brett geografiskt område med ett globalt redo CDN med det statiska innehållet i molnet. På så sätt undviker du behovet av en dedikerad webbserver. Läs Integrera ett Azure Storage-konto med Azure CDN för att komma igång. Skydda ditt program med HTTPS. Läs metodtipsen för att använda nätverk för innehållsleverans för ytterligare rekommendationer.
Använd en snabb och tillförlitlig CI/CD-tjänst som Azure Pipelines eller GitHub Actions för att automatiskt skapa och distribuera varje källändring. Källan måste finnas i ett system för onlineversionskontroll. Mer information om Azure Pipelines finns i Skapa din första pipeline. Mer information om GitHub Actions för Azure finns i Distribuera appar till Azure.
Komprimera dina webbplatsfiler för att minska bandbreddsförbrukningen på CDN och förbättra prestandan. Azure CDN tillåter komprimering direkt på gränsservrarna. Alternativt komprimerar distributionspipelinen i den här referensarkitekturen filerna innan de distribueras till Blob Storage. Detta minskar lagringskravet och ger dig större frihet att välja komprimeringsverktyg, oavsett eventuella CDN-begränsningar.
CDN bör kunna rensa cacheminnet för att säkerställa att alla användare får det senaste innehållet. En cacherensning krävs om bygg- och distributionsprocesserna inte är atomiska, till exempel om de ersätter gamla filer med nybyggda filer i samma ursprungsmapp.
En annan cachestrategi, till exempel versionshantering med hjälp av kataloger, kanske inte kräver en rensning av CDN. Bygg-pipelinen i det här klientdelsprogrammet skapar en ny katalog för varje ny version. Den här versionen laddas upp som en atomisk enhet till Blob Storage. Azure CDN pekar på den här nya versionen först efter en slutförd distribution.
Öka cache-TTL genom att cachelagra resursfiler under en längre tid, som sträcker sig över månader. Kontrollera att cachelagrade filer uppdateras när de ändras genom att ta fingeravtryck på filnamnen när de återskapas. Det här klientprogrammet fingeravtryckar alla filer förutom offentliga filer, till exempel index.html. Eftersom index.html uppdateras ofta återspeglar den de ändrade filnamnen som orsakar en cacheuppdatering. Mer information finns i Hantera förfallodatum för webbinnehåll i Azure CDN .

Serverdelsdistribution

För att distribuera funktionsappen rekommenderar vi att du använder paketfiler ("Kör från paket"). Med den här metoden laddar du upp en zip-fil till en Blob Storage-container och Functions-körningen monterar zip-filen som ett skrivskyddat filsystem. Det här är en atomisk åtgärd, vilket minskar risken för att en misslyckad distribution lämnar programmet i ett inkonsekvent tillstånd. Det kan också förbättra kalla starttider, särskilt för Node.js appar, eftersom alla filer växlas samtidigt.

API-versionshantering

Ett API är ett kontrakt mellan en tjänst och klienter. I den här arkitekturen definieras API-kontraktet på API Management-lagret. API Management har stöd för två distinkta men kompletterande versionsbegrepp:

Versioner gör det möjligt för API-konsumenter att välja en API-version baserat på deras behov, till exempel v1 jämfört med v2.
Med revisioner kan API-administratörer göra icke-icke-bakåtkompatibla ändringar i ett API och distribuera ändringarna, tillsammans med en ändringslogg för att informera API-konsumenter om ändringarna.

Om du gör en icke-bakåtkompatibel ändring i ett API publicerar du en ny version i API Management. Distribuera den nya versionen sida vid sida med den ursprungliga versionen i en separat funktionsapp. På så sätt kan du migrera befintliga klienter till det nya API:et utan att bryta klientprogram. Så småningom kan du inaktuella den tidigare versionen. API Management stöder flera versionsscheman: URL-sökväg, HTTP-huvud eller frågesträng. Mer information om API-versionshantering i allmänhet finns i Versionshantering av ett RESTful-webb-API.

För uppdateringar som inte bryter mot API-ändringar distribuerar du den nya versionen till ett mellanlagringsfack i samma funktionsapp. Kontrollera att distributionen lyckades och växla sedan mellanlagrad version med produktionsversionen. Publicera en revision i API Management.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

Normalt beräknar du kostnader med hjälp av priskalkylatorn för Azure. Tänk på dessa punkter för att optimera kostnaden för den här arkitekturen.

Azure Functions

Azure Functions stöder två värdmodeller.

Förbrukningsplan.

Beräkningskraft allokeras automatiskt när koden körs.
App Service-plan.

En uppsättning virtuella datorer allokeras för din kod. Den här planen definierar antalet virtuella datorer och storleken på den virtuella datorn.

I den här arkitekturen anropas en funktion när en klient gör en HTTP-begäran. Eftersom ett konstant dataflöde med stora volymer inte förväntas i det här användningsfallet rekommenderas förbrukningsplanen eftersom du endast betalar för de beräkningsresurser som du använder.

Azure Cosmos DB

Azure Cosmos DB fakturerar för etablerat dataflöde och förbrukad lagring per timme. Etablerat dataflöde uttrycks i enheter för begäranden per sekund (RU/s), som kan användas för vanliga databasåtgärder, till exempel infogningar, läsningar. Priset baseras på den kapacitet i RU/s som du reserverar.

Lagring debiteras för varje GB som används för dina lagrade data och index.

Mer information finns i Prismodellen för Azure Cosmos DB.

I den här arkitekturen hämtar funktionsprogrammet dokument från Azure Cosmos DB som svar på HTTP GET-begäranden från klienten. Azure Cosmos DB är kostnadseffektivt i det här fallet eftersom läsåtgärder är betydligt billigare än skrivåtgärder som uttrycks på RU/s.

Content Delivery Network

Faktureringsfrekvensen kan variera beroende på faktureringsregionen baserat på platsen för källservern som levererar innehållet till slutanvändaren. Klientens fysiska plats är inte faktureringsregionen. Alla HTTP- eller HTTPS-begäranden som träffar CDN är en fakturerbar händelse som innehåller alla svarstyper: lyckade, misslyckade eller andra. Olika svar kan generera olika trafikmängder.

I den här referensarkitekturen finns distributionen i en enda Azure-region.

Om du vill sänka kostnaderna kan du överväga att öka cache-TTL genom att cachelagra resursfiler under en längre tid och ställa in den längsta TTL som är möjlig för ditt innehåll.

Mer information finns i avsnittet Kostnad i Microsoft Azure Well-Architected Framework.

Distribuera det här scenariot

Information om hur du distribuerar referensimplementeringen för den här arkitekturen finns i GitHub-readme.

Nästa steg

Produktdokumentation:

Learn-moduler:

Mer information om referensimplementeringen finns i Genomgång av kod: Serverlöst program med Azure Functions.

Relaterad vägledning:

Serverlöst webbprogram

Arkitektur

Komponenter

Information om scenario

Potentiella användningsfall

Rekommendationer

Funktionsappplaner

Gränser för funktionsapp

Funktionsbindningar

Att tänka på

Skalbarhet

Haveriberedskap

Säkerhet

Autentisering

Auktorisering

CORS

Använda HTTPS

Lås funktionsappen

Skydda programhemligheter

DevOps

Klientdelsdistribution

Serverdelsdistribution

API-versionshantering

Kostnadsoptimering

Azure Functions

Azure Cosmos DB

Content Delivery Network

Distribuera det här scenariot

Nästa steg

Feedback

Feedback

Ytterligare resurser

Serverlöst webbprogram

Arkitektur

Komponenter

Information om scenario

Potentiella användningsfall

Rekommendationer

Funktionsappplaner

Gränser för funktionsapp

Funktionsbindningar

Att tänka på

Skalbarhet

Haveriberedskap

Säkerhet

Autentisering

Auktorisering

CORS

Använda HTTPS

Lås funktionsappen

Skydda programhemligheter

DevOps

Klientdelsdistribution

Serverdelsdistribution

API-versionshantering

Kostnadsoptimering

Azure Functions

Azure Cosmos DB

Content Delivery Network

Distribuera det här scenariot

Nästa steg

Relaterade resurser

Feedback

Feedback

Ytterligare resurser