Összevont API-kezelés munkaterületekkel

A KÖVETKEZŐRE VONATKOZIK: Alapszintű v2 | Standard v2 | Prémium | Prémium v2

Ez a cikk áttekintést nyújt az API Management-munkaterületekről , és arról, hogyan teszik lehetővé a decentralizált API-fejlesztői csapatok számára, hogy az API-kat egy közös szolgáltatási infrastruktúrában felügyeljék és termékeljék.

Miért kell a szervezeteknek összevonni az API-kezelést?

Napjainkban a szervezetek egyre nagyobb kihívásokkal szembesülnek az API-k elterjedésének kezelése terén. Ahogy nő az API-k és az API-fejlesztői csapatok száma, úgy a kezelésük összetettsége is. Ez az összetettség megnövelheti a működési terhelést, a biztonsági kockázatokat és csökkentheti a rugalmasságot. A szervezetek egyrészt egy központosított API-infrastruktúrát szeretnének létrehozni az API-szabályozás, a biztonság és a megfelelőség biztosítása érdekében. Másrészt azt szeretnék, hogy az API-csapatok gyorsan újítsanak és reagáljanak az üzleti igényekre anélkül, hogy az API-platform felügyeletének többlettere lenne.

Az API management összevont modellje kielégíti ezeket az igényeket. Az összevont API-felügyelet lehetővé teszi, hogy a fejlesztői csapatok decentralizált API-felügyeletet biztosítson a vezérlő- és adatsíkok megfelelő elkülönítésével, miközben fenntartja a központosított szabályozást, a monitorozást és az API-felderítést egy API-platform csapata által. Ez a modell leküzdi az alternatív megközelítések korlátait, például a platformcsapat által teljes mértékben központosított API-kezelést vagy az egyes fejlesztői csapatok által a silózott API-kezelést.

Az összevont API-felügyelet a következőket biztosítja:

  • Központosított API-szabályozás és megfigyelhetőség
  • Egységes fejlesztői portál a hatékony API-felderítéshez és előkészítéshez
  • Elkülönített rendszergazdai engedélyek az API-csapatok között, a hatékonyság és a biztonság növelése
  • Elkülönített API-futtatókörnyezet az API-csapatok között, javítva a megbízhatóságot, a rugalmasságot és a biztonságot

Hogyan teszik lehetővé a munkaterületek az összevont API-kezelést?

Az Azure API Managementben munkaterületek használatával valósíthat meg összevont API-kezelést. A munkaterületek az API Management szolgáltatásban a "mappákhoz" hasonló módon működnek:

  • Minden munkaterület API-kat, termékeket, előfizetéseket, elnevezett értékeket és kapcsolódó erőforrásokat tartalmaz. A munkaterületeken támogatott erőforrások és műveletek teljes listáját az API Management REST API-referenciájában találja.
  • A Teams egy munkaterületen belüli erőforrásokhoz való hozzáférését az Azure szerepköralapú hozzáférés-vezérlése (RBAC) kezeli, amely beépített vagy egyéni szerepkörökkel rendelkezik, amelyek hozzárendelhetők a Microsoft Entra-fiókokhoz, és hatókörük egy munkaterületre terjed ki.
  • Minden munkaterület egy vagy több átjáróval van társítva az API-forgalom átirányításához a munkaterület API-k háttérszolgáltatásaihoz. A szolgáltatási szinttől és a követelményektől függően a munkaterület használhatja a szolgáltatás alapértelmezett felügyelt átjáróját vagy egy vagy több munkaterületi átjárót.
  • A platformcsapat az API-kra és a munkaterületeken található termékekre kiterjedő szabályzatokat alkalmazhat az API-futtatókörnyezet szervezeten belüli szabályozásához. A beépített Azure Policy-definíció (API Management policies should inherit parent scope policies using <base/>) lehetővé teszi a szabályzatok minden munkaterület-erőforrásra való alkalmazásának naplózását vagy kikényszerítését.
  • A platformcsapat központosított API-felderítést valósíthat meg egy fejlesztői portálon.
  • Minden munkaterületi csapat összegyűjtheti és elemezheti az átjáróerőforrás-naplókat a saját munkaterületi API-k figyeléséhez, míg a platformcsapat összevont hozzáféréssel rendelkezik a naplókhoz az API Management szolgáltatás összes munkaterületén, biztosítva a felügyeletet, a biztonságot és a megfelelőséget az API-ökoszisztémájukban.

Az API Management szolgáltatás elméleti diagramja munkaterületekkel.

Note

  • Újdonság! A munkaterületek funkció már elérhető az Alapszintű v2 és Standard v2 szinteken a Prémium és a Prémium v2 szint mellett. A v2-szintek munkaterületei az alapértelmezett API Management felügyelt átjáróhoz vagy egy külön munkaterületi átjáró-erőforráshoz társíthatók, így rugalmasan konfigurálhatja és méretezheti a munkaterületeket.
  • A díjszabással kapcsolatos szempontokért tekintse meg az API Management díjszabását.

Bár a munkaterületek kezelése független az API Management szolgáltatástól és más munkaterületektől, tervezésük során a kiválasztott szolgáltatásszintű erőforrásokra hivatkozhatnak. Tekintse meg a munkaterületeket és az API Management egyéb funkcióit a cikk későbbi részében.

Példaforgatókönyv áttekintése

Az Azure API Managementet az API-k kezelésére használó szervezeteknek több fejlesztőcsapatuk is lehet, amelyek különböző API-készleteket fejlesztenek, határoznak meg, tartanak karban és alakítanak termékké. A munkaterületek használatával ezek a csapatok az API Management használatával külön és a szolgáltatásinfrastruktúra kezelésétől függetlenül kezelhetik, érhetik el és védhetik API-kat.

Az alábbi munkafolyamat egy mintafolyamatot mutat be egy munkaterület létrehozásához és használatához.

  1. Az API Management-példányt kezelő központi API-platformcsapat létrehoz egy munkaterületet, és RBAC-szerepkörök használatával engedélyeket rendel a munkaterület-közreműködőkhöz. Rendeljen például engedélyeket erőforrások létrehozásához vagy olvasásához a munkaterületen. A csapat létrehoz vagy társít egy API-átjárót a munkaterülethez az API-forgalom irányításához.

  2. Egy központi API-platform csapata DevOps-eszközökkel hoz létre egy DevOps-folyamatot az adott munkaterület API-khoz.

  3. A munkaterület tagjai API-kat fejlesztenek, publikálnak, termékké alakítanak és karbantartanak a munkaterületen.

  4. A központi API-platform csapata felügyeli a szolgáltatás infrastruktúráját, például a monitorozást, a rugalmasságot és a teljes API-szabályzatok kikényszerítését.

Munkaterületi kapcsolódási pont

Minden munkaterület egy vagy több átjáróval van konfigurálva a munkaterületen felügyelt API-k futtatókörnyezetének engedélyezéséhez. A szolgáltatási szinttől és a követelményektől függően használhatja a szolgáltatás alapértelmezett felügyelt átjáróját és/vagy egy vagy több munkaterületi átjárót (külön átjáróerőforrásokat).

Option Availability Előnyök Considerations
Alapértelmezett felügyelt átjáró Jelenleg v2-szinteken Az átjáró-erőforrás nem jár többletköltséggel; minden olyan régióban elérhető, ahol ez a szolgáltatási szint is elérhető; a munkaterületek kihasználhatják azokat a beépített átjáró-képességeket, amelyek a munkaterület-átjárókban nem érhetők el, például a többrégiós üzembe helyezéseket, az egyéni gazdagépneveket vagy – ha a szolgáltatási szint támogatja – a Private Link-kapcsolatot Kevesebb elkülönítés; minden munkaterület osztozik az átjáró kapacitásán és konfigurációján
Munkaterületi kapcsolódási pont Alapszintű v2, Standard v2, Premium, Premium v2 Erős futásidejű elkülönítés; független skálázás, állomásnév- és hálózati konfiguráció munkaterületi átjárónként Többletköltség; hosszabb üzembe helyezési idő; támogatás kevesebb régióban

Alapértelmezett felügyelt átjáró

A v2-szinteken konfigurálhat egy munkaterületet úgy, hogy az API-forgalmat a szolgáltatás alapértelmezett felügyelt átjáróján keresztül irányíthassa egy vagy több különálló munkaterület-átjáró-erőforrás mellett. Ha egy munkaterület az alapértelmezett felügyelt átjárót használja:

  • Az API-forgalom a szolgáltatás alapértelmezett állomásnevén (például <service-name>.azure-api.net) halad át.
  • A munkaterület más munkaterületekkel és szolgáltatásszintű API-kkal osztja meg az átjáró kapacitását és konfigurációját.

Note

Egy munkaterületet jelenleg csak a v2 szolgáltatási szinteken és az API Management-munkaterületen – REST API létrehozása vagy frissítése – keresztül társíthat az alapértelmezett felügyelt átjáróhoz.

Munkaterületi kapcsolódási pont

A munkaterület-átjáró egy különálló Azure erőforrás (munkatér-átjáró prémium), amelynek alapvető funkciója megegyezik az alapértelmezett felügyelt átjáróval.

A munkaterület-átjárókat az API Management szolgáltatástól és egymástól függetlenül kezelheti. Lehetővé teszik a futtatókörnyezet elkülönítését a munkaterületek vagy használati esetek között, ami növeli az API megbízhatóságát, rugalmasságát és biztonságát. Lehetővé teszik a futtatókörnyezeti problémák munkaterületekhez való hozzárendelését is.

Munkaterületek társítása egy munkaterületi kapuval

A szervezet igényeitől függően egy munkaterületet vagy több munkaterületet társíthat egy munkaterület-átjáróhoz.

Note

Több munkaterület munkaterület-átjáróval való társítása csak a 2025. április 15. után létrehozott munkaterület-átjárók esetében érhető el.

  • A munkaterületi átjáró bizonyos konfigurációs beállításokkal rendelkezik, például virtuális hálózattal, skálázással és gazdagépnévvel, valamint lefoglalt számítási erőforrásokkal, beleértve a CPU-t, a memóriát és a hálózati erőforrásokat.
  • Az átjárón üzembe helyezett összes munkaterület osztozik a konfigurációs és a számítási erőforrásokon.
  • Az API-k hibái vagy a rendellenes forgalom ezeknek az erőforrásoknak a kimerülését okozhatják, ami az átjáró összes munkaterületét érinti. Más szóval minél több munkaterületet helyez üzembe egy átjárón, annál nagyobb annak a kockázata, hogy egy munkaterület API-ja megbízhatósági problémákat tapasztal egy másik munkaterületről származó API miatt.
  • A munkaterület-átjárója teljesítményét a processzor- és memóriahasználat figyelésére szolgáló beépített metrikák segítségével figyelheti.

Fontolja meg a megbízhatóságot, a biztonságot és a költségeket a munkaterületek üzembehelyezési modelljének kiválasztásakor.

  • Munkaterület hozzárendelése saját dedikált munkaterület-átjáróhoz a kritikus fontosságú számítási feladatokhoz – Az API megbízhatóságának és biztonságának maximalizálása érdekében rendeljen hozzá minden kritikus fontosságú munkaterületet a saját átjáróhoz, elkerülve a más munkaterületekkel való megosztott használatot.
  • A megbízhatóság, a biztonság és a költségek kiegyensúlyozása – Több munkaterület társítása egy munkaterület-átjáróhoz (vagy adott esetben az alapértelmezett felügyelt átjáróhoz) a nem kritikus számítási feladatok megbízhatóságának, biztonságának és költségeinek egyensúlya érdekében. Ossza el a munkaterületeket legalább két átjáró között, hogy megelőzze az olyan problémákat, mint az erőforrás-kimerültség vagy a konfigurációs hibák, amelyek a szervezet összes API-ját érintik.
  • Különböző átjárók használata különböző használati esetekhez – Munkaterületek csoportosítása egy munkaterület-átjárón használati eset vagy hálózati követelmények alapján. Különbséget tehet például a belső és a külső API-k között, ha külön átjárókhoz rendeli őket, és mindegyik saját hálózati konfigurációval rendelkezik.
  • Prepare a problémás munkaterületek karanténba helyezéséhez – Használjon proxyt, például Azure Application Gateway vagy Azure Front Door a megosztott munkaterület-átjárók előtt, hogy egyszerűbb legyen áthelyezni egy olyan munkaterületet, amely erőforrás-kimerülést okoz egy másik átjáróra. Ez a megközelítés megakadályozza az átjárót megosztó többi munkaterületre gyakorolt hatást.

Note

  • A munkaterület-átjárónak ugyanabban a régióban kell lennie, mint az API Management-példány elsődleges Azure régiója és ugyanabban az előfizetésben.
  • A munkaterület-átjáróhoz társított összes munkaterületnek ugyanabban az API Management-példányban kell lennie.
  • Egy munkaterület-átjáróhoz legfeljebb 30 munkaterület társítható. A korlát növeléséhez forduljon az ügyfélszolgálathoz.

Munkaterület-átjáró állomásneve

Minden munkaterületi átjáró egyedi gazdagépnevet biztosít a hozzá tartozó munkaterületen kezelt API-khoz. Az alapértelmezett állomásnevek a mintát <gateway-name>-<hash>.gateway.<region>.azure-api.netkövetik. Az átjáró hostneve segítségével irányítsa az API-kérelmeket a munkaterület API-khoz.

A munkaterületi átjárók jelenleg nem támogatják az egyéni gazdagépneveket. Az Azure Application Gatewayt vagy az Azure Front Doort egyéni gazdagépnévvel konfigurálhatja egy munkaterület-átjáró előtt.

Munkaterület-átjárók hálózatelkülönítése

Igény szerint konfigurálhat egy munkaterületi átjáróerőforrást egy privát virtuális hálózaton a bejövő és kimenő forgalom elkülönítésére. Ha ezt az elkülönítést konfigurálja, a munkaterületi átjárónak dedikált alhálózatot kell használnia a virtuális hálózaton.

A részletes követelményekért tekintse meg a munkaterület-átjárók hálózati erőforrás-követelményeit.

Note

  • A munkaterület-átjáró hálózati konfigurációja független az API Management-példány hálózati konfigurációitól.
  • A munkaterületi átjárók jelenleg csak az átjáró létrehozásakor konfigurálhatók virtuális hálózaton. Az átjáró hálózati konfigurációját vagy beállításait később nem módosíthatja.

A munkaterület-átjárók kapacitásának skálázása

A munkaterület-átjáró kapacitásának kezelése skálázási egységek hozzáadásával vagy eltávolításával, hasonlóan a bizonyos szolgáltatási szintek API Management-példányához hozzáadható egységekhez . A munkaterület-átjárók költségei a kiválasztott egységek számán alapulnak.

Munkaterület-átjárók regionális rendelkezésre állása

Azoknak a régióknak az aktuális listáját, ahol a munkaterületi átjárók elérhetők, tekintse meg a v2-szintek és a munkaterületi átjárók rendelkezésre állását.

Munkaterület- és munkaterület-átjárók korlátozásai

Munkaterületek korlátozásai

  • A munkaterület nem társítható saját üzemeltetésű átjáróhoz
  • A munkaterületek API-it nem fedik le az API-khoz készült Defender
  • A munkaterületek nem támogatják a hitelesítő adatok kezelőjét
  • A munkaterületek csak a belső gyorsítótárat támogatják; a külső gyorsítótár nem támogatott
  • A munkaterületek nem támogatják a szintetikus GraphQL API-kat
  • A munkaterületek nem támogatják közvetlenül az API-k létrehozását Azure erőforrásokból, például Azure OpenAI Service, App Service, Függvényalkalmazások stb. az Azure portálon
  • A munkaterületek nem támogatják az MCP-kiszolgálókat
  • A kérelemmetrikákat nem lehet munkaterületek szerint felosztani az Azure Monitorban; az összes munkaterületi metrikát a szolgáltatás szintjén összesíti a rendszer
  • A munkaterületek nem támogatják a hitelesítésszolgáltatói tanúsítványokat
  • A munkaterületek nem támogatják a felügyelt identitásokat, beleértve az olyan kapcsolódó funkciókat, mint a titkos kódok tárolása Azure Key Vault és a authentication-managed-identity szabályzat használata

Munkaterület-átjáró korlátozásai

A felügyelt munkaterület-átjáró erőforrására az alábbi korlátozások vonatkoznak. Ezek nem alkalmazhatók a munkaterületeknek a szolgáltatás alapértelmezett felügyelt átjáróján történő használatakor.

  • A munkaterület-átjárók nem támogatják a bejövő privát végpontokat
  • A munkaterület-átjárók nem támogatják az egyéni gazdagépneveket
  • A munkaterületek csak az API Management-erőforrással azonos régióban és előfizetésben található munkaterület-átjárókkal társíthatók

Globális szabályzatöröklés munkaterületi átjárókban

A munkaterület-átjárók végrehajtják a teljes szabályzatláncot, beleértve a szolgáltatási szintű globális szabályzatot (global.policy.xml). Ez a viselkedés azt jelenti, hogy a globális hatókörben definiált szabályzatok kiértékelése és végrehajtása a munkaterület-átjárók által feldolgozott API-hívásokhoz ugyanúgy történik, mint az alapértelmezett átjáró esetében. Ez a viselkedés az API Management szabályzat-kiértékelési modelljével összhangban van, ahol hierarchikusan alkalmazza a szabályzatokat a következő hatókörökben: globális (szolgáltatás-) > munkaterület > termék > API-művelete > .

Javaslatok a munkaterület-átjárókkal rendelkező globális szabályzatokhoz

  • Tekintse át a globális szabályzatot, és győződjön meg arról, hogy csak az összes átjáróra érvényes szabályzatokat tartalmazza, beleértve a munkaterületi átjárókat is.

  • Ha átjárónként eltérő viselkedésre van szüksége, használja a kiválasztási szabályzatot context.Deployment.Gateway.Id a szabályzatok feltételes végrehajtásához a kérést feldolgozó átjáró alapján.

  • Ha egy hitelesítéssel felügyelt identitást határoz meg a globális hatókörben, de a jogkivonatnak nem szabad a munkaterület-hatókörű API-k számára rendelkezésre állnia, helyezze át a szabályzatot a globális szabályzat helyett szűkebb hatókörre (például termék- vagy API-szintre).

RBAC-szerepkörök munkaterületekhez

Az Azure RBAC használatával konfigurálhatók a munkaterület közreműködőinek a munkaterületen lévő entitások olvasására és szerkesztésére vonatkozó engedélyei. A szerepkörök listájáért lásd : Szerepköralapú hozzáférés-vezérlés használata az API Managementben.

A munkaterület API-jainak és egyéb erőforrásainak kezeléséhez rendeljen szerepköröket a munkaterület tagjaihoz (vagy az egyéni szerepkörökön keresztüli egyenértékű engedélyekhez), amelyek hatóköre az API Management szolgáltatásra és a munkaterületre terjed ki. A szolgáltatás hatókörébe tartozó szerepkör lehetővé teszi bizonyos szolgáltatási szintű erőforrások munkaterületszintű erőforrásokra való hivatkozását. Például egy felhasználót egy munkaterületszintű csoportba rendezve szabályozhatja az API-t és a termékek láthatóságát.

Ha a munkaterület dedikált munkaterületi átjárót használ, az átjárót kezelő tagokat is hozzá kell rendelni a munkaterület-átjáró erőforrásához hatókörrel rendelkező szerepkörhöz.

Note

A könnyebb kezelés érdekében állítsa be a Microsoft Entra-csoportokat, hogy több felhasználóhoz rendeljen munkaterületi engedélyeket.

Munkaterületek és egyéb API Management-funkciók

A munkaterületek önállóak a felügyeleti hozzáférés és az API-futtatókörnyezet elkülönítésének maximalizálása érdekében. A nagyobb hatékonyság biztosítása és a platformszintű szabályozás, a megfigyelhetőség, az újrahasználhatóság és az API-felderítés lehetővé tétele érdekében számos kivétel létezik.

  • Erőforráshivatkozások – A munkaterület erőforrásai hivatkozhatnak a munkaterület más erőforrásaira, valamint a szolgáltatási szintről kiválasztott erőforrásokra, például felhasználókra, engedélyezési kiszolgálókra vagy beépített felhasználói csoportokra. Nem hivatkozhatnak más munkaterületről származó erőforrásokra.

    Biztonsági okokból nem hivatkozhat szolgáltatásszintű erőforrásokra munkaterületszintű szabályzatokból (például elnevezett értékekből) vagy erőforrásnevekből, például backend-id a háttérszolgáltatás-házirendből .

    Important

    Az API Management szolgáltatás összes erőforrásának (például API-knak, termékeknek, címkéknek vagy előfizetéseknek) egyedi névvel kell rendelkeznie, még akkor is, ha különböző munkaterületeken találhatók. Nem rendelkezhet azonos típusú és azonos Azure erőforrásnévvel ugyanabban a munkaterületen, más munkaterületeken vagy szolgáltatásszinten.

  • Fejlesztői portál – A munkaterületek felügyeleti fogalmak, és nem jelennek meg ilyen módon a fejlesztői portál felhasználói számára, például a fejlesztői portál felhasználói felületén és az alapul szolgáló API-on keresztül. A munkaterületen belüli API-kat és termékeket a fejlesztői portálon is közzéteheti, ugyanúgy, mint az API-kat és a szolgáltatási szintű termékeket.

    Note

    Az API Management támogatja a szolgáltatásszinten definiált engedélyezési kiszolgálók hozzárendelését a munkaterületeken belüli API-khoz.

Migrálás előzetes verziójú munkaterületekről

Ha előzetes verziójú munkaterületeket hozott létre az Azure API Managementben, és továbbra is használni szeretné őket, migrálja a munkaterületeket az általánosan elérhető verzióra egy munkaterület-átjáró társításával az egyes munkaterületekkel.

A részletekért és az előzetes verziójú munkaterületeket érintő egyéb módosításokért lásd: Munkaterületek kompatibilitástörő változásai (2025. március).

Munkaterület törlése

Amikor az Azure Portal felületének használatával töröl egy munkaterületet, annak összes alárendelt erőforrását (API-kat, termékeket stb.), valamint a hozzá társított dedikált munkaterületi átjárót is törli, ha van ilyen. Nem törli az API Management-példányt vagy más munkaterületeket.

Kapcsolódó tartalom

  • Last updated on