Serverlöst webbprogram

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

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

en STÖDG för den här arkitekturen.

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

• Backend som en tjänst (BaaS). Backend-molntjä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" ett kodstycke 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 idén att utvecklare och DevOps-personal inte behöver distribuera, konfigurera eller hantera servrar. Den här referensarkitekturen fokuserar på FaaS med 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:

1. Beräkningsresurser allokeras dynamiskt efter behov av plattformen.
2. Förbrukningsbaserad prissättning: Du debiteras endast för de beräkningsresurser som används för att köra din kod.
3. 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 kommer till en kö. Detta gör en händelsedriven arkitekturstil naturlig för serverlösa arkitekturer. Överväg att använda meddelandeköer eller pub/sub-mönster för att samordna arbetet mellan komponenter i arkitekturen. Om du behöver hjälp med att välja mellan meddelandetekniker i Azure kan du gå till Välj mellan Azure-tjänster som levererar meddelanden.

Arkitektur

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 betjänas av klienter med hjälp av en statisk webbplats som är värd för. Alla dynamiska interaktioner sker via JavaScript-kod som gör anrop till backend-API:erna. Det finns ingen kod på serversidan för att rendera webbsidan. Värdtjänster för statiska webbplatser stöder indexdokument och anpassade 404-felsidor.

CDN. Använd Azure Content Delivery Network (CDN) för att cachelagra innehåll för kortare svarstider 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 ett kodstycke (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. 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. Med en gateway kan du frikoppla frontend-programmet från backend-API:erna. Du kan till API Management skriva om URL:er, transformera begäranden innan de når backend-delen, ange begärande- eller svarshuvuden och så vidare.

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

• Framtvinga användningskvoter och hastighetsbegränsningar
• Verifiera OAuth-token för autentisering
• Aktivera begäranden om korsande ursprung (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-proxy. Med den här Azure Functions kan du definiera en enda API-yta för flera funktionsappar genom att skapa vägar till backend-funktioner. Funktionsproxies kan också utföra begränsade omvandlingar på HTTP-begäran och -svar. De ger dock inte samma omfattande principbaserade funktioner som API Management.

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

Azure Active Directory (Azure AD). Användare loggar in på webbappen med sina Autentiseringsuppgifter för Azure AD. Azure AD returnerar en åtkomsttoken för API:et som webbappen använder för att autentisera API-begäranden (se Autentisering).

Azure Monitor. 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 även in programloggar.

Azure Pipelines. 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 ställer in på din GitHub lagringsplats. Du kan skapa, testa, paketera, släppa eller distribuera ett projekt på GitHub med ett arbetsflöde.

Rekommendationer

Planer för funktionsapp

Azure Functions stöder två värdmodeller. Med förbrukningsplanenallokeras beräkningskraften automatiskt när koden körs. Med App Service plan allokeras en uppsättning virtuella datorer för din kod. Den App Service plan definierar antalet virtuella datorer och VM-storleken.

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

Här är 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 viss ytterligare fördröjning nästa gång den körs. Den här ytterligare svarstiden beror på att du allokerar och förbereder körningsmiljön. Det beror vanligtvis på sekunderna, men det beror på flera faktorer, inklusive antalet beroenden som behöver läsas in. Mer information finns i Förstå serverlös kallstart. Kallstart är vanligtvis mer av intresse för interaktiva arbetsbelastningar (HTTP-utlösare) än asynkrona meddelandedrivna arbetsbelastningar (kö- eller händelsehubbutlösare), eftersom den ytterligare svarstiden observeras direkt av användarna.
• Tidsgränsperiod. I förbrukningsplanen uppnår en funktionskörning en time out efter en konfigurerbar tidsperiod (högst 10 minuter)
• Isolering av virtuellt nätverk. Med en App Service plan kan funktioner köras inuti en App Service-miljön, som är en dedikerad och isolerad värdmiljö.
• Prismodell. Förbrukningsplanen faktureras per antal körningar och resursförbrukning (minne och × körningstid). Den App Service plan debiteras per timme baserat på VM-instansens SKU. Förbrukningsplanen kan ofta 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 trafiken upplever 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 skalas dynamiskt efter behov, baserat på den inkommande trafiken. Den här skalningen sker snabbt, men det finns fortfarande en upp- och nedskalningsperiod. För vissa arbetsbelastningar kanske du avsiktligt vill överetablera de virtuella datorerna, så att du kan hantera trafikbelastningar utan någon upprampningstid. I så fall bör du överväga App Service plan.

Funktionsappgränser

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 tillsammans 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änstsmetod, där varje funktionsapp representerar en mikrotjänst, som eventuellt består av flera relaterade funktioner. I en arkitektur för mikrotjänster bör tjänsterna ha lös koppling och hög funktionell struktur. 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 Utforma mikrotjänster: Domänanalys.

Funktionsbindningar

Använd Functions-bindningar när det är möjligt. Bindningar är ett deklarativt sätt att ansluta din kod 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 data mottagare, till exempel en kö eller databas.

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

[FunctionName("GetStatusFunction")]
public static Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
    [CosmosDB(
        databaseName: "%COSMOSDB_DATABASE_NAME%",
        collectionName: "%COSMOSDB_DATABASE_COL%",
        ConnectionStringSetting = "COSMOSDB_CONNECTION_STRING",
        Id = "{Query.deviceId}",
        PartitionKey = "{Query.deviceId}")] dynamic deviceStatus,
    ILogger log)
{
    ...
}

Med hjälp av bindningar behöver du inte skriva kod som kommunicerar direkt med tjänsten, vilket gör funktionskoden enklare och även abstraherar informationen om datakällan eller mottagaren. I vissa fall kan du dock behöva mer komplex logik än vad bindningen tillhandahåller. I så fall använder du Azure-klient-SDK:er direkt.

Skalbarhetsöverväganden

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 skalas HTTP-utlösaren enligt antalet VIRTUELLA datorinstanser, 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 Azure Functions skala och vara värd för.

Cosmos DB. Dataflödeskapaciteten för Cosmos DB mäts i enheter för förfrågning (RU). Ett dataflöde på 1 RU motsvarar dataflödet som måste hämta ett dokument på 1 kB. För att kunna skala en 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 and scale in Azure Cosmos DB.

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

Överväganden kring haveriberedskap

Distributionen som visas här finns i en enda Azure-region. För en mer motståndskraftig metod för haveriberedskap kan du dra nytta av geo-distributionsfunktioner i de olika tjänsterna:

• API Management har stöd för distribution i flera regioner, som kan användas för att distribuera en enskild API Management-instans över val av antal Azure-regioner. Mer information finns i Så här distribuerar du 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 redundans till en sekundär region.

• Cosmos DB har stöd för flera skrivregioner,vilket möjliggör skrivningar till alla regioner som du lägger till i ditt Cosmos DB konto. Om du inte aktiverar multiskrivning kan du fortfarande växla över den primära skrivregionen. De Cosmos DB klient-SDK:erna och Azure Function-bindningarna hanterar automatiskt redundansen, så du behöver inte uppdatera några programkonfigurationsinställningar.

Säkerhetsöverväganden

Autentisering

GetStatusAPI:et i referensimplementering använder Azure AD för att autentisera begäranden. Azure AD stöder OpenID Anslut protokoll, vilket ä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:

1. Användaren klickar på länken "Logga in" i webbappen.
2. Webbläsaren omdirigeras till inloggningssidan för Azure AD.
3. Användaren loggar in.
4. Azure AD omdirigerar tillbaka till klientprogrammet, inklusive en åtkomsttoken i URL-fragmentet.
5. När webbappen anropar API:et inkluderar den åtkomsttoken i autentiseringshuvudet. Program-ID:t skickas som målgruppsanspråk ('aud') i åtkomsttoken.
6. Backend-API:et verifierar åtkomsttoken.

Så här konfigurerar du autentisering:

• Registrera ett program i din Azure AD-klientorganisation. Detta genererar ett program-ID som klienten inkluderar med inloggnings-URL:en.

• Aktivera Azure AD-autentisering i funktionsappen. Mer information finns i Autentisering och auktorisering i Azure App Service.

• Lägg till principen validate-jwt för att API Management auktorisera begäran i förväg genom att verifiera åtkomsttoken.

Mer information finns i GitHub readme.

Vi rekommenderar att du skapar separata appregistreringar i Azure AD för klientprogrammet och backend-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 kontrollera behörigheterna för var och en.

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

Auktorisering

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

DEN ID-token som Azure AD returnerar till klienten innehåller några av användarens anspråk. I funktionsappen är dessa anspråk tillgängliga i huvudet X-MS-CLIENT-PRINCIPAL för 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 Azure AD. (Användaren måste godkänna den här åtgärden vid inloggning.)

Mer information finns i Arbeta med klientidentiteter.

CORS

I den här referensarkitekturen delar webbappen 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 för principen för samma ursprung och förhindrar att en skadlig webbplats läser känsliga data från en annan plats. Om du vill aktivera en begäran om korsande ursprung lägger du till en CORS-princip (Cross-Origin Resource Sharing) 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-credentialssant. Detta ger webbläsaren behörighet att skicka autentiseringsuppgifter (inklusive cookies) med begäran. Annars skickar webbläsaren som standard inte autentiseringsuppgifter med en begäran om korsande ursprung.

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å *.azureedge.net underdomänen som standard. Information om hur du aktiverar HTTPS CDN för anpassade domännamn finns i Självstudie: Konfigurera HTTPS på en Azure CDN anpassad domän.

• Statisk webbplats som är värd för. Aktivera alternativet"Säker överföring krävs"på Storage konto. 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 Portal 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åsa funktionsappen

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

• Konfigurera funktionsappen så att den kräver en funktionsnyckel. Den API Management gatewayen innehåller funktionsnyckeln när den anropar funktionsappen. Detta förhindrar att klienter anropar funktionen direkt, vilket kringgår gatewayen.

• Den API Management gatewayen har en statisk IP-adress. Begränsa Azure-funktionen till att endast tillåta anrop från den statiska IP-adressen. Mer information finns i Azure App Service statiska IP-begränsningar. (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 en Azure-webbapp 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ällningarna. Det finns inget inbyggt sätt att konfigurera utlösare och bindningar att använda Key Vault hemligheter.

DevOps-överväganden

Frontend-distribution

Frontend-delen av den här referensarkitekturen är ett ensidesprogram med JavaScript som har åtkomst till serverlösa server-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 CDN, med det statiska innehåll som finns 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 Metodtips 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 Actionsför att automatiskt skapa och distribuera varje källändring. Källan måste finnas i ett versionskontrollsystem online. Mer information om Azure Pipelines finns i Skapa din första pipeline. Mer information om hur 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 prestanda. Azure CDN tillåter komprimering direkt på gränsservrarna. Alternativt komprimerar den distribuerade pipelinen 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.
• Användaren CDN kunna rensa sin cache för att se till 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 nyligen skapade i samma ursprungsmapp.
• En annan cachestrategi, till exempel versionshantering med kataloger, kräver kanske inte en rensning av CDN. Bygg-pipelinen i det här frontend-programmet skapar en ny katalog för varje nyskapad version. Den här versionen laddas upp som en atomisk enhet till Blob Storage. Den Azure CDN pekar på den nya versionen först efter en slutförd distribution.
• Öka cachens TTL-värde genom att cachelagra resursfiler under en längre tid och sträcka sig över flera månader. Se till att de cachelagrade filerna uppdateras när de ändras genom att fingeravtrycka filnamnen när de återskapas. Det här frontend-programmet fingeravtryckar alla filer utom 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 mer information.

Backend-distribution

Om du vill 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 skrivskyddade 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 kallstarttiderna, särskilt 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 API Management lager. API Management två distinkta men kompletterande versionshanteringsbegrepp:

• Med versioner kan API-konsumenter välja en API-version baserat på deras behov, till exempel v1 eller v2.

• Revideringar gör att API-administratörer kan göra icke-större ändringar i ett API och distribuera ändringarna, tillsammans med en ändringslogg för att informera API-konsumenter om ändringarna.

Om du gör en viktig ä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 göra den tidigare versionen inaktuell. API Management har stöd för 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 en mellanlagringsplats i samma funktionsapp. Kontrollera att distributionen har lyckats och växla sedan den mellanspelade versionen med produktionsversionen. Publicera en revision i API Management.

Kostnadsöverväganden

Normalt beräknar du kostnader med hjälp av priskalkylatorn för Azure. Överväg dessa punkter för att optimera kostnaden för den här arkitekturen.

Azure Functions

Azure Functions två värdmodeller.

• Förbrukningsplan.

  Beräkningskraften 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 VM-storleken.

I den här arkitekturen anropas en funktion när en klient gör en HTTP-begäran. Eftersom ett konstant dataflöde med hög volym 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 faktureras för etablerat dataflöde och förbrukat lagringsutrymme per timme. Etablerat dataflöde uttrycks i enheter för programbegäran per sekund (RU/s), som kan användas för vanliga databasåtgärder, till exempel infogningar, läsningar. Priset baseras på kapaciteten i RU/s som du reserverar.

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

Mer Cosmos DB finns i Cosmos DB prismodell.

I den här arkitekturen hämtar funktionsprogrammet dokument från Cosmos DB som svar på HTTP GET-begäranden från klienten. 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

Faktureringspriset kan variera beroende på faktureringsregion beroende på platsen för källservern som levererar innehållet till slutanvändaren. Klientens fysiska plats är inte faktureringsregionen. En HTTP- eller HTTPS-begäran 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 TTL-värdet för cachelagring genom att cachelagra resursfiler under en längre tid och ange den längsta möjliga TTL-värdet för ditt innehåll.

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

Distribuera lösningen

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

Nästa steg

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

Relaterad vägledning:

• Metodtips för att använda CDN
• Mönster för värdtjänster för statiskt innehåll