Service Fabric med Azure API Management-översikt

Molnprogram behöver ofta en klientdelsgateway som enda åtkomstpunkt för ingång för användare, enheter och andra program. I Service Fabric kan en gateway vara valfri tillståndslös tjänst, till exempel ett ASP.NET Core program eller en annan tjänst som är utformad för inkommande trafik, till exempel Event Hubs, IoT Hub eller Azure API Management.

Den här artikeln är en introduktion till att använda Azure API Management som en gateway till dina Service Fabric-program. API Management integreras direkt med Service Fabric, så att du kan publicera API:er med en omfattande uppsättning routningsregler till dina Service Fabric-tjänster i serverdelen.

Tillgänglighet

Viktigt

Den här funktionen är tillgänglig på premium- och utvecklarnivåerna för API Management på grund av nödvändig stöd för virtuella nätverk.

Arkitektur

En vanlig Service Fabric-arkitektur använder ett enkelsidigt webbprogram som gör HTTP-anrop till serverdelstjänster som exponerar HTTP-API:er. Exempelprogrammet För att komma igång med Service Fabric visar ett exempel på den här arkitekturen.

I det här scenariot fungerar en tillståndslös webbtjänst som gateway till Service Fabric-programmet. Den här metoden kräver att du skriver en webbtjänst som kan skicka HTTP-begäranden via proxy till serverdelstjänster, som du ser i följande diagram:

I takt med att programmen blir mer komplexa gör även gatewayerna som måste presentera ett API framför otaliga serverdelstjänster. Azure API Management är utformat för att hantera komplexa API:er med routningsregler, åtkomstkontroll, hastighetsbegränsning, övervakning, händelseloggning och cachelagring av svar med minimalt arbete från din sida. Azure API Management har stöd för serviceidentifiering, partitionsmatchning och replikval för att på ett intelligent sätt dirigera begäranden direkt till serverdelstjänster i Service Fabric så att du inte behöver skriva en egen tillståndslös API-gateway.

I det här scenariot hanteras webbgränssnittet fortfarande via en webbtjänst, medan HTTP API-anrop hanteras och dirigeras via Azure API Management, enligt följande diagram:

Programscenarier

Tjänsterna i Service Fabric kan vara antingen tillståndslösa eller tillståndskänsliga, och de kan partitioneras med något av tre scheman: singleton, int-64-intervall och namngivet. Lösning av tjänstslutpunkter kräver identifiering av en specifik partition för en specifik tjänstinstans. När du löser en slutpunkt för en tjänst måste både tjänstinstansnamnet (till exempel fabric:/myapp/myservice) och den specifika partitionen för tjänsten anges, förutom när det gäller singleton-partition.

Azure API Management kan användas med valfri kombination av tillståndslösa tjänster, tillståndskänsliga tjänster och valfritt partitioneringsschema.

Skicka trafik till en tillståndslös tjänst

I det enklaste fallet vidarebefordras trafiken till en tillståndslös tjänstinstans. För att uppnå detta innehåller en API Management-åtgärd en inkommande bearbetningsprincip med en Service Fabric-serverdel som mappar till en specifik tillståndslös tjänstinstans i Service Fabric-serverdelen. Begäranden som skickas till den tjänsten skickas till en slumpmässig instans av tjänsten.

Exempel

I följande scenario innehåller ett Service Fabric-program en tillståndslös tjänst med namnet fabric:/app/fooservice som exponerar ett internt HTTP-API. Namnet på tjänstinstansen är välkänt och kan hårdkodas direkt i API Management inkommande bearbetningsprincipen.

Skicka trafik till en tillståndskänslig tjänst

På samma sätt som i scenariot med tillståndslös tjänst kan trafik vidarebefordras till en tillståndskänslig tjänstinstans. I det här fallet innehåller en API Management-åtgärd en inkommande bearbetningsprincip med en Service Fabric-serverdel som mappar en begäran till en specifik partition av en specifik tillståndskänslig tjänstinstans. Partitionen som varje begäran ska mappas till beräknas via en lambda-metod med hjälp av indata från den inkommande HTTP-begäran, till exempel ett värde i URL-sökvägen. Principen kan konfigureras för att endast skicka begäranden till den primära repliken eller till en slumpmässig replik för läsåtgärder.

Exempel

I följande scenario innehåller ett Service Fabric-program en partitionerad tillståndskänslig tjänst med namnet fabric:/app/userservice som exponerar ett internt HTTP-API. Namnet på tjänstinstansen är välkänt och kan hårdkodas direkt i API Management inkommande bearbetningsprincipen.

Tjänsten partitioneras med int64-partitionsschemat med två partitioner och ett nyckelintervall som sträcker sig över Int64.MinValue till Int64.MaxValue. Serverdelsprincipen beräknar en partitionsnyckel inom det intervallet genom att konvertera id värdet som anges i URL-begärandesökvägen till ett 64-bitars heltal, även om alla algoritmer kan användas här för att beräkna partitionsnyckeln.

Skicka trafik till flera tillståndslösa tjänster

I mer avancerade scenarier kan du definiera en API Management åtgärd som mappar begäranden till mer än en tjänstinstans. I det här fallet innehåller varje åtgärd en princip som mappar begäranden till en specifik tjänstinstans baserat på värden från den inkommande HTTP-begäran, till exempel URL-sökvägen eller frågesträngen, och när det gäller tillståndskänsliga tjänster, en partition i tjänstinstansen.

För att uppnå detta innehåller en API Management-åtgärd en inkommande bearbetningsprincip med en Service Fabric-serverdel som mappar till en tillståndslös tjänstinstans i Service Fabric-serverdelen baserat på värden som hämtats från den inkommande HTTP-begäran. Begäranden till en tjänst skickas till en slumpmässig instans av tjänsten.

Exempel

I det här exemplet skapas en ny tillståndslös tjänstinstans för varje användare av ett program med ett dynamiskt genererat namn med hjälp av följande formel:

• fabric:/app/users/<username>

  Varje tjänst har ett unikt namn, men namnen är inte kända i förväg eftersom tjänsterna skapas som svar på indata från användare eller administratörer och därför inte kan hårdkodas i APIM-principer eller routningsregler. I stället genereras namnet på den tjänst som en begäran ska skickas till i principdefinitionen för serverdelen från name värdet som anges i URL-begärandesökvägen. Exempel:

  • En begäran till /api/users/foo dirigeras till tjänstinstansen fabric:/app/users/foo
  • En begäran till /api/users/bar dirigeras till tjänstinstansen fabric:/app/users/bar

Skicka trafik till flera tillståndskänsliga tjänster

På samma sätt som i exemplet med tillståndslös tjänst kan en API Management-åtgärd mappa begäranden till mer än en tillståndskänslig tjänstinstans. I så fall kan du också behöva utföra partitionsmatchning för varje tillståndskänslig tjänstinstans.

För att uppnå detta innehåller en API Management-åtgärd en inkommande bearbetningsprincip med en Service Fabric-serverdel som mappar till en tillståndskänslig tjänstinstans i Service Fabric-serverdelen baserat på värden som hämtats från den inkommande HTTP-begäran. Förutom att mappa en begäran till en specifik tjänstinstans kan begäran också mappas till en specifik partition i tjänstinstansen och eventuellt till antingen den primära repliken eller en slumpmässig sekundär replik i partitionen.

Exempel

I det här exemplet skapas en ny tillståndskänslig tjänstinstans för varje användare av programmet med ett dynamiskt genererat namn med hjälp av följande formel:

• fabric:/app/users/<username>

  Varje tjänst har ett unikt namn, men namnen är inte kända i förväg eftersom tjänsterna skapas som svar på indata från användare eller administratörer och därför inte kan hårdkodas i APIM-principer eller routningsregler. I stället genereras namnet på den tjänst som en begäran ska skickas till i principdefinitionen för serverdelen från name värdet som angav url-begärandesökvägen. Exempel:

  • En begäran till /api/users/foo dirigeras till tjänstinstansen fabric:/app/users/foo
  • En begäran till /api/users/bar dirigeras till tjänstinstansen fabric:/app/users/bar

Varje tjänstinstans partitioneras också med int64-partitionsschemat med två partitioner och ett nyckelintervall som sträcker sig över Int64.MinValue till Int64.MaxValue. Serverdelsprincipen beräknar en partitionsnyckel inom det intervallet genom att konvertera id värdet som anges i URL-begärandesökvägen till ett 64-bitars heltal, även om alla algoritmer kan användas här för att beräkna partitionsnyckeln.

Nästa steg

Följ självstudien för att konfigurera ditt första Service Fabric-kluster med API Management och flödesbegäranden via API Management till dina tjänster.