Service Fabric és Azure API Management – áttekintés

A felhőalapú alkalmazásokhoz általában előtér-átjáró szükséges, amely egyetlen belépési pontként szolgálhat a felhasználók, eszközök és egyéb alkalmazások számára. A Service Fabricben az átjárók lehetnek bármilyen állapot nélküli szolgáltatás, például egy ASP.NET Core alkalmazás vagy egy forgalomforgalomra tervezett szolgáltatás, például az Event Hubs, a IoT Hub vagy az Azure API Management.

Ez a cikk az Azure API Management Service Fabric-alkalmazások átjárójaként való használatát ismerteti. API Management közvetlenül integrálható a Service Fabric szolgáltatással, így számos útválasztási szabályt tartalmazó API-kat tehet közzé a háttérbeli Service Fabric-szolgáltatásokban.

Rendelkezésre állás

Fontos

Ez a funkció a API Management prémium és fejlesztői szintjeiben érhető el a szükséges virtuális hálózati támogatás miatt.

Architektúra

A Service Fabric-architektúra egy egyoldalas webalkalmazást használ, amely HTTP-hívásokat indít a HTTP API-kat közzételő háttérszolgáltatásokhoz. A Service Fabric első lépések mintaalkalmazása egy példát mutat be erre az architektúrára.

Ebben a forgatókönyvben egy állapot nélküli webszolgáltatás szolgál átjáróként a Service Fabric-alkalmazásba. Ehhez a megközelítéshez olyan webszolgáltatást kell írnia, amely képes HTTP-kéréseket proxyként használni a háttérszolgáltatásokhoz, ahogy az az alábbi ábrán is látható:

Ahogy az alkalmazások egyre összetettebbé fejlődnek, azoknak az átjáróknak is, amelyeknek API-t kell bemutatniuk a számtalan háttérszolgáltatás előtt. Az Azure API Management összetett API-k kezelésére szolgál útválasztási szabályokkal, hozzáférés-vezérléssel, sebességkorlátozással, monitorozással, eseménynaplózással és válasz-gyorsítótárazással, minimális munkával. Az Azure API Management támogatja a Service Fabric szolgáltatásfelderítést, a partíciófeloldást és a replika kiválasztását, hogy intelligensen irányíthassa a kéréseket közvetlenül a Service Fabric háttérszolgáltatásaiba, így nem kell saját állapot nélküli API-átjárót írnia.

Ebben a forgatókönyvben a webes felhasználói felület továbbra is egy webszolgáltatáson keresztül lesz kiszolgálva, míg a HTTP API-hívások kezelése és átirányítása az Azure API Management keresztül történik az alábbi ábrán látható módon:

Alkalmazáshasználati helyzetek

A Service Fabric szolgáltatásai állapot nélküliek vagy állapotalapúak lehetnek, és három séma egyikével particionálhatók: singleton, int-64 tartomány és név. A szolgáltatásvégpont-feloldáshoz egy adott szolgáltatáspéldány adott partíciójának azonosítására van szükség. Egy szolgáltatás végpontjának feloldásakor a szolgáltatáspéldány nevét (például fabric:/myapp/myservice) és a szolgáltatás adott partícióját is meg kell adni, kivéve a singleton partíciót.

Az Azure API Management az állapot nélküli szolgáltatások, az állapotalapú szolgáltatások és a particionálási sémák bármilyen kombinációjával használható.

Forgalom küldése állapot nélküli szolgáltatásba

A legegyszerűbb esetben a forgalom egy állapot nélküli szolgáltatáspéldányra továbbítja a forgalmat. Ennek eléréséhez egy API Management művelet tartalmaz egy bejövő feldolgozási szabályzatot egy Service Fabric háttérrendszerrel, amely leképez egy adott állapot nélküli szolgáltatáspéldányt a Service Fabric háttérrendszerében. A szolgáltatásnak küldött kéréseket a rendszer a szolgáltatás egy véletlenszerű példányára küldi.

Példa

A következő forgatókönyvben a Service Fabric-alkalmazások egy nevű fabric:/app/fooservice állapot nélküli szolgáltatást tartalmaznak, amely egy belső HTTP API-t tesz elérhetővé. A szolgáltatáspéldány neve jól ismert, és közvetlenül a API Management bejövő feldolgozási szabályzatban kódolt.

Forgalom küldése állapotalapú szolgáltatásnak

Az állapot nélküli szolgáltatásforgatókönyvhez hasonlóan a forgalom továbbítható egy állapotalapú szolgáltatáspéldánynak. Ebben az esetben egy API Management művelet tartalmaz egy bejövő feldolgozási szabályzatot egy Service Fabric háttérrendszerrel, amely leképez egy kérést egy adott állapotalapú szolgáltatáspéldány adott partíciójára. Az egyes kérések leképezésére szolgáló partíciót egy lambda metóduson keresztül számítjuk ki a bejövő HTTP-kérés bizonyos bemenetével, például az URL-cím elérési útjának egy értékével. A szabályzat konfigurálható úgy, hogy csak az elsődleges replikának vagy egy véletlenszerű replikának küldjön kéréseket olvasási műveletekhez.

Példa

A következő forgatókönyvben a Service Fabric-alkalmazások egy nevű fabric:/app/userservice particionált állapotalapú szolgáltatást tartalmaznak, amely egy belső HTTP API-t tesz elérhetővé. A szolgáltatáspéldány neve jól ismert, és közvetlenül a API Management bejövő feldolgozási szabályzatban kódolt.

A szolgáltatás particionálása az Int64 partíciós sémával történik két partícióval és egy kulcstartománysal, amely a következőre terjed ki Int64.MinValueInt64.MaxValue: . A háttérházirend egy partíciókulcsot számít ki az adott tartományon belül úgy, hogy az id URL-kérelem elérési útján megadott értéket 64 bites egész számmá alakítja, bár itt bármilyen algoritmus használható a partíciókulcs kiszámításához.

Forgalom küldése több állapot nélküli szolgáltatásnak

Speciálisabb forgatókönyvekben meghatározhat egy API Management műveletet, amely egynél több szolgáltatáspéldányra leképezi a kéréseket. Ebben az esetben minden művelet tartalmaz egy szabályzatot, amely leképezi a kéréseket egy adott szolgáltatáspéldányra a bejövő HTTP-kérés értékei alapján, például az URL-elérési út vagy a lekérdezési sztring, állapotalapú szolgáltatások esetében pedig a szolgáltatáspéldányon belüli partíció alapján.

Ennek eléréséhez egy API Management művelet tartalmaz egy bejövő feldolgozási szabályzatot egy Service Fabric háttérrendszerrel, amely a bejövő HTTP-kérésből lekért értékek alapján leképez egy állapot nélküli szolgáltatáspéldányt a Service Fabric háttérrendszerében. A szolgáltatásra irányuló kéréseket a rendszer a szolgáltatás egy véletlenszerű példányára küldi.

Példa

Ebben a példában egy új állapot nélküli szolgáltatáspéldány jön létre egy dinamikusan generált névvel rendelkező alkalmazás minden felhasználója számára az alábbi képlettel:

• fabric:/app/users/<username>

  Minden szolgáltatás egyedi névvel rendelkezik, de a nevek nem ismertek előre, mert a szolgáltatások a felhasználói vagy rendszergazdai bemenetre reagálva jönnek létre, és így nem kódozhatók szigorúan APIM-szabályzatokba vagy útválasztási szabályokba. Ehelyett annak a szolgáltatásnak a neve, amelyre a kérést küldeni szeretné, a háttérházirend-definícióban jön létre az name URL-kérelem elérési útján megadott értékből. Például:

  • A kérést /api/users/foo a rendszer a szolgáltatáspéldányra irányítja fabric:/app/users/foo
  • A kérést /api/users/bar a rendszer a szolgáltatáspéldányra irányítja fabric:/app/users/bar

Forgalom küldése több állapotalapú szolgáltatásnak

Az állapot nélküli szolgáltatás példájához hasonlóan egy API Management művelet több állapotalapú szolgáltatáspéldányra is leképezheti a kéréseket, ebben az esetben az egyes állapotalapú szolgáltatáspéldányok partíciófeloldására is szükség lehet.

Ennek eléréséhez egy API Management művelet tartalmaz egy bejövő feldolgozási szabályzatot egy Service Fabric háttérrendszerrel, amely a bejövő HTTP-kérésből lekért értékek alapján leképez egy állapotalapú szolgáltatáspéldányt a Service Fabric háttérrendszerében. A kérés adott szolgáltatáspéldányhoz való hozzárendelése mellett a kérés leképezhető egy adott partícióra is a szolgáltatáspéldányon belül, és opcionálisan az elsődleges replikára vagy egy véletlenszerű másodlagos replikára a partíción belül.

Példa

Ebben a példában egy új állapotalapú szolgáltatáspéldány jön létre az alkalmazás minden felhasználója számára egy dinamikusan generált névvel az alábbi képlettel:

• fabric:/app/users/<username>

  Minden szolgáltatás egyedi névvel rendelkezik, de a nevek nem ismertek előre, mert a szolgáltatások a felhasználói vagy rendszergazdai bemenetre reagálva jönnek létre, és így nem kódozhatók szigorúan APIM-szabályzatokba vagy útválasztási szabályokba. Ehelyett annak a szolgáltatásnak a neve, amelyre a kérést küldeni szeretné, a háttérházirend-definícióban jön létre az name URL-kérelem elérési útjaként megadott értékből. Például:

  • A kérést /api/users/foo a rendszer a szolgáltatáspéldányra irányítja fabric:/app/users/foo
  • A kérést /api/users/bar a rendszer a szolgáltatáspéldányra irányítja fabric:/app/users/bar

Az egyes szolgáltatáspéldányok particionálása az Int64 partíciós sémával történik, két partícióval és egy kulcstartománysal, amely a következőre terjed ki Int64.MinValueInt64.MaxValue: . A háttérházirend egy partíciókulcsot számít ki az adott tartományon belül úgy, hogy az id URL-kérelem elérési útján megadott értéket 64 bites egész számmá alakítja, bár itt bármilyen algoritmus használható a partíciókulcs kiszámításához.

Következő lépések

Kövesse az oktatóanyagot, és állítsa be az első Service Fabric-fürtöt API Management és folyamatkérésekkel a szolgáltatások API Management keresztül.