Overzicht van Service Fabric met Azure API Management

Cloudtoepassingen hebben meestal een gateway in de front-end nodig om een centraal ingangspunt te bieden voor gebruikers, apparaten of andere toepassingen. In Service Fabric kan een gateway elke staatloze service zijn, zoals een ASP.NET Core-toepassing of een andere service die is ontworpen voor inkomend verkeer, zoals Event Hubs, IoT Hub of Azure API Management.

Dit artikel is een inleiding tot het gebruik van Azure API Management als gateway voor uw Service Fabric-toepassingen. API Management kan rechtstreeks worden geïntegreerd met Service Fabric, zodat u API's kunt publiceren met een uitgebreide set routeringsregels voor uw back-endService Fabric-services.

Beschikbaarheid

Belangrijk

Deze functie is beschikbaar in de Premium - en Developer-lagen van API Management vanwege de vereiste ondersteuning voor virtuele netwerken.

Architectuur

Een algemene Service Fabric-architectuur maakt gebruik van een webtoepassing met één pagina waarmee HTTP-aanroepen worden uitgevoerd naar back-endservices die HTTP-API's beschikbaar maken. In de voorbeeldtoepassing aan de slag met Service Fabric ziet u een voorbeeld van deze architectuur.

In dit scenario fungeert een staatloze webservice als de gateway naar de Service Fabric-toepassing. Voor deze aanpak moet u een webservice schrijven die HTTP-aanvragen naar back-endservices kan proxyen, zoals wordt weergegeven in het volgende diagram:

Naarmate toepassingen complexer worden, moeten de gateways die een API moeten presenteren voor talloze back-endservices. Azure API Management is ontworpen voor het verwerken van complexe API's met routeringsregels, toegangsbeheer, snelheidsbeperking, bewaking, gebeurtenislogboekregistratie en caching van reacties met minimale hoeveelheid werk. Azure API Management biedt ondersteuning voor Service Fabric-servicedetectie, partitieomzetting en replicaselectie om aanvragen rechtstreeks naar back-endservices in Service Fabric te routeren, zodat u uw eigen stateless API-gateway niet hoeft te schrijven.

In dit scenario wordt de webgebruikersinterface nog steeds geleverd via een webservice, terwijl HTTP-API-aanroepen worden beheerd en doorgestuurd via Azure API Management, zoals wordt weergegeven in het volgende diagram:

Toepassingsscenario's

Services in Service Fabric kunnen staatloos of stateful zijn en ze kunnen worden gepartitioneerd met behulp van een van de drie schema's: singleton, int-64-bereik en benoemd. Voor het oplossen van service-eindpunten moet een specifieke partitie van een specifiek service-exemplaar worden geïdentificeerd. Bij het omzetten van een eindpunt van een service moet zowel de naam van het service-exemplaar (bijvoorbeeld fabric:/myapp/myservice) als de specifieke partitie van de service worden opgegeven, behalve in het geval van singleton-partitie.

Azure API Management kan worden gebruikt met elke combinatie van staatloze services, stateful services en elk partitioneringsschema.

Verkeer verzenden naar een stateless service

In het eenvoudigste geval wordt verkeer doorgestuurd naar een stateless service-exemplaar. Hiervoor bevat een API Management-bewerking een beleid voor binnenkomende verwerking met een Service Fabric-back-end die is toegewezen aan een specifiek stateless service-exemplaar in de Service Fabric-back-end. Aanvragen die naar die service worden verzonden, worden verzonden naar een willekeurig exemplaar van de service.

Voorbeeld

In het volgende scenario bevat een Service Fabric-toepassing een staatloze service met de naam fabric:/app/fooservice die een interne HTTP-API beschikbaar maakt. De naam van het service-exemplaar is bekend en kan rechtstreeks in het binnenkomende verwerkingsbeleid van API Management worden vastgelegd.

Verkeer verzenden naar een stateful service

Net als bij het stateless servicescenario kan verkeer worden doorgestuurd naar een stateful service-exemplaar. In dit geval bevat een API Management-bewerking een beleid voor binnenkomende verwerking met een Service Fabric-back-end waarmee een aanvraag wordt toegewezen aan een specifieke partitie van een specifiek stateful service-exemplaar. De partitie waarnaar elke aanvraag moet worden toegewezen, wordt berekend via een lambda-methode met behulp van invoer van de binnenkomende HTTP-aanvraag, zoals een waarde in het URL-pad. Het beleid kan worden geconfigureerd om aanvragen alleen naar de primaire replica te verzenden of naar een willekeurige replica voor leesbewerkingen.

Voorbeeld

In het volgende scenario bevat een Service Fabric-toepassing een gepartitioneerde stateful service met de naam fabric:/app/userservice die een interne HTTP-API beschikbaar maakt. De naam van het service-exemplaar is bekend en kan rechtstreeks in het binnenkomende verwerkingsbeleid van API Management worden vastgelegd.

De service wordt gepartitioneerd met behulp van het Int64-partitieschema met twee partities en een sleutelbereik dat zich overspant Int64.MinValue tot Int64.MaxValue. Het back-endbeleid berekent een partitiesleutel binnen dat bereik door de id waarde in het URL-aanvraagpad te converteren naar een 64-bits geheel getal, hoewel elk algoritme hier kan worden gebruikt om de partitiesleutel te berekenen.

Verkeer verzenden naar meerdere stateless services

In meer geavanceerde scenario's kunt u een API Management-bewerking definiëren waarmee aanvragen worden toegewezen aan meer dan één service-exemplaar. In dit geval bevat elke bewerking een beleid waarmee aanvragen worden toegewezen aan een specifiek service-exemplaar op basis van waarden uit de binnenkomende HTTP-aanvraag, zoals het URL-pad of de queryreeks, en in het geval van stateful services, een partitie binnen het service-exemplaar.

Hiervoor bevat een API Management-bewerking een beleid voor binnenkomende verwerking met een Service Fabric-back-end die is toegewezen aan een stateless service-exemplaar in de Service Fabric-back-end op basis van waarden die zijn opgehaald uit de binnenkomende HTTP-aanvraag. Aanvragen naar een service worden verzonden naar een willekeurig exemplaar van de service.

Voorbeeld

In dit voorbeeld wordt een nieuw stateless service-exemplaar gemaakt voor elke gebruiker van een toepassing met een dynamisch gegenereerde naam met behulp van de volgende formule:

• fabric:/app/users/<username>

  Elke service heeft een unieke naam, maar de namen zijn niet vooraf bekend omdat de services worden gemaakt als reactie op gebruikers- of beheerdersinvoer en dus niet kunnen worden vastgelegd in APIM-beleidsregels of routeringsregels. In plaats daarvan wordt de naam van de service waarnaar een aanvraag moet worden verzonden, gegenereerd in de back-endbeleidsdefinitie op basis van de name waarde die is opgegeven in het URL-aanvraagpad. Voorbeeld:

  • Een aanvraag naar /api/users/foo het service-exemplaar wordt doorgestuurd fabric:/app/users/foo
  • Een aanvraag naar /api/users/bar het service-exemplaar wordt doorgestuurd fabric:/app/users/bar

Verkeer verzenden naar meerdere stateful services

Net als bij het staatloze servicevoorbeeld kan een API Management-bewerking aanvragen toewijzen aan meer dan één stateful service-exemplaar. In dat geval moet u mogelijk ook partitieomzetting uitvoeren voor elk stateful service-exemplaar.

Om dit te bereiken, bevat een API Management-bewerking een beleid voor binnenkomende verwerking met een Service Fabric-back-end die is toegewezen aan een stateful service-exemplaar in de Service Fabric-back-end op basis van waarden die zijn opgehaald uit de binnenkomende HTTP-aanvraag. Naast het toewijzen van een aanvraag aan een specifiek service-exemplaar, kan de aanvraag ook worden toegewezen aan een specifieke partitie binnen het service-exemplaar en eventueel aan de primaire replica of een willekeurige secundaire replica binnen de partitie.

Voorbeeld

In dit voorbeeld wordt een nieuw stateful service-exemplaar gemaakt voor elke gebruiker van de toepassing met een dynamisch gegenereerde naam met behulp van de volgende formule:

• fabric:/app/users/<username>

  Elke service heeft een unieke naam, maar de namen zijn niet vooraf bekend omdat de services worden gemaakt als reactie op gebruikers- of beheerdersinvoer en dus niet kunnen worden vastgelegd in APIM-beleidsregels of routeringsregels. In plaats daarvan wordt de naam van de service waarnaar een aanvraag moet worden verzonden, gegenereerd in de back-endbeleidsdefinitie op basis van de name waarde die het URL-aanvraagpad heeft opgegeven. Voorbeeld:

  • Een aanvraag naar /api/users/foo het service-exemplaar wordt doorgestuurd fabric:/app/users/foo
  • Een aanvraag naar /api/users/bar het service-exemplaar wordt doorgestuurd fabric:/app/users/bar

Elk service-exemplaar wordt ook gepartitioneerd met behulp van het Int64-partitieschema met twee partities en een sleutelbereik dat overspantInt64.MinValue.Int64.MaxValue Het back-endbeleid berekent een partitiesleutel binnen dat bereik door de id waarde in het URL-aanvraagpad te converteren naar een 64-bits geheel getal, hoewel elk algoritme hier kan worden gebruikt om de partitiesleutel te berekenen.

Volgende stappen

Volg de zelfstudie om uw eerste Service Fabric-cluster in te stellen met API Management en stroomaanvragen via API Management voor uw services.