Udostępnij za pośrednictwem

Korzystanie z usługi Azure API Management w rozwiązaniu wielodostępnym

  • Artykuł

Usługa Azure API Management to kompleksowa brama interfejsu API i zwrotny serwer proxy dla interfejsów API. Udostępnia wiele funkcji, w tym buforowanie, pozorowanie odpowiedzi i portal dla deweloperów, które są przydatne w przypadku aplikacji skoncentrowanych na interfejsie API. 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 zapewnienie bramy usługi API Management jako usługi innym zespołom. 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 ułatwiają udostępnianie wystąpienia usługi API Management w wielu zespołach, które mogą mieć różne poziomy dostępu.

Modele izolacji

Usługa API Management jest zwykle wdrażana jako składnik udostępniony z pojedynczym wystąpieniem, które obsługuje żądania dla wielu dzierżaw. Jednak na podstawie modelu dzierżawy istnieje wiele sposobów wdrażania usługi API Management. W tym artykule założono, że rozwiązanie jest wdrażane przy użyciu sygnatur wdrażania.

Zazwyczaj sposób korzystania z usługi API Management jest podobny, niezależnie od modelu 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 Wystąpienie udostępnione z zapleczem z jedną dzierżawą Udostępnione wystąpienie z udostępnionym wielodostępnym zapleczem Wystąpienie dla każdej dzierżawy
Liczba obsługiwanych dzierżaw Dużo Prawie bez ruchu Jeden dla każdego wystąpienia
Koszt Lower Lower Wyższa
Złożoność wdrożenia Niski: pojedyncze wystąpienie do zarządzania dla każdej sygnatury Niski: pojedyncze wystąpienie do zarządzania dla każdej sygnatury Wysoki: wiele wystąpień do zarządzania
Złożoność konfiguracji routingu Wyższa Lower Lower
Podatność na problemy z hałaśliwym sąsiadem Tak Tak Nie.
Izolacja sieci na poziomie dzierżawy Nie Nie. Tak
Przykładowy scenariusz Niestandardowe nazwy domen dla każdej dzierżawy Duże rozwiązanie wielodostępne z udostępnioną warstwą aplikacji Sygnatury wdrożenia specyficzne dla dzierżawy

Modele izolacji współużytkowanego wystąpienia

Wspólne jest udostępnianie wystąpienia usługi API Management między wieloma dzierżawami, co pomaga zmniejszyć koszty i złożoność wdrażania i zarządzania. Szczegółowe informacje na temat sposobu udostępniania wystąpienia usługi API Management zależą od sposobu przypisywania dzierżaw do aplikacji interfejsu API zaplecza.

Aplikacja zaplecza z jedną dzierżawą

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

Ponieważ wymaga to dodatkowego wyszukiwania, takie podejście może nie być skalowane do dużej liczby dzierżaw, które współużytkuje pojedyncze wystąpienie usługi API Management. Podczas wyszukiwania zaplecza dzierżawy 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 takiego wyszukiwania.

Udostępniona wielodostępna aplikacja zaplecza

W scenariuszach, w których dzierżawcy mają wspólną aplikację zaplecza, proces routingu usługi API Management jest uproszczony, ponieważ można kierować wszystkie żądania do jednego zaplecza. Jeśli używasz domen wieloznacznych lub domen wystawionych przez dostawcę, możesz osiągnąć niemal niezwiązaną skalę przy użyciu tego podejścia. Ponadto, ponieważ żądania nie muszą być mapowane na zaplecze dzierżawy, nie ma wpływu na wydajność z dostosowanych decyzji dotyczących routingu.

Wystąpienie dla każdej dzierżawy

W niektórych sytuacjach można wdrożyć wystąpienie usługi API Management dla każdej dzierżawy. Zalecamy takie podejście tylko wtedy, gdy masz niewielką liczbę dzierżaw lub jeśli masz ścisłe wymagania dotyczące zgodności, które ograniczają udostępnianie dowolnej infrastruktury między dzierżawami. Jeśli na przykład wdrożysz dedykowaną sieć wirtualną dla każdej dzierżawy, prawdopodobnie musisz również wdrożyć dedykowane wystąpienie usługi API Management 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 w wielu regionach 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ług, w tym wszelkie limity, które mogą mieć zastosowanie do liczby wystąpień usługi API Management w ramach subskrypcji lub regionu platformy Azure.

Wystąpienia z jedną dzierżawą zwykle mają minimalną konfigurację routingu, ponieważ można kierować wszystkie żądania do jednego zaplecza. 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ć wystąpienia z jedną dzierżawą, rozważ, czy bramy hostowane samodzielnie umożliwiają ponowne użycie zasobów obliczeniowych specyficznych dla dzierżawy, które zostały już wdrożone.

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

Usługa API Management używa zasad w celu zapewnienia elastyczności. 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 dzierżaw w żądaniach przychodzących

Zastanów się, jak można zidentyfikować odpowiednią dzierżawę w ramach każdego żądania przychodzącego. W rozwiązaniu wielodostępnym ważne jest, aby jasno zrozumieć, kto wysyła każde żądanie, aby zwracać dane dla tej konkretnej dzierżawy 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ń dobrym rozwiązaniem jest użycie subskrypcji do identyfikowania dzierżaw.

Alternatywnie można zidentyfikować dzierżawę przy użyciu innych metod. Oto kilka przykładów podejść uruchamianych w ramach zdefiniowanych zasad niestandardowych:

  • 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). Możesz na przykład mieć oświadczenie niestandardowe tenantId w zestawie JWT wystawionym przez dostawcę 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 dzierżawy. 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ć dodatkowe informacje o dzierżawie. Aby użyć tej metody, 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ą z każdą dodaną, usuniętą lub przeniesioną dzierżawą, która ma wpływ na wyszukiwanie zaplecza.

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żawy, 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 ustawiania nazw nazwanych wartości. Jeśli ustawienia różnią się między dzierżawami, pamiętaj, aby uwzględnić identyfikator dzierżawy w nazwie. Na przykład można użyć wzorca, takiego jak tenantId-key:value po potwierdzeniu, że tenantId jest odpowiednie dla żądania.

Dołącz identyfikator, aby zmniejszyć prawdopodobieństwo przypadkowego odwoływania się do wartości innej dzierżawy lub manipulowania nią podczas przetwarzania żądania dla innej dzierżawy.

Uwierzytelnianie żądań przychodzących

Żądania interfejsu API wysyłane do bramy usługi API Management zwykle wymagają uwierzytelnienia. Usługa API Management udostępnia kilka metod uwierzytelniania żądań przychodzących do bramy, w tym certyfikatów OAuth 2.0 i klienta. Należy wziąć pod uwagę typy poświadczeń, które należy obsługiwać i gdzie powinny być weryfikowane. Rozważ na przykład, czy walidacja powinna nastąpić 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 Azure 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, ale jest przydatny w innych scenariuszach, takich jak śledzenie użycia interfejsu API poszczególnych dzierżawców.

Kierowanie do zapleczy specyficznych dla dzierżawy

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 sygnaturach wdrożenia lub mogą być różne aplikacje w ramach pojedynczej sygnatury. Aby dostosować routing w definicji zasad, użyj zasad 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ń dzierżaw, jeśli używasz logiki niestandardowej lub jeśli wyszukasz mapowanie z usługi zewnętrznej.

Użyj zasad cache-store-value i cache-lookup-value, aby zaimplementować podejście 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ć między dzierżawami, upewnij się, że identyfikator dzierżawy został uwzględniony w kluczu pamięci podręcznej.

Dołącz identyfikator, aby zmniejszyć prawdopodobieństwo przypadkowego przywoływania się do manipulowania wartością innej dzierżawy podczas przetwarzania żądania dla innej dzierżawy.

Niestandardowe domeny

Użyj usługi API Management, aby skonfigurować własne domeny niestandardowe dla bramy interfejsu API i portalu deweloperów. W niektórych warstwach można skonfigurować domeny wieloznaczne lub wiele w pełni kwalifikowanych nazw domen (FQDN).

Możesz również używać usługi API Management razem z usługą, np . Azure Front Door. W takiej konfiguracji usługa Azure Front Door często obsługuje domeny niestandardowe i certyfikaty zabezpieczeń warstwy transportu (TLS) i komunikuje się z usługą API Management przy użyciu jednej nazwy domeny. Jeśli oryginalny adres URL od 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 X-Forwarded-Host nagłówka żądania lub użyj reguł usługi Azure Front Door, aby przekazać informacje jako nagłówek HTTP.

Limity szybkości

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

Użyj usługi API Management, aby wymusić limity szybkości specyficzne dla dzierżawy. Jeśli używasz subskrypcji specyficznych dla dzierżawy, rozważ użycie zasad przydziału w celu wymuszenia limitu przydziału dla każdej subskrypcji. Alternatywnie rozważ użycie zasad limitu przydziału według klucza , aby wymusić przydziały przy użyciu dowolnego innego klucza limitu szybkości, takiego jak identyfikator dzierżawy uzyskany z adresu URL żądania lub JWT.

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 pewną 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 pojemności. Pojemność wystąpienia można zarządzać 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 wielodostępne mogą zużywać więcej pojemności niż wystąpienia z jedną dzierżawą, na przykład jeśli używasz wielu zasad do routingu żądań do różnych zapleczy dzierżawy. Rozważ dokładne planowanie pojemności i zaplanuj skalowanie pojemności wystąpienia, jeśli widzisz wzrost użycia. Należy również przetestować wydajność rozwiązania, aby poznać potrzeby pojemności przed upływem czasu.

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

Wdrożenia w wielu regionach

Usługa API Management obsługuje wdrożenia w wielu regionach, co oznacza, że można wdrożyć jeden logiczny zasób usługi API Management w wielu regionach świadczenia usługi Azure bez konieczności replikowania konfiguracji na oddzielne zasoby. Ta funkcja jest szczególnie przydatna w przypadku globalnego dystrybuowania lub replikowania rozwiązania. Możesz skutecznie wdrożyć flotę wystąpień usługi API Management w wielu regionach, co umożliwia przetwarzanie żądań o małych opóźnieniach i zarządzanie nimi jako pojedyncze wystąpienie logiczne.

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

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

Inny współautor:

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

Następne kroki

Zapoznaj się z podejściami architektury do integracji w rozwiązaniach wielodostępnych.