Dela via

Service Fabric med Azure API Management-översikt

  • Artikel

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å nivåerna Premium och Developer i API Management på grund av nödvändig stöd för virtuella nätverk.

Arkitektur

En vanlig Service Fabric-arkitektur använder ett ensideswebbprogram som gör HTTP-anrop till serverdelstjänster som exponerar HTTP-API:er. Exempelprogrammet För att komma igång med Service Fabric visas 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 proxy-HTTP-begäranden till serverdelstjänster, enligt följande diagram:

Diagram som visar hur en tillståndslös webbtjänst fungerar som gateway till Service Fabric-programmet.

I takt med att programmen blir komplexa ökar även de gatewayer 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 stöder 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:

Diagram som visar hur webbgränssnittet fortfarande hanteras via en webbtjänst, medan HTTP API-anrop hanteras och dirigeras via Azure API Management.

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 namngivna. Tjänstslutpunktsmatchning kräver att en specifik partition identifieras för en specifik tjänstinstans. När du löser en slutpunkt för en tjänst måste både tjänstinstansens namn (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 princip för inkommande bearbetning med en Service Fabric-serverdel som mappar till en specifik tillståndslös tjänstinstans i Service Fabric-serverdelen. Begäranden som skickas till 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-principen för inkommande bearbetning.

Diagram som visar ett Service Fabric-program innehåller en tillståndslös tjänst som exponerar ett internt HTTP-API.

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 princip för inkommande bearbetning 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 några 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-principen för inkommande bearbetning.

Tjänsten partitioneras med int64-partitionsschemat med två partitioner och ett nyckelintervall som sträcker Int64.MinValue sig över 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.

Översikt över Service Fabric med Azure API Management-topologi

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 princip för inkommande bearbetning 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å användar- eller administratörsindata 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 värdet name som anges i sökvägen för URL-begäran. Till 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

Diagram som visar ett exempel där en ny tillståndslös tjänstinstans skapas för varje användare i ett program med ett dynamiskt genererat namn.

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

På samma sätt som i det tillståndslösa tjänstexemplet kan en API Management-åtgärd mappa begäranden till mer än en tillståndskänslig tjänstinstans, i vilket fall du också kan 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 princip för inkommande bearbetning 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å användar- eller administratörsindata 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 värdet name som angav sökvägen till URL-begäran. Till 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 Int64.MinValue sig över 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.

Diagram som visar att varje tjänstinstans också partitioneras med int64-partitionsschemat med två partitioner och ett nyckelintervall som sträcker sig över Int64.MinValue till Int64.MaxValue.

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.