Share via

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

  • Artykuł

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.

W tym artykule przedstawiono wprowadzenie do korzystania z usługi Azure API Management jako bramy do aplikacji usługi Service Fabric. 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 Deweloper 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 usługa internetowa bezstanowa służy jako brama do aplikacji usługi Service Fabric. Takie podejście wymaga zapisania usługi internetowej, która może proxy żądań HTTP do usług zaplecza, jak pokazano na poniższym diagramie:

Diagram przedstawiający sposób, w jaki usługa internetowa bezstanowa służy jako brama do aplikacji usługi Service Fabric.

W miarę zwiększania złożoności aplikacji bramy, które muszą prezentować 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 z minimalną pracą nad twoją częścią. 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 przez usługę Azure API Management, jak pokazano na poniższym diagramie:

Diagram przedstawiający sposób, w jaki 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.

Scenariusze aplikacji

Usługi w usłudze Service Fabric mogą być bezstanowe lub stanowe i mogą być podzielone na partycje przy użyciu jednego z trzech schematów: pojedynczego, zakresu int-64 i nazwanych. Rozpoznawanie 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 przypadku partycji pojedynczej.

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 API Management zawiera zasady przetwarzania przychodzącego z zapleczem usługi Service Fabric, które mapuje 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 API Management.

Diagram przedstawiający aplikację usługi Service Fabric zawierającą usługę bezstanową, która uwidacznia wewnętrzny interfejs API HTTP.

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 API Management zawiera zasady przetwarzania przychodzącego z zapleczem usługi Service Fabric, który mapuje żądanie na określoną partycję określonego wystąpienia usługi stanowej. Partycja do mapowania każdego żądania jest obliczana za pośrednictwem 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 API Management.

Usługa jest partycjonowana przy użyciu schematu partycji Int64 z dwiema partycjami i zakresem kluczy obejmującym Int64.MinValueInt64.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ż dowolny algorytm może służyć tutaj do obliczenia klucza partycji.

Omówienie topologii usługi Service Fabric z usługą Azure API Management

Wysyłanie ruchu do wielu usług bezstanowych

W bardziej zaawansowanych scenariuszach można zdefiniować operację 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 API Management zawiera zasady przetwarzania przychodzącego z zapleczem usługi Service Fabric, które mapuje 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 tworzone jest nowe wystąpienie usługi bezstanowej 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, a tym samym 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. Przykład:

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

Diagram przedstawiający przykład tworzenia nowego wystąpienia usługi bezstanowej dla każdego użytkownika aplikacji o dynamicznie wygenerowanej nazwie.

Wysyłanie ruchu do wielu usług stanowych

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

Aby to osiągnąć, operacja API Management zawiera zasady przetwarzania przychodzącego z zapleczem usługi Service Fabric, które mapuje 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 zostanie utworzone nowe wystąpienie usługi stanowej dla każdego użytkownika aplikacji o dynamicznie wygenerowanej nazwie 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, a tym samym 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 wartości podanej name ścieżki żądania ADRESU URL. Przykład:

    • Żądanie kierowane do /api/users/foo wystąpienia usługi fabric:/app/users/foo
    • Żądanie kierowane do /api/users/bar 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 dwoma partycjami i zakresem kluczy obejmującym Int64.MinValueInt64.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ż dowolny algorytm może służyć tutaj do obliczenia klucza partycji.

Diagram pokazujący, że każde wystąpienie usługi jest również partycjonowane przy użyciu schematu partycji Int64 z dwiema partycjami i zakresem kluczy obejmującym wartość Int64.MinValue do int64.MaxValue.

Następne kroki

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