Service Fabric mit Azure API Management-ÜbersichtService Fabric with Azure API Management overview

Cloudanwendungen benötigen normalerweise ein Front-End-Gateway, um für Benutzer, Geräte oder andere Anwendungen einen zentralen Eingangspunkt bereitzustellen.Cloud applications typically need a front-end gateway to provide a single point of ingress for users, devices, or other applications. In Service Fabric kann ein Gateway ein beliebiger zustandsloser Dienst sein, z.B. eine ASP.NET Core-Anwendung, oder ein anderer Dienst, der für den Eingang von Datenverkehr ausgelegt ist, z.B. Event Hubs, IoT Hub oder Azure API Management.In Service Fabric, a gateway can be any stateless service such as an ASP.NET Core application, or another service designed for traffic ingress, such as Event Hubs, IoT Hub, or Azure API Management.

Dieser Artikel enthält eine Einführung in die Verwendung von Azure API Management als Gateway für Ihre Service Fabric-Anwendungen.This article is an introduction to using Azure API Management as a gateway to your Service Fabric applications. API Management ist direkt in Service Fabric integriert, sodass Sie APIs mit einem umfassenden Satz von Routingregeln für Ihre Service Fabric-Back-End-Dienste veröffentlichen können.API Management integrates directly with Service Fabric, allowing you to publish APIs with a rich set of routing rules to your back-end Service Fabric services.

VerfügbarkeitAvailability

Wichtig

Dieses Feature ist auf den Ebenen Premium und Entwickler von API Management aufgrund der erforderlichen Unterstützung virtueller Netzwerke verfügbar.This feature is available in the Premium and Developer tiers of API Management due to the required virtual network support.

AufbauArchitecture

Für eine allgemeine Service Fabric-Architektur wird eine einseitige Webanwendung verwendet, die HTTP-Aufrufe für Back-End-Dienste durchführt, von denen HTTP-APIs verfügbar gemacht werden.A common Service Fabric architecture uses a single-page web application that makes HTTP calls to back-end services that expose HTTP APIs. Unter Service Fabric Getting Started Sample (Service Fabric-Beispiel für die ersten Schritte) finden Sie ein Beispiel für diese Architektur.The Service Fabric getting-started sample application shows an example of this architecture.

In diesem Szenario dient ein zustandsloser Webdienst als Gateway für die Service Fabric-Anwendung.In this scenario, a stateless web service serves as the gateway into the Service Fabric application. Bei diesem Ansatz ist es erforderlich, einen Webdienst zu schreiben, mit dem HTTP-Anforderungen über einen Proxy an Back-End-Dienste gesendet werden können. Dies ist im folgenden Diagramm dargestellt:This approach requires you to write a web service that can proxy HTTP requests to back-end services, as shown in the following diagram:

Service Fabric mit Azure API Management-Topologie – Übersicht

Wenn die Komplexität von Anwendungen zunimmt, gilt dies auch für die Gateways, die eine API im Vordergrund einer Vielzahl von Back-End-Diensten darstellen müssen.As applications grow in complexity, so do the gateways that must present an API in front of myriad back-end services. Azure API Management ist so konzipiert, dass komplexe APIs mit Routingregeln, Zugriffssteuerung, Ratenbegrenzung, Überwachung, Ereignisprotokollierung und Zwischenspeicherung von Antworten mit minimalem Aufwand für Sie verarbeitet werden können.Azure API Management is designed to handle complex APIs with routing rules, access control, rate limiting, monitoring, event logging, and response caching with minimal work on your part. Azure API Management unterstützt Service Fabric-Dienstermittlung, -Partitionsauflösung und -Replikatauswahl, um Anforderungen auf intelligente Weise direkt an Back-End-Dienste in Service Fabric leiten zu können, damit Sie kein eigenes zustandsloses API-Gateway schreiben müssen.Azure API Management supports Service Fabric service discovery, partition resolution, and replica selection to intelligently route requests directly to back-end services in Service Fabric so you don't have to write your own stateless API gateway.

In diesem Szenario wird die Webbenutzeroberfläche über einen Webdienst bereitgestellt, während HTTP-API-Aufrufe per Azure API Management verwaltet und weitergeleitet werden. Dies ist im folgenden Diagramm dargestellt:In this scenario, the web UI is still served through a web service, while HTTP API calls are managed and routed through Azure API Management, as shown in the following diagram:

Service Fabric mit Azure API Management-Topologie – Übersicht

AnwendungsszenarienApplication scenarios

Dienste können in Service Fabric entweder zustandslos oder zustandsbehaftet sein, und für die Partitionierung können drei Schemas verwendet werden: „singleton“, „int-64 range“ und „named“.Services in Service Fabric may be either stateless or stateful, and they may be partitioned using one of three schemes: singleton, int-64 range, and named. Für die Auflösung von Dienstendpunkten ist die Identifizierung einer bestimmten Partition einer bestimmten Dienstinstanz erforderlich.Service endpoint resolution requires identifying a specific partition of a specific service instance. Beim Auflösen des Endpunkts eines Diensts muss sowohl der Dienstinstanzname (z.B. fabric:/myapp/myservice) als auch die bestimmte Partition des Diensts angegeben werden (mit Ausnahme einer Singleton-Partition).When resolving an endpoint of a service, both the service instance name (for example, fabric:/myapp/myservice) as well as the specific partition of the service must be specified, except in the case of singleton partition.

Azure API Management kann mit einer beliebigen Kombination aus zustandslosen Diensten, zustandsbehafteten Diensten und Partitionierungsschema verwendet werden.Azure API Management can be used with any combination of stateless services, stateful services, and any partitioning scheme.

Senden von Datenverkehr an einen zustandslosen DienstSend traffic to a stateless service

Im einfachsten Fall wird Datenverkehr an die Instanz eines zustandslosen Diensts weitergeleitet.In the simplest case, traffic is forwarded to a stateless service instance. Zu diesem Zweck enthält ein API Management-Vorgang eine Richtlinie für die Verarbeitung von eingehendem Datenverkehr mit einem Service Fabric-Back-End, das einer bestimmten Instanz eines zustandslosen Diensts auf dem Service Fabric-Back-End zugeordnet ist.To achieve this, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps to a specific stateless service instance in the Service Fabric back-end. An diesen Dienst gesendete Anforderungen werden an eine zufällige Instanz des Diensts geleitet.Requests sent to that service are sent to a random instance of the service.

BeispielExample

Im folgenden Szenario enthält eine Service Fabric-Anwendung einen zustandslosen Dienst mit dem Namen fabric:/app/fooservice, der eine interne HTTP-API verfügbar macht.In the following scenario, a Service Fabric application contains a stateless service named fabric:/app/fooservice, that exposes an internal HTTP API. Der Dienstinstanzname ist bekannt und kann direkt in der API Management-Richtlinie für die Verarbeitung von eingehendem Datenverkehr hartcodiert werden.The service instance name is well known and can be hard-coded directly in the API Management inbound processing policy.

Service Fabric mit Azure API Management-Topologie – Übersicht

Senden von Datenverkehr an einen zustandsbehafteten DienstSend traffic to a stateful service

Ähnlich wie beim Szenario mit dem zustandslosen Dienst kann Datenverkehr auch an die Instanz eines zustandsbehafteten Diensts weitergeleitet werden.Similar to the stateless service scenario, traffic can be forwarded to a stateful service instance. In diesem Fall enthält ein API Management-Vorgang eine Richtlinie für die Verarbeitung von eingehendem Datenverkehr mit einem Service Fabric-Back-End, das eine Anforderung einer bestimmten Partition einer bestimmten Instanz des zustandsbehafteten Diensts zuordnet.In this case, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps a request to a specific partition of a specific stateful service instance. Die Partition, der die einzelnen Anforderungen jeweils zugeordnet werden, wird mithilfe einer Lambda-Methode berechnet. Hierfür wird eine Eingabe der eingehenden HTTP-Anforderung verwendet, z.B. ein Wert im URL-Pfad.The partition to map each request to is computed via a lambda method using some input from the incoming HTTP request, such as a value in the URL path. Die Richtlinie kann so konfiguriert werden, dass Anforderungen nur an das primäre Replikat oder für Lesevorgänge an ein zufälliges Replikat gesendet werden.The policy may be configured to send requests to the primary replica only, or to a random replica for read operations.

BeispielExample

Im folgenden Szenario enthält eine Service Fabric-Anwendung einen partitionierten zustandsbehafteten Dienst mit dem Namen fabric:/app/userservice, der eine interne HTTP-API verfügbar macht.In the following scenario, a Service Fabric application contains a partitioned stateful service named fabric:/app/userservice that exposes an internal HTTP API. Der Dienstinstanzname ist bekannt und kann direkt in der API Management-Richtlinie für die Verarbeitung von eingehendem Datenverkehr hartcodiert werden.The service instance name is well known and can be hard-coded directly in the API Management inbound processing policy.

Der Dienst wird mit dem Int64-Partitionsschema partitioniert, das über zwei Partitionen und einen Schlüsselbereich von Int64.MinValue bis Int64.MaxValue verfügt.The service is partitioned using the Int64 partition scheme with two partitions and a key range that spans Int64.MinValue to Int64.MaxValue. Mit der Back-End-Richtlinie wird ein Partitionsschlüssel innerhalb dieses Bereichs berechnet, indem der id-Wert, der im URL-Anforderungspfad angegeben ist, in eine 64-Bit-Ganzzahl konvertiert wird. Es kann hier aber ein beliebiger Algorithmus verwendet werden, um den Partitionsschlüssel zu berechnen.The back-end policy computes a partition key within that range by converting the id value provided in the URL request path to a 64-bit integer, although any algorithm can be used here to compute the partition key.

Service Fabric mit Azure API Management-Topologie – Übersicht

Senden von Datenverkehr an mehrere zustandslose DiensteSend traffic to multiple stateless services

Bei erweiterten Szenarien können Sie einen API Management-Vorgang definieren, bei dem Anforderungen mehr als einer Dienstinstanz zugeordnet werden.In more advanced scenarios, you can define an API Management operation that maps requests to more than one service instance. In diesem Fall enthält jeder Vorgang eine Richtlinie, bei der Anforderungen einer bestimmten Dienstinstanz zugeordnet werden. Dies erfolgt basierend auf Werten aus der eingehenden HTTP-Anforderung, z.B. dem URL-Pfad oder der Abfragezeichenfolge, und bei zustandsbehafteten Diensten aus der Partition in der Dienstinstanz.In this case, each operation contains a policy that maps requests to a specific service instance based on values from the incoming HTTP request, such as the URL path or query string, and in the case of stateful services, a partition within the service instance.

Zu diesem Zweck enthält ein API Management-Vorgang eine Richtlinie für die Verarbeitung von eingehendem Datenverkehr mit einem Service Fabric-Back-End, das einer Instanz eines zustandslosen Diensts auf dem Service Fabric-Back-End zugeordnet ist – basierend auf Werten, die aus der eingehenden HTTP-Anforderung abgerufen werden.To achieve this, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps to a stateless service instance in the Service Fabric back-end based on values retrieved from the incoming HTTP request. An Dienste gesendete Anforderungen werden an eine zufällige Instanz des Diensts geleitet.Requests to a service are sent to a random instance of the service.

BeispielExample

In diesem Beispiel wird für jeden Benutzer einer Anwendung eine neue Instanz eines zustandslosen Diensts mit einem dynamisch generierten Namen erstellt, indem die folgende Formel verwendet wird:In this example, a new stateless service instance is created for each user of an application with a dynamically generated name using the following formula:

  • fabric:/app/users/<username>

    Jeder Dienst hat einen eindeutigen Namen, aber die Namen sind vorher nicht bekannt, da die Dienste als Antwort auf eine Benutzer- oder Administratoreingabe erstellt werden und daher nicht in APIM-Richtlinien oder Routingregeln hartcodiert werden können.Each service has a unique name, but the names are not known up-front because the services are created in response to user or admin input and thus cannot be hard-coded into APIM policies or routing rules. Stattdessen wird der Name des Diensts, an den eine Anforderung gesendet werden soll, in der Definition der Back-End-Richtlinie über den Wert name generiert, der im URL-Anforderungspfad angegeben ist.Instead, the name of the service to which to send a request is generated in the back-end policy definition from the name value provided in the URL request path. Beispiel:For example:

    • Eine Anforderung an /api/users/foo wird an die Dienstinstanz fabric:/app/users/foo weitergeleitet.A request to /api/users/foo is routed to service instance fabric:/app/users/foo
    • Eine Anforderung an /api/users/bar wird an die Dienstinstanz fabric:/app/users/bar weitergeleitet.A request to /api/users/bar is routed to service instance fabric:/app/users/bar

Service Fabric mit Azure API Management-Topologie – Übersicht

Senden von Datenverkehr an mehrere zustandsbehaftete DiensteSend traffic to multiple stateful services

Ähnlich wie beim Beispiel für den zustandslosen Dienst können Anforderungen bei einem API Management-Vorgang mehr als einer Instanz eines zustandsbehafteten Diensts zugeordnet werden. In diesem Fall kann es sein, dass sie für jede Instanz eines zustandsbehafteten Diensts eine Partitionsauflösung durchführen müssen.Similar to the stateless service example, an API Management operation can map requests to more than one stateful service instance, in which case you also may need to perform partition resolution for each stateful service instance.

Zu diesem Zweck enthält ein API Management-Vorgang eine Richtlinie für die Verarbeitung von eingehendem Datenverkehr mit einem Service Fabric-Back-End, das einer Instanz eines zustandsbehafteten Diensts auf dem Service Fabric-Back-End zugeordnet ist – basierend auf Werten, die aus der eingehenden HTTP-Anforderung abgerufen werden.To achieve this, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps to a stateful service instance in the Service Fabric back-end based on values retrieved from the incoming HTTP request. Zusätzlich zur Zuordnung einer Anforderung zu einer bestimmten Dienstinstanz kann die Anforderung auch einer bestimmten Partition innerhalb der Dienstinstanz zugeordnet werden, und optional entweder dem primären Replikat oder einem zufälligen sekundären Replikat innerhalb der Partition.In addition to mapping a request to specific service instance, the request can also be mapped to a specific partition within the service instance, and optionally to either the primary replica or a random secondary replica within the partition.

BeispielExample

In diesem Beispiel wird für jeden Benutzer der Anwendung eine neue Instanz eines zustandsbehafteten Diensts mit einem dynamisch generierten Namen erstellt, indem die folgende Formel verwendet wird:In this example, a new stateful service instance is created for each user of the application with a dynamically generated name using the following formula:

  • fabric:/app/users/<username>

    Jeder Dienst hat einen eindeutigen Namen, aber die Namen sind vorher nicht bekannt, da die Dienste als Antwort auf eine Benutzer- oder Administratoreingabe erstellt werden und daher nicht in APIM-Richtlinien oder Routingregeln hartcodiert werden können.Each service has a unique name, but the names are not known up-front because the services are created in response to user or admin input and thus cannot be hard-coded into APIM policies or routing rules. Stattdessen wird der Name des Diensts, an den eine Anforderung gesendet werden soll, in der Definition der Back-End-Richtlinie über den Wert name generiert, der im URL-Anforderungspfad angegeben ist.Instead, the name of the service to which to send a request is generated in the back-end policy definition from the name value provided the URL request path. Beispiel:For example:

    • Eine Anforderung an /api/users/foo wird an die Dienstinstanz fabric:/app/users/foo weitergeleitet.A request to /api/users/foo is routed to service instance fabric:/app/users/foo
    • Eine Anforderung an /api/users/bar wird an die Dienstinstanz fabric:/app/users/bar weitergeleitet.A request to /api/users/bar is routed to service instance fabric:/app/users/bar

Jede Dienstinstanz wird außerdem mit dem Int64-Partitionsschema partitioniert, das über zwei Partitionen und einen Schlüsselbereich von Int64.MinValue bis Int64.MaxValue verfügt.Each service instance is also partitioned using the Int64 partition scheme with two partitions and a key range that spans Int64.MinValue to Int64.MaxValue. Mit der Back-End-Richtlinie wird ein Partitionsschlüssel innerhalb dieses Bereichs berechnet, indem der id-Wert, der im URL-Anforderungspfad angegeben ist, in eine 64-Bit-Ganzzahl konvertiert wird. Es kann hier aber ein beliebiger Algorithmus verwendet werden, um den Partitionsschlüssel zu berechnen.The back-end policy computes a partition key within that range by converting the id value provided in the URL request path to a 64-bit integer, although any algorithm can be used here to compute the partition key.

Service Fabric mit Azure API Management-Topologie – Übersicht

Nächste SchritteNext steps

Verwenden Sie das Tutorial, um Ihren ersten Service Fabric-Cluster mit API Management einzurichten und Anforderungen per API Management an Ihre Dienste zu leiten.Follow the tutorial to set up your first Service Fabric cluster with API Management and flow requests through API Management to your services.