Reverzní proxy server v Azure Service Fabric

reverzní proxy server integrovaný do Azure Service Fabric pomáhá mikroslužbám běžícím v clusteru Service Fabric zjišťovat a komunikovat s dalšími službami, které mají koncové body http.

Komunikační model mikroslužeb

mikroslužby v Service Fabric běží na podmnožině uzlů v clusteru a můžou migrovat mezi uzly z různých důvodů. V důsledku toho se koncové body pro mikroslužby můžou dynamicky měnit. Pro zjišťování a komunikaci s dalšími službami v clusteru musí mikroslužba projít následujícími kroky:

  1. Vyřešte umístění služby prostřednictvím názvové služby.
  2. Připojení ke službě.
  3. Zabalte předchozí kroky ve smyčce, které implementují řešení služeb a zásady opakování, které se použijí při selhání připojení.

další informace najdete v tématu Připojení a komunikace se službami.

Komunikace pomocí reverzního proxy serveru

Reverzní proxy je služba, která běží na všech uzlech a zpracovává překlad koncových bodů, automatické opakování a další selhání připojení jménem služeb klienta. Reverzní proxy server je možné nakonfigurovat tak, aby při zpracovávání požadavků od služeb klienta mohl používat různé zásady. Použití reverzního proxy umožňuje, aby služba klienta používala jakékoli komunikační knihovny HTTP na straně klienta a nevyžadovala ve službě speciální rozlišení a logiku opakování.

Reverzní proxy zpřístupňuje jeden nebo více koncových bodů v místním uzlu pro klientské služby, které se použijí pro odesílání požadavků do jiných služeb.

Interní komunikace

Poznámka

Podporované platformy

reverzní proxy server v Service Fabric aktuálně podporuje následující platformy

  • Windows Cluster: Windows 8 a novější nebo Windows Server 2012 a novější
  • Cluster se systémem Linux: reverzní proxy server není aktuálně k dispozici pro clustery se systémem Linux

Dosahování mikroslužeb mimo cluster

Výchozí externí komunikační model pro mikroslužby je model souhlasu, ve kterém se ke každé službě nedá získat přímý pøístup z externích klientů. Azure Load Balancer, což je hranice sítě mezi mikroslužbami a externími klienty, provádí překlad síťových adres a předávají externí požadavky do interní IP adresy: koncové body portů. Aby byl koncový bod mikroslužeb přímo přístupný pro externí klienty, je nutné nejprve nakonfigurovat Load Balancer pro přenos provozu na každý port, který služba používá v clusteru. Většina mikroslužeb, obzvláště stavové mikroslužby, ale nejsou živé na všech uzlech clusteru. Mikroslužby se můžou přesouvat mezi uzly při převzetí služeb při selhání. V takových případech Load Balancer nemůže efektivně určit umístění cílového uzlu replik, na které by měl přesměrovat provoz.

Dosažení mikroslužeb prostřednictvím reverzního proxy serveru mimo cluster

Místo konfigurace portu jednotlivých služeb v Load Balancer můžete nakonfigurovat pouze port reverzního proxy serveru v Load Balancer. Tato konfigurace umožňuje klientům mimo cluster dosáhnout služeb v clusteru pomocí reverzního proxy serveru bez další konfigurace.

Externí komunikace

Upozornění

Když nakonfigurujete port reverzního proxy serveru v Load Balancer, všechny mikroslužby v clusteru, které zveřejňují koncový bod HTTP, se budou adresovat mimo cluster. To znamená, že mikroslužby, které mají být interní, mohou být zjistitelné zjištěným uživatelem se zlými úmysly. To potenciálně představuje závažné chyby zabezpečení, které je možné zneužít; například:

  • Uživatel se zlými úmysly může spustit útok s cílem odepření služby Opakovaným voláním interní služby, která nemá dostatečně posílenou plochu pro útoky.
  • Uživatel se zlými úmysly může doručovat poškozené pakety do interní služby, což vede k neúmyslnému chování.
  • Služba, která má být interní, může vracet soukromé nebo citlivé informace, které nejsou určené k zpřístupnění službám mimo cluster, takže tyto citlivé informace vystavuje uživatel se zlými úmysly.

Ujistěte se, že plně rozumíte a zmírnit potenciální důsledky zabezpečení pro váš cluster a aplikace, které jsou v něm spuštěné, a teprve potom zajistěte veřejný port reverzního proxy serveru.

Formát identifikátoru URI pro adresování služeb pomocí reverzního proxy serveru

Reverzní proxy server používá specifický formát identifikátoru URI (Uniform Resource Identifier) k identifikaci oddílu služby, do nějž má být příchozí požadavek předán:

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

  • http (s): Reverzní proxy server je možné nakonfigurovat tak, aby přijímal přenos HTTP nebo HTTPS. v případě předávání pomocí protokolu https se pomocí reverzního proxy serveru po převratných nastaveních proxy serveru na https pořiďte Připojení na zabezpečenou službu .

  • Plně kvalifikovaný název domény clusteru (FQDN) | interní IP adresa: U externích klientů můžete nakonfigurovat reverzní proxy server tak, aby byl dosažitelný prostřednictvím domény clusteru, například mycluster.eastus.cloudapp.azure.com. Ve výchozím nastavení se reverzní proxy spouští na všech uzlech. U interních přenosů můžete reverzní proxy dosáhnout na localhost nebo na jakékoli interní IP adresy uzlu, například 10.0.0.1.

  • Port: Toto je port, například 19081, který byl zadán pro reverzní proxy.

  • ServiceInstanceName: Toto je plně kvalifikovaný název nasazené instance služby, ke které se snažíte získat přístup bez "Fabric:/". programu. Například pro dosažení prostředku Fabric:/MyApp/mojesluzba/ Service byste měli použít MyApp/mojesluzba.

    V názvu instance služby se rozlišují velká a malá písmena. Použití různých malých a velkých písmen v názvu instance služby v adrese URL způsobuje selhání požadavků s 404 (Nenalezeno).

  • Cesta k příponě: Jedná se o skutečnou cestu URL, například MyAPI/Values/Add/3, pro službu, ke které se chcete připojit.

  • PartitionKey: U dělené služby se jedná o vypočtený klíč oddílu oddílu, ke kterému chcete získat přístup. Všimněte si, že se nejedná o identifikátor GUID ID oddílu. Tento parametr není vyžadován pro služby, které používají schéma oddílu singleton.

  • PartitionKind: Toto je schéma oddílu služby. Může to být "Int64Range" nebo "pojmenovaný". Tento parametr není vyžadován pro služby, které používají schéma oddílu singleton.

  • Naslouchací proces Koncové body služby jsou ve formátu {"Endpoints": {"Listener1": "Endpoint1", "Listener2": "pro endpoint2 u"...}}. Když služba vystaví více koncových bodů, identifikuje koncový bod, na který se má klientský požadavek přeslat. Tato možnost může být vynechána, pokud má služba pouze jeden naslouchací proces.

  • TargetReplicaSelector Tím se určuje, jak by měla být vybraná cílová replika nebo instance.

    • Když je cílová služba stavová, může být TargetReplicaSelector jedna z následujících: "PrimaryReplica", "RandomSecondaryReplica" nebo "RandomReplica". Pokud tento parametr není zadán, výchozí hodnota je ' PrimaryReplica '.
    • Pokud je cílová služba Bezstavová, reverzní proxy server vybere náhodnou instanci oddílu služby, aby předal požadavek.

  • Časový limit: Určuje časový limit pro požadavek HTTP vytvořený reverzním proxy serverem jménem žádosti klienta. Výchozí hodnota je 120 sekund. Toto je volitelný parametr.

Příklad použití

Příklad: Pojďme využít službu Fabric:/MyApp/mojesluzba , která otevře NASLOUCHACÍ proces http na následující adrese URL:

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

Níže jsou uvedené prostředky pro službu:

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

Pokud služba používá schéma dělení na oddíly singleton, parametry řetězce dotazu PartitionKey a PartitionKind se nevyžadují a služba může být dostupná pomocí brány jako:

  • Externě http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService
  • Užit http://localhost:19081/MyApp/MyService

Pokud služba používá jednotné schéma dělení na oddíly (Int64), musí se pro přístup k oddílu služby použít parametry řetězce dotazu PartitionKey a PartitionKind :

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

Pokud chcete dosáhnout prostředků, které služba zpřístupňuje, jednoduše umístěte cestu prostředku za název služby v adrese URL:

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

Brána pak tyto požadavky přepošle na adresu URL služby:

  • 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

Speciální zpracování pro služby pro sdílení portů

Service Fabric reverzní proxy server se znovu pokusí znovu přeložit adresu služby a pokusit se o tuto žádost znovu, pokud není dostupná služba. Obecně platí, že pokud nelze získat přístup k službě, instance služby nebo replika byla přesunuta do jiného uzlu v rámci normálního životního cyklu. V takovém případě může reverzní proxy obdržet chybu připojení k síti, což znamená, že koncový bod již není otevřen na původně přeložené adrese.

Repliky nebo instance služby však mohou sdílet hostitelský proces a mohou také sdílet port, pokud je hostován webovým serverem http.sys, včetně:

V takové situaci je pravděpodobný, že webový server je dostupný v hostitelském procesu a reaguje na požadavky, ale vyřešená instance služby nebo replika už není na hostiteli dostupná. V takovém případě brána dostane odpověď HTTP 404 od webového serveru. Proto odpověď HTTP 404 může mít dvě odlišná význam:

  • Případ #1: adresa služby je správná, ale prostředek, který uživatel požaduje, neexistuje.
  • Případ #2: adresa služby je nesprávná a prostředek, který uživatel požadoval, může existovat na jiném uzlu.

První případ je normální protokol HTTP 404, který se považuje za chybu uživatele. Ve druhém případě však uživatel požadoval prostředek, který existuje. Reverzní proxy server nebyl schopen najít, protože služba byla přesunuta. Reverzní proxy server musí tuto adresu znovu přeložit a opakovat požadavek.

Reverzní proxy server tak potřebuje způsob, jak rozlišovat mezi těmito dvěma případy. Aby bylo možné tento rozdíl rozlišovat, vyžaduje se nápověda ze serveru.

  • Reverzní proxy ve výchozím nastavení předpokládá, že #2 a pokusí se žádost vyřešit a znovu vydat.

  • Aby služba #1 použít reverzní proxy server, měla by vrátit následující hlavičku odpovědi HTTP:

    X-ServiceFabric : ResourceNotFound

Tato hlavička odpovědi HTTP indikuje normální situaci HTTP 404, ve které požadovaný prostředek neexistuje, a reverzní proxy se nepokusí přeložit adresu služby znovu.

Zvláštní zpracování pro služby spuštěné v kontejnerech

U služeb spuštěných uvnitř kontejnerů můžete pomocí proměnné prostředí vytvořit adresu URL reverzního proxy serveru, jak Fabric_NodeIPOrFQDN je vidět v následujícím kódu: 

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

Pro místní cluster je ve výchozím nastavení nastavená hodnota Fabric_NodeIPOrFQDN "localhost". Spusťte místní cluster s parametrem , abyste se ujistili, že kontejnery mohou dosáhnout -UseMachineName reverzního proxy serveru spuštěného na uzlu. Další informace najdete v tématu Konfigurace vývojového prostředí pro ladění kontejnerů.

Service Fabric služby, které běží v Docker Compose kontejnerech, vyžadují speciální část Porty docker-compose.yml http: nebo https: configuration. Další informace najdete v tématu Docker Compose nasazení v Azure Service Fabric.

Další kroky