Delen via

Omgekeerde proxy in Azure Service Fabric

  • Artikel

Omgekeerde proxy die is ingebouwd in Azure Service Fabric, helpt microservices die worden uitgevoerd in een Service Fabric-cluster, te detecteren en te communiceren met andere services met HTTP-eindpunten.

Communicatiemodel voor microservices

Microservices in Service Fabric worden uitgevoerd op een subset van knooppunten in het cluster en kunnen om verschillende redenen tussen de knooppunten worden gemigreerd. Als gevolg hiervan kunnen de eindpunten voor microservices dynamisch worden gewijzigd. Als u andere services in het cluster wilt detecteren en ermee wilt communiceren, moet microservice de volgende stappen uitvoeren:

  1. Los de servicelocatie op via de naamgevingsservice.
  2. Maak verbinding met de service.
  3. De voorgaande stappen in een lus verpakken waarmee serviceoplossing wordt geïmplementeerd en beleid voor opnieuw proberen wordt toegepast op verbindingsfouten

Zie Verbinding maken en communiceren met services voor meer informatie.

Communiceren met behulp van de omgekeerde proxy

Omgekeerde proxy is een service die op elk knooppunt wordt uitgevoerd en eindpuntomzetting, automatische nieuwe pogingen en andere verbindingsfouten namens clientservices afhandelt. Omgekeerde proxy kan worden geconfigureerd om verschillende beleidsregels toe te passen wanneer aanvragen van clientservices worden verwerkt. Met behulp van een omgekeerde proxy kan de clientservice http-communicatiebibliotheken aan de clientzijde gebruiken en is geen speciale resolutie en logica voor opnieuw proberen in de service vereist.

Omgekeerde proxy maakt een of meer eindpunten beschikbaar op het lokale knooppunt voor clientservices die kunnen worden gebruikt voor het verzenden van aanvragen naar andere services.

Interne communicatie

Notitie

Ondersteunde platforms

Omgekeerde proxy in Service Fabric ondersteunt momenteel de volgende platforms

  • Windows-cluster: Windows 8 en hoger of Windows Server 2012 en hoger
  • Linux-cluster: Omgekeerde proxy is momenteel niet beschikbaar voor Linux-clusters

Microservices bereiken van buiten het cluster

Het standaardmodel voor externe communicatie voor microservices is een opt-in model waarbij elke service niet rechtstreeks vanuit externe clients kan worden geopend. Azure Load Balancer, een netwerkgrens tussen microservices en externe clients, voert netwerkadresomzetting uit en stuurt externe aanvragen door naar interne IP:poorteindpunten. Als u het eindpunt van een microservice rechtstreeks toegankelijk wilt maken voor externe clients, moet u eerst Load Balancer configureren om verkeer door te sturen naar elke poort die door de service in het cluster wordt gebruikt. De meeste microservices, met name stateful microservices, leven echter niet op alle knooppunten van het cluster. De microservices kunnen schakelen tussen knooppunten bij failover. In dergelijke gevallen kan Load Balancer de locatie van het doelknooppunt van de replica's waarnaar verkeer moet worden doorgestuurd, niet effectief bepalen.

Microservices bereiken via de omgekeerde proxy van buiten het cluster

In plaats van de poort van een afzonderlijke service in Load Balancer te configureren, kunt u alleen de poort van de omgekeerde proxy configureren in Load Balancer. Met deze configuratie kunnen clients buiten het cluster services binnen het cluster bereiken met behulp van de omgekeerde proxy zonder extra configuratie.

Externe communicatie

Waarschuwing

Wanneer u de poort van de reverse proxy in Load Balancer configureert, zijn alle microservices in het cluster die een HTTP-eindpunt beschikbaar maken, adresseerbaar van buiten het cluster. Dit betekent dat microservices die bedoeld zijn om intern te zijn, kunnen worden gedetecteerd door een bepaalde kwaadwillende gebruiker. Dit kan ernstige beveiligingsproblemen opleveren die kunnen worden misbruikt; bijvoorbeeld:

  • Een kwaadwillende gebruiker kan een Denial of Service-aanval starten door herhaaldelijk een interne service aan te roepen die niet voldoende is beveiligd.
  • Een kwaadwillende gebruiker kan ongeldige pakketten leveren aan een interne service, wat resulteert in onbedoeld gedrag.
  • Een service die intern is, kan persoonlijke of gevoelige informatie retourneren die niet bedoeld is voor blootstelling aan services buiten het cluster, waardoor deze gevoelige informatie zichtbaar wordt voor een kwaadwillende gebruiker.

Zorg ervoor dat u de mogelijke gevolgen voor beveiliging voor uw cluster en de apps die erop worden uitgevoerd volledig begrijpt en beperkt, voordat u de omgekeerde proxypoort openbaar maakt.

URI-indeling voor adresseringsservices met behulp van de omgekeerde proxy

De omgekeerde proxy maakt gebruik van een specifieke URI-indeling (Uniform Resource Identifier) om de servicepartitie te identificeren waarnaar de binnenkomende aanvraag moet worden doorgestuurd:

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

  • http(s): De omgekeerde proxy kan worden geconfigureerd om HTTP- of HTTPS-verkeer te accepteren. Voor HTTPS-doorsturen raadpleegt u Verbinding maken met een beveiligde service met de omgekeerde proxy zodra u een omgekeerde proxy hebt ingesteld om te luisteren op HTTPS.

  • Fully Qualified Domain Name (FQDN) van cluster | intern IP-adres: voor externe clients kunt u de omgekeerde proxy zo configureren dat deze bereikbaar is via het clusterdomein, zoals mycluster.eastus.cloudapp.azure.com. Standaard wordt de omgekeerde proxy uitgevoerd op elk knooppunt. Voor intern verkeer kan de omgekeerde proxy worden bereikt op localhost of op een ip-adres van een intern knooppunt, zoals 10.0.0.1.

  • Poort: Dit is de poort, zoals 19081, die is opgegeven voor de omgekeerde proxy.

  • ServiceInstanceName: dit is de volledig gekwalificeerde naam van het geïmplementeerde service-exemplaar dat u probeert te bereiken zonder het schema 'fabric:/'. Als u bijvoorbeeld de infrastructuur wilt bereiken:/myapp/myservice/ service, gebruikt u myapp/myservice.

    De naam van het service-exemplaar is hoofdlettergevoelig. Als u een andere hoofdletter gebruikt voor de naam van het service-exemplaar in de URL, mislukken de aanvragen met 404 (niet gevonden).

  • Achtervoegselpad: dit is het werkelijke URL-pad, zoals myapi/values/add/3, voor de service waarmee u verbinding wilt maken.

  • PartitionKey: Voor een gepartitioneerde service is dit de berekende partitiesleutel van de partitie die u wilt bereiken. Houd er rekening mee dat dit niet de guid van de partitie-id is. Deze parameter is niet vereist voor services die gebruikmaken van het singleton-partitieschema.

  • PartitionKind: Dit is het servicepartitieschema. Dit kan 'Int64Range' of 'Named' zijn. Deze parameter is niet vereist voor services die gebruikmaken van het singleton-partitieschema.

  • ListenerName De eindpunten van de service hebben de vorm {"Endpoints":{"Listener1":"Endpoint1","Listener2":"Endpoint2" ...}}. Wanneer de service meerdere eindpunten beschikbaar maakt, wordt hiermee het eindpunt geïdentificeerd waarnaar de clientaanvraag moet worden doorgestuurd. Dit kan worden weggelaten als de service slechts één listener heeft.

  • TargetReplicaSelector Hiermee geeft u op hoe de doelreplica of het doelexemplaren moeten worden geselecteerd.

    • Wanneer de doelservice stateful is, kan de TargetReplicaSelector een van de volgende zijn: PrimaryReplica, RandomSecondaryReplica of RandomReplica. Wanneer deze parameter niet is opgegeven, is de standaardwaarde PrimaryReplica.
    • Wanneer de doelservice staatloos is, kiest omgekeerde proxy een willekeurig exemplaar van de servicepartitie om de aanvraag door te sturen naar.

  • Time-out: Hiermee geeft u de time-out op voor de HTTP-aanvraag die is gemaakt door de omgekeerde proxy naar de service namens de clientaanvraag. De standaardwaarde is 120 seconden. Dit is een optionele parameter.

Voorbeeld van gebruik

Laten we bijvoorbeeld de fabric gebruiken:/MyApp/MyService-service waarmee een HTTP-listener wordt geopend op de volgende URL:

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

Hier volgen de resources voor de service:

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

Als de service gebruikmaakt van het singleton partitioneringsschema, zijn de queryreeksparameters PartitionKey en PartitionKind niet vereist en kan de service worden bereikt met behulp van de gateway als:

  • Extern: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService
  • Inwendig: http://localhost:19081/MyApp/MyService

Als de service gebruikmaakt van het partitioneringsschema Uniform Int64, moeten de queryreeksparameters PartitionKey en PartitionKind worden gebruikt om een partitie van de service te bereiken:

  • Extern: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range
  • Inwendig: http://localhost:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range

Als u de resources wilt bereiken die door de service worden weergegeven, plaatst u het resourcepad na de servicenaam in de URL:

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

De gateway stuurt deze aanvragen vervolgens door naar de URL van de service:

  • 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

Speciale verwerking voor services voor het delen van poorten

De omgekeerde proxy van Service Fabric probeert een serviceadres opnieuw op te lossen en voer de aanvraag opnieuw uit wanneer een service niet kan worden bereikt. Wanneer een service niet kan worden bereikt, is het service-exemplaar of de replica verplaatst naar een ander knooppunt als onderdeel van de normale levenscyclus. Als dit gebeurt, kan de omgekeerde proxy een netwerkverbindingsfout ontvangen die aangeeft dat een eindpunt niet meer is geopend op het oorspronkelijk opgeloste adres.

Replica's of service-exemplaren kunnen echter een hostproces delen en kunnen ook een poort delen wanneer deze wordt gehost door een op http.sys gebaseerde webserver, waaronder:

In dit geval is het waarschijnlijk dat de webserver beschikbaar is in het hostproces en reageert op aanvragen, maar het opgeloste service-exemplaar of de replica is niet meer beschikbaar op de host. In dit geval ontvangt de gateway een HTTP 404-antwoord van de webserver. Een HTTP 404-antwoord kan dus twee verschillende betekenissen hebben:

  • Case #1: Het serviceadres is juist, maar de resource die de gebruiker heeft aangevraagd, bestaat niet.
  • Case 2: Het serviceadres is onjuist en de resource die de gebruiker heeft aangevraagd, kan bestaan op een ander knooppunt.

Het eerste geval is een normale HTTP 404, die wordt beschouwd als een gebruikersfout. In het tweede geval heeft de gebruiker echter een resource aangevraagd die wel bestaat. De omgekeerde proxy kan deze niet vinden omdat de service zelf is verplaatst. De omgekeerde proxy moet het adres opnieuw oplossen en de aanvraag opnieuw proberen.

De omgekeerde proxy heeft dus een manier nodig om onderscheid te maken tussen deze twee gevallen. Om dat onderscheid te maken, is een hint van de server vereist.

  • De omgekeerde proxy gaat standaard uit van case 2 en probeert de aanvraag op te lossen en opnieuw uit te voeren.

  • Als u het geval #1 wilt aangeven voor de omgekeerde proxy, moet de service de volgende HTTP-antwoordheader retourneren:

    X-ServiceFabric : ResourceNotFound

Deze HTTP-antwoordheader geeft een normale HTTP 404-situatie aan waarin de aangevraagde resource niet bestaat en de omgekeerde proxy probeert het serviceadres niet opnieuw op te lossen.

Speciale verwerking voor services die worden uitgevoerd in containers

Voor services die in containers worden uitgevoerd, kunt u de omgevingsvariabele Fabric_NodeIPOrFQDN gebruiken om de omgekeerde proxy-URL samen te stellen zoals in de volgende code:

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

Voor het lokale cluster Fabric_NodeIPOrFQDN is standaard ingesteld op 'localhost'. Start het lokale cluster met de -UseMachineName parameter om ervoor te zorgen dat containers omgekeerde proxy kunnen bereiken die op het knooppunt wordt uitgevoerd. Zie Uw ontwikkelomgeving configureren voor het opsporen van fouten in containers voor meer informatie.

Voor Service Fabric-services die worden uitgevoerd in Docker Compose-containers is een speciale docker-compose.yml sectie over poorten http: of https: configuratie vereist. Zie docker Compose-implementatieondersteuning in Azure Service Fabric voor meer informatie.

Volgende stappen