Sdílet prostřednictvím

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 a komunikovat s jiný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 mezi uzly migrovat z různých důvodů. V důsledku toho se koncové body pro mikroslužby můžou dynamicky měnit. Pokud chcete zjistit a komunikovat s dalšími službami v clusteru, mikroslužba musí projít následujícími 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. Zabalení předchozích kroků ve smyčce, která implementuje ř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 server je služba, která běží na každém uzlu a zpracovává překlad koncových bodů, automatické opakování a další chyby 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, aby klientské služby používaly 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 není aktuálně k dispozici pro clustery s Linuxem.

Dosažení mikroslužeb mimo cluster

Výchozí externí komunikační model pro mikroslužby je model výslovného souhlasu, kdy ke každé službě nelze přistupovat přímo 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ává externí požadavky interním koncovým bodům IP:port. Pokud chcete, aby byl koncový bod mikroslužby přímo přístupný externím klientům, musíte nejprve nakonfigurovat Load Balancer tak, aby předával provoz do každého portu, který služba používá v clusteru. Většina mikroslužeb, zejména stavových mikroslužeb, ale nežije na všech uzlech clusteru. Mikroslužby se můžou pohybovat 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, do kterých by měl směrovat provoz.

Dosažení mikroslužeb přes reverzní proxy server mimo cluster

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

Externí komunikace

Upozorňující

Když nakonfigurujete port reverzního proxy serveru v Load Balanceru, všechny mikroslužby v clusteru, které zpřístupňují koncový bod HTTP, se dají adresovat mimo cluster. To znamená, že mikroslužby, které mají být interní, můžou být zjistitelné určeným uživatelem se zlými úmysly. To potenciálně představuje závažná ohrožení zabezpečení, která je možné zneužít; napří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 do interní služby doručovat poškozené pakety, což vede k neúmyslnému 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 tím tyto citlivé informace vystavit škodlivému uživateli.

Než zpřístupníte port reverzního proxy serveru, ujistěte se, že plně rozumíte a zmírníte potenciální důsledky zabezpečení clusteru a aplikací, které na něm běží.

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 lze nakonfigurovat tak, aby přijímal provoz HTTP nebo HTTPS. Pokud chcete předávat PROTOKOL HTTPS, přečtěte si informace o připojení k zabezpečené službě pomocí reverzního proxy serveru , jakmile budete mít nastavení reverzního proxy serveru pro naslouchání na PROTOKOLU HTTPS.

  • Plně kvalifikovaný název domény clusteru (FQDN) | interní IP adresa: Pro externí klienty můžete nakonfigurovat reverzní proxy server tak, aby byl dostupný prostřednictvím domény clusteru, například mycluster.eastus.cloudapp.azure.com. Ve výchozím nastavení se reverzní proxy server spouští na každém uzlu. U interního provozu je reverzní proxy 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: Jedná se o plně kvalifikovaný název nasazené instance služby, ke které se pokoušíte připojit bez schématu fabric:/. Například k dosažení prostředků infrastruktury:/myapp/myservice/ služby byste použili myapp/myservice.

    V názvu instance služby se rozlišují malá a velká písmena. Použití jiného písma pro název instance služby v adrese URL způsobí selhání požadavků s chybou 404 (Nenalezena).

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

  • PartitionKey: Pro dělenou službu se jedná o vypočítaný klíč oddílu oddílu, který chcete dosáhnout. 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 jednoúčelového oddílu.

  • PartitionKind: Toto je schéma oddílů služby. Může to být Int64Range nebo Named. Tento parametr není vyžadován pro služby, které používají schéma jednoúčelového 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ůže se tento parametr vynechat.

  • TargetReplicaSelector Určuje, jak má být vybrána cílová replika nebo instance.

    • Pokud je cílová služba stavová, může být TargetReplicaSelector jedním 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 vybere náhodnou instanci oddílu služby, do které se 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 využití

Jako příklad si vezměme 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á schéma dělení s jednímtonem, parametry řetězce dotazu PartitionKey a PartitionKind nejsou vyžadovány a služba se dá dosáhnout pomocí brány jako:

  • Zevně: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService
  • Vnitřně: http://localhost:19081/MyApp/MyService

Pokud služba používá schéma dělení Uniform Int64, musí být parametry řetězce dotazu PartitionKey a PartitionKind použity k dosažení oddílu služby:

  • Zevně: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range
  • Vnitřně: http://localhost:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range

Pokud chcete získat přístup k prostředkům, které služba zveřejňuje, jednoduše umístěte cestu k prostředku za název služby v adrese URL:

  • Zevně: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService/index.html?PartitionKey=3&PartitionKind=Int64Range
  • Vnitřně: http://localhost:19081/MyApp/MyService/api/users/6?PartitionKey=3&PartitionKind=Int64Range

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

Reverzní proxy server Service Fabric se pokusí znovu přeložit adresu služby a zkusí požadavek zopakovat, když se služba nedosáhla. Obecně platí, že pokud službu nelze dosáhnout, instance služby nebo replika se v rámci svého normálního životního cyklu přesunula 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 už není otevřený na původně vyřešené adrese.

Repliky nebo instance služby ale můžou sdílet hostitelský proces a můžou také sdílet port, pokud je hostovaný 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 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 na jiném uzlu.

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

Reverzní proxy server proto potřebuje způsob, jak rozlišovat mezi těmito dvěma případy. Aby se tento rozdíl odlišil, je vyžadována nápověda ze serveru.

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

  • Pokud chcete označit případ č. 1 na reverzní proxy server, měla by služba 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, ve které požadovaný prostředek neexistuje, a reverzní proxy se nepokusí přeložit adresu služby znovu.

Speciální zpracování služeb spuštěných v kontejnerech

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

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

Pro místní cluster Fabric_NodeIPOrFQDN je ve výchozím nastavení nastavená na localhost. Spusťte místní cluster s parametrem, abyste měli jistotu -UseMachineName , že kontejnery můžou dosáhnout 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ů.

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

Další kroky