Omgekeerde proxy in Azure Service Fabric

  • Artikel

Omgekeerde proxy ingebouwd in Azure Service Fabric helpt microservices die worden uitgevoerd in een Service Fabric-cluster detecteren en 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 de microservice de volgende stappen uitvoeren:

  1. Los de servicelocatie op via de naamgevingsservice.
  2. Maak verbinding met de service.
  3. Verpak de voorgaande stappen in een lus die beleid voor serviceomzetting en opnieuw proberen implementeert om toe te passen 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 bij het verwerken van aanvragen van clientservices. Met behulp van een omgekeerde proxy kan de clientservice http-communicatiebibliotheken aan de clientzijde gebruiken en vereist geen speciale oplossings- en pogingslogica in de service.

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 van buiten het cluster bereiken

Het standaardmodel voor externe communicatie voor microservices is een opt-in-model waarbij elke service niet rechtstreeks toegankelijk is vanaf externe clients. 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 de service in het cluster gebruikt. De meeste microservices, met name stateful microservices, bevinden zich echter niet op alle knooppunten van het cluster. De microservices kunnen bij failover tussen knooppunten worden verplaatst. In dergelijke gevallen kan Load Balancer niet effectief de locatie bepalen van het doelknooppunt van de replica's waarnaar verkeer moet worden doorgestuurd.

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 aanvullende configuratie.

Externe communicatie

Waarschuwing

Wanneer u de poort van de omgekeerde 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 geen voldoende beveiligd aanvalsoppervlak heeft.
  • Een kwaadwillende gebruiker kan onjuist ingedeelde pakketten leveren aan een interne service, wat resulteert in onbedoeld gedrag.
  • Een interne service kan persoonlijke of gevoelige informatie retourneren die niet bedoeld is om te worden blootgesteld aan services buiten het cluster, waardoor deze gevoelige informatie wordt blootgesteld aan een kwaadwillende gebruiker.

Zorg ervoor dat u de mogelijke gevolgen voor de 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 het adresseren van services met behulp van de omgekeerde proxy

De omgekeerde proxy gebruikt 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. Raadpleeg Verbinding maken met een beveiligde service met de omgekeerde proxy zodra u reverse proxy hebt ingesteld om te luisteren op HTTPS voor het doorsturen van HTTPS voor het doorsturen van HTTPS.

  • FQDN (Fully Qualified Domain Name) 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 de 'fabric:/' Regeling. Als u bijvoorbeeld de service fabric:/myapp/myservice/ wilt bereiken, gebruikt u myapp/myservice.

    De naam van het service-exemplaar is hoofdlettergevoelig. Het gebruik van een andere casing voor de naam van het service-exemplaar in de URL zorgt ervoor dat de aanvragen mislukken met 404 (Niet gevonden).

  • Pad naar achtervoegsel: 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 {"Eindpunten":{"Listener1":"Endpoint1","Listener2":"Endpoint2" ...}}. Wanneer de service meerdere eindpunten beschikbaar maakt, identificeert dit het eindpunt 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 moet 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 naar door te sturen.

  • Timeout: 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.

Gebruiksvoorbeelden

Als voorbeeld nemen we de service fabric:/MyApp/MyService waarmee een HTTP-listener wordt geopend op de volgende URL:

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

Hieronder ziet u 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
  • Intern: 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
  • Intern: http://localhost:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range

Als u de resources wilt bereiken die de service beschikbaar maakt, plaatst u het resourcepad achter de servicenaam in de URL:

  • Extern: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService/index.html?PartitionKey=3&PartitionKind=Int64Range
  • Intern: 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 afhandeling voor services voor het delen van poorten

De omgekeerde proxy van Service Fabric probeert een serviceadres opnieuw om te lossen en de aanvraag opnieuw uit te voeren wanneer een service niet kan worden bereikt. Wanneer een service niet kan worden bereikt, is het service-exemplaar of de replica over het algemeen 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 http.sys webserver, waaronder:

In deze situatie is de webserver waarschijnlijk beschikbaar in het hostproces en reageert op aanvragen, maar is het opgeloste service-exemplaar of de replica 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, bestaat mogelijk 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 dit onderscheid te maken, is een hint van de server vereist.

  • Standaard wordt in de omgekeerde proxy uitgegaan van case 2 en wordt geprobeerd de aanvraag op te lossen en opnieuw uit te voeren.

  • Als u case 1 voor de omgekeerde proxy wilt aangeven, 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 niet opnieuw probeert het serviceadres op te lossen.

Speciale verwerking voor services die in containers worden uitgevoerd

Voor services die in containers worden uitgevoerd, kunt u de omgevingsvariabele gebruiken om de omgekeerde proxy-URL te maken, Fabric_NodeIPOrFQDN 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 de omgekeerde proxy kunnen bereiken die op het knooppunt wordt uitgevoerd. Zie Uw ontwikkelaarsomgeving configureren om fouten in containers op te sporen voor meer informatie.

Service Fabric-services die worden uitgevoerd in Docker Compose-containers, vereisen een speciale configuratie van docker-compose.yml-poorten : http: of https: configuratie. Zie Ondersteuning voor Docker Compose-implementatie in Azure Service Fabric voor meer informatie.

Volgende stappen