Omgekeerde proxy in Azure Service Fabric

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

Communicatiemodel voor microservices

Microservices in Service Fabric uitgevoerd op een subset van knooppunten in het cluster en kunnen om verschillende redenen worden gemigreerd tussen de knooppunten. Als gevolg hiervan kunnen de eindpunten voor microservices dynamisch worden gewijzigd. Voor het ontdekken en communiceren met andere services in het cluster moet de microservice de volgende stappen doorlopen:

  1. Los de servicelocatie op via de naamgevingsservice.
  2. Verbinding maken naar de service.
  3. Verpak de voorgaande stappen in een lus die beleidsregels voor service-oplossing en opnieuw proberen implementeert om toe te passen op verbindingsfouten

Zie voor meer informatie Verbinding maken en communiceren met services.

Communiceren met behulp van de omgekeerde proxy

Omgekeerde proxy is een service die wordt uitgevoerd op elk knooppunt en die eindpuntoplossing, automatisch opnieuw proberen en andere verbindingsfouten namens clientservices verwerkt. Omgekeerde proxy kan worden geconfigureerd om verschillende beleidsregels toe te passen wanneer deze aanvragen van clientservices verwerkt. Als u een omgekeerde proxy gebruikt, kan de clientservice http-communicatiebibliotheken aan de clientzijde gebruiken. Er is geen speciale oplossings- en pogingslogica in de service vereist.

Omgekeerde proxy geeft een of meer eindpunten op het lokale knooppunt weer die clientservices kunnen gebruiken voor het verzenden van aanvragen naar andere services.

Interne communicatie

Notitie

Ondersteunde platforms

Omgekeerde proxy in Service Fabric ondersteunt momenteel de volgende platformen

  • 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 gebruikt. Azure Load Balancer,een netwerkgrens tussen microservices en externe clients, voert een netwerkadresomtaling uit en worden externe aanvragen doorgestuurd naar interne IP:poort-eindpunten. Als u het eindpunt van een microservice rechtstreeks toegankelijk wilt maken voor externe clients, moet u eerst Load Balancer configureren voor het doorsturen van verkeer naar elke poort die de service in het cluster gebruikt. De meeste microservices, met name stateful microservices, werken echter niet op alle knooppunten van het cluster. De microservices kunnen zich na een failover verplaatsen tussen knooppunten. In dergelijke gevallen kan Load Balancer de locatie van het doel-knooppunt van de replica's waarop het 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 configureren, kunt u alleen de poort van de omgekeerde proxy 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 blootstellen adresseerbaar van buiten het cluster. Dit betekent dat microservices die bedoeld zijn om intern te zijn, kunnen worden ontdekt door een kwaadwillende gebruiker. Dit kan ernstige beveiligingsproblemen met zich mee hebben 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 gehard aanvalsoppervlak heeft.
  • Een kwaadwillende gebruiker kan verkeerd geformeerde pakketten leveren aan een interne service, wat leidt tot onbedoeld gedrag.
  • Een interne service kan persoonlijke of gevoelige informatie retourneren die niet is bedoeld om te worden blootgesteld aan services buiten het cluster, waardoor deze gevoelige informatie zichtbaar wordt voor kwaadwillende gebruikers.

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

URI-indeling voor het adresseren van services met behulp van de omgekeerde proxy

De omgekeerde proxy maakt gebruik van een specifieke URI-indeling (Uniform Resource Identifier) om de servicepartitie te identificeren waarvoor 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 doorsturen via HTTPS raadpleegt u Verbinding maken naar een beveiligde service met de omgekeerde proxy zodra u een omgekeerde proxy hebt ingesteld om op HTTPS te luisteren.

  • FQDN (Fully Qualified Domain Name) van het cluster | interne IP: 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 op elk knooppunt uitgevoerd. Voor intern verkeer kan de omgekeerde proxy worden bereikt op localhost of op elk intern knooppunt-IP-adres, 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 casegevoelig. Als u een ander casing 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 die u wilt verbinden.

  • PartitionKey: Voor een gepartitiede service is dit de berekende partitiesleutel van de partitie die u wilt bereiken. Houd er rekening mee dat dit niet de partitie-id-GUID 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":"Eindpunt2" ...}}. Wanneer de service meerdere eindpunten openbaar maakt, identificeert dit het eindpunt waar de clientaanvraag naar moet worden doorgestuurd. Dit kan worden weggelaten als de service slechts één listener heeft.

  • TargetReplicaSelector Hiermee geeft u op hoe de doelreplica of het doel-exemplaar moet worden geselecteerd.

    • Wanneer de doelservice stateful is, kan 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 de omgekeerde proxy een willekeurig exemplaar van de servicepartitie om de aanvraag naar door te sturen.

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

Gebruiksvoorbeelden

Laten we bijvoorbeeld de fabric:/MyApp/MyService-service nemen die een HTTP-listener opent 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 partitieschema voor singleton, 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 partitieschema 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

Plaats het resourcepad na de servicenaam in de URL om de resources te bereiken die de service beschikbaar maakt:

  • 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 zal deze aanvragen vervolgens doorsturen 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 poort

De Service Fabric omgekeerde proxy probeert een serviceadres opnieuw op te lossen en probeert de aanvraag opnieuw 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, ontvangt de omgekeerde proxy mogelijk een netwerkverbindingsfout 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 dit geval is de webserver waarschijnlijk beschikbaar in het hostproces en reageert op aanvragen, maar het opgeloste service-exemplaar of de omgeslagen 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 betekenis 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 bestaande resource aangevraagd. 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 een #2 en probeert de aanvraag op te lossen en opnieuw uit te geven.

  • Om aan te geven #1 naar de omgekeerde proxy, moet de service de volgende HTTP-antwoordheader retourneren:

    X-ServiceFabric : ResourceNotFound

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

Speciale verwerking voor services die worden uitgevoerd in containers

Voor services die in containers worden uitgevoerd, kunt u de omgevingsvariabele gebruiken om Fabric_NodeIPOrFQDN de omgekeerde proxy-URL te maken, 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 parameter om ervoor te zorgen dat containers een omgekeerde proxy kunnen bereiken die -UseMachineName wordt uitgevoerd op het knooppunt. Zie Configure your developer environment to debug containers (Uw ontwikkelomgeving configureren voor foutopsporing in containers) voor meer informatie.

Service Fabric services die worden uitgevoerd in Docker Compose-containers, is een speciale sectie docker-compose.yml Ports http: of https: configuration vereist. Zie Ondersteuning voor implementatie van Docker Compose in Azure Service Fabric voor meer Service Fabric.

Volgende stappen