Reverzní proxy server v Azure Service Fabric

  • Článek

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

Komunikační model mikroslužeb

Mikroslužby v Service Fabric běží na podmnožině uzlů v clusteru a můžou mezi uzly migrovat z různých důvodů. V důsledku toho se koncové body mikroslužeb můžou dynamicky měnit. Pokud chcete zjistit další služby v clusteru a komunikovat s těmito službami, musí mikroslužba provést následující kroky:

  1. Přeložte umístění služby prostřednictvím služby pojmenování.
  2. Připojte se ke službě.
  3. Zabalte předchozí kroky do smyčky, která implementuje překlad služby 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 server je služba, která běží na každém uzlu a zpracovává překlad koncových bodů, automatické opakování a další selhání připojení jménem klientských služeb. Reverzní proxy server je možné nakonfigurovat tak, aby při zpracování požadavků z klientských služeb použil různé zásady. Použití reverzního proxy serveru umožňuje klientské službě používat jakékoli komunikační knihovny HTTP na straně klienta a nevyžaduje ve službě zvláštní řešení a logiku opakování.

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

Interní komunikace

Poznámka

Podporované platformy

Reverzní proxy server v Service Fabric v současné době podporuje následující platformy

  • Cluster s Windows: Windows 8 a novější nebo Windows Server 2012 a novější
  • Cluster s Linuxem: Reverzní proxy server v současné době není k dispozici pro clustery s Linuxem

Připojení k mikroslužbám mimo cluster

Výchozí model externí komunikace pro mikroslužby je model s výslovným souhlasem, kdy ke každé službě není možné přistupovat přímo z externích klientů. Azure Load Balancer, což je síťová hranice mezi mikroslužbami a externími klienty, provádí překlad síťových adres a předává externí požadavky do interních koncových bodů IP:port. Pokud chcete koncový bod mikroslužby zpřístupnit přímo externím klientům, musíte nejprve nakonfigurovat Load Balancer tak, aby přesměrovávat provoz na každý port, který služba v clusteru používá. Většina mikroslužeb, zejména stavových mikroslužeb, ale není na všech uzlech clusteru. Mikroslužby se můžou při převzetí služeb při selhání přesouvat mezi uzly. V takových případech Load Balancer nemohou efektivně určit umístění cílového uzlu replik, do kterých by měl směrovat provoz.

Připojení k mikroslužbám přes reverzní proxy server mimo cluster

Místo konfigurace portu jednotlivé služby v Load Balancer můžete v Load Balancer nakonfigurovat jenom port reverzního proxy serveru. Tato konfigurace umožňuje klientům mimo cluster získat přístup ke službám uvnitř 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é zpřístupňují koncový bod HTTP, budou adresovatelné mimo cluster. To znamená, že mikroslužby, které mají být interní, můžou být zjistitelné uživatelem se zlými úmysly. To může představovat závažná ohrožení zabezpečení, která lze zneužít; Příklad:

  • Uživatel se zlými úmysly může spustit útok na dostupnost služby opakovaným voláním interní služby, která nemá dostatečně posílený prostor pro útok.
  • Uživatel se zlými úmysly může doručovat poškozené pakety interní službě, což má za následek neočekávané chování.
  • Služba, která má být interní, může vracet soukromé nebo citlivé informace, které nemají být vystaveny službám mimo cluster, a tak tyto citlivé informace zpřístupnit uživateli se zlými úmysly.

Než port reverzního proxy serveru nastavíte jako veřejný, ujistěte se, že plně rozumíte potenciálním dopadům na zabezpečení vašeho clusteru a aplikací, které na něm běží, a zmírněte je.

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

Reverzní proxy server používá konkrétní formát identifikátoru URI (Uniform Resource Identifier) k identifikaci oddílu služby, do kterého se má příchozí požadavek předávat:

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 provoz HTTP nebo HTTPS. Informace o přesměrování HTTPS najdete v tématu Připojení k zabezpečené službě pomocí reverzního proxy serveru , jakmile máte nastavení reverzního proxy serveru pro naslouchání na https.

  • Plně kvalifikovaný název domény clusteru (FQDN) | interní IP adresa: U externích klientů můžete reverzní proxy server nakonfigurovat tak, aby byl dostupný prostřednictvím domény clusteru, například mycluster.eastus.cloudapp.azure.com. Ve výchozím nastavení běží reverzní proxy server na každém uzlu. V případě interního provozu je reverzní proxy server dostupný na místním hostiteli nebo na jakékoli IP adrese interního uzlu, například 10.0.0.1.

  • Port: Jedná se o port, například 19081, který byl zadán pro reverzní proxy server.

  • ServiceInstanceName: Toto je plně kvalifikovaný název nasazené instance služby, ke které se pokoušíte získat přístup bez prostředku infrastruktury:/. Schéma. Například k připojení ke službě fabric:/myapp/myservice/ byste použili myapp/myservice.

    V názvu instance služby se rozlišují malá a velká písmena. Použití jiného názvu instance služby v adrese URL způsobí, že požadavky selžou s chybou 404 (Nenalezena).

  • Cesta k příponě: Toto je skutečná cesta URL, například myapi/values/add/3, pro službu, ke které se chcete připojit.

  • PartitionKey(Klíč oddílu): U dělené služby se jedná o vypočítaný klíč oddílu, ke kterému chcete získat přístup. Všimněte si, že se nejedná o IDENTIFIKÁTOR GUID oddílu. Tento parametr se nevyžaduje pro služby, které používají schéma jednoho oddílu.

  • PartitionKind: Toto je schéma oddílů služby. Může to být Int64Range nebo Pojmenované. Tento parametr se nevyžaduje pro služby, které používají schéma jednoho oddílu.

  • Název naslouchacího procesu Koncové body ze služby jsou ve formátu {"Koncové body":{"Naslouchací proces1":"Koncový bod1","Naslouchací proces2":"Koncový bod2" ...}}. Když služba zpřístupňuje více koncových bodů, identifikuje se koncový bod, do kterého se má požadavek klienta předávat. Pokud má služba jenom jeden naslouchací proces, můžete to vynechat.

  • TargetReplicaSelector Určuje, jak se má vybrat cílová replika nebo instance.

    • Pokud je cílová služba stavová, targetReplicaSelector může být jeden z následujících: PrimaryReplica, RandomSecondaryReplica nebo RandomReplica. Pokud tento parametr není zadaný, výchozí hodnota je PrimaryReplica.
    • Pokud je cílová služba bezstavová, reverzní proxy server vybere náhodnou instanci oddílu služby, do které má požadavek předat.

  • Časový limit: Určuje časový limit požadavku HTTP vytvořeného reverzním proxy serverem pro službu jménem požadavku klienta. Výchozí hodnota je 120 sekund. Jedná se o volitelný parametr.

Příklad použití

Vezměme si například službu fabric:/MyApp/MyService , která otevře naslouchací proces HTTP na následující adrese URL:

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

Toto jsou prostředky pro službu:

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

Pokud služba používá jednoúčelové schéma dělení, parametry řetězce dotazu PartitionKey a PartitionKind se nevyžadují a služba je dostupná pomocí brány jako:

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

Pokud služba používá schéma dělení Uniform Int64, musí se k dosažení 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
  • Interně: http://localhost:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range

Pokud chcete získat přístup k prostředkům, které služba zpřístupňuje, jednoduše umístěte cestu k 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
  • Interně: http://localhost:19081/MyApp/MyService/api/users/6?PartitionKey=3&PartitionKind=Int64Range

Brána pak předá tyto požadavky 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í zacházení se službami sdílení portů

Reverzní proxy server Service Fabric se pokusí znovu přeložit adresu služby a zopakuje požadavek, když služba nebude dostupná. Obecně platí, že pokud služba není dostupná, instance nebo replika služby se v rámci svého normálního životního cyklu přesunuly do jiného uzlu. V takovém případě může reverzní proxy server obdržet chybu síťového připojení, která značí, že koncový bod na původně přeložené adrese už není otevřený.

Repliky nebo instance služby však můžou sdílet hostitelský proces a můžou také sdílet port, pokud je hostovaný webovým serverem založeným na http.sys, včetně:

V této situaci je pravděpodobné, že webový server je k dispozici v hostitelském procesu a odpovídá na požadavky, ale vyřešená instance služby nebo replika již není na hostiteli k dispozici. V takovém případě brána obdrží odpověď HTTP 404 z webového serveru. Odpověď HTTP 404 proto může mít dva odlišné významy:

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

Prvním případem je normální http 404, který se považuje za chybu uživatele. Ve druhém případě však uživatel požádal o prostředek, který existuje. Reverzní proxy server ho nemohl najít, protože se přesunula samotná služba. Reverzní proxy server musí adresu přeložit znovu a zkusit požadavek zopakovat.

Reverzní proxy server proto potřebuje způsob, jak mezi těmito dvěma případy rozlišovat. Aby bylo toto rozlišení potřeba, vyžaduje se nápověda ze serveru.

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

  • Aby služba na reverzní proxy server označila případ č. 1, měla by vrátit následující hlavičku odpovědi HTTP:

    X-ServiceFabric : ResourceNotFound

Tato hlavička odpovědi HTTP označuje normální situaci HTTP 404, kdy požadovaný prostředek neexistuje a reverzní proxy server se nebude pokoušet adresu služby přeložit znovu.

Speciální manipulace pro služby spuštěné v kontejnerech

Pro služby spuštěné v kontejnerech můžete k vytvoření adresy URL reverzního proxy serveru použít proměnnou Fabric_NodeIPOrFQDN prostředí jako v následujícím kódu:

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

Místní cluster Fabric_NodeIPOrFQDN je ve výchozím nastavení nastavený na localhost. Spusťte místní cluster s parametrem , -UseMachineName aby se kontejnery mohly spojit s reverzním proxy serverem spuštěným na uzlu. Další informace najdete v tématu Konfigurace vývojářského prostředí pro ladění kontejnerů.

Služby Service Fabric, které běží v kontejnerech Docker Compose, vyžadují speciální oddíl porty docker-compose.yml http: nebo https: konfigurace. Další informace najdete v tématu Podpora nasazení Docker Compose v Azure Service Fabric.

Další kroky