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 integreert rechtstreeks met Service Fabric, zodat u API's met een uitgebreide set routeringsregels kunt publiceren naar uw back-end Service Fabric-services.

Beschikbaarheid

Architectuur

Een algemene Service Fabric-architectuur maakt gebruik van een webtoepassing met één pagina die HTTP-aanroepen uitvoert naar back-endservices die HTTP-API's beschikbaar maken. De voorbeeldtoepassing Aan de slag met Service Fabric toont een voorbeeld van deze architectuur.

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

Naarmate toepassingen steeds complexer worden, geldt dit ook voor de gateways die een API moeten presenteren voor talloze back-endservices. Azure API Management is ontworpen voor het afhandelen van complexe API's met routeringsregels, toegangsbeheer, snelheidsbeperking, bewaking, logboekregistratie van gebeurtenissen en reactiecaching met minimale hoeveelheid werk van uw kant. Azure API Management ondersteunt Service Fabric-servicedetectie, partitieomzetting en replicaselectie om aanvragen op intelligente wijze rechtstreeks naar back-endservices in Service Fabric te routeren, zodat u niet uw eigen stateless API-gateway hoeft te schrijven.

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

Toepassingsscenario's

Services in Service Fabric kunnen staatloos of stateful zijn en kunnen worden gepartitioneerd met behulp van een van 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 moeten 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 een singletonpartitie.

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

Verkeer verzenden naar een staatloze service

In het eenvoudigste geval wordt verkeer doorgestuurd naar een staatloze service-instantie. 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 specifiek staatloos 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 stateless 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 worden vastgelegd in het API Management beleid voor binnenkomende verwerking.

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 die een aanvraag toe wijst aan een specifieke partitie van een specifiek stateful service-exemplaar. De partitie waaraan 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 alleen aanvragen te verzenden naar de primaire replica 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 worden vastgelegd in het API Management beleid voor binnenkomende verwerking.

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

Verkeer verzenden naar meerdere stateless services

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

Om dit te bereiken, bevat een API Management-bewerking een binnenkomende verwerkingsbeleid met een Service Fabric-back-end die wordt toegewezen aan een staatloos 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 vooraf niet bekend omdat de services worden gemaakt als reactie op invoer van gebruikers of beheerders en dus niet kunnen worden vastgelegd in APIM-beleid of routeringsregels. In plaats daarvan wordt de naam van de service waarnaar een aanvraag moet worden verzonden, gegenereerd in de definitie van het back-endbeleid op basis van de name waarde die is opgegeven in het URL-aanvraagpad. Bijvoorbeeld:

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

Verkeer verzenden naar meerdere stateful services

Net als in het voorbeeld van een stateless service 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 binnenkomende verwerkingsbeleid met een Service Fabric-back-end die wordt 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 optioneel aan de primaire replica of een willekeurige secundaire replica binnen de partitie.

Voorbeeld

In dit voorbeeld wordt voor elke gebruiker van de toepassing een nieuw stateful service-exemplaar gemaakt 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 vooraf niet bekend omdat de services worden gemaakt als reactie op invoer van gebruikers of beheerders en dus niet kunnen worden vastgelegd in APIM-beleid of routeringsregels. In plaats daarvan wordt de naam van de service waarnaar een aanvraag moet worden verzonden, gegenereerd in de definitie van het back-endbeleid op basis van de name waarde die het URL-aanvraagpad heeft opgegeven. Bijvoorbeeld:

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

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

Volgende stappen

Volg de zelfstudie voor het instellen van uw eerste Service Fabric-cluster met API Management en stroomaanvragen via API Management naar uw services.