Zastosowanie Azure API Management w rozwiązaniu wielodostępnym

Azure API Management to kompleksowa brama API i reverse proxy dla interfejsów API. Udostępnia wiele funkcji, które są przydatne w przypadku aplikacji skoncentrowanych na interfejsie API, w tym buforowania, pozorowania odpowiedzi i portalu dla deweloperów. Ten artykuł zawiera podsumowanie niektórych kluczowych funkcji usługi API Management, które są przydatne w przypadku rozwiązań wielodostępnych.

Uwaga

Ten artykuł koncentruje się na tym, jak można używać usługi API Management, gdy masz własne aplikacje wielodostępne hostujące interfejsy API do użytku wewnętrznego lub zewnętrznego.

Inną formą wielodostępności jest udostępnianie bramy zarządzania API jako usługi dla innych zespołów. Na przykład organizacja może mieć udostępnione wystąpienie usługi API Management, które może być wdrażane i używane przez wiele zespołów aplikacji. W tym artykule nie omówiono tej formy wielodostępności. Rozważ użycie obszarów roboczych, które pomagają udostępniać wystąpienie usługi API Management w wielu zespołach z różnymi poziomami dostępu.

Modele izolacji

Usługa API Management jest zazwyczaj wdrażana jako wspólny komponent z pojedynczym wystąpieniem, które obsługuje żądania wielu dzierżawców. Jednak w oparciu o Twój model najmu istnieje wiele sposobów wdrażania zarządzania API. W tym artykule założono, że rozwiązanie jest wdrażane przy użyciu znaczników wdrażania.

Zazwyczaj sposób, w jaki usługa API Management jest używana, pozostaje spójna w różnych modelach izolacji. Ta sekcja koncentruje się na różnicach w kosztach i złożoności między modelami izolacji a sposobem, w jaki każde podejście kieruje żądania do aplikacji interfejsu API zaplecza.

Kwestie wymagające rozważenia Współdzielona instancja z backendami single-tenant Współdzielona instancja ze współdzielonym wielodzierżawnym backendem Instancja dla każdego najemcy
Liczba obsługiwanych najemców Dużo Prawie nieograniczony Jeden na każde wystąpienie
Koszt Niższy Niższy Wyższa
Złożoność wdrożenia Niski. Pojedyncza instancja do zarządzania każdą pieczęcią. Niski. Pojedyncza instancja do zarządzania każdą pieczęcią. Wysoki. Zarządzanie wieloma wystąpieniami.
Złożoność konfiguracji routingu Wyższa Niższy Niższy
Podatność na problemy z hałaśliwym sąsiadem Tak Tak Nie.
Izolacja sieci na poziomie dzierżawy Nie. Nie. Tak
Przykładowy scenariusz Spersonalizowane nazwy domen dla każdego najemcy Rozwiązanie wielodostępne na dużą skalę z współdzieloną warstwą aplikacji Znaczniki wdrożenia dedykowane dla lokatora

Modele izolacji dzielonego wystąpienia

Zwykle udostępnia się instancję usługi API Management między wieloma dzierżawami, co pomaga zmniejszyć koszty oraz złożoność wdrażania i zarządzania. Szczegóły sposobu udostępniania wystąpienia usługi API Management zależą od sposobu przypisywania dzierżawców do aplikacji interfejsu API zaplecza.

Jednodzierżawna aplikacja backendowa

W przypadku wdrażania odrębnych aplikacji backendowych dla każdego dzierżawcy można wdrożyć pojedyncze wystąpienie usługi API Management i kierować ruch do prawidłowego zaplecza dzierżawcy dla każdego żądania. Takie podejście wymaga skonfigurowania usługi API Management przy użyciu nazw hostów zaplecza dla każdego dzierżawcy lub innego sposobu mapowania żądania przychodzącego na zaplecze odpowiedniego dzierżawcy.

Ponieważ wymaga to dodatkowego odpytania, takie podejście może się nie skalować do dużej liczby najemców, którzy współużytkują pojedyncze wystąpienie usługi API Management. Podczas wyszukiwania backendu dzierżawcy może również wystąpić pewne obciążenie związane z wydajnością. Jednak rozmiar tego obciążenia związanego z wydajnością zależy od sposobu projektowania tego wyszukiwania.

Udostępniona wielodzierżawna aplikacja zaplecza

W scenariuszach, w których dzierżawcy współdzielą wspólną aplikację zaplecza, proces routingu usługi API Management jest uproszczony, ponieważ można kierować wszystkie żądania do pojedynczego zaplecza. Jeśli używasz domen wieloznacznych (wildcard) lub domen przydzielonych przez dostawcę, możesz uniknąć konfiguracji routingu bramy dla każdej dzierżawy. Ponadto, ponieważ żądania nie muszą być mapowane na backend dzierżawcy, dostosowane decyzje dotyczące routingu nie wpływają na wydajność.

Instancja dla każdego najemcy

W niektórych scenariuszach można zainstalować i uruchomić usługę zarządzania API dla każdej dzierżawy. Zalecamy takie podejście tylko wtedy, gdy masz kilka dzierżaw lub jeśli masz ścisłe wymagania dotyczące zgodności, które ograniczają udostępnianie dowolnej infrastruktury między dzierżawami. Na przykład, jeśli wdrożysz dedykowaną sieć wirtualną dla każdej dzierżawy, prawdopodobnie musisz również wdrożyć dedykowane wystąpienie usługi zarządzania API dla każdej dzierżawy.

Napiwek

Jeśli jedynym powodem wdrażania wielu wystąpień jest obsługa użytkowników w różnych regionach geograficznych, warto rozważyć, czy funkcja wdrażania wieloregionalnego w usłudze API Management spełnia Twoje wymagania.

Podczas wdrażania wystąpienia usługi API Management należy wziąć pod uwagę limity usługi, w tym wszelkie limity, które mogą dotyczyć liczby wystąpień usługi API Management w ramach danej subskrypcji lub regionu Azure.

Instancje jednodzierżawcze zwykle mają minimalną konfigurację routingu, ponieważ można kierować wszystkie żądania do jednego serwera. Ten scenariusz nie wymaga niestandardowych decyzji dotyczących routingu, więc nie ma dodatkowego wpływu na wydajność. Jednak zazwyczaj wiąże się to z wyższym kosztem zasobów niż w przypadku wdrożenia wystąpienia udostępnionego. Jeśli musisz wdrożyć instancje jednokrotnego wynajmu, rozważ, czy bramy samodzielnie hostowane umożliwiają ponowne użycie zasobów obliczeniowych specyficznych dla dzierżawy, które już wdrożyłeś.

Funkcje usługi API Management, które obsługują wielodostępność

API Management używa zasad, aby umożliwić elastyczność. Możesz dostosować sposób weryfikowania, kierowania i przetwarzania żądań podczas korzystania z zasad. Podczas projektowania wielodostępnego rozwiązania za pomocą usługi API Management można użyć zasad w celu zaimplementowania wielu jego możliwości.

Identyfikowanie najemców w żądaniach przychodzących

Zastanów się, jak można zidentyfikować odpowiedniego najemcę w każdym przychodzącym żądaniu. W rozwiązaniu wielodostępnym ważne jest, aby jasno wiedzieć, kto wysyła każde żądanie, aby zwracać dane dla tego konkretnego najemcy i nikt inny.

Usługa API Management udostępnia subskrypcje, których można użyć do uwierzytelniania żądań. Te subskrypcje używają unikatowego klucza subskrypcji, który pomaga zidentyfikować subskrybenta, który wysyła żądanie. Jeśli zdecydujesz się używać subskrypcji, rozważ sposób mapowania subskrypcji usługi API Management na własną dzierżawę lub identyfikatory klientów. Subskrypcje są ściśle zintegrowane z portalem deweloperów. W przypadku większości rozwiązań dobrą praktyką jest użycie subskrypcji do identyfikowania dzierżawców.

Alternatywnie można zidentyfikować najemcę przy użyciu innych metod. Poniższe przykłady podejść działają w ramach niestandardowej polityki, którą definiujesz:

  • Użyj niestandardowego składnika adresu URL, takiego jak poddomena, ścieżka lub ciąg zapytania. Na przykład w adresie URL https://api.contoso.com/tenant1/productsmożesz wyodrębnić pierwszą część ścieżki tenant1i traktować ją jako identyfikator dzierżawy. Podobnie, biorąc pod uwagę przychodzący adres URL https://tenant1.contoso.com/products, możesz wyodrębnić poddomenę , tenant1. Aby użyć tego podejścia, rozważ przeanalizowanie ścieżki lub ciągu zapytania z Context.Request.Url właściwości.

  • Użyj nagłówka żądania. Na przykład aplikacje klienckie mogą dodawać niestandardowy TenantID nagłówek do żądań. Aby użyć tego podejścia, rozważ przeczytanie z kolekcji Context.Request.Headers .

  • Wyodrębnianie oświadczeń z tokenu internetowego JSON (JWT). Na przykład, możesz mieć niestandardowe roszczenie tenantId w zestawie JWT, które wydaje twój dostawca tożsamości. Aby użyć tej metody, użyj zasad validate-jwt i ustaw output-token-variable-name właściwość , aby definicja zasad mogła odczytywać wartości z tokenu.

  • Dynamiczne wyszukiwanie identyfikatorów najemców. Podczas przetwarzania żądania można komunikować się z zewnętrzną bazą danych lub usługą. Korzystając z tego podejścia, można utworzyć niestandardową logikę mapowania dzierżawy, aby zamapować identyfikator dzierżawy logicznej na określony adres URL lub uzyskać więcej informacji o dzierżawie. Aby zastosować to podejście, użyj zasad wysyłania żądań .

    Takie podejście może zwiększyć opóźnienie żądań. Aby wyeliminować ten efekt, warto użyć buforowania w celu zmniejszenia liczby wywołań do zewnętrznego interfejsu API. Aby zaimplementować podejście buforowania, można użyć zasad cache-store-value i cache-lookup-value . Pamiętaj, aby unieważnić pamięć podręczną przy użyciu każdego dodanego, usuniętego lub przeniesionego tenantu, który ma wpływ na wyszukiwanie w systemie backendowym.

Ważne

Traktuj identyfikatory dzierżawy w adresach URL, nazwach hostów, ciągach zapytania i nagłówkach żądań jako niezaufanych wskazówek routingu. Uwierzytelnij obiekt wywołujący i sprawdź, czy obiekt wywołujący jest upoważniony do uzyskania dostępu do ustalonego dzierżawcy przed skierowaniem żądania lub uzyskaniem dostępu do danych dzierżawcy. W miarę możliwości preferuj oświadczenie dzierżawcy ze zweryfikowanego tokenu. Jeśli zaufana usługa brzegowa dostarcza identyfikator dzierżawy w nagłówku, usuń lub zastąp dowolną wartość podaną przez klienta na krawędzi.

Nazwane wartości

Usługa API Management obsługuje nazwane wartości, które są niestandardowymi ustawieniami konfiguracji, których można używać w ramach zasad. Możesz na przykład użyć nazwanej wartości do przechowywania adresu URL zaplecza dzierżawcy, a następnie ponownie użyć tej samej wartości w kilku miejscach w zasadach. Jeśli musisz zaktualizować adres URL, możesz zaktualizować go w jednym miejscu.

Ostrzeżenie

W rozwiązaniu wielodostępnym należy zachować ostrożność podczas nadawania nazw wartościom. Jeśli ustawienia różnią się między tenantami, pamiętaj, aby uwzględnić identyfikator tenant w nazwie. Na przykład można użyć wzorca, takiego jak tenantId-key:value po potwierdzeniu, że tenantId jest odpowiednie dla żądania.

Włącz identyfikator, aby zmniejszyć ryzyko przypadkowego odwołania się do albo manipulowania wartością innego najemcy podczas przetwarzania żądania dla tego najemcy.

Uwierzytelniaj i autoryzuj żądania przychodzące

Żądania interfejsu API wysyłane do bramy usługi API Management zwykle wymagają uwierzytelniania i autoryzacji. Usługa API Management może weryfikować tokeny dostępu protokołu OAuth 2.0 i certyfikaty klienta. Protokół OAuth 2.0 zapewnia autoryzację. Jeśli musisz uwierzytelnić użytkowników, użyj protokołu uwierzytelniania, takiego jak OpenID Connect. Zastanów się, które poświadczenia są obsługiwane i czy są weryfikowane w usłudze API Management, w aplikacjach zaplecza, czy w obu miejscach.

Aby uzyskać więcej informacji, zobacz Uwierzytelnianie i autoryzacja do interfejsów API w usłudze API Management.

Uwaga

Jeśli używasz klucza subskrypcji lub klucza interfejsu API, dobrym rozwiązaniem jest również użycie innej metody uwierzytelniania.

Sam klucz subskrypcji nie jest silną formą uwierzytelniania. Jednak jest to przydatne w przypadku innych scenariuszy, takich jak śledzenie użycia interfejsu API poszczególnych dzierżawców.

Kierowanie do zapleczy specyficznych dla dzierżawcy

W przypadku używania usługi API Management jako składnika udostępnionego może być konieczne kierowanie przychodzących żądań interfejsu API do różnych zapleczy specyficznych dla dzierżawy. Te zaplecza mogą znajdować się w różnych stemplach wdrożenia lub mogą być różnymi aplikacjami w ramach pojedynczego stempla. Aby dostosować routing w definicji polisy, użyj zasady set-backend-service. Należy określić nowy podstawowy adres URL, do którego ma zostać przekierowane żądanie.

Buforowanie odpowiedzi lub innych danych

Usługa API Management ma zaawansowaną funkcję pamięci podręcznej, której można użyć do buforowania całych odpowiedzi HTTP lub innych danych. Możesz na przykład użyć pamięci podręcznej dla mapowań najemców, jeśli stosujesz logikę niestandardową lub jeśli wyszukujesz mapowanie z usługi zewnętrznej.

Użyj zasad cache-store-value i cache-lookup-value, aby zaimplementować podejście do buforowania.

Ostrzeżenie

W rozwiązaniu wielodostępnym należy zachować ostrożność podczas ustawiania kluczy pamięci podręcznej. Jeśli buforowane dane mogą się różnić w zależności od dzierżawy, upewnij się, że uwzględniono identyfikator dzierżawy w kluczu pamięci podręcznej.

Włącz identyfikator, aby zmniejszyć ryzyko przypadkowego odwołania się do albo manipulowania wartością innego najemcy podczas przetwarzania żądania dla tego najemcy.

Interfejsy API dużych modeli językowych

Użyj funkcji bramy AI w API Management, gdy interfejsy API wywołują duże modele językowe. Te funkcje pomagają kontrolować koszty, wydajność i izolację w rozwiązaniach wielodostępnych.

Buforowanie semantyczne

Jeśli interfejsy API znajdują się przed obsługiwanymi interfejsami API dużych modeli językowych, rozważ użycie buforowania semantycznego w usłudze API Management w celu zmniejszenia kosztów i opóźnień w przypadku powtarzających się lub niemal zduplikowanych monitów.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

Pamięć podręczną należy podzielić na dzierżawę przy użyciu vary-by elementu , aby monity i odpowiedzi były odizolowane od dzierżawy, dla której są przeznaczone. Umieść politykę lookup w przetwarzaniu przychodzącym i politykę store w przetwarzaniu wychodzącym.

Ważne

Buforowanie semantyczne używa podobieństwa, a nie dokładnego dopasowania. Odczyt z pamięci podręcznej może zwrócić odpowiedź, która jest niepoprawna, nieaktualna lub niebezpieczna dla bieżącego żądania. Oceń buforowanie semantyczne dla swojego obciążenia, dostrój próg podobieństwa i zastosuj mechanizmy kontroli bezpieczeństwa zawartości oraz walidacji, jeśli jest to konieczne.

W poniższym przykładzie pokazano, jak wpisy semantycznej pamięci podręcznej są partycjonowane według identyfikatora subskrypcji lub klucza:

<!-- inbound -->
<llm-semantic-cache-lookup
   score-threshold="0.05"
   embeddings-backend-id="embeddings-backend"
   embeddings-backend-auth="system-assigned">
   <vary-by>@(context.Subscription.Id)</vary-by>
   <!-- or: <vary-by>@(context.Subscription.Key)</vary-by> -->
</llm-semantic-cache-lookup>

<!-- outbound -->
<llm-semantic-cache-store duration="60" />

Poniższy przykład partycjonuje semantyczną pamięć podręczną według roszczenia najemcy lub nagłówka.

<!-- inbound; requires validate-jwt if using a claim -->
<llm-semantic-cache-lookup
   score-threshold="0.05"
   embeddings-backend-id="embeddings-backend"
   embeddings-backend-auth="system-assigned">
   <vary-by>@(context.Principal?.Claims.GetValueOrDefault("tenantId", ""))</vary-by>
   <!-- Alternative using a custom header: -->
   <!-- <vary-by>@(context.Request.Headers.GetValueOrDefault("TenantID", ""))</vary-by> -->
</llm-semantic-cache-lookup>

<!-- outbound -->
<llm-semantic-cache-store duration="60" />

Limity oparte na tokenach dla dużych modeli językowych

Użyj zasad llm-token-limit w bramie sztucznej inteligencji, aby ograniczyć użycie dla każdego dzierżawcy, nie tylko dla poszczególnych żądań. Zasada obsługuje Azure OpenAI i inne obsługiwane interfejsy API dużych modeli językowych. Aby uzyskać więcej informacji, zobacz Zasady limitu tokenów.

Wybierz klucz unikatowy dla dzierżawy, taki jak identyfikator subskrypcji lub oświadczenie tokenu identyfikatora dzierżawy, aby upewnić się, że limity skutecznie izoluje każdą dzierżawę. Użycie tokenu jest śledzone niezależnie w każdej bramie, regionie lub obszarze roboczym, a liczniki nie są agregowane w całym wystąpieniu.

Poniższy przykład ogranicza każdego najemcę do 60 000 tokenów każdej minuty na podstawie subskrypcji.

<llm-token-limit
   counter-key="@(context.Subscription.Id)"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

W poniższym przykładzie limitowanie odbywa się według roszczeń najemcy lub nagłówka:

<!-- Using a tenant claim; requires validate-jwt earlier in the pipeline -->
<llm-token-limit
   counter-key="@(context.Principal?.Claims.GetValueOrDefault(&quot;tenantId&quot;, &quot;&quot;))"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

<!-- Or using a custom header populated by your edge/CDN/gateway -->
<llm-token-limit
   counter-key="@(context.Request.Headers.GetValueOrDefault(&quot;TenantID&quot;, &quot;&quot;))"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

Uwaga

Sprawdź, czy obecne są oświadczenie lub nagłówek i czy nie są puste, przed zastosowaniem limitów, w celu uniknięcia przypadkowego przypisania wielu klientów do pojedynczego licznika.

Niestandardowe domeny

Użyj zarządzania interfejsem API, aby skonfigurować własne niestandardowe domeny dla bramy API i portalu deweloperów.

Warstwy Standardowa w wersji 2 i Premium w wersji 2 obsługują nazwy hostów z symbolami wieloznacznymi. Jeśli każdy dzierżawca używa poddomeny, takiej jak tenant1.api.contoso.com, rozważ skonfigurowanie nazwy hosta z symbolem wieloznacznym, taka jak *.api.contoso.com. Wieloznaczne nazwy hostów mogą uprościć wdrażanie dzierżawców i zarządzanie certyfikatami, ponieważ nie trzeba konfigurować nazwy hosta dla każdego dzierżawcy.

Jeśli dzierżawcy potrzebują odrębnych nazw FQDN, które nie mają wspólnej domeny nadrzędnej, użyj wielu niestandardowych nazw hostów w bramie w warstwie Premium v2. Następnie możesz użyć nazwy hosta żądania, aby określić dzierżawcę i kierować żądanie do odpowiedniego backendu. Nie używaj nazwy hosta jako potwierdzenia, że obiekt wywołujący jest autoryzowany dla tego dzierżawcy.

Ważne

W warstwach Standardowa v2 i Premium v2 niestandardowa nazwa hosta bramy musi być publicznie rozpoznawalna. Nie można ograniczyć nazwy hosta do prywatnej strefy DNS.

Usługi API Management można również używać razem z usługą, na przykład Azure Front Door. W tej konfiguracji Azure Front Door często obsługuje domeny niestandardowe i certyfikaty TLS (Transport Layer Security) i komunikuje się z usługą API Management przy użyciu jednej nazwy domeny. Jeśli oryginalny adres URL klienta zawiera informacje o dzierżawie, które należy wysłać do wystąpienia usługi API Management w celu późniejszego przetworzenia, rozważ użycie nagłówka żądania X-Forwarded-Host lub użyj reguł Azure Front Door do przekazania informacji jako nagłówka HTTP. Aby uzyskać więcej informacji, zobacz Zachowywanie oryginalnej nazwy hosta HTTP.

Ważne

Ufaj nagłówkom przekazywanym dalej tylko wtedy, gdy pochodzą ze znanego serwera proxy. Skonfiguruj usługę brzegową, aby usunąć lub zastąpić nagłówki przekierowania dostarczone przez klienta i ograniczyć bezpośredni dostęp do bramy usługi API Management tam, gdzie to możliwe.

Limity szybkości

Często stosuje się limity przydziału lub limity czasowe w rozwiązaniu wielodostępnym. Limity szybkości mogą pomóc w ograniczeniu problemu hałaśliwego sąsiada. Możesz również użyć limitów przepustowości, aby wymusić jakość usługi i rozróżnić różne poziomy cenowe.

Użyj usługi API Management, aby wymusić limity częstotliwości specyficzne dla dzierżawy. Jeśli używasz subskrypcji specyficznych dla dzierżawy, rozważ użycie polityki ograniczeń w celu wymuszenia limitu dla każdej subskrypcji. Alternatywnie rozważ użycie polityki quota-by-key, aby wymusić przydziały za pomocą dowolnego innego klucza ograniczenia szybkości, takiego jak identyfikator najemcy uzyskany z adresu URL żądania lub JWT.

Aby uzyskać więcej informacji, zobacz Limity oparte na tokenach dla dużych modeli językowych.

Ważne

Zakres licznika różni się w zależności od zasad i topologii wdrożenia.

  • Zasady rate-limit i rate-limit-by-key prowadzą oddzielne liczniki dla każdej bramy, w której są stosowane. W przypadku wdrożeń bramy wieloregionowej lub obszaru roboczego każda brama regionalna lub brama obszaru roboczego wymusza własny licznik.

  • Zasada llm-token-limit śledzi również tokeny dla każdej bramy, regionu lub obszaru roboczego i nie agreguje zliczeń w całym wystąpieniu usługi.

  • Zasady quota i quota-by-key są globalne na poziomie usługi i mają zastosowanie w różnych regionach dla określonego wystąpienia.

Jeśli potrzebujesz globalnie spójnej przepustowości dla dzierżawy, preferuj limity przydziału, wymuszaj limity na nadrzędnej krawędzi, która widzi cały ruch lub kieruje dzierżawę do jednej bramy lub regionu.

Monetyzacja

Dokumentacja usługi API Management zawiera obszerne wskazówki dotyczące zarabiania na interfejsach API, w tym przykładowej implementacji. Metody zarabiania łączą wiele funkcji usługi API Management, dzięki czemu deweloperzy mogą publikować interfejs API, zarządzać subskrypcjami i pobierać opłaty na podstawie różnych modeli użycia.

Zarządzanie pojemnością

Wystąpienie usługi API Management obsługuje określoną ilość pojemności, która reprezentuje zasoby dostępne do przetwarzania żądań. Jeśli używasz złożonych zasad lub wdrażasz więcej interfejsów API w wystąpieniu, zużywasz więcej zasobów. Można zarządzać pojemnością instancji na kilka sposobów, na przykład kupując więcej jednostek. Możesz również dynamicznie skalować pojemność wystąpienia.

Niektóre wystąpienia wielodzierżawne mogą zużywać więcej zasobów niż wystąpienia jednodzierżawne, na przykład jeśli używasz wielu zasad do routingu żądań do różnych zapleczy dzierżawy. Przemyśl dokładnie planowanie pojemności i zaplanuj zwiększenie pojemności instancji, jeśli zauważysz wzrost zużycia. Należy również przetestować wydajność rozwiązania, aby zrozumieć potrzeby dotyczące zasobów z wyprzedzeniem.

Aby uzyskać więcej informacji na temat skalowania usługi API Management, zobacz Uaktualnianie i skalowanie wystąpienia usługi API Management.

Wdrożenia w wielu regionach

Usługa API Management obsługuje wdrożenia wieloregionowe co oznacza, że można wdrożyć pojedynczy logiczny zasób usługi API Management w wielu regionach Azure bez konieczności replikowania konfiguracji do oddzielnych zasobów. Ta funkcja jest szczególnie przydatna w przypadku globalnego dystrybuowania lub replikowania rozwiązania. Bramy regionalne można wdrożyć na potrzeby przetwarzania żądań o małych opóźnieniach i zarządzać nimi w ramach jednego wystąpienia usługi API Management.

Ważne

Wdrożenie w wielu regionach jest obsługiwane tylko w niektórych planach. Jeśli wystąpienie korzysta z innej warstwy cenowej, ale musisz wdrożyć je w wielu regionach, użyj oddzielnego wystąpienia dla każdego regionu i routingu zewnętrznego, takiego jak Azure Front Door.

Jeśli jednak potrzebujesz w pełni izolowanych wystąpień usługi API Management, możesz również wdrożyć niezależne zasoby usługi API Management w różnych regionach. Takie podejście oddziela płaszczyznę zarządzania dla każdego wystąpienia usługi API Management.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy

  • John Downs | Główny inżynier oprogramowania, wzorce i praktyki Azure
  • Daniel Scott-Raynsford | Starszy architekt rozwiązań partnerskich, rozwiązania partnerskie dla przedsiębiorstw

Inny współautor:

Aby wyświetlić profile LinkedIn niepublikacyjnych, zaloguj się do LinkedIn.

  • Ostatnia aktualizacja o