Federacyjne zarządzanie interfejsami API z obszarami roboczymi

DOTYCZY: Podstawowa wersja 2 | Standardowa, wersja 2 | Premium | Premium, wersja 2

Ten artykuł zawiera omówienie obszarów roboczych usługi API Management i sposobu, w jaki umożliwiają one zdecentralizowanym zespołom deweloperów interfejsów API zarządzanie interfejsami API i tworzenie ich produktów w wspólnej infrastrukturze usług.

Dlaczego organizacje powinny federować usługę API Management?

Obecnie organizacje coraz częściej napotykają wyzwania związane z zarządzaniem rozprzestrzenianiem się interfejsów API. Wraz ze wzrostem liczby interfejsów API i zespołów deweloperskich interfejsów API rośnie również złożoność zarządzania nimi. Ta złożoność może prowadzić do zwiększenia nakładu pracy operacyjnej, ryzyka związanego z bezpieczeństwem i zmniejszenia elastyczności. Z jednej strony organizacje chcą ustanowić scentralizowaną infrastrukturę interfejsu API w celu zapewnienia ładu, zabezpieczeń i zgodności interfejsu API. Z drugiej strony chcą, aby zespoły interfejsów API wprowadzały innowacje i szybko reagowały na potrzeby biznesowe bez konieczności zarządzania platformą interfejsu API.

Model federacyjny usługi API Management odpowiada tym potrzebom. Federacyjne zarządzanie interfejsami API umożliwia zdecentralizowane zarządzanie interfejsami API przez zespoły deweloperów z odpowiednią izolacją płaszczyzn kontroli i danych przy zachowaniu scentralizowanego ładu, monitorowania i odnajdywania interfejsów API zarządzanego przez zespół platformy interfejsu API. Ten model pozwala przezwyciężyć ograniczenia alternatywnych metod, takich jak w pełni scentralizowane zarządzanie interfejsami API przez zespół platformy lub silosowe zarządzanie interfejsami API przez każdy zespół programistyczny.

Federacyjne zarządzanie interfejsami API zapewnia:

  • Scentralizowany nadzór i możliwość obserwowania interfejsu API
  • Zintegrowany portal dla deweloperów umożliwiający efektywne odkrywanie i integrację z API
  • Segregowane uprawnienia administracyjne między zespołami interfejsów API, zwiększając produktywność i bezpieczeństwo
  • Oddzielone środowisko uruchomieniowe API pomiędzy zespołami API, co poprawia niezawodność, odporność i bezpieczeństwo.

Jak obszary robocze umożliwiają federacyjne zarządzanie interfejsami API

W usłudze Azure API Management użyj obszarów roboczych do zaimplementowania federacyjnego zarządzania interfejsami API. Obszary robocze działają jak "foldery" w usłudze API Management:

  • Każdy obszar roboczy zawiera interfejsy API, produkty, subskrypcje, nazwane wartości i powiązane zasoby. Zobacz dokumentację interfejsu API REST zarządzania API, aby uzyskać pełną listę zasobów i operacji obsługiwanych w przestrzeniach roboczych.
  • Dostęp usługi Teams do zasobów w obszarze roboczym jest zarządzany za pośrednictwem kontroli dostępu opartej na rolach (RBAC) platformy Azure z wbudowanymi lub niestandardowymi rolami przypisanymi do kont Microsoft Entra i zakresem do obszaru roboczego.
  • Każdy obszar roboczy jest powiązany z jedną lub większą liczbą bram do kierowania ruchu API do usług zaplecza interfejsów API znajdujących się w obszarze roboczym. W zależności od warstwy usługi i wymagań obszar roboczy może używać domyślnej bramy zarządzanej usługi lub co najmniej jednej bramy obszaru roboczego.
  • Zespół platformy może stosować zasady obejmujące interfejsy API i produkty w obszarach roboczych, aby zarządzać środowiskiem wykonawczym API w całej organizacji. Wbudowana definicja usługi Azure Policy (API Management policies should inherit parent scope policies using <base/>) umożliwia inspekcję lub wymuszanie zastosowania tych zasad we wszystkich zasobach obszaru roboczego.
  • Zespół platformy może zaimplementować scentralizowane środowisko odnajdywania interfejsu API za pomocą portalu dla deweloperów.
  • Zespół każdego z obszarów roboczych może zbierać i analizować dzienniki zasobów bramki w celu monitorowania własnych interfejsów API obszaru roboczego, podczas gdy zespół platformy ma federacyjny dostęp do dzienników we wszystkich obszarach roboczych w usłudze API Management, zapewniając nadzór, bezpieczeństwo i zgodność w całym ekosystemie interfejsów API.

Diagram koncepcyjny usługi API Management z obszarami roboczymi i opcjonalną bramą obszaru roboczego.

Note

  • Nowość! Funkcja obszarów roboczych jest teraz dostępna w warstwach Basic v2 i Standard v2, oprócz warstw Premium i Premium v2. Obszary robocze w warstwach v2 można skojarzyć z domyślną bramą zarządzaną usługi API Management lub oddzielnym zasobem bramy obszaru roboczego, co zapewnia elastyczność konfigurowania i skalowania obszarów roboczych. Aby uzyskać informacje na temat planu obsługi warstw obszarów roboczych, zobacz wpis w blogu.
  • Aby zapoznać się z zagadnieniami dotyczącymi cen, zobacz Cennik usługi API Management.

Obszary robocze są zarządzane niezależnie od usługi API Management i innych obszarów roboczych, jednak zgodnie z projektem mogą odwoływać się do wybranych zasobów na poziomie usługi. Zobacz Obszary robocze i inne funkcje usługi API Management w dalszej części tego artykułu.

Omówienie przykładowego scenariusza

Organizacja, która zarządza interfejsami API przy użyciu Azure API Management może mieć wiele zespołów programistycznych, które tworzą, definiują, konserwują i tworzą różne zestawy interfejsów API. Korzystając z obszarów roboczych, zespoły te mogą używać usługi API Management do zarządzania infrastrukturą usług, uzyskiwania do nich dostępu i zabezpieczania ich oddzielnie i niezależnie od zarządzania infrastrukturą usługi.

Poniższy przepływ pracy przedstawia przykładowy proces tworzenia i używania obszaru roboczego.

  1. Centralny zespół platformy API, który zarządza wystąpieniem API Management, tworzy obszar roboczy i przypisuje uprawnienia współpracownikom w obszarze roboczym za pomocą ról RBAC. Na przykład przypisz uprawnienia do tworzenia lub odczytywania zasobów w obszarze roboczym. Zespół tworzy bramę API lub przypisuje ją do obszaru roboczego, aby kierować ruchem API.

  2. Centralny zespół platformy API używa narzędzi DevOps do tworzenia ścieżki DevOps dla interfejsów API w tym obszarze roboczym.

  3. Członkowie obszaru roboczego tworzą, publikują, komercjalizują i utrzymują interfejsy API.

  4. Centralny zespół platformy interfejsu API zarządza infrastrukturą usługi, taką jak monitorowanie, odporność i wymuszanie zasad wszystkich interfejsów API.

Brama obszaru roboczego

Każdy obszar roboczy jest skonfigurowany z co najmniej jedną bramą, aby umożliwić uruchamianie interfejsów API zarządzanych w tym obszarze roboczym. W zależności od warstwy usługi i wymagań można użyć domyślnej bramy zarządzanej usługi i/lub co najmniej jednej bramy obszaru roboczego (oddzielne zasoby bramy).

Option Availability Korzyści Considerations
Domyślna brama zarządzana Obecnie w warstwach w wersji 2 Brak dodatkowych kosztów za zasób bramy; dostępność we wszystkich regionach, w których dana warstwa usługi jest dostępna; obszary robocze mogą korzystać z wbudowanych funkcji bramy, które nie są dostępne w bramach obszarów roboczych, takich jak wdrożenia wieloregionowe, niestandardowe nazwy hostów lub łączność za pomocą Private Link, jeśli jest ona obsługiwana w danej warstwie usługi Mniej izolacji; wszystkie obszary robocze współdzielą pojemność i konfigurację bramy
Brama obszaru roboczego Podstawowa wersja 2, Standardowa v2, Premium, Premium v2 Silna izolacja w czasie wykonywania; niezależne skalowanie, nazwa hosta i konfiguracja sieci dla każdej bramy obszaru roboczego Dodatkowy koszt; dłuższy czas wdrażania; obsługa w mniej regionach

Domyślna brama zarządzana

W warstwach v2 można skonfigurować obszar roboczy tak, aby kierował ruch API przez domyślną zarządzaną bramę usługi, a także przez co najmniej jeden oddzielny zasób bramy obszaru roboczego. Gdy obszar roboczy używa domyślnej bramy zarządzanej:

  • Ruch interfejsu API jest kierowany przez domyślną nazwę hosta usługi (na przykład <service-name>.azure-api.net).
  • Obszar roboczy udostępnia pojemność i konfigurację bramy innym obszarom roboczym i interfejsom API na poziomie usługi.

Note

Obecnie obszar roboczy można skojarzyć z domyślną zarządzaną bramą tylko w warstwach usługi v2 i za pomocą interfejsu API REST API Management Workspace - Create or Update.

Brama obszaru roboczego

Brama obszaru roboczego to autonomiczny zasób Azure (workspace gateway Premium) z tą samą podstawową funkcjonalnością co domyślna brama zarządzana.

Bramami obszaru roboczego zarządzasz niezależnie od usługi API Management i niezależnie od siebie nawzajem. Umożliwiają one izolację środowiska uruchomieniowego między obszarami roboczymi lub przypadkami użycia, co zwiększa niezawodność interfejsu API, odporność i zabezpieczenia. Umożliwiają one również przypisywanie problemów ze środowiskiem uruchomieniowym do obszarów roboczych.

Kojarzenie obszarów roboczych z bramą obszaru roboczego

W zależności od potrzeb organizacji można skojarzyć jeden obszar roboczy lub wiele obszarów roboczych z bramą obszaru roboczego.

Note

Kojarzenie wielu obszarów roboczych z bramą obszaru roboczego jest dostępne tylko dla bram obszarów roboczych utworzonych po 15 kwietnia 2025 r.

  • Brama obszaru roboczego ma pewne ustawienia konfiguracji, takie jak sieć wirtualna, skala i nazwa hosta oraz przydzielone zasoby obliczeniowe, w tym zasoby procesora, pamięci i sieci.
  • Wszystkie obszary robocze wdrożone na bramie współdzielą konfigurację i zasoby obliczeniowe.
  • Usterki w interfejsie API lub nietypowym ruchu mogą powodować wyczerpanie tych zasobów, co wpływa na wszystkie obszary robocze w tej bramie. Innymi słowy, im więcej obszarów roboczych wdrażasz w bramie, tym większe jest ryzyko, że interfejs API z jednego obszaru roboczego napotyka problemy z niezawodnością spowodowane przez interfejs API z innego obszaru roboczego.
  • Monitoruj wydajność bramy obszaru roboczego, korzystając z wbudowanych metryk użycia procesora i pamięci.

Podczas wybierania modelu wdrażania dla obszarów roboczych należy wziąć pod uwagę niezawodność, zabezpieczenia i koszty.

  • Przypisz obszar roboczy do własnej dedykowanej bramy obszaru roboczego dla obciążeń o krytycznym znaczeniu — aby zmaksymalizować niezawodność i bezpieczeństwo interfejsu API, przypisz każdy obszar roboczy o krytycznym znaczeniu do własnej bramy, unikając współużytkowania z innymi obszarami roboczymi.
  • Równoważenie niezawodności, zabezpieczeń i kosztów — kojarzenie wielu obszarów roboczych z bramą obszaru roboczego (lub, jeśli ma to zastosowanie, domyślną bramą zarządzaną), aby zrównoważyć niezawodność, bezpieczeństwo i koszty obciążeń niekrytycznych. Rozmieść obszary robocze między co najmniej dwie bramy, aby zapobiec temu, by problemy, takie jak wyczerpanie zasobów lub błędy konfiguracji, wpływały na wszystkie interfejsy API w organizacji.
  • Używaj osobnych bram dla różnych zastosowań — grupuj obszary robocze w ramach bramy obszaru roboczego według zastosowania lub wymagań sieciowych. Na przykład można odróżnić wewnętrzne i zewnętrzne interfejsy API, przypisując je do oddzielnych bram, z których każda ma własną konfigurację sieci.
  • Przygotywanie do kwarantanny obszarów roboczych — użyj serwera proxy, takiego jak Azure Application Gateway lub Azure Front Door, przed udostępnionymi bramami obszarów roboczych, aby uprościć przenoszenie obszaru roboczego powodującego wyczerpanie zasobów do innej bramy. Takie podejście zapobiega wpływowi na inne obszary robocze współużytkujące bramę.

Note

  • Brama obszaru roboczego musi znajdować się w tym samym regionie co podstawowy region Azure wystąpienia usługi API Management i w tej samej subskrypcji.
  • Wszystkie obszary robocze skojarzone z bramą obszaru roboczego muszą znajdować się w tym samym wystąpieniu usługi API Management.
  • Z bramą obszaru roboczego można skojarzyć maksymalnie 30 obszarów roboczych. Skontaktuj się z pomocą techniczną, aby zwiększyć ten limit.

Nazwa hosta bramy obszaru roboczego

Każda brama obszaru roboczego zapewnia unikalną nazwę hosta dla API zarządzanych w skojarzonym obszarze roboczym. Domyślne nazwy hostów są zgodne ze wzorcem <gateway-name>-<hash>.gateway.<region>.azure-api.net. Użyj nazwy hosta bramy, aby kierować żądania do interfejsów API twojego obszaru roboczego.

Obecnie bramy obszarów roboczych nie obsługują niestandardowych nazw hostów. Usługę Azure Application Gateway lub Azure Front Door można skonfigurować przed bramą obszaru roboczego, korzystając z niestandardowej nazwy hosta.

Izolacja sieci dla bram obszarów pracy

Opcjonalnie można skonfigurować zasób bramy środowiska roboczego w prywatnej sieci wirtualnej w celu odizolowania ruchu przychodzącego i wychodzącego. W przypadku skonfigurowania tej izolacji brama obszaru roboczego musi używać dedykowanej podsieci w sieci wirtualnej.

Aby uzyskać szczegółowe wymagania, zobacz Wymagania dotyczące zasobów sieciowych dla bram obszarów roboczych.

Note

  • Konfiguracja sieci bramy obszaru roboczego jest niezależna od konfiguracji sieci instancji zarządzania API.
  • Obecnie brama obszaru roboczego można skonfigurować tylko w sieci wirtualnej po utworzeniu bramy. Nie można później zmienić konfiguracji sieci lub ustawień bramy.

Skalowanie wydajności bram obszarów roboczych

Zarządzaj pojemnością bramy obszaru roboczego, dodając lub usuwając jednostki skalowania, podobnie jak jednostki, które można dodać do wystąpienia API Management w niektórych warstwach usługi. Koszty bramy dostępu do przestrzeni roboczej są oparte na wybranej liczbie jednostek.

Regionalna dostępność bram obszarów roboczych

Aby uzyskać bieżącą listę regionów, w których dostępne są bramy przestrzeni roboczych, zobacz Dostępność warstw wersji 2 oraz bram przestrzeni roboczych.

Ograniczenia obszaru roboczego i bramy obszaru roboczego

Ograniczenia obszarów roboczych

  • Nie można skojarzyć obszaru roboczego z bramą hostowaną samodzielnie
  • Interfejsy API w obszarach roboczych nie są objęte usługą Defender dla interfejsów API
  • Obszary robocze nie obsługują menedżera poświadczeń
  • Obszary robocze obsługują tylko wewnętrzną pamięć podręczną; zewnętrzna pamięć podręczna nie jest obsługiwana
  • Obszary robocze nie obsługują syntetycznych interfejsów API graphQL
  • Obszary robocze nie umożliwiają tworzenia interfejsów API bezpośrednio z zasobów platformy Azure, takich jak Azure OpenAI Service, App Service, Function Apps i tak dalej, w witrynie Azure Portal
  • Obszary robocze nie obsługują serwerów MCP
  • Nie można podzielić metryk żądań według obszaru roboczego w usłudze Azure Monitor; wszystkie metryki obszaru roboczego są agregowane na poziomie usługi
  • Obszary robocze nie obsługują certyfikatów CA
  • Obszary robocze nie obsługują tożsamości zarządzanych, w tym powiązanych funkcji, takich jak przechowywanie wpisów tajnych w usłudze Azure Key Vault i korzystanie z zasad authentication-managed-identity

Ograniczenia bramy obszaru roboczego

Następujące ograniczenia dotyczą zasobu zarządzanej bramy obszaru roboczego. Nie mają zastosowania podczas korzystania z obszarów roboczych w domyślnej bramie zarządzanej usługi.

  • Bramy obszarów roboczych nie obsługują przychodzących prywatnych punktów końcowych
  • Bramy obszarów roboczych nie obsługują niestandardowych nazw hostów
  • Obszary robocze mogą być skojarzone tylko z bramami obszaru roboczego znajdującymi się w tym samym regionie i subskrypcji co zasób usługi API Management

Dziedziczenie polityk globalnych w bramach przestrzeni roboczych

Bramki obszarów roboczych realizują cały łańcuch polityk, w tym globalną politykę na poziomie usługi (global.policy.xml). To zachowanie oznacza, że wszystkie zasady zdefiniowane w zakresie globalnym są oceniane i wykonywane dla wywołań interfejsu API przetwarzanych przez bramy obszaru roboczego, tak jak dla bramy domyślnej. Takie zachowanie jest zamierzone i zgodne z modelem oceny zasad w usłudze API Management, w którym zasady stosuje się hierarchicznie w następujących zakresach: globalnym (usługa) > obszaru roboczego > produktu > interfejsu API > operacji.

Zalecenia dotyczące zasad globalnych z bramami obszarów roboczych

  • Przejrzyj zasady globalne, aby upewnić się, że zawiera ona tylko zasady przeznaczone do zastosowania we wszystkich bramach, w tym bram obszaru roboczego.

  • Jeśli potrzebujesz innego zachowania dla każdej bramy, użyj zasady choose z elementem context.Deployment.Gateway.Id, aby warunkowo wykonywać zasady w zależności od tego, która brama przetwarza żądanie.

  • Jeśli zdefiniujesz tożsamość zarządzaną uwierzytelnianiem w zakresie globalnym, ale token nie powinien być dostępny dla interfejsów API o zakresie obszaru roboczego, przenieś zasady do węższego zakresu (na przykład poziomu produktu lub interfejsu API), a nie do zasad globalnych.

Role RBAC dla obszarów roboczych

Kontrola dostępu oparta na rolach w Azure służy do konfiguracji uprawnień współpracowników obszaru roboczego, umożliwiając im odczytywanie i edytowanie jednostek w tym obszarze. Aby uzyskać listę ról, zobacz How to use role-based access control in API Management (Jak używać kontroli dostępu opartej na rolach w usłudze API Management).

Aby zarządzać interfejsami API i innymi zasobami w obszarze roboczym, przypisz członkom obszaru roboczego role (lub równoważne uprawnienia przy użyciu ról niestandardowych) obejmujące usługę API Management i obszar roboczy. Rola o zakresie usługi umożliwia odwoływanie się do niektórych zasobów na poziomie usługi z zasobów na poziomie obszaru roboczego. Na przykład organizuj użytkownika w grupie na poziomie obszaru roboczego, aby kontrolować interfejs API i widoczność produktu.

Jeśli obszar roboczy korzysta z dedykowanej bramy obszaru roboczego, członkom zarządzającym tą bramą należy również przypisać rolę ograniczoną do zasobu bramy obszaru roboczego.

Note

Aby ułatwić zarządzanie, skonfiguruj grupy entra firmy Microsoft w celu przypisania uprawnień obszaru roboczego do wielu użytkowników.

Obszary robocze i inne funkcje usługi API Management

Obszary robocze są odizolowane, aby maksymalnie rozdzielić dostęp administracyjny i środowisko uruchomieniowe API. Aby zapewnić większą produktywność i umożliwić zarządzanie na całej platformie, obserwowanie, możliwość ponownego obsługi i odnajdywanie interfejsów API, istnieje kilka wyjątków.

  • Odwołania do zasobów — zasoby w obszarze roboczym mogą odwoływać się do innych zasobów w obszarze roboczym i wybranych zasobów z poziomu usługi, takich jak użytkownicy, serwery autoryzacji lub wbudowane grupy użytkowników. Nie mogą odwoływać się do zasobów z innego obszaru roboczego.

    Ze względów bezpieczeństwa nie można odwoływać się do zasobów na poziomie usługi z zasad na poziomie obszaru roboczego (na przykład nazwanych wartości) ani nazw zasobów, takich jak backend-idw zasadach set-backend-service .

    Important

    Wszystkie zasoby w usłudze API Management (na przykład interfejsy API, produkty, tagi lub subskrypcje) muszą mieć unikatowe nazwy, nawet jeśli znajdują się w różnych obszarach roboczych. Nie można mieć zasobów tego samego typu i o tej samej nazwie zasobu Azure w tym samym obszarze roboczym, w innych obszarach roboczych lub na poziomie usługi.

  • Portal dla deweloperów — przestrzenie robocze są koncepcją administracyjną i nie są widoczne dla użytkowników portalu deweloperów, w tym za pośrednictwem interfejsu użytkownika portalu deweloperów i podstawowego interfejsu API. Możesz publikować interfejsy API i produkty w obszarze roboczym do portalu deweloperskiego, podobnie jak interfejsy API i produkty na poziomie usługi.

    Note

    Usługa API Management obsługuje przypisywanie serwerów autoryzacji zdefiniowanych na poziomie usługi do interfejsów API w obszarach roboczych.

Migrowanie z obszarów roboczych w wersji zapoznawczej

Jeśli utworzono obszary robocze w wersji zapoznawczej w usłudze Azure API Management i chcesz nadal z nich korzystać, przeprowadź migrację obszarów roboczych do ogólnie dostępnej wersji, kojarząc bramę obszaru roboczego z każdym obszarem roboczym.

Aby uzyskać szczegółowe informacje i poznać inne zmiany, które mogą wpłynąć na obszary robocze wersji zapoznawczej, zobacz Zmiany krytyczne dla obszarów roboczych (marzec 2025 r.).

Usuwanie obszaru roboczego

Usunięcie obszaru roboczego przy użyciu interfejsu portalu Azure powoduje również usunięcie wszystkich zasobów podrzędnych (interfejsów API, produktów itd.) oraz dedykowanej bramy obszaru roboczego, jeśli jest skojarzona. Nie usuwa wystąpienia usługi API Management ani innych obszarów roboczych.

Treści powiązane

  • Last updated on