Megosztás a következőn keresztül:

Fordított proxy az Azure Service Fabricben

  • Cikk

Az Azure Service Fabricbe beépített fordított proxy segít a Service Fabric-fürtben futó mikroszolgáltatások felderítésében és a HTTP-végpontokkal rendelkező más szolgáltatásokkal való kommunikációban.

Mikroszolgáltatások kommunikációs modellje

A Service Fabric mikroszolgáltatásai a fürt csomópontjainak egy részhalmazán futnak, és különböző okokból migrálhatók a csomópontok között. Ennek eredményeképpen a mikroszolgáltatások végpontjai dinamikusan változhatnak. A fürt más szolgáltatásainak felderítéséhez és a velük való kommunikációhoz a mikroszolgáltatásnak a következő lépéseket kell végrehajtania:

  1. A szolgáltatás helyének feloldása az elnevezési szolgáltatáson keresztül.
  2. Csatlakozzon a szolgáltatáshoz.
  3. Az előző lépéseket burkolja egy hurokba, amely szolgáltatásfeloldási és újrapróbálkozási szabályzatokat implementál a kapcsolati hibákra való alkalmazáshoz

További információ: Csatlakozás és kommunikáció a szolgáltatásokkal.

Kommunikáció fordított proxyval

A fordított proxy egy olyan szolgáltatás, amely minden csomóponton fut, és kezeli a végpontfeloldásokat, az automatikus újrapróbálkozási és egyéb csatlakozási hibákat az ügyfélszolgáltatások nevében. A fordított proxy konfigurálható úgy, hogy különböző szabályzatokat alkalmazzon az ügyfélszolgáltatásoktól érkező kérések kezelésekor. Fordított proxy használatával az ügyfélszolgáltatás bármilyen ügyféloldali HTTP-kommunikációs kódtárat használhat, és nem igényel speciális feloldási és újrapróbálkozási logikát a szolgáltatásban.

A fordított proxy egy vagy több végpontot tesz elérhetővé a helyi csomóponton, hogy az ügyfélszolgáltatások kéréseket küldjenek más szolgáltatásoknak.

Belső kommunikáció

Megjegyzés

Támogatott platformok

A Fordított proxy a Service Fabricben jelenleg a következő platformokat támogatja

  • Windows-fürt: Windows 8 és újabb, illetve Windows Server 2012 és újabb
  • Linux-fürt: A fordított proxy jelenleg nem érhető el Linux-fürtökhöz

Mikroszolgáltatások elérése a fürtön kívülről

A mikroszolgáltatások alapértelmezett külső kommunikációs modellje egy olyan jóváhagyási modell, amelyben az egyes szolgáltatások nem érhetők el közvetlenül külső ügyfelekről. Azure Load Balancer, amely a mikroszolgáltatások és a külső ügyfelek közötti hálózati határ, hálózati címfordítást végez, és külső kéréseket továbbít belső IP:portvégpontoknak. Ahhoz, hogy egy mikroszolgáltatás végpontja közvetlenül elérhető legyen a külső ügyfelek számára, először konfigurálnia kell Load Balancer, hogy a forgalmat a szolgáltatás által a fürtben használt portra továbbítsa. A legtöbb mikroszolgáltatás, különösen az állapotalapú mikroszolgáltatások azonban nem a fürt összes csomópontján élnek. A mikroszolgáltatások a feladatátvétel során a csomópontok között mozoghatnak. Ilyen esetekben Load Balancer nem tudja hatékonyan meghatározni azon replikák célcsomópontjának helyét, amelyekre a forgalmat továbbítania kell.

Mikroszolgáltatások elérése fordított proxyn keresztül a fürtön kívülről

Ahelyett, hogy egy adott szolgáltatás portját konfigurálja Load Balancer, csak a fordított proxy portját konfigurálhatja Load Balancer. Ez a konfiguráció lehetővé teszi, hogy a fürtön kívüli ügyfelek további konfiguráció nélkül elérjék a fürtön belüli szolgáltatásokat a fordított proxy használatával.

Külső kommunikáció

Figyelmeztetés

Ha a fordított proxy portját Load Balancer konfigurálja, a fürt minden olyan mikroszolgáltatása, amely HTTP-végpontot tesz elérhetővé, a fürtön kívülről is kezelhető. Ez azt jelenti, hogy a belsőnek szánt mikroszolgáltatásokat egy meghatározott rosszindulatú felhasználó felderítheti. Ez potenciálisan súlyos biztonsági réseket okozhat, amelyek kihasználhatók; például:

  • A rosszindulatú felhasználók szolgáltatásmegtagadásos támadást indíthatnak egy olyan belső szolgáltatás ismételt meghívásával, amely nem rendelkezik megfelelően megkeményített támadási felülettel.
  • A rosszindulatú felhasználók helytelen formátumú csomagokat kézbesíthetnek egy belső szolgáltatásnak, ami nem kívánt viselkedést eredményez.
  • A belsőnek szánt szolgáltatások olyan privát vagy bizalmas információkat adhatnak vissza, amelyeket nem a fürtön kívüli szolgáltatásoknak kívánnak közzétenni, így ezeket a bizalmas információkat rosszindulatú felhasználónak adhatja ki.

Mielőtt nyilvánossá teszi a fordított proxyportot, győződjön meg arról, hogy teljes mértékben tisztában van a fürt és a rajta futó alkalmazások lehetséges biztonsági következményeival.

URI-formátum a szolgáltatások fordított proxy használatával történő címzéséhez

A fordított proxy egy adott egységes erőforrás-azonosító (URI) formátumot használ annak a szolgáltatáspartíciónak a azonosításához, amelyre a bejövő kérést továbbítani kell:

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

  • http(k): A fordított proxy konfigurálható HTTP- vagy HTTPS-forgalom fogadására. HTTPS-továbbítás esetén tekintse meg a Csatlakozás biztonságos szolgáltatáshoz a fordított proxyval című témakört, miután beállította a fordított proxyt a HTTPS figyeléséhez.

  • A fürt teljes tartományneve (FQDN) | belső IP-cím: Külső ügyfelek esetén konfigurálhatja a fordított proxyt úgy, hogy az elérhető legyen a fürttartományon keresztül, például mycluster.eastus.cloudapp.azure.com. Alapértelmezés szerint a fordított proxy minden csomóponton fut. Belső forgalom esetén a fordított proxy elérhető a localhoston vagy bármely belső csomópont IP-címén, például a 10.0.0.1-en.

  • Port: Ez a fordított proxyhoz megadott port (például 19081).

  • ServiceInstanceName: Ez annak az üzembe helyezett szolgáltatáspéldánynak a teljes neve, amelyet a "háló:/" nélkül próbál elérni Rendszer. A háló:/myapp/myservice/ szolgáltatás eléréséhez például a myapp/myservice értéket kell használnia.

    A szolgáltatáspéldány neve megkülönbözteti a kis- és nagybetűk nevét. Ha az URL-címben eltérő burkolatot használ a szolgáltatáspéldány nevére, a kérések 404-gyel meghiúsulnak (nem találhatók).

  • Utótag elérési útja: Ez a tényleges URL-elérési út( például myapi/values/add/3) ahhoz a szolgáltatáshoz, amelyhez csatlakozni szeretne.

  • PartitionKey: Particionált szolgáltatás esetén ez az elérni kívánt partíció számított partíciókulcsa. Vegye figyelembe, hogy ez nem a partícióazonosító GUID azonosítója. Ez a paraméter nem szükséges az egyszeri partíciós sémát használó szolgáltatásokhoz.

  • PartitionKind: Ez a szolgáltatáspartíciós séma. Ez lehet "Int64Range" vagy "Named". Ez a paraméter nem szükséges az egyszeri partíciós sémát használó szolgáltatásokhoz.

  • ListenerName A szolgáltatás végpontjai {"Endpoints":{"Listener1":"Endpoint1","Listener2":"Endpoint2" ...}} formában vannak. Ha a szolgáltatás több végpontot tesz elérhetővé, ez azonosítja azt a végpontot, amelyre az ügyfélkérést továbbítani kell. Ez kihagyható, ha a szolgáltatásnak csak egy figyelője van.

  • TargetReplicaSelector Ez határozza meg a célreplika vagy -példány kiválasztásának módját.

    • Ha a célszolgáltatás állapotalapú, a TargetReplicaSelector a következők egyike lehet: "PrimaryReplica", "RandomSecondaryReplica" vagy "RandomReplica". Ha ez a paraméter nincs megadva, az alapértelmezett érték a "PrimaryReplica".
    • Ha a célszolgáltatás állapot nélküli, a fordított proxy kiválasztja a szolgáltatáspartíció véletlenszerű példányát a kérés továbbításához.

  • Időtúllépés: Ez határozza meg a fordított proxy által a szolgáltatásnak az ügyfélkérés nevében létrehozott HTTP-kérés időtúllépését. Az alapértelmezett érték 120 másodperc. Ez egy nem kötelező paraméter.

Példa a használatra

Vegyük például azt a hálót:/MyApp/MyService szolgáltatást, amely megnyitja a HTTP-figyelőt a következő URL-címen:

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

A szolgáltatás erőforrásai a következők:

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

Ha a szolgáltatás az egyszeri particionálási sémát használja, a PartitionKey és a PartitionKind lekérdezési sztring paraméterei nem szükségesek, és a szolgáltatás az átjáró használatával érhető el a következő módon:

  • Külsőleg: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService
  • Belsőleg: http://localhost:19081/MyApp/MyService

Ha a szolgáltatás az Egységes Int64 particionálási sémát használja, a PartitionKey és a PartitionKind lekérdezési sztring paramétereit kell használni a szolgáltatás partíciójának eléréséhez:

  • Külsőleg: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range
  • Belsőleg: http://localhost:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range

A szolgáltatás által elérhetővé tenni kívánt erőforrások eléréséhez egyszerűen helyezze el az erőforrás elérési útját a szolgáltatás neve után az URL-címben:

  • Külsőleg: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService/index.html?PartitionKey=3&PartitionKind=Int64Range
  • Belsőleg: http://localhost:19081/MyApp/MyService/api/users/6?PartitionKey=3&PartitionKind=Int64Range

Az átjáró ezután továbbítja ezeket a kéréseket a szolgáltatás URL-címére:

  • 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ális kezelés a portmegosztási szolgáltatásokhoz

A Service Fabric fordított proxyja megpróbálja újra feloldani a szolgáltatás címét, és újrapróbálkozhat a kéréssel, ha egy szolgáltatás nem érhető el. Általában, ha egy szolgáltatás nem érhető el, a szolgáltatáspéldány vagy a replika a normál életciklus részeként egy másik csomópontra lett áthelyezve. Ha ez történik, a fordított proxy hálózati kapcsolati hibát kaphat, amely azt jelzi, hogy egy végpont már nem nyílik meg az eredetileg megoldott címen.

A replikák és a szolgáltatáspéldányok azonban megoszthatnak egy gazdagépfolyamatot, és egy portot is megoszthatnak egy http.sys-alapú webkiszolgáló üzemeltetésekor, beleértve a következőket:

Ebben az esetben valószínű, hogy a webkiszolgáló elérhető a gazdafolyamatban, és válaszol a kérésekre, de a feloldott szolgáltatáspéldány vagy replika már nem érhető el a gazdagépen. Ebben az esetben az átjáró HTTP 404-választ kap a webkiszolgálótól. Így a HTTP 404-válasz két különböző jelentéssel rendelkezhet:

  • 1. eset: A szolgáltatás címe helyes, de a felhasználó által kért erőforrás nem létezik.
  • 2. eset: A szolgáltatás címe helytelen, és a felhasználó által kért erőforrás egy másik csomóponton is létezhet.

Az első eset egy normál HTTP 404, amely felhasználói hibának minősül. A második esetben azonban a felhasználó olyan erőforrást kért, amely létezik. A fordított proxy nem találta meg, mert maga a szolgáltatás áthelyeződött. A fordított proxynak újra fel kell oldania a címet, és újra meg kell próbálkoznia a kéréssel.

A fordított proxynak tehát meg kell különböztetnie a két esetet. A különbségtételhez egy tippre van szükség a kiszolgálótól.

  • Alapértelmezés szerint a fordított proxy feltételezi a 2. esetet, és megpróbálja megoldani és újból kiadni a kérést.

  • Ha az 1. esetet a fordított proxyra szeretné jelezni, a szolgáltatásnak a következő HTTP-válaszfejlécet kell visszaadnia:

    X-ServiceFabric : ResourceNotFound

Ez a HTTP-válaszfejléc egy normál HTTP 404-helyzetet jelez, amelyben a kért erőforrás nem létezik, és a fordított proxy nem próbálja meg újból feloldani a szolgáltatás címét.

Speciális kezelés a tárolókban futó szolgáltatásokhoz

A tárolókon belül futó szolgáltatások esetében a környezeti változó Fabric_NodeIPOrFQDN használatával a fordított proxy URL-címét az alábbi kódban leírtak szerint hozhatja létre:

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

A helyi fürt Fabric_NodeIPOrFQDN esetében alapértelmezés szerint a "localhost" értékre van állítva. Indítsa el a helyi fürtöt a -UseMachineName paraméterrel, hogy a tárolók elérjék a csomóponton futó fordított proxyt. További információ: A fejlesztői környezet konfigurálása tárolók hibakeresésére.

A Docker Compose-tárolókban futó Service Fabric-szolgáltatásokhoz speciális docker-compose.yml Portok szakaszra van szükség: http: vagy https: konfiguráció. További információ: Docker Compose üzembehelyezési támogatás az Azure Service Fabricben.

Következő lépések