Panoramica di Service Fabric con Gestione API di AzureService Fabric with Azure API Management overview

Le applicazioni cloud necessitano in genere di un gateway front-end per garantire un singolo punto di ingresso per utenti, dispositivi o altre applicazioni.Cloud applications typically need a front-end gateway to provide a single point of ingress for users, devices, or other applications. In Service Fabric un gateway può essere qualsiasi servizio senza stato, ad esempio un'applicazione ASP.NET Core, o un altro servizio progettati per l'ingresso del traffico, ad esempio Hub eventi, Hub IoT o Gestione API di Azure.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.

In questo articolo viene illustrata un'introduzione all'uso di Gestione API di Azure come gateway per le applicazioni Service Fabric.This article is an introduction to using Azure API Management as a gateway to your Service Fabric applications. Gestione API si integra direttamente in Service Fabric, consentendo di pubblicare API con un ampio set di regole di routing nei servizi Service Fabric back-end.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.

ArchitetturaArchitecture

Un'architettura Service Fabric comune usa un'applicazione Web di una pagina che esegue chiamate HTTP ai servizi back-end che espongono API HTTP.A common Service Fabric architecture uses a single-page web application that makes HTTP calls to back-end services that expose HTTP APIs. L'applicazione introduttive a Service Fabric di esempio mostra un esempio di questa architettura.The Service Fabric getting-started sample application shows an example of this architecture.

In questo scenario, un servizio Web senza stato funge da gateway nell'applicazione Service Fabric.In this scenario, a stateless web service serves as the gateway into the Service Fabric application. Questo approccio richiede la scrittura di un servizio Web che possa inoltrare richieste HTTP a servizi back-end, come illustrato nel diagramma seguente:This approach requires you to write a web service that can proxy HTTP requests to back-end services, as shown in the following diagram:

Panoramica di Service Fabric con topologia di Gestione API di Azure

Man mano che le applicazioni aumentano in termini di complessità, lo stesso avviene per i gateway che devono presentare un'API a una miriade di servizi back-end.As applications grow in complexity, so do the gateways that must present an API in front of myriad back-end services. Gestione API di Azure è progettato per gestire API complesse con regole di routing, controllo di accesso, limitazione della velocità, monitoraggio, registrazione degli eventi e memorizzazione delle risposte nella cache con minimo intervento dell'utente.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. Gestione API di Azure supporta l'individuazione di servizi Service Fabric, la risoluzione delle partizioni e la selezione di repliche per indirizzare in modo intelligente le richieste direttamente ai servizi back-end in Service Fabric, senza richiedere all'utente di scrivere un gateway API senza stato personalizzato.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 questo scenario, l'interfaccia utente Web viene comunque gestita tramite un servizio Web, mentre le chiamate API HTTP vengono gestite e instradate tramite Gestione API di Azure, come illustrato nel diagramma seguente: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:

Panoramica di Service Fabric con topologia di Gestione API di Azure

Scenari applicativiApplication scenarios

I servizi in Service Fabric possono essere con stato o senza stato ed essere partizionati usando uno di tre schemi: singleton, Int64 range e 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. La risoluzione degli endpoint di servizio richiede l'identificazione di una specifica partizione di una determinata istanza del servizio.Service endpoint resolution requires identifying a specific partition of a specific service instance. Durante la risoluzione di un endpoint di un servizio, è necessario specificare il nome dell'istanza del servizio (ad esempio, fabric:/myapp/myservice) e la specifica partizione del servizio, tranne nel caso di una partizione singleton.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.

Gestione API di Azure può essere usato con qualsiasi combinazione di servizi senza stato e con stato o qualsiasi schema di partizionamento.Azure API Management can be used with any combination of stateless services, stateful services, and any partitioning scheme.

Inviare traffico a un servizio senza statoSend traffic to a stateless service

Nel caso più semplice, il traffico viene inoltrato a un'istanza del servizio senza stato.In the simplest case, traffic is forwarded to a stateless service instance. A tale scopo, un'operazione di Gestione API contiene criteri di elaborazione in ingresso con un back-end Service Fabric per l'esecuzione del mapping a una specifica istanza del servizio senza stato nel back-end Service Fabric.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. Le richieste inviate al servizio vengono inviate a una replica casuale dell'istanza del servizio senza stato.Requests sent to that service are sent to a random replica of the stateless service instance.

EsempioExample

Nello scenario seguente un'applicazione Service Fabric contiene un servizio senza stato denominato fabric:/app/fooservice, che espone un'API HTTP interna.In the following scenario, a Service Fabric application contains a stateless service named fabric:/app/fooservice, that exposes an internal HTTP API. Il nome dell'istanza del servizio è noto e può essere specificato a livello di codice direttamente nei criteri di elaborazione in ingresso di Gestione API.The service instance name is well known and can be hard-coded directly in the API Management inbound processing policy.

Panoramica di Service Fabric con topologia di Gestione API di Azure

Inviare traffico a un servizio con statoSend traffic to a stateful service

Come per lo scenario del servizio senza stato, il traffico può essere inoltrato a un'istanza del servizio con stato.Similar to the stateless service scenario, traffic can be forwarded to a stateful service instance. In questo caso, un'operazione di Gestione API contiene criteri di elaborazione in ingresso con un back-end Service Fabric per l'esecuzione del mapping di una richiesta a una specifica partizione di una specifica istanza del servizio con stato.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. La partizione a cui eseguire il mapping di ogni richiesta viene calcolata tramite un metodo lambda usando un input dalla richiesta HTTP in ingresso, ad esempio un valore nel percorso dell'URL.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. I criteri possono essere configurati per l'invio di richieste alla sola replica primaria o a una replica casuale per le operazioni di lettura.The policy may be configured to send requests to the primary replica only, or to a random replica for read operations.

EsempioExample

Nello scenario seguente un'applicazione Service Fabric contiene un servizio con stato partizionato denominato fabric:/app/userservice, che espone un'API HTTP interna.In the following scenario, a Service Fabric application contains a partitioned stateful service named fabric:/app/userservice that exposes an internal HTTP API. Il nome dell'istanza del servizio è noto e può essere specificato a livello di codice direttamente nei criteri di elaborazione in ingresso di Gestione API.The service instance name is well known and can be hard-coded directly in the API Management inbound processing policy.

Il servizio viene partizionato usando lo schema di partizione Int64 con due partizioni e un intervallo di chiavi compreso tra Int64.MinValue e Int64.MaxValue.The service is partitioned using the Int64 partition scheme with two partitions and a key range that spans Int64.MinValue to Int64.MaxValue. I criteri back-end calcolano una chiave di partizione entro l'intervallo specificato convertendo il valore id indicato nel percorso della richiesta URL in un intero a 64 bit, sebbene sia possibile usare qualsiasi algoritmo per calcolare la chiave di partizione.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.

Panoramica di Service Fabric con topologia di Gestione API di Azure

Inviare traffico a più servizi senza statoSend traffic to multiple stateless services

Negli scenari più avanzati è possibile definire un'operazione di Gestione API che esegua il mapping delle richieste a più di un'istanza del servizio.In more advanced scenarios, you can define an API Management operation that maps requests to more than one service instance. In questo caso, ogni operazione contiene criteri che eseguono il mapping delle richieste a una specifica istanza del servizio in base ai valori della richiesta HTTP in ingresso, ad esempio la stringa di query o il percorso dell'URL, e nel caso di servizi con stato una partizione nell'istanza del servizio.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.

A tale scopo, un'operazione di Gestione API contiene criteri di elaborazione in ingresso con un back-end Service Fabric per l'esecuzione del mapping a un'istanza del servizio senza stato nel back-end Service Fabric in base ai valori recuperati dalla richiesta HTTP in ingresso.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. Le richieste a un'istanza del servizio vengono inviate a una replica casuale dell'istanza.Requests to a service instance are sent to a random replica of the service instance.

EsempioExample

Questo esempio illustra come creare una nuova istanza del servizio senza stato per ogni utente di un'applicazione con un nome generato dinamicamente usando la formula seguente: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>

    Ogni servizio dispone di un nome univoco, ma i nomi non sono noti in anticipo, poiché i servizi vengono creati in risposta all'input dell'utente o dell'amministratore e non possono quindi essere codificati in criteri APIM o regole di routing.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. Al contrario, il nome del servizio a cui inviare una richiesta viene generato nella definizione dei criteri back-end del valore name indicato nel percorso della richiesta dell'URL.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. ad esempio:For example:

    • Una richiesta a /api/users/foo viene instradata all'istanza del servizio fabric:/app/users/fooA request to /api/users/foo is routed to service instance fabric:/app/users/foo
    • Una richiesta a /api/users/bar viene instradata all'istanza del servizio fabric:/app/users/barA request to /api/users/bar is routed to service instance fabric:/app/users/bar

Panoramica di Service Fabric con topologia di Gestione API di Azure

Inviare traffico a più servizi con statoSend traffic to multiple stateful services

In modo analogo all'esempio del servizio senza stato, un'operazione di Gestione API può eseguire il mapping di richieste a più istanze del servizio con stato, nel qual caso potrebbe anche essere necessario eseguire la risoluzione delle partizioni per ogni istanza del servizio con stato.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.

A tale scopo, un'operazione di Gestione API contiene criteri di elaborazione in ingresso con un back-end Service Fabric per l'esecuzione del mapping a un'istanza del servizio con stato nel back-end Service Fabric in base ai valori recuperati dalla richiesta HTTP in ingresso.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. Oltre al mapping di una richiesta a una specifica istanza del servizio, è possibile eseguire il mapping di una richiesta a una specifica partizione all'interno dell'istanza del servizio e, facoltativamente, alla replica primaria o a una replica secondaria casuale all'interno della partizione.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.

EsempioExample

Questo esempio illustra come creare una nuova istanza del servizio con stato per ogni utente di un'applicazione con un nome generato dinamicamente usando la formula seguente: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>

    Ogni servizio dispone di un nome univoco, ma i nomi non sono noti in anticipo, poiché i servizi vengono creati in risposta all'input dell'utente o dell'amministratore e non possono quindi essere codificati in criteri APIM o regole di routing.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. Al contrario, il nome del servizio a cui inviare una richiesta viene generato nella definizione dei criteri back-end del valore name indicato nel percorso della richiesta dell'URL.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. ad esempio:For example:

    • Una richiesta a /api/users/foo viene instradata all'istanza del servizio fabric:/app/users/fooA request to /api/users/foo is routed to service instance fabric:/app/users/foo
    • Una richiesta a /api/users/bar viene instradata all'istanza del servizio fabric:/app/users/barA request to /api/users/bar is routed to service instance fabric:/app/users/bar

Ogni istanza del servizio viene anche partizionata usando lo schema di partizione Int64 con due partizioni e un intervallo di chiavi compreso tra Int64.MinValue e Int64.MaxValue.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. I criteri back-end calcolano una chiave di partizione entro l'intervallo specificato convertendo il valore id indicato nel percorso della richiesta URL in un intero a 64 bit, sebbene sia possibile usare qualsiasi algoritmo per calcolare la chiave di partizione.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.

Panoramica di Service Fabric con topologia di Gestione API di Azure

Passaggi successiviNext steps

Seguire l'esercitazione per impostare il primo cluster Service Fabric con Gestione API e trasferire le richieste ai servizi tramite Gestione API.Follow the tutorial to set up your first Service Fabric cluster with API Management and flow requests through API Management to your services.