Omvänd proxy i Azure Service Fabric

  • Artikel

Omvänd proxy som är inbyggd i Azure Service Fabric hjälper mikrotjänster som körs i ett Service Fabric-kluster att identifiera och kommunicera med andra tjänster som har http-slutpunkter.

Kommunikationsmodell för mikrotjänster

Mikrotjänster i Service Fabric körs på en delmängd av noder i klustret och kan migrera mellan noderna av olika skäl. Därför kan slutpunkterna för mikrotjänster ändras dynamiskt. För att identifiera och kommunicera med andra tjänster i klustret måste mikrotjänsten gå igenom följande steg:

  1. Lös tjänstplatsen via namngivningstjänsten.
  2. Anslut till tjänsten.
  3. Omslut föregående steg i en loop som implementerar principer för tjänstmatchning och återförsök som ska tillämpas vid anslutningsfel

Mer information finns i Ansluta och kommunicera med tjänster.

Kommunicera med hjälp av omvänd proxy

Omvänd proxy är en tjänst som körs på varje nod och hanterar slutpunktsmatchning, automatiskt återförsök och andra anslutningsfel för klienttjänsters räkning. Omvänd proxy kan konfigureras för att tillämpa olika principer eftersom den hanterar begäranden från klienttjänster. Om du använder en omvänd proxy kan klienttjänsten använda alla HTTP-kommunikationsbibliotek på klientsidan och kräver inte särskild lösning och omprövningslogik i tjänsten.

Omvänd proxy exponerar en eller flera slutpunkter på den lokala noden för klienttjänster som ska användas för att skicka begäranden till andra tjänster.

Intern kommunikation

Anteckning

Plattformar som stöds

Omvänd proxy i Service Fabric stöder för närvarande följande plattformar

  • Windows-kluster: Windows 8 och senare eller Windows Server 2012 och senare
  • Linux-kluster: Omvänd proxy är för närvarande inte tillgängligt för Linux-kluster

Nå mikrotjänster utanför klustret

Standardmodellen för extern kommunikation för mikrotjänster är en opt-in-modell där varje tjänst inte kan nås direkt från externa klienter. Azure Load Balancer, som är en nätverksgräns mellan mikrotjänster och externa klienter, utför översättning av nätverksadresser och vidarebefordrar externa begäranden till interna IP:portslutpunkter. Om du vill göra en mikrotjänsts slutpunkt direkt tillgänglig för externa klienter måste du först konfigurera Load Balancer att vidarebefordra trafik till varje port som tjänsten använder i klustret. De flesta mikrotjänster, särskilt tillståndskänsliga mikrotjänster, finns dock inte på alla noder i klustret. Mikrotjänsterna kan flyttas mellan noder vid redundansväxling. I sådana fall kan Load Balancer inte på ett effektivt sätt fastställa platsen för målnoden för de repliker som den ska vidarebefordra trafik till.

Nå mikrotjänster via omvänd proxy utanför klustret

I stället för att konfigurera porten för en enskild tjänst i Load Balancer kan du bara konfigurera porten för den omvända proxyn i Load Balancer. Med den här konfigurationen kan klienter utanför klustret nå tjänster i klustret med hjälp av omvänd proxy utan ytterligare konfiguration.

Extern kommunikation

Varning

När du konfigurerar den omvända proxyporten i Load Balancer kan alla mikrotjänster i klustret som exponerar en HTTP-slutpunkt adresseras utanför klustret. Det innebär att mikrotjänster som är avsedda att vara interna kan identifieras av en bestämd illvillig användare. Detta kan innebära allvarliga sårbarheter som kan utnyttjas. till exempel:

  • En obehörig användare kan starta en Denial of Service-attack genom att upprepade gånger anropa en intern tjänst som inte har en tillräckligt härdad attackyta.
  • En obehörig användare kan leverera felaktiga paket till en intern tjänst, vilket resulterar i oavsiktligt beteende.
  • En tjänst som är avsedd att vara intern kan returnera privat eller känslig information som inte är avsedd att exponeras för tjänster utanför klustret, vilket exponerar denna känsliga information för en obehörig användare.

Se till att du förstår och minimerar eventuella säkerhetsrisker för klustret och de appar som körs på det innan du gör den omvända proxyporten offentlig.

URI-format för adressering av tjänster med hjälp av omvänd proxy

Den omvända proxyn använder ett specifikt URI-format (Uniform Resource Identifier) för att identifiera tjänstpartitionen som den inkommande begäran ska vidarebefordras till:

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

  • http(s): Den omvända proxyn kan konfigureras för att acceptera HTTP- eller HTTPS-trafik. Information om HTTPS-vidarebefordring finns i Ansluta till en säker tjänst med omvänd proxy när du har konfigurerat omvänd proxy för att lyssna på HTTPS.

  • Fullständigt domännamn för kluster (FQDN) | intern IP-adress: För externa klienter kan du konfigurera omvänd proxy så att den kan nås via klusterdomänen, till exempel mycluster.eastus.cloudapp.azure.com. Som standard körs den omvända proxyn på varje nod. För intern trafik kan den omvända proxyn nås på localhost eller på en intern nod-IP, till exempel 10.0.0.1.

  • Port: Det här är porten, till exempel 19081, som har angetts för omvänd proxy.

  • ServiceInstanceName: Det här är det fullständigt kvalificerade namnet på den distribuerade tjänstinstansen som du försöker nå utan "fabric:/" System. Om du till exempel vill nå tjänsten fabric:/myapp/myservice/ använder du myapp/myservice.

    Tjänstinstansnamnet är skiftlägeskänsligt. Om du använder ett annat hölje för tjänstinstansnamnet i URL:en misslyckas begäranden med 404 (hittades inte).

  • Suffixsökväg: Det här är den faktiska URL-sökvägen, till exempel myapi/values/add/3, för den tjänst som du vill ansluta till.

  • PartitionKey: För en partitionerad tjänst är detta den beräknade partitionsnyckeln för den partition som du vill nå. Observera att detta inte är partitions-ID:ts GUID. Den här parametern krävs inte för tjänster som använder singleton-partitionsschemat.

  • PartitionKind: Det här är tjänstpartitionsschemat. Detta kan vara "Int64Range" eller "Namngivet". Den här parametern krävs inte för tjänster som använder singleton-partitionsschemat.

  • ListenerName Slutpunkterna från tjänsten är av formatet {"Slutpunkter":{"Lyssnare1":"Slutpunkt1","Lyssnare2":"Slutpunkt2" ...}}. När tjänsten exponerar flera slutpunkter identifierar detta den slutpunkt som klientbegäran ska vidarebefordras till. Detta kan utelämnas om tjänsten bara har en lyssnare.

  • TargetReplicaSelector Detta anger hur målrepliken eller -instansen ska väljas.

    • När måltjänsten är tillståndskänslig kan TargetReplicaSelector vara något av följande: "PrimaryReplica", "RandomSecondaryReplica" eller "RandomReplica". När den här parametern inte anges är standardvärdet PrimaryReplica.
    • När måltjänsten är tillståndslös väljer omvänd proxy en slumpmässig instans av tjänstpartitionen som begäran ska vidarebefordras till.

  • Timeout: Detta anger tidsgränsen för HTTP-begäran som skapats av den omvända proxyn till tjänsten för klientbegäran. Standardvärdet är 120 sekunder. Det här är en valfri parameter.

Exempel på användning

Vi tar till exempel tjänsten fabric:/MyApp/MyService som öppnar en HTTP-lyssnare på följande URL:

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

Följande är resurserna för tjänsten:

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

Om tjänsten använder singleton-partitioneringsschemat krävs inte frågesträngsparametrarna PartitionKey och PartitionKind , och tjänsten kan nås med hjälp av gatewayen som:

  • Externt: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService
  • Internt: http://localhost:19081/MyApp/MyService

Om tjänsten använder partitioneringsschemat Uniform Int64 måste frågesträngsparametrarna PartitionKey och PartitionKind användas för att nå en partition av tjänsten:

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

Om du vill nå de resurser som tjänsten exponerar placerar du bara resurssökvägen efter tjänstnamnet i URL:en:

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

Gatewayen vidarebefordrar sedan dessa begäranden till tjänstens URL:

  • 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

Särskild hantering för portdelningstjänster

Omvänd Proxy för Service Fabric försöker matcha en tjänstadress igen och försöker igen när en tjänst inte kan nås. När en tjänst inte kan nås har tjänstinstansen eller repliken i allmänhet flyttats till en annan nod som en del av dess normala livscykel. När detta inträffar kan den omvända proxyn få ett nätverksanslutningsfel som anger att en slutpunkt inte längre är öppen på den ursprungligen lösta adressen.

Repliker eller tjänstinstanser kan dock dela en värdprocess och kan även dela en port när den hanteras av en http.sys-baserad webbserver, inklusive:

I den här situationen är det troligt att webbservern är tillgänglig i värdprocessen och svarar på begäranden, men den lösta tjänstinstansen eller repliken är inte längre tillgänglig på värden. I det här fallet får gatewayen ett HTTP 404-svar från webbservern. Därför kan ett HTTP 404-svar ha två distinkta betydelser:

  • Fall 1: Tjänstadressen är korrekt, men resursen som användaren begärde finns inte.
  • Fall 2: Tjänstadressen är felaktig och resursen som användaren begärde kan finnas på en annan nod.

Det första fallet är en normal HTTP 404, som anses vara ett användarfel. Men i det andra fallet har användaren begärt en resurs som finns. Det gick inte att hitta den omvända proxyn eftersom själva tjänsten har flyttats. Den omvända proxyn måste matcha adressen igen och försöka begära igen.

Den omvända proxyn behöver därför ett sätt att skilja mellan dessa två fall. För att göra den skillnaden krävs en ledtråd från servern.

  • Som standard förutsätter den omvända proxyn fall nr 2 och försöker lösa och utfärda begäran igen.

  • För att ange ärende 1 till den omvända proxyn bör tjänsten returnera följande HTTP-svarshuvud:

    X-ServiceFabric : ResourceNotFound

Det här HTTP-svarshuvudet anger en normal HTTP 404-situation där den begärda resursen inte finns och den omvända proxyn försöker inte lösa tjänstadressen igen.

Särskild hantering för tjänster som körs i containrar

För tjänster som körs i containrar kan du använda miljövariabeln Fabric_NodeIPOrFQDN för att skapa den omvända proxy-URL:en som i följande kod:

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

För det lokala klustret Fabric_NodeIPOrFQDN är inställt på "localhost" som standard. Starta det lokala klustret med parametern -UseMachineName för att se till att containrar kan nå omvänd proxy som körs på noden. Mer information finns i Konfigurera utvecklarmiljön för att felsöka containrar.

Service Fabric-tjänster som körs i Docker Compose-containrar kräver ett särskilt docker-compose.yml-portavsnitt http: eller https: konfiguration. Mer information finns i Docker Compose-distributionsstöd i Azure Service Fabric.

Nästa steg