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 pośrednictwem usługi nazewnictwa.
  2. Połącz się z usługą.
  3. Zawijanie powyższych kroków w pętli, która implementuje zasady rozpoznawania 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 uruchamiana 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ć do stosowania różnych zasad w miarę obsługi żądań z usług klienckich. Użycie zwrotnego serwera proxy umożliwia usłudze klienckiej używanie 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 używały żądań do wysyłania żądań do innych usług.

Komunikacja wewnętrzna

Uwaga

Obsługiwane platformy

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

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

Docieranie do mikrousług spoza klastra

Domyślnym modelem komunikacji zewnętrznej dla mikrousług jest model opt-in, w którym nie można uzyskać dostępu do każdej usługi bezpośrednio z klientów zewnętrznych. Azure Load Balancer, która jest granicą sieci między mikrousługami i klientami zewnętrznymi, wykonuje tłumaczenie 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ć Load Balancer do przekazywania ruchu do każdego portu używanego przez usługę w klastrze. Jednak większość mikrousług, zwłaszcza stanowych mikrousług, nie działa na wszystkich węzłach klastra. Mikrousługi mogą przechodzić między węzłami w trybie failover. W takich przypadkach Load Balancer 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 Load Balancer, można skonfigurować tylko port odwrotnego serwera proxy w 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 odwrotnego serwera proxy w Load Balancer wszystkie mikrousługi w klastrze, które uwidaczniają punkt końcowy HTTP, są adresowalne spoza klastra. Oznacza to, że mikrousługi, które mają być wewnętrzne, 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 ataku.
  • 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śliwym użytkownikom.

Przed udostępnieniem zwrotnego portu serwera proxy upewnij się, że w pełni rozumiesz potencjalne konsekwencje zabezpieczeń dla klastra i aplikacji uruchomionych na nim.

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

Zwrotny serwer proxy używa określonego formatu identyfikatora URI (Uniform Resource Identifier), aby zidentyfikować partycję usługi, do której ma zostać przekazane żą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 Nawiązywanie połączenia 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 na dowolnym wewnętrznym adresie IP węzła, takim jak 10.0.0.1.

  • Portu: 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 ciągu "fabric:/" Schemat. Aby na przykład uzyskać dostęp do sieci szkieletowej:/myapp/myservice/ service, użyj polecenia myapp/myservice.

    Nazwa wystąpienia usługi jest wrażliwa na 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 podzielonej na partycje 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 dla usług korzystających ze schematu partycji pojedynczej.

  • PartitionKind: Jest to schemat partycji usługi. Może to być "Int64Range" lub "Nazwane". Ten parametr nie jest wymagany dla usług korzystających ze schematu partycji pojedynczej.

  • Nazwa odbiornika 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ład użycia

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 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ę, po prostu umieść ś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

Zwrotny 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 usługa nie może zostać osiągnięta, 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 nieprawidłowy, a zasób, którego zażądał użytkownik, mógł 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 może go zlokalizować, ponieważ sama usługa została przeniesiona. Zwrotny serwer proxy musi ponownie rozpoznać adres i ponowić próbę żądania.

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

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

  • Aby wskazać przypadek #1 do zwrotnego 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 podejmie próby ponownego rozpoznania adresu usługi.

Specjalna obsługa usług działających w kontenerach

W przypadku usług działających wewnątrz kontenerów można użyć zmiennej środowiskowej, Fabric_NodeIPOrFQDN aby skonstruować zwrotny adres URL serwera proxy , tak 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ą uzyskiwać dostęp do zwrotnego serwera proxy działającego w węźle. Aby uzyskać więcej informacji, zobacz Konfigurowanie środowiska deweloperskiego w celu debugowania kontenerów.

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

Następne kroki