Udostępnij za pośrednictwem

Federacyjne zarządzanie interfejsami API z obszarami roboczymi

DOTYCZY: Premium

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 co najmniej jedną bramą obszaru roboczego, która kieruje ruch interfejsów API do usług zaplecza w tym obszarze.
  • Zespół platformy może stosować zasady interfejsu API obejmujące interfejsy API w obszarach roboczych i 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.

Uwaga

  • Najnowsze funkcje obszaru roboczego są obsługiwane w interfejsie API REST usługi API Management w wersji 2023-09-01-preview lub nowszej.
  • 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 usługi Azure API Management, może mieć wiele zespołów programistycznych, które tworzą, definiują, konserwują i tworzą różne zestawy interfejsów API. Obszary robocze umożliwiają tym zespołom używanie usługi API Management do oddzielnego zarządzania interfejsami API, uzyskiwania do nich dostępu i zabezpieczania ich oraz niezależnie od zarządzania infrastrukturą usługi.

Poniżej przedstawiono przykładowy przepływ pracy do tworzenia i używania obszaru roboczego.

  1. Centralny zespół platformy interfejsu API, który zarządza wystąpieniem usługi API Management, tworzy obszar roboczy i przypisuje uprawnienia współpracownikom obszaru roboczego przy użyciu ról RBAC — na przykład uprawnienia do tworzenia lub odczytywania zasobów w obszarze roboczym. Brama interfejsu API o zakresie obszaru roboczego jest również tworzona dla obszaru roboczego.

  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ą obszaru roboczego, aby umożliwić działanie interfejsów API zarządzanych w obszarze roboczym. Brama obszaru roboczego to autonomiczny zasób platformy Azure (brama obszaru roboczego w warstwie Premium) z taką samą podstawową funkcjonalnością, jak brama wbudowana w usługę API Management.

Bramy obszarów roboczych są zarządzane niezależnie od usługi API Management i od siebie. Umożliwiają one izolację środowiska uruchomieniowego między obszarami roboczymi lub przypadkami użycia, zwiększenie niezawodności interfejsu API, odporności i zabezpieczeń oraz umożliwienie przypisywania 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.

Uwaga

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 posiada określoną konfigurację (taką jak sieć wirtualna, skala, nazwa hosta) oraz przydzielone zasoby obliczeniowe (CPU, pamięć, zasoby sieciowe).
  • Zasoby konfiguracji i przetwarzania są współużytkowane przez wszystkie obszary robocze wdrożone w bramie.
  • Usterki w interfejsie API lub nietypowym ruchu mogą powodować wyczerpanie tych zasobów, wpływając na wszystkie obszary robocze w tej bramie. Innymi słowy, im więcej obszarów roboczych jest umieszczanych na bramie, tym większe jest ryzyko, że interfejs API z jednego obszaru roboczego doświadczy problemów z niezawodnością spowodowanych przez interfejs API z innego obszaru roboczego.
  • Monitoruj wydajność bramy przy użyciu wbudowanych metryk do monitorowania wykorzystania procesora i pamięci.

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

  • Użyj dedykowanych bram 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ą w celu zrównoważenia niezawodności, zabezpieczeń i kosztów obciążeń niekrytycznych. Dystrybucja obszarów roboczych na co najmniej dwóch bramach pomaga zapobiegać problemom, takim jak wyczerpanie zasobów czy błędy konfiguracji, które mogłyby wpłynąć na wszystkie interfejsy API w organizacji.
  • Użyj odrębnych bram dla różnych przypadków użycia — grupuj obszary robocze na bramie w oparciu o przypadek użycia lub wymagania dotyczące sieci. 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.
  • Przygotowanie do kwarantanny obszarów roboczych z problemami — użyj serwera proxy, takiego jak usługa Azure Application Gateway lub usługa Azure Front Door, przed udostępnionymi bramami obszarów roboczych, aby uprościć przenoszenie obszaru roboczego, który powoduje wyczerpanie zasobów do innej bramy, uniemożliwiając wpływ na inne obszary robocze współużytkujące bramę.

Uwaga

  • Brama dostępu obszaru roboczego musi znajdować się w tym samym regionie co główny region usługi Azure instancji API Management oraz w tej samej subskrypcji.
  • Wszystkie obszary robocze skojarzone z bramą obszaru roboczego muszą znajdować się w tym samym wystąpieniu usługi API Management
  • Brama obszaru roboczego może być skojarzona z maksymalnie 30 obszarami roboczymi (skontaktuj się z pomocą techniczną, aby zwiększyć ten limit)

Nazwa hosta bramy

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 niestandardowe nazwy hostów nie są obsługiwane w przypadku bram obszarów roboczych. Usługę Azure Application Gateway lub Azure Front Door można skonfigurować przed bramą obszaru roboczego, korzystając z niestandardowej nazwy hosta.

Izolacja sieciowa

Bramę obszaru roboczego można opcjonalnie skonfigurować w prywatnej sieci wirtualnej w celu odizolowania ruchu przychodzącego i/lub wychodzącego. Jeśli jest skonfigurowana, brama dla przestrzeni roboczej 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.

Uwaga

  • 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 pojemności

Zarządzaj pojemnością bramy poprzez dodawanie lub usuwanie jednostek skali, podobnie jak jednostki, które można dodać do instancji API Management w pewnych poziomach usług. Koszty bramy dostępu do przestrzeni roboczej są oparte na wybranej liczbie jednostek.

Dostępność w regionach

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 bramy

Następujące ograniczenia dotyczą obecnie bram obszarów roboczych:

  • Nie można skojarzyć obszaru roboczego z bramą hostowaną samodzielnie
  • Bramy obszarów roboczych nie obsługują przychodzących prywatnych punktów końcowych
  • Interfejsy API w bramach obszarów roboczych nie mogą mieć przypisanych niestandardowych nazw hostów
  • Interfejsy API w obszarach roboczych nie są objęte usługą Defender dla interfejsów API
  • Bramy obszarów roboczych nie obsługują menedżera poświadczeń usługi API Management
  • Bramy obszarów roboczych obsługują tylko wewnętrzną pamięć podręczną; zewnętrzna pamięć podręczna nie jest obsługiwana
  • Bramy obszarów roboczych nie obsługują syntetycznych interfejsów API GraphQL
  • Bramy obszarów roboczych nie obsługują tworzenia interfejsów API bezpośrednio z zasobów platformy Azure, takich jak Usługa Azure OpenAI Service, App Service, Aplikacje funkcji itd.
  • 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
  • Bramki obszarów roboczych nie obsługują certyfikatów CA
  • Bramy obszarów roboczych nie obsługują tożsamości zarządzanych, w tym powiązanych funkcji, takich jak przechowywanie sekretów w usłudze Azure Key Vault i używanie authentication-managed-identity polityki
  • Bramy obszarów roboczych można tworzyć tylko w podstawowym regionie Azure wystąpienia usługi API Management.

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, członkowie obszaru roboczego muszą mieć przypisane role (lub równoważne uprawnienia przy użyciu ról niestandardowych) obejmujące usługę API Management, obszar roboczy i bramę obszaru roboczego. 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.

Uwaga

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 zaprojektowano tak, aby maksymalizować samodzielność i segregację dostępu administracyjnego oraz środowiska uruchomieniowego API. Istnieje kilka wyjątków zapewniających większą produktywność oraz umożliwiających zapewnienie ładu na poziomie całej platformy, obserwowalność, ponowne wykorzystanie i odkrywanie interfejsów API.

  • 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) lub według nazw zasobów, takich jak backend-idw zasadach set-backend-service .

    Ważne

    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ć żadnych zasobów tego samego typu i o tej samej nazwie zasobu platformy 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. Interfejsy API i produkty w obszarze roboczym można publikować w portalu deweloperów, podobnie jak interfejsy API i produkty na poziomie usługi.

    Uwaga

    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 spowoduje usunięcie wszystkich zasobów podrzędnych (interfejsów API, produktów itd.) oraz powiązanej bramy, jeśli usuniesz obszar roboczy przy użyciu interfejsu Azure Portal. Nie usuwa wystąpienia usługi API Management ani innych obszarów roboczych.

Powiązana zawartość