Udostępnij za pośrednictwem

Zwrotny serwer proxy w usłudze Azure Service Fabric

  • Artykuł

Zwrotny serwer proxy wbudowany w usługę Azure Service Fabric ułatwia mikrousługi działające w klastrze usługi Service Fabric odnajdywanie i komunikowanie się z innymi usługami, które mają punkty końcowe HTTP.

Model komunikacji mikrousług

Mikrousługi w usłudze Service Fabric działają w podzestawie węzłów w klastrze i mogą migrować między węzłami z różnych powodów. W związku z tym punkty końcowe mikrousług mogą zmieniać się dynamicznie. Aby odnajdywać i komunikować się z innymi usługami w klastrze, mikrousługi muszą wykonać następujące czynności:

  1. Rozwiąż lokalizację usługi za pomocą usługi nazewnictwa.
  2. Połącz się z usługą.
  3. Zawijanie powyższych kroków w pętli, która implementuje zasady rozwiązywania i ponawiania prób w celu zastosowania w przypadku niepowodzeń połączenia

Aby uzyskać więcej informacji, zobacz Łączenie się z usługami i komunikowanie się z nimi.

Komunikacja przy użyciu zwrotnego serwera proxy

Zwrotny serwer proxy to usługa, która działa w każdym węźle i obsługuje rozpoznawanie punktów końcowych, automatyczne ponawianie i inne błędy połączeń w imieniu usług klienckich. Zwrotny serwer proxy można skonfigurować tak, aby stosować różne zasady, ponieważ obsługuje żądania z usług klienckich. Użycie zwrotnego serwera proxy umożliwia usłudze klienckiej korzystanie z dowolnych bibliotek komunikacyjnych HTTP po stronie klienta i nie wymaga specjalnej rozdzielczości i logiki ponawiania prób w usłudze.

Zwrotny serwer proxy uwidacznia co najmniej jeden punkt końcowy w węźle lokalnym, aby usługi klienckie korzystały z wysyłania żądań do innych usług.

Komunikacja wewnętrzna

Uwaga

Obsługiwane platformy

Zwrotny serwer proxy w usłudze Service Fabric obsługuje obecnie następujące platformy

  • Klaster systemu Windows: System Windows 8 lub nowszy lub Windows Server 2012 lub nowszy
  • Klaster systemu Linux: zwrotny serwer proxy nie jest obecnie dostępny dla klastrów systemu Linux

Dotarcie do mikrousług spoza klastra

Domyślny model komunikacji zewnętrznej dla mikrousług to model zgody, w którym nie można uzyskać dostępu do każdej usługi bezpośrednio z klientów zewnętrznych. Usługa Azure Load Balancer, która jest granicą sieci między mikrousługami i klientami zewnętrznymi, wykonuje translacje adresów sieciowych i przekazuje żądania zewnętrzne do wewnętrznych punktów końcowych IP:port. Aby punkt końcowy mikrousługi był bezpośrednio dostępny dla klientów zewnętrznych, należy najpierw skonfigurować usługę Load Balancer, aby przekazywać ruch do każdego portu używanego przez usługę w klastrze. Jednak większość mikrousług, zwłaszcza mikrousług stanowych, nie działa we wszystkich węzłach klastra. Mikrousługi mogą przechodzić między węzłami w trybie failover. W takich przypadkach moduł równoważenia obciążenia nie może skutecznie określić lokalizacji węzła docelowego replik, do których powinien przekazywać ruch.

Dotarcie do mikrousług za pośrednictwem zwrotnego serwera proxy spoza klastra

Zamiast konfigurować port pojedynczej usługi w usłudze Load Balancer, można skonfigurować tylko port zwrotnego serwera proxy w usłudze Load Balancer. Ta konfiguracja umożliwia klientom spoza klastra dostęp do usług wewnątrz klastra przy użyciu zwrotnego serwera proxy bez dodatkowej konfiguracji.

Komunikacja zewnętrzna

Ostrzeżenie

Podczas konfigurowania portu zwrotnego serwera proxy w usłudze Load Balancer wszystkie mikrousługi w klastrze, które uwidaczniają punkt końcowy HTTP, są adresowane spoza klastra. Oznacza to, że mikrousługi przeznaczone do użytku wewnętrznego mogą być wykrywalne przez określonego złośliwego użytkownika. Potencjalnie stwarza to poważne luki w zabezpieczeniach, które mogą zostać wykorzystane; na przykład:

  • Złośliwy użytkownik może uruchomić atak typu "odmowa usługi", wielokrotnie wywołując usługę wewnętrzną, która nie ma wystarczająco wzmocnionej powierzchni ataków.
  • Złośliwy użytkownik może dostarczać źle sformułowane pakiety do usługi wewnętrznej, co powoduje niezamierzone zachowanie.
  • Usługa przeznaczona do użytku wewnętrznego może zwracać prywatne lub poufne informacje, które nie mają być widoczne dla usług spoza klastra, co spowoduje ujawnienie tych poufnych informacji złośliwemu użytkownikowi.

Przed upublicznieniem odwrotnego portu serwera proxy upewnij się, że w pełni rozumiesz i ograniczasz potencjalne konsekwencje zabezpieczeń dla klastra i uruchomionych w nim aplikacji.

Format identyfikatora URI dla usług adresowania przy użyciu zwrotnego serwera proxy

Zwrotny serwer proxy używa określonego formatu identyfikatora URI(URI) do identyfikowania partycji usługi, do której powinno zostać przesłane żądanie przychodzące:

http(s)://<Cluster FQDN | internal IP>:Port/<ServiceInstanceName>/<Suffix path>?PartitionKey=<key>&PartitionKind=<partitionkind>&ListenerName=<listenerName>&TargetReplicaSelector=<targetReplicaSelector>&Timeout=<timeout_in_seconds>

  • http(s): zwrotny serwer proxy można skonfigurować tak, aby akceptował ruch HTTP lub HTTPS. W przypadku przekazywania HTTPS zapoznaj się z tematem Łączenie się z bezpieczną usługą z zwrotnym serwerem proxy po skonfigurowaniu zwrotnego serwera proxy do nasłuchiwania przy użyciu protokołu HTTPS.

  • W pełni kwalifikowana nazwa domeny klastra (FQDN) | wewnętrzny adres IP: w przypadku klientów zewnętrznych można skonfigurować zwrotny serwer proxy, aby był dostępny za pośrednictwem domeny klastra, takiej jak mycluster.eastus.cloudapp.azure.com. Domyślnie zwrotny serwer proxy jest uruchamiany w każdym węźle. W przypadku ruchu wewnętrznego zwrotny serwer proxy można uzyskać na hoście lokalnym lub w dowolnym wewnętrznym adresie IP węzła, takim jak 10.0.0.1.

  • Port: jest to port, taki jak 19081, określony dla zwrotnego serwera proxy.

  • ServiceInstanceName: jest to w pełni kwalifikowana nazwa wdrożonego wystąpienia usługi, z którym próbujesz nawiązać połączenie bez schematu "fabric:/". Aby na przykład uzyskać dostęp do sieci szkieletowej :/myapp/myservice/ service, użyj polecenia myapp/myservice.

    W nazwie wystąpienia usługi jest uwzględniana wielkość liter. Użycie innej wielkości liter dla nazwy wystąpienia usługi w adresie URL powoduje niepowodzenie żądań z 404 (Nie znaleziono).

  • Ścieżka sufiksu: jest to rzeczywista ścieżka adresu URL, taka jak myapi/values/add/3, dla usługi, z którą chcesz nawiązać połączenie.

  • PartitionKey: w przypadku usługi partycjonowanej jest to obliczony klucz partycji partycji, którą chcesz uzyskać. Należy pamiętać, że nie jest to identyfikator GUID identyfikatora partycji. Ten parametr nie jest wymagany w przypadku usług korzystających ze schematu partycji pojedynczej.

  • PartitionKind: jest to schemat partycji usługi. Może to być wartość "Int64Range" lub "Named". Ten parametr nie jest wymagany w przypadku usług korzystających ze schematu partycji pojedynczej.

  • ListenerName Punkty końcowe z usługi mają postać {"Endpoints":{"Listener1":"Endpoint1","Listener2":"Endpoint2" ...}}. Gdy usługa uwidacznia wiele punktów końcowych, identyfikuje punkt końcowy, do którego powinno zostać przekazane żądanie klienta. Można to pominąć, jeśli usługa ma tylko jeden odbiornik.

  • TargetReplicaSelector określa sposób wybierania repliki docelowej lub wystąpienia.

    • Gdy usługa docelowa jest stanowa, element TargetReplicaSelector może być jednym z następujących elementów: "PrimaryReplica", "RandomSecondaryReplica" lub "RandomReplica". Jeśli ten parametr nie zostanie określony, wartość domyślna to "PrimaryReplica".
    • Gdy usługa docelowa jest bezstanowa, zwrotny serwer proxy wybiera losowe wystąpienie partycji usługi, aby przekazać żądanie do.

  • Limit czasu: określa limit czasu żądania HTTP utworzonego przez zwrotny serwer proxy do usługi w imieniu żądania klienta. Wartość domyślna to 120 sekund. Jest to opcjonalny parametr.

Przykładowe użycie

Na przykład użyjemy usługi fabric:/MyApp/MyService , która otwiera odbiornik HTTP pod następującym adresem URL:

http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/

Poniżej przedstawiono zasoby dla usługi:

  • /index.html
  • /api/users/<userId>

Jeśli usługa używa schematu partycjonowania jednotonowego, parametry ciągu zapytania PartitionKey i PartitionKind nie są wymagane, a usługa może zostać osiągnięta przy użyciu bramy jako:

  • Zewnętrznie: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService
  • Wewnętrznie: http://localhost:19081/MyApp/MyService

Jeśli usługa używa schematu partycjonowania Uniform Int64, parametry ciągu zapytania PartitionKey i PartitionKind muszą być używane do osiągnięcia partycji usługi:

  • Zewnętrznie: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range
  • Wewnętrznie: http://localhost:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range

Aby uzyskać dostęp do zasobów udostępnianych przez usługę, wystarczy umieścić ścieżkę zasobu po nazwie usługi w adresie URL:

  • Zewnętrznie: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService/index.html?PartitionKey=3&PartitionKind=Int64Range
  • Wewnętrznie: http://localhost:19081/MyApp/MyService/api/users/6?PartitionKey=3&PartitionKind=Int64Range

Następnie brama przekaże te żądania do adresu URL usługi:

  • http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/index.html
  • http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/api/users/6

Specjalna obsługa usług udostępniania portów

Odwrotny serwer proxy usługi Service Fabric próbuje ponownie rozpoznać adres usługi i ponowić próbę żądania, gdy usługa nie może zostać osiągnięta. Ogólnie rzecz biorąc, gdy nie można uzyskać dostępu do usługi, wystąpienie usługi lub replika zostały przeniesione do innego węzła w ramach normalnego cyklu życia. W takim przypadku zwrotny serwer proxy może otrzymać błąd połączenia sieciowego wskazujący, że punkt końcowy nie jest już otwarty na pierwotnie rozpoznanym adresie.

Jednak repliki lub wystąpienia usługi mogą współużytkować proces hosta, a także współużytkować port hostowany przez serwer internetowy oparty na http.sys, w tym:

W takiej sytuacji prawdopodobnie serwer internetowy jest dostępny w procesie hosta i odpowiada na żądania, ale rozpoznane wystąpienie usługi lub replika nie są już dostępne na hoście. W takim przypadku brama otrzyma odpowiedź HTTP 404 z serwera internetowego. W związku z tym odpowiedź HTTP 404 może mieć dwa odrębne znaczenie:

  • Przypadek nr 1: Adres usługi jest poprawny, ale zasób, którego zażądał użytkownik, nie istnieje.
  • Przypadek nr 2: Adres usługi jest niepoprawny, a zasób, którego zażądał użytkownik, może istnieć w innym węźle.

Pierwszy przypadek to normalny błąd HTTP 404, który jest uważany za błąd użytkownika. Jednak w drugim przypadku użytkownik zażądał zasobu, który istnieje. Zwrotny serwer proxy nie mógł go zlokalizować, ponieważ sama usługa została przeniesiona. Zwrotny serwer proxy musi ponownie rozpoznać adres i ponowić próbę żądania.

Zwrotny serwer proxy potrzebuje zatem sposobu rozróżnienia między tymi dwoma przypadkami. Aby to rozróżnić, wymagana jest wskazówka z serwera.

  • Domyślnie zwrotny serwer proxy zakłada przypadek 2 i próbuje rozwiązać i ponownie wysłać żądanie.

  • Aby wskazać przypadek 1 odwrotnego serwera proxy, usługa powinna zwrócić następujący nagłówek odpowiedzi HTTP:

    X-ServiceFabric : ResourceNotFound

Ten nagłówek odpowiedzi HTTP wskazuje normalną sytuację HTTP 404, w której żądany zasób nie istnieje, a zwrotny serwer proxy nie spróbuje ponownie rozpoznać adresu usługi.

Specjalna obsługa usług uruchomionych w kontenerach

W przypadku usług działających wewnątrz kontenerów można użyć zmiennej środowiskowej, Fabric_NodeIPOrFQDN aby skonstruować odwrotny adres URL serwera proxy, jak w poniższym kodzie:

    var fqdn = Environment.GetEnvironmentVariable("Fabric_NodeIPOrFQDN");
    var serviceUrl = $"http://{fqdn}:19081/DockerSFApp/UserApiContainer";

W przypadku klastra Fabric_NodeIPOrFQDN lokalnego jest domyślnie ustawiona wartość "localhost". Uruchom klaster lokalny z parametrem , -UseMachineName aby upewnić się, że kontenery mogą uzyskać dostęp do zwrotnego serwera proxy uruchomionego w węźle. Aby uzyskać więcej informacji, zobacz Konfigurowanie środowiska deweloperskiego do debugowania kontenerów.

Usługi Service Fabric uruchamiane w kontenerach narzędzia Docker Compose wymagają specjalnej sekcji porty docker-compose.yml http: lub https: konfiguracja. Aby uzyskać więcej informacji, zobacz Obsługa wdrażania narzędzia Docker Compose w usłudze Azure Service Fabric.

Następne kroki