Serverloze webtoepassing

Deze referentiearchitectuur toont een serverloze webtoepassing. De toepassing levert statische inhoud van Azure Blob Storage en implementeert een API met behulp van Azure Functions. De API leest gegevens uit Cosmos DB en retourneert de resultaten naar de web-app.

GitHub: Drone Delivery App (ARM & Azure Pipelines) en To Do App (Bicep & GitHub Actions).

Download een SVG van deze architectuur.

De term serverloos heeft twee verschillende maar gerelateerde betekenis:

• Back-en-a-service (BaaS). Back-endcloudservices, zoals databases en opslag, bieden API's waarmee clienttoepassingen rechtstreeks verbinding kunnen maken met deze services.
• Functions as a Service (FaaS). In dit model is een 'functie' een stukje code dat wordt geïmplementeerd in de cloud en wordt uitgevoerd in een hostingomgeving die de servers waarop de code wordt uitgevoerd, volledig abstract maakt.

Beide definities hebben gemeenschappelijk het idee dat ontwikkelaars en DevOps-medewerkers geen servers hoeven te implementeren, configureren of beheren. Deze referentiearchitectuur is gericht op FaaS met behulp van Azure Functions, hoewel het leveren van webinhoud van Azure Blob Storage een voorbeeld van BaaS kan zijn. Enkele belangrijke kenmerken van FaaS zijn:

1. Rekenresources worden naar behoefte dynamisch toegewezen door het platform.
2. Prijzen op basis van verbruik: er worden alleen kosten in rekening gebracht voor de rekenbronnen die worden gebruikt om uw code uit te voeren.
3. De rekenbronnen worden op aanvraag geschaald op basis van verkeer, zonder dat de ontwikkelaar enige configuratie hoeft uit te kunnen.

Functies worden uitgevoerd wanneer er een externe trigger plaatsvindt, zoals een HTTP-aanvraag of een bericht dat in een wachtrij binnenkomt. Dit maakt een gebeurtenisgestuurde architectuurstijl natuurlijk voor serverloze architecturen. Als u het werk tussen onderdelen in de architectuur wilt coördineren, kunt u berichtenbrokers of pub-/subpatronen gebruiken. Zie Kiezen tussen Azure-servicesdie berichten bezorgen voor hulp bij het kiezen tussen berichtentechnologieën in Azure.

Architectuur

De architectuur bestaat uit de volgende onderdelen:

Blob Storage. Statische webinhoud, zoals HTML-, CSS- en JavaScript-bestanden, wordt opgeslagen in Azure Blob Storage en wordt aan clients bediend met behulp van statische websitehosting. Alle dynamische interactie vindt plaats via JavaScript-code die aanroepen doet naar de back-end-API's. Er is geen code aan de serverzijde om de webpagina weer te geven. Hosting van statische websites ondersteunt indexdocumenten en aangepaste 404-foutpagina's.

CDN. Gebruik Azure Content Delivery Network (CDN) om inhoud in de cache op te slaan voor een lagere latentie en snellere levering van inhoud, en om een HTTPS-eindpunt te bieden.

Functie-apps. Azure Functions is een serverloze rekenoptie. Er wordt gebruikgemaakt van een gebeurtenisgestuurd model, waarbij een stukje code (een 'functie') wordt aangeroepen door een trigger. In deze architectuur wordt de functie aangeroepen wanneer een client een HTTP-aanvraag indient. De aanvraag wordt altijd gerouteerd via een API-gateway, zoals hieronder wordt beschreven.

API Management. API Management biedt een API-gateway die zich voor de HTTP-functie bevindt. U kunt deze API Management voor het publiceren en beheren van API's die worden gebruikt door clienttoepassingen. Het gebruik van een gateway helpt bij het loskoppelen van de front-endtoepassing van de back-end-API's. Zo kunnen API Management URL's herschrijven, aanvragen transformeren voordat ze de back-end bereiken, aanvraag- of antwoordheaders instellen, enzovoort.

API Management kunnen ook worden gebruikt voor het implementeren van alles-in-andere zaken, zoals:

• Gebruiksquota en snelheidslimieten afdwingen
• OAuth-tokens valideren voor verificatie
• Cross-Origin Requests (CORS) inschakelen
• Caching antwoorden
• Aanvragen voor bewaking en logboekregistratie

Als u niet alle functionaliteit van de API Management nodig hebt, kunt u ook Functions-proxies gebruiken. Met deze functie Azure Functions u één API-oppervlak voor meerdere functie-apps definiëren door routes naar back-endfuncties te maken. Functie-proxies kunnen ook beperkte transformaties uitvoeren op de HTTP-aanvraag en het antwoord. Ze bieden echter niet dezelfde uitgebreide op beleid gebaseerde mogelijkheden van API Management.

Cosmos DB. Cosmos DB is een databaseservice met meerdere modellen. Voor dit scenario haalt de functietoepassing documenten op uit Cosmos DB reactie op HTTP GET-aanvragen van de client.

Azure Active Directory (Azure AD). Gebruikers melden zich aan bij de webtoepassing met hun Azure AD-referenties. Azure AD retourneert een toegangs token voor de API, die door de webtoepassing wordt gebruikt voor het verifiëren van API-aanvragen (zie Verificatie).

Azure Monitor. Monitor verzamelt metrische prestatiegegevens over de Azure-services die in de oplossing zijn geïmplementeerd. Door deze in een dashboard te visualiseren, krijgt u inzicht in de status van de oplossing. Ook werden er toepassingslogboeken verzameld.

Azure Pipelines. Pijplijnen is een SERVICE voor continue integratie (CI) en continue levering (CD) die de toepassing bouwt, test en implementeert.

GitHub Acties. Werkstroom is een geautomatiseerd proces (CI/CD) dat u in uw opslagplaats GitHub instellen. U kunt elk project bouwen, testen, verpakken, vrijgeven of implementeren op GitHub met een werkstroom.

Aanbevelingen

Functie-app-plannen

Azure Functions ondersteunt twee hostingmodellen. Met het verbruiksplan wordt automatisch rekenkracht toegewezen wanneer uw code wordt uitgevoerd. Met het App Service wordt een set VM's toegewezen voor uw code. Het App Service definieert het aantal VM's en de VM-grootte.

Houd er rekening mee dat App Service serverloze plan niet strikt serverloos is, volgens de hierboven opgegeven definitie. Het programmeermodel is hetzelfde, maar dezelfde functiecode kan worden uitgevoerd in zowel een verbruiksplan als — een App Service abonnement.

Hier zijn enkele factoren waarmee u rekening moet houden bij het kiezen van het type plan dat u wilt gebruiken:

• Koude start. Met het verbruiksplan leidt een functie die niet onlangs is aangeroepen tot extra latentie bij de volgende keer dat deze wordt uitgevoerd. Deze extra latentie wordt veroorzaakt door het toewijzen en voorbereiden van de runtime-omgeving. Dit gebeurt meestal in de volgorde van seconden, maar is afhankelijk van verschillende factoren, waaronder het aantal afhankelijkheden dat moet worden geladen. Zie Understanding Serverless Cold Start (Serverloze koude start) voor meer informatie. Koude start is meestal belangrijker voor interactieve workloads (HTTP-triggers) dan asynchrone berichtgestuurde workloads (wachtrij- of Event Hubs-triggers), omdat de extra latentie rechtstreeks door gebruikers wordt waargenomen.
• Time-outperiode. In het verbruiksplan t/m een time-out voor de uitvoering van een functie na een configureerbare periode (tot maximaal 10 minuten)
• Isolatie van virtueel netwerk. Door een App Service-abonnement te gebruiken, kunnen functies worden uitgevoerd in een App Service Environment. Dit is een toegewezen en geïsoleerde hostingomgeving.
• Prijsmodel. Het verbruiksplan wordt gefactureerd op het aantal uitvoeringen en het resourceverbruik × (uitvoeringstijd van het geheugen). Het App Service wordt per uur gefactureerd op basis van de SKU van het VM-exemplaar. Vaak is het verbruiksplan goedkoper dan een App Service abonnement, omdat u alleen betaalt voor de rekenbronnen die u gebruikt. Dit geldt met name als uw verkeer pieken en dalen ervaart. Als een toepassing echter een constante hoge doorvoersnelheid heeft, kan een App Service minder kosten dan het verbruiksplan.
• Schalen. Een groot voordeel van het verbruiksmodel is dat het naar behoefte dynamisch schaalt op basis van het binnenkomende verkeer. Hoewel deze schaalbaarheid snel plaatsvindt, is er nog steeds een opschalingsperiode. Voor sommige workloads wilt u de VM's mogelijk opzettelijk te veel in de toekomst in gebruik nemen, zodat u bursts van verkeer kunt verwerken zonder dat u meer tijd nodig hebt. In dat geval kunt u een App Service overwegen.

Grenzen van functie-apps

Een functie-app fungeert als host voor de uitvoering van een of meer functies. U kunt een functie-app gebruiken om verschillende functies te groepen als een logische eenheid. Binnen een functie-app delen de functies dezelfde toepassingsinstellingen, hetzelfde hostingplan en dezelfde implementatielevenscyclus. Elke functie-app heeft een eigen hostnaam.

Gebruik functie-apps om functies te groeperen die dezelfde levenscyclus en instellingen delen. Functies die niet dezelfde levenscyclus delen, moeten worden gehost in verschillende functie-apps.

Overweeg een microservicesbenadering waarbij elke functie-app één microservice vertegenwoordigt, die mogelijk uit verschillende gerelateerde functies bestaat. In een microservicesarchitectuur moeten services losjes worden gekoppeld en een hoge functionele samenhang hebben. Losjes gekoppeld betekent dat u één service kunt wijzigen zonder dat andere services tegelijkertijd moeten worden bijgewerkt. Samenhangend betekent dat een service één goed gedefinieerd doel heeft. Zie Microservices ontwerpen: domeinanalyse voor meer informatie over deze ideeën.

Functiebindingen

Gebruik waar mogelijk Functions-bindingen. Bindingen bieden een declaratieve manier om uw code te verbinden met gegevens en te integreren met andere Azure-services. Een invoerbinding vult een invoerparameter uit een externe gegevensbron. Een uitvoerbinding verzendt de retourwaarde van de functie naar een gegevenss sink, zoals een wachtrij of database.

De functie in de GetStatus referentie-implementatie gebruikt bijvoorbeeld de Cosmos DB invoerbinding. Deze binding is geconfigureerd om een document op te zoeken in Cosmos DB, met behulp van queryparameters die zijn overgenomen uit de queryreeks in de HTTP-aanvraag. Als het document wordt gevonden, wordt het als parameter doorgegeven aan de functie.

[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)
{
    ...
}

Door bindingen te gebruiken, hoeft u geen code te schrijven die rechtstreeks met de service praat, waardoor de functiecode eenvoudiger wordt en ook de details van de gegevensbron of sink worden geabstraheerd. In sommige gevallen hebt u echter mogelijk complexere logica nodig dan de binding biedt. In dat geval gebruikt u de Azure-client-SDK's rechtstreeks.

Schaalbaarheidsoverwegingen

Functies. Voor het verbruiksplan wordt de HTTP-trigger geschaald op basis van het verkeer. Er geldt een limiet voor het aantal gelijktijdige functie-exemplaren, maar elk exemplaar kan meer dan één aanvraag tegelijk verwerken. Voor een App Service-abonnement wordt de HTTP-trigger geschaald op basis van het aantal VM-exemplaren. Dit kan een vaste waarde zijn of automatisch schalen op basis van een set regels voor automatisch schalen. Zie Schalen Azure Functions hosten voor meer informatie.

Cosmos DB. De doorvoercapaciteit voor Cosmos DB wordt gemeten in aanvraageenheden (RU's). Een doorvoer van 1 RU komt overeen met de doorvoer die nodig is om een 1 KB-document op te halen. Als u een Cosmos DB container van meer dan 10.000 RU wilt schalen, moet u een partitiesleutel opgeven wanneer u de container maakt en de partitiesleutel opgeeft in elk document dat u maakt. Zie Partition and scale in Azure Cosmos DB voor meer informatie over partitiesleutels.

API Management. API Management kunt uitschalen en ondersteunt automatisch schalen op basis van regels. Het schaalproces duurt ten minste 20 minuten. Als uw verkeer bursty is, moet u inrichten voor het maximale burst-verkeer dat u verwacht. Automatische schalen is echter handig voor het verwerken van variaties in verkeer per uur of per dag. Zie Automatisch een Azure API Management schalen voor meer informatie.

Overwegingen voor herstel na noodgeval

De hier weergegeven implementatie bevindt zich in één Azure-regio. Voor een robuustere benadering van herstel na noodherstel kunt u profiteren van de geo-distributiefuncties in de verschillende services:

• API Management ondersteunt implementatie in meerdere regio's, die kan worden gebruikt om één exemplaar van API Management te distribueren over een aantal Azure-regio's. Zie How to deploy an Azure API Management service instance to multiple Azure regions (Een Azure API Management-service-exemplaar implementeren in meerdere Azure-regio's) voor meer informatie.

• Gebruik Traffic Manager om HTTP-aanvragen naar de primaire regio te routeer. Als de functie-app die in die regio wordt uitgevoerd niet meer beschikbaar is, Traffic Manager fail over naar een secundaire regio.

• Cosmos DB ondersteunt meerdere schrijfregio's.Hiermee kunt u schrijfgegevens schrijven naar elke regio die u aan uw Cosmos DB toevoegt. Als u multi-write niet inschakelen, kunt u nog steeds een fail over de primaire schrijfregio. De Cosmos DB client-SDK's en de Azure Function-bindingen verwerken de failover automatisch, zodat u geen toepassingsconfiguratie-instellingen hoeft bij te werken.

Beveiligingsoverwegingen

Verificatie

De GetStatus API in de referentie-implementatie gebruikt Azure AD om aanvragen te verifiëren. Azure AD ondersteunt het OpenID Verbinding maken-protocol, een verificatieprotocol dat boven op het OAuth 2-protocol is gebouwd.

In deze architectuur is de clienttoepassing een toepassing met één pagina (SPA) die wordt uitgevoerd in de browser. Dit type clienttoepassing kan een clientgeheim of een autorisatiecode niet verborgen houden, dus de impliciete toekenningsstroom is geschikt. (Zie Welke OAuth 2.0-stroom moet ik gebruiken?). Dit is de algehele stroom:

1. De gebruiker klikt op de koppeling 'Aanmelden' in de webtoepassing.
2. De browser wordt omgeleid naar de aanmeldingspagina van Azure AD.
3. De gebruiker meldt zich aan.
4. Azure AD wordt teruggeleid naar de clienttoepassing, met inbegrip van een toegangs token in het URL-fragment.
5. Wanneer de webtoepassing de API aanroept, bevat deze het toegangs token in de verificatieheader. De toepassings-id wordt verzonden als de doelgroepclaim ('aud') in het toegangs token.
6. De back-end-API valideert het toegangsken.

Verificatie configureren:

• Registreer een toepassing in uw Azure AD-tenant. Hiermee wordt een toepassings-id gegenereerd, die de client met de aanmeldings-URL bevat.

• Schakel Azure AD-verificatie in de functie-app in. Raadpleeg Verificatie en autorisatie in Azure App Service voor meer informatie.

• Voeg het validate-jwt-beleid toe aan API Management aanvraag vooraf te autoriëren door het toegangsteken te valideren.

Zie het leesmij-GitHub voor meer informatie.

Het is raadzaam om afzonderlijke app-registraties te maken in Azure AD voor de clienttoepassing en de back-end-API. Verleen de clienttoepassing toestemming om de API aan te roepen. Deze aanpak biedt u de flexibiliteit om meerdere API's en clients te definiëren en de machtigingen voor elke API te bepalen.

Gebruik binnen een API-scopes om toepassingen een fijnkeurige controle te geven over welke machtigingen ze aanvragen van een gebruiker. Een API kan bijvoorbeeld - en -scopes hebben en een bepaalde client-app kan de gebruiker vragen om Read Write alleen Read machtigingen te verlenen.

Autorisatie

In veel toepassingen moet de back-end-API controleren of een gebruiker toestemming heeft om een bepaalde actie uit te voeren. Het is raadzaam om op claims gebaseerde autorisatie te gebruiken, waarbij informatie over de gebruiker wordt overgebracht door de id-provider(in dit geval Azure AD) en wordt gebruikt om autorisatiebeslissingen te nemen. Wanneer u bijvoorbeeld een toepassing registreert in Azure AD, kunt u een set toepassingsrollen definiëren. Wanneer een gebruiker zich bij de toepassing meldt, bevat Azure AD een claim voor elke rol die aan de gebruiker is verleend, inclusief rollen die zijn overgenomen via roles groepslidmaatschap.

Het id-token dat Azure AD retourneert naar de client bevat enkele claims van de gebruiker. Binnen de functie-app zijn deze claims beschikbaar in de X-MS-CLIENT-PRINCIPAL-header van de aanvraag. Het is echter eenvoudiger om deze informatie te lezen uit bindingsgegevens. Voor andere claims gebruikt u Microsoft Graph om query's uit te voeren op Azure AD. (De gebruiker moet toestemming geven voor deze actie bij het aanmelden.)

Zie Werken met clientidentiteiten voor meer informatie.

CORS

In deze referentiearchitectuur delen de webtoepassing en de API niet dezelfde oorsprong. Dit betekent dat wanneer de toepassing de API aanroept, het een cross-origin-aanvraag is. Browserbeveiliging voorkomt dat een webpagina AJAX-aanvragen indient bij een ander domein. Deze beperking wordt het same origin-beleid genoemd en voorkomt dat een kwaadwillende site gevoelige gegevens van een andere site leest. Als u een cross-origin-aanvraag wilt inschakelen, voegt u een CORS-beleid (Cross-Origin Resource Sharing) toe aan API Management gateway:

<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>

In dit voorbeeld is het kenmerk allow-credentials true. Hiermee wordt de browser gemachtigd om referenties (inclusief cookies) met de aanvraag te verzenden. Anders verzendt de browser standaard geen referenties met een cross-origin-aanvraag.

HTTPS afdwingen

Voor maximale beveiliging is HTTPS vereist in de aanvraagpijplijn:

• CDN. Azure CDN ondersteunt standaard HTTPS op *.azureedge.net het subdomein. Als u HTTPS wilt inschakelen in CDN voor aangepaste domeinnamen, zie Zelfstudie: HTTPSconfigureren op een Azure CDN aangepast domein.

• Statische website die als host voor gebruikt wordt. Schakel de optieVeilige overdracht vereistin op het Storage account. Wanneer deze optie is ingeschakeld, staat het opslagaccount alleen aanvragen van beveiligde HTTPS-verbindingen toe.

• API Management. Configureer de API's om alleen het HTTPS-protocol te gebruiken. U kunt dit configureren in de Azure Portal of via een Resource Manager sjabloon:

  {
      "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. Schakel de instelling'Alleen HTTPS'in.

De functie-app vergrendelen

Alle aanroepen naar de functie moeten via de API-gateway gaan. U kunt dit als volgt doen:

• Configureer de functie-app om een functiesleutel te vereisen. De API Management-gateway bevat de functiesleutel wanneer deze de functie-app aanroept. Dit voorkomt dat clients de functie rechtstreeks aanroepen, waardoor de gateway wordt omzeild.

• De API Management-gateway heeft een statisch IP-adres. Beperk de Azure-functie om alleen aanroepen vanaf dat statische IP-adres toe te staan. Zie Statische IP Azure App Service beperkingen voor meer informatie. (Deze functie is alleen beschikbaar voor services in de Standard-laag.)

Toepassingsgeheimen beveiligen

Sla toepassingsgeheimen, zoals databasereferenties, niet op in uw code of configuratiebestanden. Gebruik in plaats daarvan App-instellingen, die versleuteld zijn opgeslagen in Azure. Zie Beveiliging in Azure App Service en Azure Functions voor meer Azure Functions.

U kunt toepassingsgeheimen ook opslaan in Key Vault. Hiermee kunt u de opslag van geheimen centraliseren, de distributie ervan bepalen en controleren hoe en wanneer geheimen worden gebruikt. Zie Een Azure-webtoepassing configureren voor het lezenvan een geheim uit Key Vault. Houd er echter rekening mee dat de configuratie-instellingen van Functions-triggers en -bindingen vanuit app-instellingen worden geladen. Er is geen ingebouwde manier om de triggers en bindingen te configureren voor het gebruik van Key Vault geheimen.

DevOps overwegingen

Front-endimplementatie

De front-end van deze referentiearchitectuur is een toepassing met één pagina, met JavaScript toegang tot de serverloze back-end-API's en statische inhoud die een snelle gebruikerservaring biedt. Hier volgen enkele belangrijke overwegingen voor een dergelijke toepassing:

• Implementeer de toepassing op uniforme wijze voor gebruikers in een breed geografisch gebied met een wereldwijd CDN, met de statische inhoud die in de cloud wordt gehost. Dit voorkomt dat u een toegewezen webserver nodig hebt. Lees Een Azure Storage-account integreren met Azure CDN om aan de slag te gaan. Beveilig uw toepassing met HTTPS. Lees de Aanbevolen procedures voor het gebruik van netwerken voor contentlevering voor aanvullende aanbevelingen.
• Gebruik een snelle en betrouwbare CI/CD-service, zoals Azure Pipelines of GitHub Actions,om automatisch elke bronwijziging te bouwen en te implementeren. De bron moet zich in een online versiebeheersysteem bevinden. Lees Uw eerste pijplijn maken voor meer informatie over Azure Pipelines. Zie Apps implementeren in Azure voor GitHub acties voor Azure.
• Comprimeren van uw websitebestanden om het bandbreedteverbruik op de CDN prestaties te verbeteren. Azure CDN kunt compressie op de randservers. De implementatiepijplijn in deze referentiearchitectuur comprimeert de bestanden ook voordat ze in de Blob-opslag worden geïmplementeerd. Dit vermindert de opslagvereiste en geeft u meer vrijheid om de compressiehulpprogramma's te kiezen, ongeacht CDN beperkingen.
• De CDN moet de cache kunnen leegmaken om ervoor te zorgen dat alle gebruikers de nieuwste inhoud krijgen. Cache leegmaken is vereist als de build- en implementatieprocessen niet atomisch zijn, bijvoorbeeld als ze oude bestanden vervangen door nieuw gebouwde bestanden in dezelfde oorspronkelijke map.
• Voor een andere cachestrategie, zoals versiebeleid met behulp van -directories, is mogelijk geen opsting door de CDN. De build-pijplijn in deze front-endtoepassing maakt een nieuwe map voor elke nieuw gebouwde versie. Deze versie wordt als atomische eenheid geüpload naar de Blob-opslag. De Azure CDN wijst pas naar deze nieuwe versie na een voltooide implementatie.
• Verhoog de cache-TTL door resourcebestanden voor een langere duur op te slaan in de cache, die maanden beslaat. Om ervoor te zorgen dat de bestanden in de cache worden bijgewerkt wanneer ze worden gewijzigd, moet u de bestandsnamen een vingerafdruk geven wanneer ze opnieuw worden gemaakt. Met deze front-endtoepassing worden alle bestanden met uitzondering van openbare bestanden, zoalsindex.html. Omdat de index.html regelmatig wordt bijgewerkt, worden de gewijzigde bestandsnamen weergegeven waardoor de cache wordt vernieuwd. Zie Verloopdatum van webinhoud beheren in Azure CDN voor meer informatie.

Back-endimplementatie

Voor het implementeren van de functie-app raden we u aan pakketbestanden ('Uitvoeren vanuit pakket') te gebruiken. Met deze methode uploadt u een zip-bestand naar een Blob Storage-container en wordt het ZIP-bestand door de Functions-runtime als een alleen-lezen bestandssysteem aan het bestandssysteem toegevoegd. Dit is een atomische bewerking, waardoor de kans wordt verkleind dat een mislukte implementatie de toepassing in een inconsistente status laat. Het kan ook koude starttijden verbeteren, met name voor Node.js apps, omdat alle bestanden in één keer worden gewisseld.

API-versieversies

Een API is een contract tussen een service en clients. In deze architectuur wordt het API-contract gedefinieerd op API Management laag. API Management ondersteunt twee verschillende maar aanvullende versieconcepten:

• Met versies kunnen API-consumenten een API-versie kiezen op basis van hun behoeften, zoals v1 versus v2.

• Met revisies kunnen API-beheerders niet-belangrijke wijzigingen aanbrengen in een API en deze wijzigingen implementeren, samen met een wijzigingslogboek om API-consumenten te informeren over de wijzigingen.

Als u een belangrijke wijziging aan brengt in een API, publiceert u een nieuwe versie in API Management. Implementeer de nieuwe versie naast de oorspronkelijke versie in een afzonderlijke functie-app. Hiermee kunt u bestaande clients migreren naar de nieuwe API zonder clienttoepassingen te verbreken. Uiteindelijk kunt u de vorige versie afvangen. API Management ondersteunt verschillende versieschema's:URL-pad, HTTP-header of queryreeks. Zie Versioning a RESTful web API (Versie maken van een RESTful-web-API)voor meer informatie over API-versieversies in het algemeen.

Voor updates die geen wijzigingen in de API veroorzaken, implementeert u de nieuwe versie in een staging-sleuf in dezelfde functie-app. Controleer of de implementatie is geslaagd en verwissel vervolgens de gefaseerd versie met de productieversie. Publiceer een revisie in API Management.

Kostenoverwegingen

Gebruik de Azure-prijscalculator om een schatting van de kosten te maken. Houd rekening met deze punten om de kosten van deze architectuur te optimaliseren.

Azure Functions

Azure Functions ondersteunt twee hostingmodellen.

• Verbruiksplan.

  Rekenkracht wordt automatisch toegewezen wanneer uw code wordt uitgevoerd.

• App Service plan.

  Er wordt een set VM's toegewezen voor uw code. Dit plan definieert het aantal VM's en de VM-grootte.

In deze architectuur wordt een functie aangeroepen wanneer een client een HTTP-aanvraag indient. Omdat in dit gebruiksgeval geen constante grote doorvoer wordt verwacht, wordt het verbruiksplan aanbevolen omdat u alleen betaalt voor de rekenbronnen die u gebruikt.

Azure Cosmos DB

Azure Cosmos DB facturen voor inrichtende doorvoer en verbruikte opslag per uur. Inrichten van doorvoer wordt uitgedrukt in aanvraageenheden per seconde (RU/s), die kunnen worden gebruikt voor typische databasebewerkingen, zoals invoegingen, leesbewerkingen. De prijs is gebaseerd op de capaciteit in RU/s die u reserveert.

Storage wordt gefactureerd voor elke GB die wordt gebruikt voor uw opgeslagen gegevens en index.

Zie Cosmos DB prijsmodel voor meer informatie.

In deze architectuur haalt de functietoepassing documenten op uit Cosmos DB reactie op HTTP GET-aanvragen van de client. Cosmos DB is in dit geval rendabel omdat leesbewerkingen aanzienlijk goedkoper zijn dan schrijfbewerkingen uitgedrukt in RU/s.

Content Delivery Network

Het factureringspercentage kan verschillen, afhankelijk van de factureringsregio op basis van de locatie van de bronserver die de inhoud aan de eindgebruiker levert. De fysieke locatie van de client is niet de factureringsregio. Elke HTTP- of HTTPS-aanvraag die de CDN is een factureerbare gebeurtenis, die alle antwoordtypen omvat: geslaagd, mislukt of anders. Verschillende antwoorden kunnen verschillende verkeersbedragen genereren.

In deze referentiearchitectuur bevindt de implementatie zich in één Azure-regio.

Als u de kosten wilt verlagen, kunt u de cache-TTL verhogen door resourcebestanden voor een langere duur in de cache op te slaan en de langst mogelijke TTL voor uw inhoud in te stellen.

Zie de sectie Kosten in Microsoft Azure Well-Architected Framework voor meer informatie.

De oplossing implementeren

Als u de referentie-implementatie voor deze architectuur wilt implementeren, zie GitHub readme.

Volgende stappen

Lees code walkthrough: Serverloze toepassingmet Azure Functions voor meer informatie over de referentie-implementatie.

Verwante richtlijnen:

• Best practices voor het gebruik van CDN's
• Patroon Hosting van statische inhoud