Omvänd proxy i Azure Service Fabric

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 noder i klustret och kan migreras mellan noderna av olika orsaker. Därför kan slutpunkterna för mikrotjänster ändras dynamiskt. Mikrotjänsten måste gå igenom följande steg för att identifiera och kommunicera med andra tjänster i klustret:

  1. Lös tjänstplatsen via namngivningstjänsten.
  2. Anslut till tjänsten.
  3. Omslut föregående steg i en loop som implementerar tjänstupplösning och återförsöksprinciper för att tillämpa på anslutningsfel

Mer information finns i Anslut 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, automatiska återförsök och andra anslutningsfel för klienttjänster. Omvänd proxy kan konfigureras för att tillämpa olika principer när den hanterar begäranden från klienttjänster. Med en omvänd proxy kan klienttjänsten använda ALLA HTTP-kommunikationsbibliotek på klientsidan och kräver ingen särskild lösnings- och omprövningslogik i tjänsten.

Omvänd proxy exponerar en eller flera slutpunkter på den lokala noden som klienttjänster kan använda 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 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 nätverksadressöversättning 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åndsful mikrotjänster, finns dock inte på alla noder i klustret. Mikrotjänster kan flyttas mellan noder vid redundans. I sådana fall kan Load Balancer bestämma 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 Load Balancer kan du 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 porten för den omvända proxyn 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 upptäckas av en bestämd skadlig användare. Detta kan potentiellt medföra allvarliga sårbarheter som kan utnyttjas. till exempel:

  • En obehörig användare kan starta en doS-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 känslig information för en obehörig användare.

Se till att du förstår och minimerar potentiella säkerhetsförgreningar för klustret och apparna som körs på det innan du gör porten för omvänd proxy offentlig.

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

Omvänd proxy 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-vidarebefordran finns Anslut en säker tjänst med omvänd proxy när du har en omvänd proxykonfiguration för att lyssna på HTTPS.

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

    Namnet på tjänstinstansen är ärendekänsligt. Om du använder ett annat hölje för namnet på tjänstinstansen i URL:en misslyckas begärandena 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 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 "Named". Den här parametern krävs inte för tjänster som använder singleton-partitionsschemat.

  • ListenerName Slutpunkterna från tjänsten har formen {"Endpoints":{"Listener1":"Endpoint1","Listener2":"Endpoint2" ...}}. 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 målinstansen ska väljas.

    • När måltjänsten är tillståndsfull kan TargetReplicaSelector vara något av följande: "PrimaryReplica", "RandomSecondaryReplica" eller "RandomReplica". Om 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 att vidarebefordra begäran till.

  • Tidsgräns: 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 kan till exempel ta fabric:/MyApp/MyService-tjänsten 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 schemat för singleton-partitionering 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

För att nå de resurser som tjänsten exponerar placerar du helt enkelt 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

Den Service Fabric en omvänd proxy försöker matcha en tjänstadress igen och försöka 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 felmeddelande om nätverksanslutning som anger att en slutpunkt inte längre är öppen för den ursprungligen lösta adressen.

Repliker eller tjänstinstanser kan dock dela en värdprocess och kan också dela en port när den finns på en http.sys-baserad webbserver, inklusive:

I det här fallet ä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 den resurs 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. Den omvända proxyn kunde inte hitta den eftersom själva tjänsten har flyttats. Den omvända proxyn måste matcha adressen igen och försöka igen.

Omvänd proxy måste därför kunna skilja mellan dessa två fall. För att göra den skillnaden krävs ett tips från servern.

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

  • För att #1 till omvänd proxy ska tjänsten returnera följande HTTP-svarshuvud:

    X-ServiceFabric : ResourceNotFound

Http-svarshuvudet indikerar en normal HTTP 404-situation där den begärda resursen inte finns och den omvända proxyn inte försöker matcha 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 för att skapa den Fabric_NodeIPOrFQDN 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 -UseMachineName parametern 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 felsökning av containrar.

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

Nästa steg