Serverlose Webanwendung

Microsoft Entra ID

Azure API Management

Azure Blob Storage

Azure Content Delivery Network

Azure-Funktionen

Azure Monitor

Diese Referenzarchitektur zeigt eine serverlose Webanwendung. Die Anwendung stellt statische Inhalte aus Azure Blob Storage bereit und implementiert eine API mit Azure Functions. Die API liest Daten aus Azure Cosmos DB und gibt die Ergebnisse an die Web-App zurück.

GitHub-Logo Für diese Architektur sind zwei Referenzimplementierungen auf GitHub verfügbar: Drone Delivery App (App für Drohnenlieferung, ARM Azure Pipelines) und To Do App (Aufgaben-App, Bicep and GitHub Actions).

Architektur

Diagramm der Referenzarchitektur einer serverlosen Webanwendung.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Der Begriff „serverlos“ hat zwei separate Bedeutungen, die aber miteinander zusammenhängen:

Back-End-as-a-Service (BaaS). Back-End-Clouddienste, z. B. Datenbanken und Speicher, stellen APIs bereit, mit denen Clientanwendungen eine direkte Verbindung mit diesen Diensten herstellen können.
Functions-as-a-Service (FaaS). Bei diesem Modell ist eine „Funktion“ ein Codeabschnitt, der in der Cloud bereitgestellt und in einer Hostumgebung ausgeführt wird, in der die Server für die Ausführung des Codes vollständig abstrahiert werden.

Für beide Definitionen steckt die Idee dahinter, dass Entwickler und DevOps-Benutzer keine Server bereitstellen, konfigurieren oder verwalten müssen. Bei dieser Referenzarchitektur liegt der Schwerpunkt auf FaaS mit Azure Functions. Die Bereitstellung von Webinhalten aus Azure Blob Storage ist ein Beispiel für BaaS. Hier sind einige wichtige Merkmale von FaaS angegeben:

Computeressourcen werden je nach den Anforderungen der Plattform dynamisch zugeordnet.
Nutzungsbasierte Preise: Ihnen werden nur die Computeressourcen berechnet, die zum Ausführen des Codes verwendet werden.
Die Computeressourcen werden bedarfsabhängig anhand des Datenverkehrs skaliert, ohne dass der Entwickler eine Konfiguration durchführen muss.

Die Funktionen werden ausgeführt, wenn ein externer Auslöser vorliegt, z.B. eine HTTP-Anforderung oder der Empfang einer Nachricht in einer Warteschlange. Daher ist ein ereignisgesteuerter Architekturstil die natürliche Wahl für serverlose Architekturen. Für die Koordinierung der Arbeit zwischen den Komponenten der Architektur können Sie erwägen, Nachrichtenbroker oder Pub/Sub-Muster zu nutzen. Hilfe zur Auswahl der richtigen Messagingtechnologie in Azure finden Sie unter Auswählen zwischen Azure-Diensten für die Nachrichtenübermittlung.

Komponenten

Die Architektur umfasst die folgenden Komponenten:

Blobspeicher. Statische Webinhalte, z. B. HTML-, CSS- und JavaScript-Dateien, werden in Azure Blob Storage gespeichert und für Clients unter Verwendung des Hostens statischer Websites bereitgestellt. Alle dynamischen Interaktionen erfolgen über JavaScript-Code, der Back-End-APIs aufruft. Es ist kein serverseitiger Code zum Rendern der Webseite vorhanden. Für das Hosten statischer Websites werden Indexdokumente und benutzerdefinierte 404-Fehlerseiten unterstützt.

Content Delivery Network. Verwenden Sie Azure Content Delivery Network zum Zwischenspeichern von Inhalten, um eine geringere Latenz und schnellere Bereitstellung eines HTTPS-Endpunkts zu erzielen.

Funktions-Apps. Azure Functions ist eine serverlose Computeoption. Es wird ein ereignisgesteuertes Modell verwendet, bei dem ein Codeabschnitt (eine „Funktion“) durch einen Trigger aufgerufen wird. In dieser Architektur wird die Funktion aufgerufen, wenn ein Client eine HTTP-Anforderung sendet. Die Anforderung wird immer über ein API-Gateway geleitet, wie unten beschrieben.

API Management. Azure API Management stellt ein API-Gateway bereit, das vor der HTTP-Funktion platziert ist. Sie können API Management nutzen, um von Clientanwendungen verwendete APIs zu veröffentlichen und zu verwalten. Mit der Verwendung eines Gateways wird die Entkopplung der Front-End-Anwendung von den Back-End-APIs unterstützt. Beispielsweise kann API Management URLs umschreiben, Anforderungen vor dem Erreichen des Back-Ends transformieren, Anforderungs- oder Antwortheader festlegen usw.

API Management kann auch verwendet werden, um übergreifende Aspekte zu implementieren, z.B.:

Erzwingen von Nutzungskontingenten und Ratenbegrenzungen
Überprüfen von OAuth-Token für die Authentifizierung
Aktivieren von ursprungsübergreifenden Anforderungen (Cross-Origin Requests, CORS)
Zwischenspeichern von Antworten
Überwachen und Protokollieren von Anforderungen

Falls Sie nicht die gesamte Funktionalität benötigen, die von API Management bereitgestellt wird, ist die Nutzung von Funktionsproxys eine Alternative. Mit diesem Feature von Azure Functions können Sie eine einzelne API-Oberfläche für mehrere Funktions-Apps definieren, indem Sie Routen zu Back-End-Funktionen erstellen. Außerdem können mit Funktionsproxys eingeschränkte Transformationen für die HTTP-Anforderung und -Antwort durchgeführt werden. Sie ermöglichen aber nicht die gleichen umfassenden richtlinienbasierten Funktionen wie API Management.

Azure Cosmos DB. Azure Cosmos DB ist ein Datenbankdienst mit mehreren Modellen. Für dieses Szenario ruft die Funktionsanwendung Dokumente aus Azure Cosmos DB als Antwort auf HTTP GET-Anforderungen vom Client ab.

Microsoft Entra ID. Benutzer melden sich mit ihren Microsoft Entra ID-Anmeldeinformationen bei der Webanwendung an. Microsoft Entra ID gibt ein Zugriffstoken für die API zurück, das von der Webanwendung genutzt wird, um API-Anforderungen zu authentifizieren (siehe Authentifizierung).

Azure Monitor: Azure Monitor erfasst Leistungsmetriken zu den in der Lösung bereitgestellten Azure-Diensten. Durch die Visualisierung dieser Metriken in einem Dashboard können Sie einen Einblick in die Integrität der Lösung gewinnen. Außerdem werden Anwendungsprotokolle erfasst.

Azure Pipelines. Azure Pipelines ist ein CI-/CD-Dienst (Continuous Integration/Continuous Delivery), mit dem die Anwendung erstellt, getestet und bereitgestellt wird.

GitHub Actions. Workflow ist ein automatisierter Prozess (CI/CD), den Sie in Ihrem GitHub-Repository einrichten. Sie können jedes Projekt auf GitHub mit einem Workflow erstellen, testen, verpacken, freigeben oder bereitstellen.

Szenariodetails

Mögliche Anwendungsfälle

Diese Drohnenlieferungslösung eignet sich ideal für die Flugzeug-, Luftfahrt-, Raumfahrt- und Robotikindustrie.

Empfehlungen

Funktions-App-Pläne

Azure Functions unterstützt zwei Hostingmodelle. Beim Verbrauchstarif wird automatisch Computeleistung zugeordnet, wenn Ihr Code ausgeführt wird. Beim App Service-Plan wird eine Gruppe von VMs für Ihren Code zugeordnet. Mit dem App Service-Plan wird die Anzahl von VMs und die VM-Größe definiert.

Beachten Sie, dass der App Service-Plan nicht serverlos im strengeren Sinne gemäß der obigen Definition ist. Das Programmiermodell ist aber identisch: Sowohl unter einem Verbrauchstarif als auch unter einem App Service-Plan kann der gleiche Funktionscode ausgeführt werden.

Hierbei müssen einige Faktoren berücksichtigt werden, wenn ausgewählt wird, welche Art von Plan verwendet werden soll:

Kaltstart. Beim Verbrauchstarif führt eine Funktion, die nicht kürzlich aufgerufen wurde, bei der nächsten Ausführung zu zusätzlicher Latenz. Der Grund für diese zusätzliche Latenz ist die Zuordnung und Vorbereitung der Laufzeitumgebung. Dies bewegt sich normalerweise im Sekundenbereich, ist aber von mehreren Faktoren abhängig, z. B. der Anzahl der Abhängigkeiten, die geladen werden müssen. Weitere Informationen finden Sie unter Understanding Serverless Cold Start (Grundlegendes zum serverlosen Kaltstart). Der Kaltstart ist normalerweise eher ein Problem bei interaktiven Workloads (HTTP-Trigger) als bei asynchronen nachrichtengesteuerten Workloads (Warteschlangen- oder Event Hubs-Trigger), da die zusätzliche Latenz von den Benutzern direkt erkannt wird.
Zeitlimit. Beim Verbrauchstarif tritt für eine Funktionsausführung nach einem konfigurierbaren Zeitraum ein Timeout auf (maximal zehn Minuten).
Isolation virtueller Netzwerke. Bei der Nutzung eines App Service-Plans können Funktionen in einer App Service-Umgebung ausgeführt werden, bei der es sich um eine dedizierte und isolierte Hostingumgebung handelt.
Preismodell. Die Abrechnung für den Verbrauchstarif erfolgt anhand der Anzahl von Ausführungen und des Ressourcenverbrauchs (Arbeitsspeicher × Ausführungszeit). Beim App Service-Plan erfolgt die Abrechnung stündlich basierend auf der VM-Instanz-SKU. Der Verbrauchstarif kann häufig kostengünstiger als ein App Service-Plan sein, da Sie nur für die genutzten Computeressourcen zahlen. Dies gilt besonders, wenn Ihr Datenverkehr Spitzen und Täler aufweist. Falls eine Anwendung aber über einen konstant hohen Datendurchsatz verfügt, sind die Kosten für einen App Service-Plan unter Umständen aber geringer als beim Verbrauchstarif.
Skalierung. Ein großer Vorteil des Verbrauchsmodells ist, dass basierend auf dem eingehenden Datenverkehr bedarfsabhängig dynamisch skaliert wird. Diese Skalierung kann zwar schnell durchgeführt werden, aber es ist eine Vorlaufzeit erforderlich. Für einige Workloads kann es ratsam sein, absichtlich zu viele VMs bereitzustellen, damit Datenverkehrsspitzen ohne Vorlaufzeit verarbeitet werden können. In diesem Fall sollten Sie erwägen, einen App Service-Plan zu nutzen.

Grenzen von Funktions-Apps

Eine Funktions-App hostet die Ausführung von einer oder mehreren Funktionen. Sie können eine Funktions-App nutzen, um mehrere Funktionen als logische Einheit zu gruppieren. Innerhalb einer Funktions-App sind für die Funktionen die Anwendungseinstellungen, der Hostingplan und der Entwicklungslebenszyklus jeweils gleich. Jede Funktions-App verfügt über einen eigenen Hostnamen.

Verwenden Sie Funktions-Apps zum Gruppieren von Funktionen, die den gleichen Lebenszyklus und die gleichen Einstellungen aufweisen. Funktionen, die nicht über den gleichen Lebenszyklus verfügen, sollten in anderen Funktions-Apps gehostet werden.

Erwägen Sie, einen Ansatz mit Microservices zu nutzen, bei dem jede Funktions-App einen Microservice darstellt, der unter Umständen aus mehreren verwandten Funktionen besteht. In einer Architektur mit Microservices sollten Dienste eine lose Kopplung und eine hohe funktionale Kohäsion aufweisen. Lose gekoppelt bedeutet, dass Sie einen Dienst ändern können, ohne gleichzeitig andere Dienste aktualisieren zu müssen. Mit Kohäsion ist gemeint, dass ein Dienst einem einzelnen, klar definierten Zweck dient. Weitere Informationen zu diesen Aspekten finden Sie unter Entwerfen von Microservices: Domänenanalyse.

Funktionsbindungen

Nutzen Sie Funktionsbindungen, wann immer dies möglich ist. Bindungen stellen eine deklarative Möglichkeit dar, Ihren Code mit Daten zu verbinden und in andere Azure-Dienste zu integrieren. Mit einer Eingabebindung wird ein Eingabeparameter aus einer externen Datenquelle aufgefüllt. Eine Ausgabebindung sendet den Rückgabewert der Funktion an eine Datensenke, z.B. eine Warteschlange oder Datenbank.

Für die Funktion GetStatus in der Referenzimplementierung wird die Azure Cosmos DB-Eingabebindung verwendet. Diese Bindung ist so konfiguriert, dass nach einem Dokument in Azure Cosmos DB gesucht wird. Hierzu werden Abfrageparameter verwendet, die aus der Abfragezeichenfolge in der HTTP-Anforderung stammen. Wenn das Dokument gefunden wird, wird es als Parameter an die Funktion übergeben.

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

Aufgrund der Nutzung von Bindungen müssen Sie keinen Code schreiben, der direkt mit dem Dienst kommuniziert. Hierdurch wird der Funktionscode vereinfacht, und außerdem werden die Details der Datenquelle bzw. -senke abstrahiert. In einigen Fällen benötigen Sie aber unter Umständen eine komplexere Logik als die von der Bindung bereitgestellte Logik. Verwenden Sie in diesem Fall direkt die Azure-Client-SDKs.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Skalierbarkeit

Funktionen. Für den Verbrauchstarif wird der HTTP-Trigger basierend auf dem Datenverkehr skaliert. Es gilt ein Limit für die Anzahl von gleichzeitigen Funktionsinstanzen, aber jede Instanz kann mehr als eine Anforderung gleichzeitig verarbeiten. Für einen App Service-Plan wird der HTTP-Trigger gemäß der Anzahl von VM-Instanzen skaliert. Dies kann ein fester Wert sein, oder es kann eine automatische Skalierung basierend auf einem Satz mit entsprechenden Regeln durchgeführt werden. Informationen hierzu finden Sie unter Skalierung und Hosting von Azure Functions.

Azure Cosmos DB. Die Durchsatzkapazität für Azure Cosmos DB wird in Anforderungseinheiten (Request Units, RUs) gemessen. Ein Durchsatz von einer Anforderungseinheit (1 RU) entspricht dem Durchsatz für das Abrufen eines 1-KB-Dokuments per GET-Anforderung. Um einen Azure Cosmos DB-Container auf eine Kapazität von mehr als 10.000 RU zu skalieren, müssen Sie beim Erstellen des Containers einen Partitionsschlüssel angeben und diesen in jedes von Ihnen erstellte Dokument einfügen. Weitere Informationen zu Partitionsschlüsseln finden Sie unter Partitionieren und Skalieren in Azure Cosmos DB.

API Management. API Management ermöglicht das Aufskalieren und unterstützt die regelbasierte automatische Skalierung. Der Skalierungsvorgang dauert mindestens 20 Minuten. Wenn Ihr Datenverkehr Spitzen („Bursts“) aufweist, sollten Sie entsprechende Ressourcen bereitstellen, um den erwarteten maximalen Burstdatenverkehr abzudecken. Die automatische Skalierung ist aber für die Verarbeitung von stündlichen oder täglichen Schwankungen beim Datenverkehr nützlich. Weitere Informationen finden Sie unter Automatisches Skalieren einer Azure API Management-Instanz.

Notfallwiederherstellung

Die hier dargestellte Bereitstellung befindet sich in nur einer Azure-Region. Nutzen Sie die Features für die geografische Verteilung in den verschiedenen Diensten, um einen stabileren Ansatz für die Notfallwiederherstellung zu erzielen:

API Management unterstützt eine Bereitstellung für mehrere Regionen. Dies kann genutzt werden, um einen einzelnen API Management-Dienst in einer beliebigen Anzahl von Azure-Regionen zur Verfügung zu stellen. Weitere Informationen finden Sie unter Bereitstellen einer Azure API Management-Dienstinstanz für mehrere Azure-Regionen.
Verwenden Sie Traffic Manager, um HTTP-Anforderungen an die primäre Region zu leiten. Wenn die Funktions-App, die in dieser Region ausgeführt wird, nicht verfügbar ist, kann Traffic Manager ein Failover in eine sekundäre Region ausführen.
Azure Cosmos DB unterstützt mehrere Schreibregionen, sodass Schreibvorgänge in alle Regionen möglich sind, die Sie Ihrem Azure Cosmos DB-Konto hinzufügen. Wenn Sie die Funktion für mehrere Schreibvorgänge nicht aktivieren, können Sie trotzdem ein Failover auf die primäre Schreibregion ausführen. Die Azure Cosmos DB-Client-SDKs und die Azure Function-Bindungen verarbeiten das Failover automatisch, sodass Sie keine Einstellungen für die Anwendungskonfiguration aktualisieren müssen.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Authentifizierung

Die GetStatus-API in der Referenzimplementierung verwendet Microsoft Entra ID zum Authentifizieren von Anforderungen. Microsoft Entra ID unterstützt das OpenID Connect-Protokoll, bei dem es sich um ein Authentifizierungsprotokoll handelt, das auf dem OAuth 2-Protokoll basiert.

In dieser Architektur ist die Clientanwendung eine Single-Page-Anwendung (SPA), die im Browser ausgeführt wird. Da bei dieser Art von Clientanwendung der geheime Clientschlüssel oder der Autorisierungscode nicht ausgeblendet werden können, ist die implizite Genehmigung hierfür der geeignete Ablauf. (Siehe Which OAuth 2.0 flow should I use? (Welchen OAuth 2.0-Ablauf soll ich verwenden?).) Hier ist der allgemeine Ablauf angegeben:

Der Benutzer klickt in der Webanwendung auf den Link „Anmelden“.
Der Browser wird zur Microsoft Entra-Anmeldeseite umgeleitet.
Der Benutzer meldet sich an.
Microsoft Entra ID leitet zurück zur Clientanwendung, einschließlich eines Zugriffstokens im URL-Fragment.
Wenn die Webanwendung die API aufruft, fügt sie das Zugriffstoken in den Authentifizierungsheader ein. Die Anwendungs-ID wird im Zugriffstoken als „Audience“-Anspruch („aud“) gesendet.
Die Back-End-API überprüft das Zugriffstoken.

Konfigurieren Sie die Authentifizierung wie folgt:

Registrieren Sie eine Anwendung in Ihrem Microsoft Entra-Mandanten. Es wird eine Anwendungs-ID generiert, die vom Client in die Anmelde-URL eingefügt wird.
Aktivieren Sie die Microsoft Entra-Authentifizierung in der Funktions-App. Weitere Informationen finden Sie unter Authentifizierung und Autorisierung in Azure App Service.
Fügen Sie API Management die Richtlinie „validate-jwt“ hinzu, um die Anforderung durch Überprüfung des Zugriffstokens vorab zu autorisieren.

Weitere Informationen finden Sie in der GitHub-Infodatei.

Es wird empfohlen, für die Clientanwendung und die Back-End-API separate App-Registrierungen in Microsoft Entra ID zu erstellen. Erteilen Sie der Clientanwendung Berechtigungen zum Aufrufen der API. Bei diesem Ansatz können Sie ganz flexibel mehrere APIs und Clients definieren und die einzelnen Berechtigungen dafür steuern.

Verwenden Sie innerhalb einer API Bereiche, damit Anwendungen präzise steuern können, welche Berechtigungen sie bei einem Benutzer voraussetzen. So kann eine API beispielsweise über die Bereiche Read und Write verfügen und eine bestimmte Client-App den Benutzer lediglich zur Autorisierung von Berechtigungen des Typs Read auffordern.

Authorization

In vielen Anwendungen muss die Back-End-API überprüfen, ob ein Benutzer über die Berechtigung zum Durchführen einer bestimmten Aktion verfügt. Es wird empfohlen, die anspruchsbasierte Autorisierung zu verwenden, bei der Informationen über den Benutzer vom Identitätsanbieter (in diesem Fall Microsoft Entra ID) übermittelt und für Autorisierungsentscheidungen verwendet werden. Wenn Sie beispielsweise eine Anwendung in Microsoft Entra ID registrieren, können Sie einen Satz mit Anwendungsrollen definieren. Wenn sich ein Benutzer bei der Anwendung anmeldet, enthält Microsoft Entra ID einen roles-Anspruch für jede Rolle, die dem Benutzer gewährt wurde, einschließlich der Rollen, die über die Gruppenmitgliedschaft vererbt werden.

Das ID-Token, das von Microsoft Entra ID an den Client zurückgegeben wird, enthält einige der Ansprüche des Benutzers. In der Funktions-App sind diese Ansprüche im X-MS-CLIENT-PRINCIPAL-Header der Anforderung verfügbar. Allerdings ist es einfacher, diese Informationen aus den Bindungsdaten zu lesen. Verwenden Sie für andere Ansprüche Microsoft Graph, um Microsoft Entra ID abzufragen. (Der Benutzer muss seine Einwilligung zu dieser Aktion erteilen, wenn er sich anmeldet.)

Weitere Informationen finden Sie unter Arbeiten mit Clientidentitäten.

CORS

In dieser Referenzarchitektur weisen die Webanwendung und die API nicht denselben Ursprung auf. Dies bedeutet, dass es sich um eine ursprungsübergreifende Anforderung handelt, wenn die Anwendung die API aufruft. Die Browsersicherheit verhindert, dass eine Webseite AJAX-Anforderungen an eine andere Domäne richtet. Diese Einschränkung wird als Richtlinie des gleichen Ursprungs bezeichnet und verhindert, dass eine schädliche Website sensible Daten von einer anderen Website liest. Sie können eine ursprungsübergreifende Anforderung aktivieren, indem Sie dem API Management-Gateway eine Richtlinie vom Typ CORS (Cross-Origin Resource Sharing, Ressourcenfreigabe zwischen verschiedenen Ursprüngen) hinzufügen:

<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 diesem Beispiel ist das Attribut allow-credentials auf true festgelegt. Hiermit wird für den Browser das Senden von Anmeldeinformationen (einschließlich Cookies) mit der Anforderung autorisiert. Andernfalls sendet der Browser standardmäßig keine Anmeldeinformationen mit einer ursprungsübergreifenden Anforderung.

Hinweis

Gehen Sie beim Festlegen von allow-credentials auf true mit Bedacht vor, da eine Website die Benutzeranmeldeinformationen dann im Namen des Benutzers an Ihre API senden kann, ohne dass der Benutzer darüber informiert ist. Sie müssen den zugelassenen Ursprung als vertrauenswürdig festlegen.

Erzwingen von HTTPS

Sie können maximale Sicherheit erzielen, indem Sie HTTPS für die gesamte Anforderungspipeline erzwingen:

CDN. Azure CDN unterstützt HTTPS standardmäßig für die Unterdomäne *.azureedge.net. Informationen zur Aktivierung von HTTPS im CDN für benutzerdefinierte Domänennamen finden Sie unter Tutorial: Konfigurieren von HTTPS in einer benutzerdefinierten Azure CDN-Domäne.
Hosten von statischen Websites. Aktivieren Sie die Option „Sichere Übertragung erforderlich“ im Speicherkonto. Wenn diese Option aktiviert ist, lässt das Speicherkonto nur Anforderungen von sicheren HTTPS-Verbindungen zu.

API Management. Konfigurieren Sie die APIs so, das nur das HTTPS-Protokoll verwendet werden kann. Sie können dies im Azure-Portal oder über eine Resource Manager-Vorlage konfigurieren:

{
    "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. Aktivieren Sie die Einstellung „Nur HTTPS“.

Sperren der Funktions-App

Alle Aufrufe der Funktion sollten über das API-Gateway verlaufen. Sie können dies wie folgt erreichen:

Konfigurieren Sie die Funktions-App so, dass ein Funktionsschlüssel verwendet werden muss. Das API Management-Gateway enthält den Funktionsschlüssel, wenn es die Funktions-App aufruft. So wird verhindert, dass Clients die Funktion direkt aufrufen, indem sie das Gateway umgehen.
Das API Management-Gateway hat eine statische IP-Adresse. Beschränken Sie die Azure-Funktion, damit nur Aufrufe über diese statische IP-Adresse zulässig sind. Weitere Informationen finden Sie unter Statische Azure App Service-IP-Einschränkungen. (Dieses Feature ist nur für Dienste mit dem Standard-Tarif verfügbar.)

Schützen von Anwendungsgeheimnissen

Speichern Sie Anwendungsgeheimnisse, z.B. Datenbank-Anmeldeinformationen, nicht in Ihrem Code oder in Konfigurationsdateien. Verwenden Sie stattdessen App-Einstellungen, die in Azure verschlüsselt gespeichert werden. Weitere Informationen finden Sie unter Sicherheit in Azure App Service und Azure Functions.

Alternativ hierzu können Sie Anwendungsgeheimnisse in Key Vault speichern. Dies ermöglicht Ihnen die Zentralisierung der Speicherung von Geheimnissen, die Steuerung ihrer Verteilung und die Überwachung, wie und wann auf Geheimnisse zugegriffen wird. Weitere Informationen finden Sie unter Konfigurieren einer Azure-Webanwendung zum Lesen eines Geheimnisses aus Key Vault. Beachten Sie aber, dass Functions-Trigger und -Bindungen ihre Konfigurationseinstellungen aus App-Einstellungen laden. Es gibt keine integrierte Möglichkeit, Trigger und Bindungen für die Verwendung von Key Vault-Geheimnissen zu konfigurieren.

DevOps

Sichere Bereitstellungsmethoden werden mithilfe eines zuverlässigen CI/CD-Diensts wie Azure-Pipelines oder GitHub-Aktionen automatisiert. Diese Dienste werden verwendet, um alle Quelländerungen im Front-End und Back-End automatisch zu erstellen und bereitzustellen. Die Quelle muss sich in einem Online-Versionskontrollsystem befinden. Weitere Informationen zu Azure Pipelines finden Sie unter Erstellen Ihrer ersten Pipeline. Weitere Informationen über GitHub Actions für Azure finden Sie unter Bereitstellen von Apps in Azure.

Front-End-Bereitstellung

Das Front-End dieser Referenzarchitektur ist eine Einzelseitenanwendung, bei der JavaScript auf die serverlosen Back-End-APIs zugreift und statische Inhalte für ein schnelles Benutzererlebnis sorgen. Im Folgenden finden Sie einige wichtige Überlegungen zu einer solchen Anwendung:

Stellen Sie die Anwendung mit einem CDN, das sich für den globalen Einsatz eignet, einheitlich für Benutzer in einem umfangreichen geografischen Gebiet bereit. Die statischen Inhalte werden in der Cloud gehostet. Dadurch entfällt die Notwendigkeit eines dedizierten Webservers. Lesen Sie zum Einstieg den Artikel Integrieren eines Azure-Speicherkontos in Azure CDN. Sichern Sie Ihre Anwendung mit HTTPS. Weitere Empfehlungen finden Sie unter Bewährte Methoden für die Verwendung von Content Delivery Networks (CDNs).
Komprimieren Sie Websitedateien, um die Bandbreitennutzung im CDN zu reduzieren und die Leistung zu verbessern. Azure CDN ermöglicht eine Komprimierung im laufenden Betrieb auf den Edgeservern. Alternativ dazu komprimiert die Bereitstellungspipeline in dieser Referenzarchitektur die Dateien, bevor diese im Blobspeicher bereitgestellt werden. Dadurch sinken die Speicheranforderungen, und Sie erhalten mehr Flexibilität bei der Auswahl der Komprimierungstools – unabhängig von Einschränkungen durch das CDN.
Das CDN sollte in der Lage sein, den Cache zu bereinigen, um sicherzustellen, dass alle Benutzer die neuesten Inhalte erhalten. Eine Bereinigung des Caches ist notwendig, wenn die Erstellungs- und Bereitstellungsprozesse nicht atomisch sind, also beispielsweise alte Dateien im gleichen Ursprungsordner durch neu erstellte Dateien ersetzen.
Bei einer anderen Cachestrategie – z. B. der Versionsverwaltung mithilfe von Verzeichnissen – ist eine Bereinigung durch das CDN möglicherweise nicht erforderlich. Die Buildpipeline in dieser Front-End-Anwendung erstellt ein neues Verzeichnis für jede neu erstellte Version. Diese Version wird als atomische Einheit in den Blobspeicher hochgeladen. Das Azure CDN zeigt erst nach einer abgeschlossenen Bereitstellung auf diese Version.
Erhöhen Sie die TTL für den Cache, indem Sie Ressourcendateien über einen längeren Zeitraum – z. B. mehrere Monate – zwischenspeichern. Um sicherzustellen, dass die zwischengespeicherten Dateien bei einer Änderung aktualisiert werden, versehen Sie die Dateinamen bei der erneuten Erstellung mit einem Fingerabdruck. Diese Front-End-Anwendung versieht alle Dateien mit einem Fingerabdruck, mit Ausnahme von Dateien für den öffentlichen Zugriff, z. B. index.html. Da die Datei „index.html“ häufig aktualisiert wird, reflektiert sie die geänderten Dateinamen, die eine Aktualisierung des Caches verursachen. Weitere Informationen finden Sie unter Verwalten des Ablaufs von Webinhalten in Azure CDN.

Back-End-Bereitstellung

Für die Bereitstellung der Funktions-App wird die Verwendung von Paketdateien („Aus Paket ausführen“) empfohlen. Bei diesem Ansatz laden Sie eine ZIP-Datei in einen Blob Storage-Container hoch, und die Functions-Runtime bindet die ZIP-Datei als schreibgeschütztes Dateisystem ein. Dieser atomische Vorgang verringert die Wahrscheinlichkeit, dass die Anwendung aufgrund einer fehlerhaften Bereitstellung in einem inkonsistenten Zustand verbleibt. Er kann darüber hinaus Kaltstartzeiten verbessern (insbesondere für Node.js-Apps), da alle Dateien auf einmal ausgetauscht werden.

Fügen Sie eine ausreichende Anzahl von automatisierten Tests sowohl in Ihren Build- als auch in Bereitstellungspipelines hinzu. Beachten Sie, dass die mehr individuellen bereitstellungsfähigen Einheiten Ihren Workload bilden, desto mehr Netzwerkgrenzen werden eingeführt. Diese einzelnen Einheiten arbeiten zusammen, um Benutzer- und Datenflüsse zu unterstützen. Anschließend erfordert End-to-End-Tests eines solchen Systems zusätzliche Investitionen in Integrationstests.

API-Versionsverwaltung

Eine API ist ein Vertrag zwischen einem Dienst und Clients. In dieser Architektur wird der API-Vertrag auf API Management-Ebene festgelegt. API Management unterstützt zwei unterschiedliche Versionierungskonzepte, die sich aber gegenseitig ergänzen:

Versionen bieten API-Consumern die Möglichkeit, eine API-Version basierend auf ihren Anforderungen zu wählen, z.B. v1 oder v2.
Revisionen ermöglichen API-Administratoren das Vornehmen geringfügiger Änderungen in einer API und das Bereitstellen dieser Änderungen zusammen mit einem Änderungsprotokoll, um API-Benutzer über die Änderungen zu informieren.

Wenn Sie eine grundlegende Änderung in einer API vornehmen, veröffentlichen Sie eine neue Version in API Management. Stellen Sie die neue Version parallel zur Originalversion in einer separaten Funktions-App bereit. So können Sie vorhandene Clients zur neuen API migrieren, ohne die Funktion von Clientanwendungen zu beeinträchtigen. Letztendlich können Sie die frühere Version dann als veraltet deklarieren. API Management unterstützt mehrere Versionsverwaltungsschemas: URL-Pfad, HTTP-Header und Abfragezeichenfolge. Weitere Informationen zur API-Versionsverwaltung im Allgemeinen finden Sie unter Versionsverwaltung einer RESTful-Web-API.

Stellen Sie für Updates, die keine grundlegenden API-Änderungen darstellen, die neue Version in einem Stagingslot in der derselben Funktions-App bereit. Überprüfen Sie, ob die Bereitstellung erfolgreich war, und ersetzen Sie dann die bereitgestellte Version durch die Produktionsversion. Veröffentlichen Sie eine Revision in API Management.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln. Beachten Sie diese Punkte, um die Kosten dieser Architektur zu optimieren.

Azure-Funktionen

Azure Functions unterstützt zwei Hostingmodelle.

Verbrauchstarif:

Computeleistung wird automatisch zugeordnet, wenn Ihr Code ausgeführt wird.
App Service-Plan:

Für Ihren Code wird eine Gruppe mit VMs zugeordnet. Mit diesem Plan wird die Anzahl von VMs und die VM-Größe definiert.

In dieser Architektur wird eine Funktion aufgerufen, wenn ein Client eine HTTP-Anforderung sendet. Da bei diesem Anwendungsfall nicht mit einem hohen Durchsatz zu rechnen ist, wird die Verwendung des Verbrauchstarifs empfohlen, weil Sie dabei nur für die genutzten Computeressourcen zahlen.

Azure Cosmos DB

Bei Azure Cosmos DB werden Kosten für den bereitgestellten Durchsatz und den genutzten Speicher pro Stunde berechnet. Der bereitgestellte Durchsatz wird in Anforderungseinheiten pro Sekunde (RU/s) ausgedrückt. Dies kann für gängige Datenbankvorgänge, z. B. Einfügungen und Lesevorgänge, genutzt werden. Der Preis basiert auf der von Ihnen reservierten Kapazität in RU/s.

Der Speicher wird pro genutztem Gigabyte (GB) berechnet, das für Ihre gespeicherten Daten und den Index verwendet wird.

Weitere Informationen finden Sie unter Azure Cosmos DB – Preismodell.

Bei dieser Architektur ruft die Funktionsanwendung Dokumente aus Azure Cosmos DB als Antwort auf HTTP GET-Anforderungen vom Client ab. Die Verwendung von Azure Cosmos DB ist in diesem Fall kostengünstig, weil Lesevorgänge basierend auf RU/s erheblich günstiger als Schreibvorgänge sind.

Content Delivery Network

Die Abrechnungshäufigkeit kann je nach Abrechnungsregion basierend auf dem Standort des Quellservers variieren, über den dem Endbenutzer die Inhalte bereitgestellt werden. Der physische Ort des Clients ist nicht die Abrechnungsregion. Jede HTTP- oder HTTPS-Anforderung, die an das CDN gesendet wird, ist ein abrechenbares Ereignis, das alle Antworttypen einschließt: Erfolg, Fehler oder andere. Für verschiedene Antworten können unterschiedliche Datenverkehrsmengen generiert werden.

Bei dieser Referenzarchitektur ist die Bereitstellung nur in einer Azure-Region angeordnet.

Erwägen Sie, zum Senken der Kosten die Gültigkeitsdauer des Caches zu erhöhen, indem Sie Ressourcendateien länger zwischenspeichern und für Ihren Inhalt die längste zulässige Gültigkeitsdauer festlegen.

Weitere Informationen finden Sie im Microsoft Azure Well-Architected Framework unter Grundsätze der Kostenoptimierung.

Bereitstellen dieses Szenarios

Informationen zum Bereitstellen der Referenzimplementierung für diese Architektur finden Sie in der GitHub-Infodatei.

Nächste Schritte

Produktdokumentation:

Learn-Module:

Weitere Informationen zur Referenzimplementierung finden Sie unter Exemplarische Vorgehensweise mit Code: Serverlose Anwendung mit Azure Functions.

Verwandte Leitfäden:

Freigeben über

Serverlose Webanwendung

Architektur

Komponenten

Szenariodetails

Mögliche Anwendungsfälle

Empfehlungen

Funktions-App-Pläne

Grenzen von Funktions-Apps

Funktionsbindungen

Überlegungen

Skalierbarkeit

Notfallwiederherstellung

Sicherheit

Authentifizierung

Authorization

CORS

Erzwingen von HTTPS

Sperren der Funktions-App

Schützen von Anwendungsgeheimnissen

DevOps

Front-End-Bereitstellung

Back-End-Bereitstellung

API-Versionsverwaltung

Kostenoptimierung

Azure-Funktionen

Azure Cosmos DB

Content Delivery Network

Bereitstellen dieses Szenarios

Nächste Schritte

Feedback

Zusätzliche Ressourcen

Freigeben über

Serverlose Webanwendung

Architektur

Komponenten

Szenariodetails

Mögliche Anwendungsfälle

Empfehlungen

Funktions-App-Pläne

Grenzen von Funktions-Apps

Funktionsbindungen

Überlegungen

Skalierbarkeit

Notfallwiederherstellung

Sicherheit

Authentifizierung

Authorization

CORS

Erzwingen von HTTPS

Sperren der Funktions-App

Schützen von Anwendungsgeheimnissen

DevOps

Front-End-Bereitstellung

Back-End-Bereitstellung

API-Versionsverwaltung

Kostenoptimierung

Azure-Funktionen

Azure Cosmos DB

Content Delivery Network

Bereitstellen dieses Szenarios

Nächste Schritte

Zugehörige Ressourcen

Feedback

Zusätzliche Ressourcen