Usługi Service Fabric i Azure API Management — omówienie

Aplikacje w chmurze zwykle potrzebują bramy frontonu, aby udostępniać pojedynczy punkt danych przychodzących dla użytkowników, urządzeń lub innych aplikacji. W usłudze Service Fabric brama może być dowolną usługą bezstanową, taką jak aplikacja ASP.NET Core lub inna usługa przeznaczona do ruchu przychodzącego, takich jak Event Hubs, IoT Hub lub Azure API Management.

Ten artykuł stanowi wprowadzenie do używania usługi Azure API Management jako bramy do aplikacji usługi Service Fabric. Usługa API Management integruje się bezpośrednio z usługą Service Fabric, umożliwiając publikowanie interfejsów API z bogatym zestawem reguł routingu w usługach zaplecza usługi Service Fabric.

Dostępność

Ważne

Ta funkcja jest dostępna w warstwach Premium i Developer usługi API Management ze względu na wymaganą obsługę sieci wirtualnej.

Architektura

Typowa architektura usługi Service Fabric używa jednostronicowej aplikacji internetowej, która wykonuje wywołania HTTP do usług zaplecza, które uwidaczniają interfejsy API HTTP. Przykładowa aplikacja wprowadzająca do usługi Service Fabric przedstawia przykład tej architektury.

W tym scenariuszu bezstanowa usługa internetowa służy jako brama do aplikacji usługi Service Fabric. Takie podejście wymaga napisania usługi internetowej, która może proxy żądań HTTP do usług zaplecza, jak pokazano na poniższym diagramie:

W miarę zwiększania złożoności aplikacji należy więc przedstawić interfejs API przed niezliczonymi usługami zaplecza. Usługa Azure API Management jest przeznaczona do obsługi złożonych interfejsów API z regułami routingu, kontrolą dostępu, ograniczaniem szybkości, monitorowaniem, rejestrowaniem zdarzeń i buforowaniem odpowiedzi przy minimalnej pracy ze strony użytkownika. Usługa Azure API Management obsługuje odnajdywanie usługi Service Fabric, rozpoznawanie partycji i wybór replik w celu inteligentnego kierowania żądań bezpośrednio do usług zaplecza w usłudze Service Fabric, dzięki czemu nie trzeba zapisywać własnej bezstanowej bramy interfejsu API.

W tym scenariuszu internetowy interfejs użytkownika jest nadal obsługiwany za pośrednictwem usługi internetowej, podczas gdy wywołania interfejsu API HTTP są zarządzane i kierowane za pośrednictwem usługi Azure API Management, jak pokazano na poniższym diagramie:

Scenariusze aplikacji

Usługi w usłudze Service Fabric mogą być bezstanowe lub stanowe i mogą być partycjonowane przy użyciu jednego z trzech schematów: pojedynczego, int-64 zakresu i nazwanych. Rozwiązanie punktu końcowego usługi wymaga zidentyfikowania określonej partycji określonego wystąpienia usługi. Podczas rozpoznawania punktu końcowego usługi należy określić zarówno nazwę wystąpienia usługi (na przykład fabric:/myapp/myservice), jak i konkretną partycję usługi, z wyjątkiem pojedynczej partycji.

Usługa Azure API Management może być używana z dowolną kombinacją usług bezstanowych, usług stanowych i dowolnego schematu partycjonowania.

Wysyłanie ruchu do usługi bezstanowej

W najprostszym przypadku ruch jest przekazywany do wystąpienia usługi bezstanowej. Aby to osiągnąć, operacja usługi API Management zawiera zasady przetwarzania przychodzącego z zapleczem usługi Service Fabric, które mapują na określone wystąpienie usługi bezstanowej w zapleczu usługi Service Fabric. Żądania wysyłane do tej usługi są wysyłane do losowego wystąpienia usługi.

Przykład

W poniższym scenariuszu aplikacja usługi Service Fabric zawiera usługę bezstanową o nazwie fabric:/app/fooservice , która uwidacznia wewnętrzny interfejs API HTTP. Nazwa wystąpienia usługi jest dobrze znana i może być zakodowana bezpośrednio w zasadach przetwarzania przychodzącego usługi API Management.

Wysyłanie ruchu do usługi stanowej

Podobnie jak w scenariuszu usługi bezstanowej, ruch może być przekazywany do wystąpienia usługi stanowej. W takim przypadku operacja usługi API Management zawiera zasady przetwarzania przychodzącego z zapleczem usługi Service Fabric, które mapują żądanie na określoną partycję określonego wystąpienia usługi stanowej . Partycja do mapowania każdego żądania na jest obliczana za pomocą metody lambda przy użyciu niektórych danych wejściowych z przychodzącego żądania HTTP, takiego jak wartość w ścieżce adresu URL. Zasady można skonfigurować do wysyłania żądań tylko do repliki podstawowej lub do losowej repliki na potrzeby operacji odczytu.

Przykład

W poniższym scenariuszu aplikacja usługi Service Fabric zawiera partycjonowaną usługę stanową o nazwie fabric:/app/userservice , która uwidacznia wewnętrzny interfejs API HTTP. Nazwa wystąpienia usługi jest dobrze znana i może być zakodowana bezpośrednio w zasadach przetwarzania przychodzącego usługi API Management.

Usługa jest podzielona na partycje przy użyciu schematu partycji Int64 z dwiema partycjami i zakresem kluczy obejmującym Int64.MinValue Int64.MaxValuewartość . Zasady zaplecza oblicza klucz partycji w tym zakresie, konwertując id wartość podaną w ścieżce żądania adresu URL na 64-bitową liczbę całkowitą, chociaż w tym miejscu można użyć dowolnego algorytmu do obliczenia klucza partycji.

Wysyłanie ruchu do wielu usług bezstanowych

W bardziej zaawansowanych scenariuszach można zdefiniować operację usługi API Management, która mapuje żądania na więcej niż jedno wystąpienie usługi. W takim przypadku każda operacja zawiera zasady mapujące żądania do określonego wystąpienia usługi na podstawie wartości przychodzących żądań HTTP, takich jak ścieżka adresu URL lub ciąg zapytania, a w przypadku usług stanowych partycja w wystąpieniu usługi.

Aby to osiągnąć, operacja usługi API Management zawiera zasady przetwarzania przychodzącego z zapleczem usługi Service Fabric, które są mapowane na wystąpienie usługi bezstanowej w zapleczu usługi Service Fabric na podstawie wartości pobranych z przychodzącego żądania HTTP. Żądania do usługi są wysyłane do losowego wystąpienia usługi.

Przykład

W tym przykładzie dla każdego użytkownika aplikacji z dynamicznie wygenerowaną nazwą jest tworzone nowe wystąpienie usługi bezstanowej przy użyciu następującej formuły:

• fabric:/app/users/<username>

  Każda usługa ma unikatową nazwę, ale nazwy nie są znane z góry, ponieważ usługi są tworzone w odpowiedzi na dane wejściowe użytkownika lub administratora i w związku z tym nie mogą być zakodowane w zasadach usługi APIM lub regułach routingu. Zamiast tego nazwa usługi, do której ma być wysyłane żądanie, jest generowana w definicji zasad zaplecza z name wartości podanej w ścieżce żądania adresu URL. Na przykład:

  • Żądanie do /api/users/foo jest kierowane do wystąpienia usługi fabric:/app/users/foo
  • Żądanie do /api/users/bar jest kierowane do wystąpienia usługi fabric:/app/users/bar

Wysyłanie ruchu do wielu usług stanowych

Podobnie jak w przykładzie usługi bezstanowej, operacja usługi API Management może mapować żądania na więcej niż jedno wystąpienie usługi stanowej . W tym przypadku może być konieczne również przeprowadzenie rozpoznawania partycji dla każdego wystąpienia usługi stanowej.

Aby to osiągnąć, operacja usługi API Management zawiera zasady przetwarzania przychodzącego z zapleczem usługi Service Fabric, które są mapowane na stanowe wystąpienie usługi w zapleczu usługi Service Fabric na podstawie wartości pobranych z przychodzącego żądania HTTP. Oprócz mapowania żądania do określonego wystąpienia usługi żądanie może być również mapowane na określoną partycję w ramach wystąpienia usługi, a opcjonalnie do repliki podstawowej lub losowej repliki pomocniczej w ramach partycji.

Przykład

W tym przykładzie dla każdego użytkownika aplikacji tworzone jest nowe wystąpienie usługi stanowej z dynamicznie wygenerowaną nazwą przy użyciu następującej formuły:

• fabric:/app/users/<username>

  Każda usługa ma unikatową nazwę, ale nazwy nie są znane z góry, ponieważ usługi są tworzone w odpowiedzi na dane wejściowe użytkownika lub administratora i w związku z tym nie mogą być zakodowane w zasadach usługi APIM lub regułach routingu. Zamiast tego nazwa usługi, do której ma być wysyłane żądanie, jest generowana w definicji zasad zaplecza z name wartości podanej ścieżki żądania adresu URL. Na przykład:

  • Żądanie do /api/users/foo jest kierowane do wystąpienia usługi fabric:/app/users/foo
  • Żądanie do /api/users/bar jest kierowane do wystąpienia usługi fabric:/app/users/bar

Każde wystąpienie usługi jest również partycjonowane przy użyciu schematu partycji Int64 z dwiema partycjami i zakresem kluczy obejmującym Int64.MinValue Int64.MaxValuewartość . Zasady zaplecza oblicza klucz partycji w tym zakresie, konwertując id wartość podaną w ścieżce żądania adresu URL na 64-bitową liczbę całkowitą, chociaż w tym miejscu można użyć dowolnego algorytmu do obliczenia klucza partycji.

Następne kroki

Postępuj zgodnie z samouczkiem, aby skonfigurować pierwszy klaster usługi Service Fabric za pomocą usługi API Management i żądania przepływu za pośrednictwem usługi API Management do usług.