Serverloze webtoepassing

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

Er zijn twee referentie-implementaties voor deze architectuur beschikbaar op GitHub: Drone Delivery App (ARM & Azure Pipelines) en Taken-app (Bicep & GitHub Actions).

Architectuur

Een Visio-bestand van deze architectuur downloaden.

De term serverloos heeft twee verschillende maar gerelateerde betekenissen:

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

Beide definities hebben gemeen 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 rekenresources die worden gebruikt om uw code uit te voeren.
3. De rekenresources worden op aanvraag geschaald op basis van verkeer, zonder dat de ontwikkelaar een configuratie hoeft uit te voeren.

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

Onderdelen

De architectuur bestaat uit de volgende onderdelen:

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

CDN. Gebruik Azure Content Delivery Network (CDN) om inhoud op te cachen voor een lagere latentie en snellere levering van inhoud, en om een HTTPS-eindpunt op te geven.

Functie-apps. Azure Functions is een serverloze rekenoptie. Het maakt gebruik 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 doet. De aanvraag wordt altijd gerouteerd via een API-gateway, zoals hieronder wordt beschreven.

API Management. Azure API Management biedt een API-gateway die zich vóór de HTTP-functie bevindt. U kunt API Management gebruiken voor het publiceren en beheren van API's die worden gebruikt door clienttoepassingen. Met behulp van een gateway kunt u de front-endtoepassing loskoppelen van de back-end-API's. API Management kan bijvoorbeeld URL's herschrijven, aanvragen transformeren voordat ze de back-end bereiken, aanvraag- of antwoordheaders instellen, enzovoort.

API Management kan ook worden gebruikt om kruislingse problemen te implementeren, zoals:

• Gebruiksquota en frequentielimieten afdwingen
• OAuth-tokens valideren voor verificatie
• CORS (Cross-Origin Requests) inschakelen
• Antwoorden opslaan in cache
• Aanvragen voor bewaking en logboekregistratie

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

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

Microsoft Entra-id (Microsoft Entra-id). Gebruikers melden zich aan bij de webtoepassing met behulp van hun Microsoft Entra ID-referenties . Microsoft Entra ID retourneert een toegangstoken voor de API, die door de webtoepassing wordt gebruikt voor het verifiëren van API-aanvragen (zie Verificatie).

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

Azure Pipelines. Azure Pipelines is een service voor continue integratie (CI) en continue levering (CD) waarmee de toepassing wordt gebouwd, getest en geïmplementeerd.

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

Scenariodetails

Potentiële gebruikscases

Deze droneleveringsoplossing is ideaal voor de luchtvaart-, luchtvaart-, luchtvaart- en robotica-industrie.

Aanbevelingen

Plannen voor functie-apps

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

Houd er rekening mee dat het App Service-plan niet strikt serverloos is, volgens de bovenstaande definitie. Het programmeermodel is echter hetzelfde. Dezelfde functiecode kan echter worden uitgevoerd in zowel een verbruiksabonnement als een App Service-plan.

Hier volgen enkele factoren waarmee u rekening moet houden bij het kiezen van welk type abonnement u wilt gebruiken:

• Koude start. Met het verbruiksabonnement krijgt een functie die onlangs niet is aangeroepen, extra latentie wanneer deze wordt uitgevoerd. Deze extra latentie wordt veroorzaakt door het toewijzen en voorbereiden van de runtime-omgeving. Dit is meestal afhankelijk van de volgorde van seconden, maar is afhankelijk van verschillende factoren, waaronder het aantal afhankelijkheden dat moet worden geladen. Zie Serverloze koude start voor meer informatie. Koude start is meestal meer een probleem voor interactieve workloads (HTTP-triggers) dan asynchrone berichtgestuurde werkbelastingen (wachtrij- of event hubs-triggers), omdat de extra latentie rechtstreeks wordt waargenomen door gebruikers.
• Time-outperiode. In het verbruiksabonnement treedt er een time-out op voor de uitvoering van een functie na een configureerbare periode (tot maximaal 10 minuten)
• Isolatie van virtuele netwerken. Met behulp van een App Service-plan kunnen functies worden uitgevoerd binnen een App Service-omgeving. Dit is een toegewezen en geïsoleerde hostingomgeving.
• Prijsmodel. Het verbruiksplan wordt gefactureerd op basis van het aantal uitvoeringen en resourceverbruik (geheugen × uitvoeringstijd). Het App Service-plan wordt elk uur gefactureerd op basis van de SKU van het VM-exemplaar. Vaak kan het verbruiksabonnement goedkoper zijn dan een App Service-abonnement, omdat u alleen betaalt voor de rekenresources die u gebruikt. Dit geldt vooral als uw verkeer pieken en dalen ondervindt. Als een toepassing echter een constante doorvoer met een hoog volume ondervindt, kan een App Service-abonnement minder kosten dan het verbruiksabonnement.
• Schalen. Een groot voordeel van het verbruiksmodel is dat het dynamisch wordt geschaald op basis van het binnenkomende verkeer. Hoewel deze schaal snel plaatsvindt, is er nog steeds een oplopende periode. Voor sommige workloads wilt u de VM's bewust te veel inrichten, zodat u bursts van verkeer met nul opstarttijd kunt afhandelen. In dat geval kunt u een App Service-plan overwegen.

Grenzen van functie-app

Een functie-app fungeert als host voor de uitvoering van een of meer functies. U kunt een functie-app gebruiken om verschillende functies als een logische eenheid te groeperen. Binnen een functie-app delen de functies dezelfde toepassingsinstellingen, hostingabonnementen en 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 te nemen, waarbij elke functie-app één microservice vertegenwoordigt, mogelijk bestaande uit verschillende gerelateerde functies. In een microservicesarchitectuur moeten services losse koppeling en een hoge functionele samenhang hebben. Losjes gekoppeld betekent dat u de ene service kunt wijzigen zonder dat andere services tegelijkertijd moeten worden bijgewerkt. Samenhang betekent dat een service één goed gedefinieerd doel heeft. Zie Microservices ontwerpen: Domeinanalyse voor meer informatie over deze ideeën.

Functiebindingen

Gebruik indien 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 van een externe gegevensbron in. Een uitvoerbinding verzendt de retourwaarde van de functie naar een gegevenssink, zoals een wachtrij of database.

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

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

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 SDK's van de Azure-client rechtstreeks.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Schaalbaarheid

Functies. Voor het verbruiksabonnement wordt de HTTP-trigger geschaald op basis van het verkeer. Er is een limiet voor het aantal gelijktijdige functie-exemplaren, maar elk exemplaar kan meerdere aanvragen tegelijk verwerken. Voor een App Service-plan 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 Azure Functions schalen en hosten voor meer informatie.

Azure Cosmos DB. Doorvoercapaciteit voor Azure Cosmos DB wordt gemeten in aanvraageenheden (RU). Een doorvoer van 1 RU komt overeen met de doorvoer die nodig is om een document van 1 KB op te halen. Als u een Azure Cosmos DB-container na 10.000 RU wilt schalen, moet u een partitiesleutel opgeven wanneer u de container maakt en de partitiesleutel opnemen in elk document dat u maakt. Zie Partitie en schaal in Azure Cosmos DB voor meer informatie over partitiesleutels.

API Management. API Management kan uitschalen en ondersteuning bieden voor 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 schaalaanpassing is echter handig voor het verwerken van uur- of dagvariaties in het verkeer. Zie Automatisch een Azure API Management-exemplaar schalen voor meer informatie.

Herstel na noodgeval

De implementatie die hier wordt weergegeven, bevindt zich in één Azure-regio. Voor een flexibelere benadering van herstel na noodgevallen kunt u gebruikmaken van de functies voor geodistributie in de verschillende services:

• API Management biedt ondersteuning voor implementatie met meerdere regio's, die kunnen worden gebruikt om één API Management-exemplaar over een willekeurig aantal Azure-regio's te distribueren. Zie 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 routeren. Als de functie-app die in die regio wordt uitgevoerd niet meer beschikbaar is, kan Traffic Manager een failover uitvoeren naar een secundaire regio.

• Azure Cosmos DB ondersteunt meerdere schrijfregio's, waarmee schrijfbewerkingen worden uitgevoerd naar elke regio die u toevoegt aan uw Azure Cosmos DB-account. Als u meerdere schrijfbewerkingen niet inschakelt, kunt u nog steeds een failover uitvoeren voor de primaire schrijfregio. De Azure Cosmos DB-client-SDK's en de Azure Function-bindingen verwerken de failover automatisch, zodat u geen configuratie-instellingen voor toepassingen hoeft bij te werken.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

Verificatie

De GetStatus API in de referentie-implementatie maakt gebruik van Microsoft Entra-id om aanvragen te verifiëren. Microsoft Entra ID ondersteunt het OpenID Verbinding maken-protocol. Dit is een verificatieprotocol dat is gebouwd boven op het OAuth 2-protocol.

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

1. De gebruiker klikt op de koppeling Aanmelden in de webtoepassing.
2. De browser wordt omgeleid naar de aanmeldingspagina van Microsoft Entra.
3. De gebruiker meldt zich aan.
4. Microsoft Entra ID leidt terug naar de clienttoepassing, inclusief een toegangstoken in het URL-fragment.
5. Wanneer de webtoepassing de API aanroept, bevat deze het toegangstoken in de verificatieheader. De toepassings-id wordt verzonden als de doelgroepclaim ('aud') in het toegangstoken.
6. De back-end-API valideert het toegangstoken.

Verificatie configureren:

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

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

• Voeg het beleid validate-jwt toe aan API Management om de aanvraag vooraf te autoriseren door het toegangstoken te valideren.

Zie het Leesmij-leesmij-bestand van GitHub voor meer informatie.

Het is raadzaam om afzonderlijke app-registraties te maken in Microsoft Entra ID voor de clienttoepassing en de back-end-API. Verdeel de clienttoepassing toestemming om de API aan te roepen. Deze benadering biedt u de flexibiliteit om meerdere API's en clients te definiëren en de machtigingen voor elke api te beheren.

Gebruik binnen een API bereiken om toepassingen nauwkeurige controle te geven over de machtigingen die ze van een gebruiker aanvragen. Een API kan bijvoorbeeld een bereik hebben Read en Write bereiken hebben en een bepaalde client-app kan de gebruiker vragen om alleen machtigingen te autoriseren Read .

Autorisatie

In veel toepassingen moet de back-end-API controleren of een gebruiker gemachtigd is 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 Microsoft Entra-id) en wordt gebruikt om autorisatiebeslissingen te nemen. Wanneer u bijvoorbeeld een toepassing registreert in Microsoft Entra ID, kunt u een set toepassingsrollen definiëren. Wanneer een gebruiker zich aanmeldt bij de toepassing, bevat Microsoft Entra ID een roles claim voor elke rol waaraan de gebruiker is verleend, inclusief rollen die worden overgenomen via groepslidmaatschap.

Het id-token dat microsoft Entra-id naar de client retourneert, 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 een query uit te voeren op Microsoft Entra-id. (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. Dat 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 hetzelfde 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 de 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 waar. Hierdoor kan de browser referenties (inclusief cookies) met de aanvraag verzenden. Anders verzendt de browser standaard geen referenties met een cross-origin-aanvraag.

HTTPS afdwingen

Voor maximale beveiliging moet u HTTPS in de aanvraagpijplijn vereisen:

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

• Statische websitehosting. Schakel de optie Veilige overdracht vereist in voor het opslagaccount. Wanneer deze optie is ingeschakeld, staat het opslagaccount alleen aanvragen van beveiligde HTTPS-verbindingen toe.

• API Management. Configureer de API's alleen voor het gebruik van het HTTPS-protocol. U kunt dit configureren in 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 worden uitgevoerd. 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. Hiermee voorkomt u dat clients de functie rechtstreeks aanroepen, waardoor de gateway wordt overgeslagen.

• 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 Azure-app Statische IP-beperkingen voor services voor meer informatie. (Deze functie is alleen beschikbaar voor services in de Standard-laag.)

Toepassingsgeheimen beveiligen

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

U kunt ook toepassingsgeheimen opslaan in Key Vault. Hiermee kunt u de opslag van geheimen centraliseren, de distributie beheren en controleren hoe en wanneer geheimen worden geopend. Zie Een Azure-webtoepassing configureren om een geheim uit Key Vault te lezen voor meer informatie. Houd er echter rekening mee dat functions hun configuratie-instellingen laadt vanuit app-instellingen. Er is geen ingebouwde manier om de triggers en bindingen te configureren voor het gebruik van Key Vault-geheimen.

DevOps

Front-endimplementatie

De front-end van deze referentiearchitectuur is een toepassing met één pagina, waarbij JavaScript toegang heeft 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 uniform voor gebruikers in een breed geografisch gebied met een wereldwijd gereed CDN, met de statische inhoud die wordt gehost in de cloud. Dit voorkomt dat er een toegewezen webserver nodig is. Lees Een Azure-opslagaccount 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 meer informatie over GitHub Actions voor Azure.
• Comprimeer uw websitebestanden om het bandbreedteverbruik op het CDN te verminderen en de prestaties te verbeteren. Met Azure CDN kunt u tegelijkertijd compressie op de randservers uitvoeren. U kunt de implementatiepijplijn in deze referentiearchitectuur ook comprimeren 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 eventuele CDN-beperkingen.
• Het CDN moet de cache kunnen leegmaken om ervoor te zorgen dat alle gebruikers de meest recente inhoud worden geleverd. Een cache opschonen is vereist als de build- en implementatieprocessen niet atomisch zijn, bijvoorbeeld als ze oude bestanden vervangen door nieuwe ingebouwde bestanden in dezelfde oorspronkelijke map.
• Een andere cachestrategie, zoals versiebeheer met behulp van mappen, vereist mogelijk geen opschoning door het CDN. De build-pijplijn in deze front-endtoepassing maakt een nieuwe map voor elke nieuw gebouwde versie. Deze versie wordt geüpload als een atomische eenheid naar de Blob-opslag. De Azure CDN verwijst alleen naar deze nieuwe versie na een voltooide implementatie.
• Verhoog de TTL van de cache door resourcebestanden voor een langere duur in de cache op te nemen, die maanden beslaat. Als u ervoor wilt zorgen dat de bestanden in de cache worden bijgewerkt wanneer ze worden gewijzigd, vingerafdrukt u de bestandsnamen wanneer ze opnieuw worden opgebouwd. Deze front-endtoepassing vingerafdrukt alle bestanden, met uitzondering van openbare bestanden, zoals index.html. Omdat de index.html regelmatig wordt bijgewerkt, worden de gewijzigde bestandsnamen weergegeven die een cachevernieuwing veroorzaken. Zie de vervaldatum van webinhoud beheren in Azure CDN voor meer informatie.

Back-endimplementatie

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

API-versiebeheer

Een API is een contract tussen een service en clients. In deze architectuur wordt het API-contract gedefinieerd op de API Management-laag. API Management biedt ondersteuning voor twee afzonderlijke, maar aanvullende versiebeheerconcepten:

• Met versies kunnen API-gebruikers 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-gebruikers te informeren over de wijzigingen.

Als u een belangrijke wijziging aanbrengt 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 breken. Uiteindelijk kunt u de vorige versie verwijderen. API Management ondersteunt verschillende versiebeheerschema's: URL-pad, HTTP-header of querytekenreeks. Zie Versiebeheer voor een RESTful-web-API voor meer informatie over API-versiebeheer in het algemeen.

Voor updates die geen belangrijke API-wijzigingen veroorzaken, implementeert u de nieuwe versie in een staging-site in dezelfde functie-app. Controleer of de implementatie is geslaagd en vervang vervolgens de gefaseerde versie door de productieversie. Publiceer een revisie in API Management.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

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.

• Verbruiksabonnement.

  Rekenkracht wordt automatisch toegewezen wanneer uw code wordt uitgevoerd.

• App Service-plan.

  Er wordt een set virtuele machines 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 doet. Omdat een constante doorvoer met een hoog volume niet wordt verwacht in dit gebruiksscenario, wordt het verbruiksplan aanbevolen omdat u alleen betaalt voor de rekenresources die u gebruikt.

Azure Cosmos DB

Azure Cosmos DB factureert voor ingerichte doorvoer en verbruikte opslag per uur. Ingerichte 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.

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

Zie het prijsmodel van Azure Cosmos DB voor meer informatie.

In deze architectuur haalt de functietoepassing documenten op uit Azure Cosmos DB als reactie op HTTP GET-aanvragen van de client. Azure Cosmos DB is in dit geval rendabel omdat leesbewerkingen aanzienlijk goedkoper zijn dan schrijfbewerkingen die worden uitgedrukt op 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. Een HTTP- of HTTPS-aanvraag die het CDN bereikt, is een factureerbare gebeurtenis, die alle antwoordtypen bevat: geslaagd, mislukt of andere. 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 overwegen om de TTL van de cache te verhogen door bronbestanden voor een langere duur in de cache op te slaan en de langste TTL in te stellen die mogelijk is voor uw inhoud.

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

Dit scenario implementeren

Als u de referentie-implementatie voor deze architectuur wilt implementeren, raadpleegt u het Leesmij-leesmij-bestand voor GitHub.

Volgende stappen

Productdocumentatie:

• Wat is Azure Blob Storage?
• Azure-netwerk voor contentlevering (CDN)
• Inleiding tot Azure Functions
• Meer informatie over API Management
• Welkom bij Azure Cosmos DB
• Microsoft Entra ID
• Overzicht van Azure Monitor
• Wat is Azure Pipelines?

Learn-modules:

• Kies de beste serverloze Azure-technologie voor uw bedrijfsscenario
• Serverloze logica maken met Azure Functions

Verwante resources

Lees code-overzicht voor meer informatie over de referentie-implementatie: Serverloze toepassing met Azure Functions.

Verwante richtlijnen:

• Aanbevolen procedures voor het gebruik van CDN's
• Patroon Voor het hosten van statische inhoud