Udostępnij za pośrednictwem

Najlepsze praktyki architektoniczne dla zarządzania interfejsem API Azure

Azure API Management to platforma zarządzania i brama dla interfejsów API we wszystkich środowiskach, w tym hybrydowych i multicloud. Jako rozwiązanie typu platforma jako usługa (PaaS), zarządzanie interfejsami API pomaga obsługiwać cykl życia API Twojego obciążenia.

W tym artykule założono, że jako architekt przejrzałeś drzewo decyzyjne usług integracji i wybrałeś API Management jako usługę integracji dla obciążenia. Wskazówki w tym artykule zawierają zalecenia dotyczące architektury, dopasowane do zasad filarów Well-Architected Framework.

Zakres technologii

Ten przegląd koncentruje się na powiązanych decyzjach dotyczących następującego zasobu platformy Azure:

  • Azure API Management

Zakresem tego przewodnika jest usługa API Management, przede wszystkim składnik bramy (płaszczyzna danych), która przekazuje żądania API z aplikacji klienckich do interfejsów API zaplecza hostowanych na różnych platformach lub w lokalizacjach między różnymi ośrodkami. Architektura obciążenia powinna uwzględniać płaszczyznę sterowania usługi API Management i powiązane składniki, takie jak aplikacje klienckie, które uzyskują dostęp do bramy i interfejsów API zaplecza, które przetwarzają kierowane żądania. Integruje również obsługę usług platformy Azure, w tym sieci, monitorowania, zarządzania tożsamościami i innych możliwości.

Ten przewodnik nie obejmuje centrum interfejsu API platformy Azure. Odnosi się jedynie do zagadnień na poziomie interfejsu API w kontekście zarządzania API, zamiast zapewniać dobrze przemyślaną perspektywę dotyczącą zagadnień projektowania interfejsu API.

Note

Nie wszystkie zalecenia dotyczą wszystkich warstw usług usługi API Management. Wiele zaleceń w tym przewodniku koncentruje się na warstwach Standardowa w wersji 2, klasycznej Premium i Premium w wersji 2 usługi API Management, które są zalecanymi warstwami produkcyjnymi dla większości obciążeń przedsiębiorstwa.

Reliability

Celem filaru niezawodności jest zapewnienie ciągłej funkcjonalności poprzez budowanie wystarczającej odporności i zdolności do szybkiego odzyskiwania po awariach.

zasady projektowania niezawodności zapewniają ogólną strategię projektowania stosowaną dla poszczególnych składników, przepływów systemowych i całego systemu.

Lista kontrolna projektowania obciążenia

Rozpocznij strategię projektowania na podstawie listy kontrolnej przeglądu projektu pod kątem niezawodności. Określ jego znaczenie dla wymagań biznesowych, mając na uwadze warstwy i funkcje API Management oraz jego zależności. Rozszerz strategię w celu uwzględnienia większej liczby podejść zgodnie z potrzebami.

  • Ocena możliwości bramy sieciowej pod kątem niezawodności i nadmiaru: Określ warstwę i funkcje zarządzania API, które są potrzebne do spełnienia wymagań dotyczących niezawodności pracy w każdym środowisku.

    Ocena funkcji nadmiarowości bramy, w tym stref dostępności, wielu jednostek bramy, wielu regionów i obszarów roboczych. Wszystkie te funkcje są obsługiwane w warstwie Premium. Warstwa Premium w wersji 2 obsługuje obecnie wszystkie te funkcje z wyjątkiem wielu regionów. Warstwa Deweloper, która nie obejmuje umowy dotyczącej poziomu usług (SLA), nie jest odpowiednia dla obciążeń produkcyjnych. Rozważ kompromisy związane z wdrażaniem funkcji, takich jak zewnętrzne buforowanie, które może powodować potencjalne punkty awarii i wąskich gardeł wydajności.

  • Przejrzyj możliwości obserwacji: Rozważ możliwości obserwowania usługi, w tym dzienniki i metryki usługi Azure Monitor, usługę Application Insights, wbudowaną analizę i wbudowaną diagnostykę. Użyj tych możliwości, aby monitorować sygnały niezawodności obciążenia.

    Rozważ na przykład użycie alertów usługi Azure Monitor , aby powiadomić o potencjalnych problemach z bramą usługi API Management lub jej zależnościami.

  • Przejrzyj strategie skalowania: Zdefiniuj kryteria skalowania poziomego bramy przez dodanie jednostek w celu zachowania niezawodności usługi. Zastanów się, czy należy skalować na podstawie żądań, wyjątków, czy obu. Oceń wpływ skalowania składnika bramy na inne składniki obciążenia. Na przykład jej wpływ na przestrzeń adresową sieci i możliwości skalowania zaplecza.

  • Izolowanie obciążeń krytycznych: Ustal, czy izolacja obliczeniowa jest wymagana do spełnienia wymagań dotyczących obciążeń, takich jak niezależność danych lub optymalizacja wydajności, w interfejsach API. Użyj dedykowanych bram dla krytycznych interfejsów API i bram udostępnionych dla mniej krytycznych interfejsów API.

    Wybierz podejście izolacji, takie jak użycie dedykowanej bramy obszaru roboczego lub oddzielnej instancji usługi API Management. Aby zapewnić bezpieczeństwo wdrożeń, utrzymuj synchronizację środowisk dla wielu instancji.

  • Skoordynowanie celów poziomu usług (SLO): Uwzględnij zakres SLA bramy przy definiowaniu celów SLO dla obciążenia. Usługa zapewnia własną umowę SLA, ale musisz również uwzględnić przewidywaną niezawodność innych składników obciążenia, takich jak zaplecza API.

  • Rozwiąż błędy zaplecza: Zaplanuj zarówno oczekiwane, jak i nieoczekiwane błędy zaplecza. Testowanie doświadczeń klienta w tych scenariuszach. Ocena zasad bramy w celu zwiększenia odporności i poprawy doświadczenia klienta. Skup się na przydziałach, limitach szybkości, zasadach ponawiania prób, wyłącznikach zaplecza, równoważeniu obciążenia i obsłudze wyjątków zgodnie ze specyfikacjami interfejsu API.

  • Definiowanie strategii testowania: Użyj rozwiązania do testowania, takiego jak testowanie obciążenia platformy Azure z sieci, aby odzwierciedlić rzeczywiste obciążenia produkcyjne. Nie polegaj na opublikowanej przepustowości ani innych szacunkach, które mogą nie mieć zastosowania do twojego obciążenia pracą.

  • Planowanie odzyskiwania po awarii (DR): Przejrzyj dostępne opcje tworzenia kopii zapasowych i przywracania infrastruktury bramy i interfejsów API. Wbudowane możliwości tworzenia i przywracania kopii zapasowych mogą być przydatne w niektórych scenariuszach. Można również rozważyć opcje zarządzane przez klienta, takie jak narzędzia APIOps i infrastruktura jako rozwiązanie kodu (IaC). Opracowywanie strategii utrzymywania innych danych systemowych, w tym subskrypcji użytkowników.

Zalecenia dotyczące konfiguracji

Te zalecenia dotyczące niezawodności dotyczą samej usługi lub ruchu przepływanego przez interfejsy API i ich zasady. Designatory (Service) lub (API) wskazują, czy zalecenie dotyczy usługi, czy interfejsów API.

Recommendation Benefit
(Usługa) Włącz nadmiarowość strefy (dostępną w warstwach Premium i Premium w wersji 2) i wdróż co najmniej dwie jednostki.

W normalnych warunkach operacyjnych wszystkie jednostki skalowania we wszystkich skonfigurowanych strefach są aktywne i obsługują ruch bramy.

W każdym scenariuszu aktywny-aktywny zaplanuj wsparcie skalowania w poziomie w pozostałych strefach aktywnych, aby obsłużyć ruch, który jednostki pierwotnie przetwarzały w uszkodzonej strefie.		 Odporność jest zapewniana podczas awarii centrum danych w regionie. Podczas całkowitej utraty centrum danych ruch interfejsu API nadal przepływa przez pozostałe jednostki wdrożone w innych strefach.
(Usługa) Włącz automatyczne skalowanie w poziomie na podstawie zapotrzebowania na ruch.

W przypadku wdrożeń w wielu regionach, regiony pomocnicze nie mają możliwości automatycznego skalowania poziomego ani skalowania wstecznego. Musisz zaimplementować funkcję niestandardową lub aplikację logiki, która aktywuje się w odpowiedzi na alerty metryk usługi Azure Monitor, aby zarządzać korektami jednostek na podstawie zapotrzebowania.		 Gwarantowane są wystarczające zasoby, aby zaspokoić zapotrzebowanie klientów interfejsu API, co zapobiega awariom z powodu niewystarczającej pojemności.
(Usługa) Użyj topologii obejmującej wiele regionów , aby zapewnić odporność na kompletną awarię regionalną.

Takie podejście wymaga od ciebie koordynacji z innymi elementami w obciążeniu roboczym i zrozumienia ich planowanego mechanizmu przełączania awaryjnego. W każdym scenariuszu aktywny-aktywny zaplanuj wsparcie dla skalowania w poziomie w pozostałych aktywnych regionach, aby obsłużyć ruch, który pierwotnie był przetwarzany przez region, który stał się nieaktywny.

Upewnij się, że topologia w wielu regionach jest zgodna z wszelkimi wymaganiami dotyczącymi zgodności danych przesyłanych lub danych przechowywanych w pamięci podręcznej.		 Niezawodna odporność jest zapewniana podczas pełnej awarii regionalnej, co pomaga zapewnić nieprzerwany ruch interfejsu API za pośrednictwem jednostek wdrożonych w innych regionach.
(Usługa) Izolowanie niepowiązanych interfejsów API z obszarami roboczymi lub dodatkowymi wystąpieniami usługi API Management. Wpływ awarii spowodowanych nieprawidłową konfiguracją lub przerwami w działaniu jest zminimalizowany przez oddzielenie interfejsów API między różnymi wystąpieniami obliczeniowymi.
(INTERFEJS API) Dokładnie przetestuj wyrażenia zasad i logikę i połącz je z odpornymi technikami obsługi błędów w zasadach zarządzania interfejsami API. Doświadczenie klienta zostało ulepszone przez zapobieganie nowym źródłom awarii przy bramie oraz zapewnienie płynnej degradacji lub bezpiecznego przetwarzania błędów przejściowych.
(Usługa i interfejs API) Zbieranie metryk niezawodności.

Typowe metryki niezawodności interfejsu API obejmują:

- Limity szybkości i naruszenia limitów przydziału.
- Współczynnik błędów na podstawie kodów stanu HTTP.
- Odchylenie częstotliwości żądań z punktu odniesienia.
- Kontrole zdrowia, w tym stan zdrowia zależności.		 Zidentyfikowano odchylenia od oczekiwanego zachowania i poprzednich punktów odniesienia. Te dane mogą służyć do śledzenia głównych przyczyn, takich jak zmienione zachowanie użytkownika, interferencja z rutynowych operacji, nieoczekiwany wpływ na nowe funkcje lub nieplanowane błędy w obciążeniu.
(Usługa i interfejs API) Użyj wbudowanych funkcji tworzenia i przywracania kopii zapasowych wbudowanych w usługę API Management w ramach podręcznika odzyskiwania po awarii. Uzupełnij te funkcje artefaktami IaC i procesami APIOps, aby uzyskać niezawodne rozwiązanie, które może obsługiwać różne scenariusze, w tym koordynację odzyskiwania z zależnościami i zapleczami. Ciągłość działania jest zapewniana przez umożliwienie odzyskiwania bramy interfejsu API i przywrócenie zdefiniowanych interfejsów API po całkowitej utracie systemu.

Zabezpieczenia

Celem filaru Zabezpieczenia jest zapewnienie gwarancji dotyczących poufności, integralności i dostępności obciążenia.

Zasady projektowania zabezpieczeń zapewniają ogólną strategię projektowania w celu osiągnięcia tych celów, stosując podejścia do projektu technicznego usługi API Management.

Note

Lista kontrolna i zalecenia w tej sekcji koncentrują się na zabezpieczaniu zasobu bramy usługi API Management. Zabezpieczenie samych interfejsów API jest tylko krótko wspomniane. Aby uzyskać więcej informacji, zobacz Łagodzenie 10 najważniejszych zagrożeń bezpieczeństwa API OWASP w zarządzaniu API.

Lista kontrolna projektowania obciążenia

Rozpocznij strategię projektowania w oparciu o listę kontrolną przeglądu projektu dla zabezpieczeń i identyfikuj luki w zabezpieczeniach oraz mechanizmy kontroli, aby podnieść poziom bezpieczeństwa.

  • Ustanów punkt odniesienia zabezpieczeń: Przejrzyj punkt odniesienia zabezpieczeń dla usługi API Management i uwzględnij odpowiednie miary w punkcie odniesienia.

  • Chroń potok wdrażania: Identyfikuj osoby i role kontroli dostępu opartej na rolach, które są wymagane do zarządzania platformą usług, potokami ciągłej integracji i ciągłego wdrażania (CI/CD), a także poszczególnymi interfejsami API. Upewnij się, że dostęp do zarządzania usługą i jej interfejsami API mają tylko osoby upoważnione.

  • Ocena poufności danych: Jeśli poufne dane przepływa przez żądania interfejsu API i odpowiedzi w bramie usługi API Management, upewnij się, że jej ochrona w całym cyklu życia. Uwzględnij różne wymagania dotyczące ochrony danych w różnych regionach. Oceń funkcje usługi takie jak wiele regionów w celu odizolowania określonych danych. Upewnij się również, czy strategia buforowania jest zgodna z tymi wymaganiami dotyczącymi izolacji.

  • Opracowywanie strategii segmentacji w bramach udostępnionych: Jeśli wystąpienie usługi API Management hostuje interfejsy API dla wielu zespołów, można użyć obszarów roboczych do segregowania ról, sieci i ewentualnie bram. Takie podejście gwarantuje, że każdy zespół ma odpowiedni dostęp i kontrolę nad interfejsami API, którymi zarządza, jednocześnie ograniczając dostęp do interfejsów API innych zespołów.

  • Rozważ kontrolę sieci: Identyfikowanie wymagań i opcji izolowania lub filtrowania ruchu przychodzącego i wychodzącego bramy przy użyciu sieci wirtualnych. Ustal, czy dostęp do bramy może być ograniczony za pośrednictwem usługi Azure Private Link, czy też publiczny dostęp do bramy jest konieczny. Oceń, czy architektura powinna zawierać zaporę aplikacji internetowej, taką jak usługa Azure Web Application Firewall w usłudze Azure Application Gateway lub azure Front Door, aby osiągnąć wymaganą izolację sieci i filtrować ruch sieciowy.

  • Rozważ możliwości uwierzytelniania i autoryzacji interfejsu API: Oceń użycie dostawców tożsamości, takich jak Microsoft Entra ID, który obejmuje wbudowane grupy lub Identyfikator zewnętrzny firmy Microsoft, aby wyświetlać żądania bramy i włączać autoryzację OAuth dla interfejsów API zaplecza.

  • Szyfrowanie ruchu sieciowego: Zidentyfikuj najbezpieczniejsze wersje protokołu Transport Layer Security (TLS) i szyfry obsługiwane przez obciążenia. Nie wymagaj niezabezpieczonych wersji protokołu TLS. Użyj protokołu TLS 1.3, jeśli jest obsługiwany przez klientów.

  • Wykonaj modelowanie zagrożeń w usłudze API Management i zmniejsz jego obszar powierzchni: Ustal, czy określone składniki usługi API Management, takie jak bezpośredni interfejs API zarządzania lub publiczny dostęp do portalu dla deweloperów, mogą być wyłączone, ograniczone lub usunięte.

  • Identyfikowanie sekretów wymaganych przez obciążenia: Operacja bramy może wymagać certyfikatów, kluczy API lub innych tajnych wartości. Zapoznaj się z wymaganiami i możliwościami usługi Azure Key Vault, aby przechowywać wpisy tajne i certyfikaty. Możesz też przejrzeć wbudowane funkcje usługi API Management, takie jak nazwane wartości i zarządzane certyfikaty.

Zalecenia dotyczące konfiguracji

Te zalecenia dotyczące zabezpieczeń mogą dotyczyć samej usługi lub ruchu przepływanego przez interfejsy API i ich zasady. Designatory (Service) lub (API) wskazują, czy zalecenie dotyczy usługi, czy interfejsów API.

Recommendation Benefit
(Usługa) Wyłącz przestarzały bezpośredni interfejs zarządzania API. Użyj usługi Azure Resource Manager jako płaszczyzny sterowania. Powierzchnia usługowa jest redukowana poprzez usunięcie punktu dostępu do płaszczyzny sterowania.
(Usługa) Ogranicz ekspozycję bramy wyłącznie na podstawie miejsca, z którego łączą się legalni klienci.

- Użyj iniekcji sieci wirtualnej bez publicznego adresu IP, gdy wszyscy klienci mogą kierować ruch przez sieć wirtualną. Użyj grupy zabezpieczeń sieciowych, aby dodatkowo ograniczyć ruch tylko do oczekiwanych źródłowych adresów IP klientów.

— Użyj integracji sieci wirtualnej z usługą Application Gateway lub usługą Azure Front Door, jeśli jakikolwiek ruch musi pochodzić z Internetu. Skonfiguruj sieciową grupę zabezpieczeń tak, aby akceptowała ruch tylko z pojedynczego punktu wejścia.		 Poufność ruchu sieciowego jest chroniona przez ograniczenie narażenia na zakresy źródłowych adresów IP, które powinny zawierać uzasadnionych klientów. Te ograniczenia blokują dostęp ze źródeł, które nie powinny inicjować uzasadnionej komunikacji klienta. Ograniczenie narażenia na uzasadnione źródła ruchu zwiększa poufność, integralność i dostępność usługi.
(Usługa) Wyłącz portal dla deweloperów , jeśli nie jest używany. Jeśli portal jest w użyciu, wyłącz środowisko rejestracji, wyłącz dostęp anonimowy i ogranicz dostęp tylko do zaufanych lokalizacji sieciowych. Powierzchnia usługi i szansa na błędną konfigurację lub zaniedbanie zostaje zmniejszona.
(Usługa) Jawnie ustaw najwęższe możliwe obsługiwane wersje TLS, protokoły i szyfry dla Twoich klientów i zaplecza. Wersje i obsługiwane szyfry są ograniczone tylko do tych opcji, które obsługują klienci i zaplecza. Takie podejście pomaga zapewnić, że połączenia mają priorytet połączeń najwyższej klasy, które są możliwe do zachowania poufności.
(Usługa) Przechowuj certyfikaty niestandardowe w Key Vault. Funkcje zarządzania certyfikatami są udostępniane przy użyciu usługi Key Vault, która obsługuje rutynową rotację i inspekcję dostępu do certyfikatów.
(Usługa) Zaplecza powinny akceptować tylko ruch z bram interfejsu API i blokować cały inny ruch. Złośliwy ruch jest blokowany przed ominięciem zabezpieczeń oraz innych ogólnych zagadnień przeniesionych na bramę.
(Usługa) W przypadku wystąpień usługi API Management hostujących interfejsy API dla wielu zespołów lub obciążeń segmentowanych należy zaprojektować niezawodną strategię izolacji kontroli dostępu. Użyj obszarów roboczych lub zaimplementuj rygorystyczny proces APIOps , aby osiągnąć tę strategię.

Zespoły powinny mieć dostęp tylko do interfejsów API, które posiadają. Nie powinny mieć dostępu do innych interfejsów API, które mogłyby być hostowane w tym samym wystąpieniu.		 Ograniczone jest przemieszczanie się atakujących z jednego naruszonego interfejsu API do innych, niezwiązanych interfejsów API.
(API) Przechowuj tajemnice w usłudze Key Vault i udostępniaj je zasadom za pomocą nazwanych wartości. Nie używaj usługi Key Vault do przechowywania rzeczy niebędących tajemnicami. Użyj właściwości wartości nazwanej bezpośrednio dla tych wartości. Rotacja tajnych danych jest zalecana poprzez pojedynczą platformę zarządzania w usłudze Key Vault, podobnie jak w przypadku certyfikatów. Ten proces gwarantuje, że usługa API Management zostanie odpowiednio zaktualizowana. Nazwane wartości zapewniają również spójność konfiguracji zasad zarówno dla tajemnic, jak i jawnych informacji. Cały dostęp do tajnych informacji jest również audytowany w Key Vault, aby zapewnić historię dostępu. Przechowywanie tylko wpisów tajnych w usłudze Key Vault minimalizuje zależność od usługi Key Vault i nie przekształca usługi Key Vault w usługę konfiguracji aplikacji.
Użyj różnych tożsamości zarządzanych przypisanych użytkownikowi dla różnych zastosowań API przy użyciu zasady authentication-managed-identity. Każdy interfejs API ma niezależną tożsamość, która obsługuje cele segmentacji za pośrednictwem dostępu do najmniejszych uprawnień dla każdego interfejsu API. Zapewnia również lepszą inspekcję w systemach zaplecza.
(INTERFEJS API) Jeśli to możliwe, należy wymagać, aby klienci uwierzytelniali się za pomocą mechanizmów OAuth 2.0 zamiast używania kluczy współdzielonych, w tym kluczy subskrypcji lub certyfikatów klienta. Ulepszono identyfikację klienta do celów inspekcji, wyeliminowano rotację kluczy, a zmniejszono obciążenie klientów związane z ochroną tajemnic w porównaniu z używaniem wstępnie uzgodnionych kluczy.
Tłumienie nagłówków HTTP z odpowiedzi API przy użyciu zasady set-header, która może ujawniać szczegóły implementacji. Koszt dla atakujących jest zwiększany przez wstrzymywanie informacji o implementacji.
(API) Nie używaj śledzenia API w środowisku produkcyjnym. Dane poufne nie mogą być widoczne w śladach żądań.
(API) Użyj Defender dla API. Udostępniane są szczegółowe informacje o zabezpieczeniach interfejsu API, zalecenia i wykrywanie zagrożeń.
(API) Ochrona zasobów zaplecza poprzez delegowanie kluczowych sprawdzeń zabezpieczeń w zasadach API, takich jak validate-jwt, ip-filter, validate-headers, validate-content. Ilość ruchu niezgodnego z zasadami, który dociera do usług zaplecza, jest zmniejszana przez przeprowadzanie kontroli zabezpieczeń w bramie. Takie podejście odciążające pomaga chronić integralność i dostępność tych zasobów.
(INTERFEJS API) Zastosowanie praktyk cyklu projektowania zabezpieczeń (SDL) do zmian zasad polityki interfejsu API w taki sam sposób, jak proponowane zmiany w kodzie aplikacji w ramach obciążenia. Zasady są egzekwowane z widokiem o wysokim poziomie uprawnień na ruch interfejsu API. Obejście ochrony zaplecza pod kątem poufności, integralności i dostępności przez naruszoną bramę interfejsu API jest blokowane.
(Usługa i interfejs API) Użyj tożsamości zarządzanych dla zależności związanych z usługami i interfejsami API. Połączenia z usługą Key Vault, usługą Azure Event Hubs i innymi zależnościami, takimi jak certyfikaty i nazwane wartości, są ustanawiane bez polegania na przesyłanych wcześniej tajnych danych.
(Usługa i interfejs API) Połącz się z zależnościami, takimi jak Key Vault, Event Hubs i zaplecza za pośrednictwem prywatnych połączeń sieciowych, jeśli to możliwe. Poufność ruchu jest chroniona przez nieujawnianie ruchu poza siecią prywatną.
(Usługa i interfejs API) Ruch klienta skierowany do interfejsów API wystawionych na internet powinien najpierw przechodzić przez zaporę aplikacji sieci Web, taką jak Web Application Firewall, zanim dotrze do API Management. Ponadto należy chronić publiczne punkty końcowe przy użyciu usługi Azure DDoS Protection. Ilość ruchu niezgodnego z zasadami, który dociera do bramy i usług zaplecza, jest ograniczona przez przeprowadzenie kontroli zabezpieczeń za pomocą zapory aplikacji internetowej. Zmniejszenie tego ruchu pomaga chronić integralność i dostępność tych zasobów.
(Usługa i API) Oceń i włącz wszystkie kontrole zgodności z przepisami Azure Policy, które są istotne dla twojego obciążenia roboczego. Instancja usługi API Management jest dostosowana do żądanej postawy i pozostaje dostosowana w miarę rozwoju obciążenia dzięki wprowadzeniu zasad zabezpieczeń.

Optymalizacja kosztów

Optymalizacja kosztów koncentruje się na wykrywaniu wzorców wydatków, określaniu priorytetów inwestycji w krytycznych obszarach i optymalizacji w innych w celu spełnienia budżetu organizacji przy jednoczesnym spełnieniu wymagań biznesowych.

Zasady projektowania optymalizacji kosztów zapewniają strategię projektowania wysokiego poziomu w celu osiągnięcia tych celów i podejmowania kompromisów zgodnie z potrzebami w projekcie technicznym związanym z usługą API Management i jego środowiskiem.

Lista kontrolna projektowania obciążenia

Rozpocznij strategię projektową, opierając się na liście kontrolnej przeglądu projektu dla optymalizacji kosztów związanych z inwestycjami. Dopracuj projekt, aby obciążenie było zgodne z przydzielonym budżetem. Projekt powinien korzystać z odpowiednich możliwości platformy Azure, monitorować inwestycje i znajdować możliwości optymalizacji w czasie.

  • Rozważmy model kosztów usługi API Management: Skorzystaj z kalkulatora cen platformy Azure z korzyściami i kryteriami konta organizacji dotyczącymi umowy SLA i skalowalności, aby opracować dokładne oszacowania kosztów przy użyciu warstwy usługi API Management. Ustal, czy jest konieczny model obciążenia zwrotnego i określ, jak go obliczyć na podstawie metryk, tagów i tokenów.

    Model kosztów usług jest głównie wpływany przez poziom usługi, liczbę jednostek i liczbę bram. Oceń dodatkowe koszty związane z utrzymywaniem jednostki rezerwowej lub wdrażaniem konfiguracji odzyskiwania danych po awarii typu aktywne-pasywne.

    W przypadku implementowania obszarów roboczych należy ocenić koszty korzystania z oddzielnych i udostępnionych bram obszarów roboczych, aby spełnić różne wymagania dotyczące przepływu interfejsu API różnych zespołów interfejsu API lub uczestników projektu.

  • Szacowanie kosztów skalowania: Opracuj kryteria skalowania, aby zachować wysokie użycie zasobów bramy. Ocena kosztów bazowych w środowisku przedprodukcyjnym i przeprowadzenie testów w celu modelowania kosztów skalowania na podstawie przewidywanego ruchu obciążenia.

    Zaprojektuj strategię ograniczania ryzyka, aby zapobiec niewłaściwemu używaniu bram, co może spowodować kosztowne skalowanie poza przewidywanym użyciem.

  • Ocena konfiguracji i zasad usługi: Możliwości, takie jak rate-limit i limit-concurrency , mogą służyć jako techniki optymalizacji kosztów do zarządzania obciążeniami żądań.

  • Optymalizowanie umieszczania logiki: Oceń, czy serwery zaplecza są bardziej ekonomiczne pod kątem przetwarzania logiki, czy też brama powinna obsługiwać użycie zasobów. Brama jest silnym składnikiem do implementowania zagregowanych zagadnień, ale może wykonywać nadmierne funkcje w niektórych scenariuszach. Zidentyfikuj zadania przetwarzania żądań o dużej ilości zasobów wykonywane przez bramę i określ, czy przeniesienie tej logiki na serwery zaplecza może obniżyć koszty.

Zalecenia dotyczące konfiguracji

Te zalecenia dotyczące optymalizacji kosztów dotyczą samej usługi lub ruchu przepływanego przez interfejsy API i ich zasady. Designatory (Service) lub (API) wskazują, czy zalecenie dotyczy usługi, czy interfejsów API.

Recommendation Benefit
(Usługa) Użyj najmniej kosztownej warstwy , która obsługuje wymagania obciążenia. Na przykład wybierz warstwę Standardowa zamiast warstwy Premium, jeśli obciążenie nie skorzysta z dodanych funkcji w sposób, który uzasadnia zwrot z inwestycji (ROI). Unika się zakupu nieużywanych lub niedostatecznie używanych możliwości.
(Usługa) Używaj warstw nieprodukcyjnych lub infrastruktury przejściowej w niższych środowiskach, takich jak środowiska deweloperskie, wdrożenia weryfikacji koncepcji i początkowe działania modelowania kosztów. Koszty zasobów są oszczędzane w środowiskach, które mogą pozostać przydatne bez konieczności pełnego odzwierciedlania dokładnej konfiguracji lub wymagań dotyczących czasu działania systemu produkcyjnego.
(Usługa) Skalowanie w przypadku spadku zapotrzebowania. Skonfiguruj reguły automatycznego skalowania lub inne zautomatyzowane procesy, aby zmniejszyć liczbę jednostek, gdy pojemność bramy spadnie poniżej zdefiniowanych progów. Niepotrzebne koszty są zmniejszane przez dopasowanie pojemności do zapotrzebowania.
(Usługa) Oblicz korzyści kosztowe modelu federacyjnego dla API Management, używając obszarów roboczych do obsługi API, zapewniając jednocześnie izolację zespołu. Powierzchnia wdrażania i zarządzania jest ograniczona. Takie podejście ma na celu osiągnięcie korzyści skali dzięki zakupowi czasu i zasobów.
(Usługa) Likwiduj obszary robocze , gdy nie są już używane. Unikanie wydatków na nieużywane zasoby.
(Usługa) Użyj wbudowanej pamięci podręcznej , jeśli buforowane dane obciążenia mieszczą się w ramach ograniczeń wbudowanej pamięci podręcznej w warstwie. Unika się kosztów związanych z zakupem i konserwowanie zewnętrznej pamięci podręcznej zgodnej z usługą Redis.
(Usługa) Blokuj złośliwy ruch przed dotarciem do bramy przy użyciu mechanizmów kontroli sieci, ochrony przed atakami DDoS i zapór aplikacji internetowych. Określone warstwy usługi API Management powodują naliczanie opłat na podstawie liczby operacji żądania HTTP przetwarzanych przez bramę. W związku z tym niepożądany ruch, taki jak żądania generowane przez bota, może zwiększyć koszty.

Oceń koszt mechanizmu blokowania w porównaniu z szacowanym kosztem redukcji operacji HTTP, aby ocenić, czy takie podejście ma zwrot z inwestycji.		 Opłaty naliczane z powodu nadmiernych złośliwych lub uciążliwych operacji HTTP na bramie są zmniejszane.
(API) Zoptymalizuj wyrażenia zasad, przetwarzanie i kod, aby uniknąć nadmiernego użycia zasobów obliczeniowych, takich jak procesor, sieć lub pamięć. Unika się niepotrzebnego wdrażania większej liczby jednostek w celu zapewnienia pojemności dla niezoptymalizowanych implementacji polityki i kodu.
(API) Oceń koszt umieszczania logiki pomiędzy bramą, zapleczem lub publicznym punktem wejścia, takim jak usługa Azure Front Door. To samo przetwarzanie może często występować w każdej z tych warstw, z których każda ma własne kompromisy. Jednak niektóre warstwy mogą zapewnić oszczędności kosztów ze względu na nieużywaną pojemność dostępną na tym poziomie. Na przykład logika buforowania pierwotnie zaimplementowana w zapleczu może być bardziej ekonomiczna implementacja na poziomie bramy przy użyciu wbudowanej pamięci podręcznej. Takie podejście zmniejsza dodatkowe obciążenie związane z siecią i obliczeniami w usługach zaplecza. Obciążenie zasobów o wysokich kosztach jest zminimalizowane przez umieszczenie możliwości w najbardziej ekonomicznej warstwie. Takie podejście przenosi obciążenia na warstwy, które mają wolną pojemność lub tańsze opcje obliczeniowe.

Doskonałość operacyjna

Doskonałość operacyjna koncentruje się przede wszystkim na procedurach dotyczących praktyk programistycznych, możliwości obserwacji i zarządzania wydaniami.

Zasady projektowania doskonałości operacyjnej zapewniają ogólną strategię projektowania w celu osiągnięcia tych celów, uwzględniając wymagania operacyjne pracy.

Lista kontrolna projektowania obciążenia

Rozpocznij strategię projektowania na podstawie listy kontrolnej przeglądu projektów dla Doskonałości Operacyjnej, aby definiować procesy związane z obserwowalnością, testowaniem i wdrażaniem w kontekście zarządzania API.

  • Przejrzyj kluczową wiedzę i umiejętności potrzebne do obsługi usługi: Obszary obejmują cykl życia interfejsu API, procesy DevOps, sieć i łączność, monitorowanie i obserwowanie oraz tworzenie oprogramowania. Takie podejście obejmuje konfigurację zasad, testy jednostkowe oraz tworzenie potoków CI/CD.

  • Weź pod uwagę wymagania dotyczące dokumentacji: Zatwierdź proces dokumentowania procesów konfiguracji na poziomie usługi i na poziomie interfejsu API, operacji cyklu życia i różnych wzorców dostępu dla zespołów interfejsu API.

  • Oceń standardowe narzędzia do obsługi operacji usług. Na przykład zastosować metody APIOps, takie jak GitOps i CI/CD, w celu publikowania interfejsów API oraz zarządzania ich konfiguracjami. Użyj narzędzi IaC, aby wprowadzić zmiany konfiguracji na poziomie usługi. Projektuj artefakty wielokrotnego użytku, które mogą bezproblemowo przechodzić ze środowisk deweloperskich do środowiska produkcyjnego. Rozważ zintegrowanie lintera, takiego jak Spectral, samodzielnie zarządzane lub zintegrowane z usługą w Azure, np. Azure API Center, w potokach zatwierdzania interfejsu API.

  • Określ kluczowe metryki operacyjne i logi: Przejrzyj metryki produkcji. Te metryki obejmują pojemność bramy, użycie procesora CPU, użycie pamięci i liczbę żądań. Przejrzyj dzienniki i narzędzia do obserwacji, takie jak Azure Monitor i Application Insights. Określ strategie i narzędzia potrzebne do efektywnego zarządzania dużymi ilościami danych obserwacyjnych w środowiskach produkcyjnych. Ustal zapytania, które dostarczają szczegółowe informacje umożliwiające podejmowanie działań zarówno dla operatora bramy, jak i uczestników projektu, które monitorują określone hostowane interfejsy API.

  • Zaplanuj regularne testowanie obciążeń produkcyjnych przy użyciu testowania obciążenia.

  • Zidentyfikuj zadania operacyjne poza procesami CI/CD lub IaC, które wymagają automatyzacji. Planowanie automatyzacji w obszarach, takich jak zarządzanie źródłami zasad usługi API Management, zasady platformy Azure i określone konfiguracje portalu deweloperów.

Zalecenia dotyczące konfiguracji

Te zalecenia dotyczące doskonałości operacyjnej mogą dotyczyć samej usługi lub ruchu przepływanego przez interfejsy API i ich zasady. Designatory (Service) lub (API) wskazują, czy zalecenie dotyczy usługi, czy interfejsów API.

Recommendation Benefit
(Usługa) Konfigurowanie dzienników zasobów diagnostyki platformy Azure dla usługi API Management. Dzienniki generowane przez platformę są dostępne do wykonywania zapytań dotyczących rutynowych operacji, potrzeb na żądanie lub pilnych scenariuszy, takich jak inspekcje zabezpieczeń.
(Usługa) Aby zautomatyzować procesy na bazie znaczących zdarzeń generowanych przez instancję usługi API Management, użyj Azure Event Grid, na przykład . Zadania automatyzacji lub powiadomień można tworzyć wokół kluczowych zdarzeń cyklu życia występujących w wystąpieniu usługi API Management.
(Usługa) Unikaj korzystania z własnej bramy , jeśli w twoim scenariuszu działa jednostka bramy hostowanej przez firmę Microsoft. Zadania automatyzacji lub powiadomień można tworzyć wokół kluczowych zdarzeń cyklu życia występujących w wystąpieniu usługi API Management.
(Usługa) Zastosuj wszystkie wbudowane zasady usługi Azure Policy , które ułatwiają zarządzanie wystąpieniem i ograniczenie go w celu dostosowania ich do wymagań dotyczących obciążeń, w tym wymagań dotyczących zabezpieczeń. Na przykład użyj zasad odmowy , aby uniemożliwić uwidocznienie interfejsów API za pośrednictwem protokołu HTTP lub uniemożliwić włączenie bezpośredniego interfejsu API REST zarządzania. Użyj zasad audytu, gdy zasady odmowy nie są dostępne, lub utwórz niestandardowe zasady odmowy, jeśli jest to ważne dla twojego obciążenia. Wystąpienie usługi API Management pasuje do projektu i pozostaje zgodne w miarę rozwoju obciążenia.
(Usługa) Zapoznaj się z funkcją Diagnozowanie i rozwiązywanie problemów w witrynie Azure Portal.

Użyj panelu Stan sieci w portalu, aby zdiagnozować problemy z łącznością sieciową.		 Osoby inżynieryjne niezawodności lokacji mogą identyfikować i rozwiązywać problemy z wydajnością bramy, dostępnością usług i łącznością sieciową we wszystkich środowiskach.
(API) Event Hubs obsługuje dzienniki lub strumienie zdarzeń z wywołań API, które wymagają reakcji niemal w czasie rzeczywistym lub operacji w krótkim przedziale czasowym. Dostępna jest dostępność wpisów dziennika niemal w czasie rzeczywistym. Można uniknąć opóźnienia wprowadzania danych dziennika, które występuje podczas rejestrowania w Azure Monitor w ramach interfejsów API.
(INTERFEJS API) Obsługa użycia śledzenia interfejsu API podczas programowania, aby ułatwić deweloperom zrozumienie implementacji zasad. Produktywność deweloperów jest zoptymalizowana przez zapewnienie wglądu w implementację zasad w interfejsie API. Bez tej możliwości deweloperzy muszą wprowadzić hacki w implementacji zasad, aby uzyskać szczegółowe informacje.
(INTERFEJS API) Zawsze definiuj zaplecze przy użyciu funkcji zaplecza zarządzania API. Odwołuj się do tych zapleczy według identyfikatora w zasadach przy użyciu usługi set-backend-service. Zaplecza z równoważonym obciążeniem powinny być zdefiniowane jako pula zaplecza. Zmiany połączeń zaplecza mają zastosowanie do wszystkich interfejsów API korzystających z zaplecza bez konieczności aktualizowania poszczególnych kodów zasad. Ryzyko niewłaściwego konfigurowania lub pomijanych zmian zasad interfejsu API jest zmniejszane, a scenariusze, w których wiele interfejsów API współużytkuje ten sam zaplecze, są odpowiednie za pośrednictwem tej warstwy abstrakcji konfiguracji.
(INTERFEJS API) Zaprojektuj podejście do przechowywania wersji interfejsów API, aby dostosować je do możliwości przechowywania wersji i poprawek usługi API Management. Należy uwzględnić to podejście do operacji wdrażania interfejsu API. Strategia przechowywania wersji interfejsu API obsługiwana w ramach usługi API Management jest używana do korzystania z wbudowanych funkcji zamiast tworzenia niestandardowych rozwiązań.
(Usługa i interfejs API) Zdefiniuj spójny i zrównoważony proces operacyjny służący do dodawania, modyfikowania i usuwania interfejsów API. Określ, czy ręcznie zarządzać tym środowiskiem za pośrednictwem portalu, czy zaimplementować je za pośrednictwem procesu APIOps. Preferuj użycie podejścia opartego na protokole IaC zamiast podejścia opartego na portalu.

Reprezentacja usługi API Management w interfejsie API usługi Resource Manager składa się z wielu zasobów podrzędnych, dlatego ważne jest wdrożenie podejścia warstwowego do zarządzania tą kolekcją zasobów na podstawie architektury IaC.		 Specyfikacje interfejsu API i ich implementacje bramy są zintegrowane z procesami kontroli zmian obciążenia. Takie podejście uniemożliwia obsługę zmian w interfejsach API zaplecza inaczej niż sposób ich uwidaczniania klientom interfejsu API za pośrednictwem bramy.

Efektywność operacyjna

Wydajność operacyjna polega na utrzymaniu doświadczenia użytkownika nawet w przypadku wzrostu obciążenia poprzez zarządzanie wydajnością. Strategia obejmuje skalowanie zasobów, identyfikowanie i optymalizowanie potencjalnych wąskich gardeł oraz optymalizowanie pod kątem szczytowej wydajności.

Zasady projektowania efektywności zapewniają strategię projektowania na wysokim poziomie w celu osiągnięcia tych celów związanych z przepustowością w kontekście oczekiwanego wykorzystania.

Lista kontrolna projektowania obciążenia

Rozpocznij strategię projektowania w oparciu o listę kontrolną przeglądu projektu pod kątem wydajności operacyjnej. Zdefiniuj punkt odniesienia oparty na kluczowych wskaźnikach wydajności usługi API Management.

  • Zdefiniuj cele wydajności: Kluczowe metryki do oceny wydajności bramy usługi API Management obejmują metryki pojemności, takie jak procent użycia procesora CPU i pamięci dla infrastruktury bramy, czas trwania żądania i przepływność żądań. We wdrożeniach w wielu regionach zdefiniuj cele wydajności dla każdego regionu. Klient musi zdefiniować odpowiednie progi skalowania na podstawie wzorców ruchu, obciążeń interfejsu API i czasów skalowania.

  • Zbieranie danych wydajności: Przejrzyj możliwości wbudowanej analizy, metryk usługi Azure Monitor, dzienników usługi Azure Monitor, usługi Application Insights i usługi Event Hubs, aby zbierać i analizować wydajność na różnych poziomach szczegółowości.

  • Sprawdź, jak zidentyfikować problemy z wydajnością na żywo: Wskaźniki problemów z wydajnością na żywo obejmują dostępność usługi platformy Azure, błędy odpowiedzi HTTP i błędy zgłoszone w sekcji Diagnozowanie i rozwiązywanie problemów w portalu. Rozwiązywanie problemów z wydajnością i dostępnością przy użyciu usługi Application Insights, zapytań Kusto i zaleceń z diagnostyki usługi API Management w witrynie Azure Portal.

  • Wydajność testowania: Testowanie wydajności w warunkach produkcyjnych przy użyciu testów obciążeniowych.

  • Ocena sąsiednich usług, które mogą zwiększyć wydajność: Zasady buforowania lub zewnętrzna pamięć podręczna mogą zwiększyć wydajność określonych operacji interfejsu API. Usługi Azure Front Door i Application Gateway to typowe opcje odciążania protokołu TLS.

  • Przejrzyj udokumentowane limity i ograniczenia: usługa API Management ma ograniczenia i ograniczenia. Przejrzyj udokumentowane ograniczenia i porównaj je z wymaganiami obciążenia, aby sprawdzić, czy musisz zaprojektować rozwiązanie, które pozwala uniknąć tych ograniczeń.

Zalecenia dotyczące konfiguracji

Te zalecenia dotyczące wydajności mogą dotyczyć samej usługi lub ruchu przepływanego przez interfejsy API i ich zasady. Designatory (Service) lub (API) wskazują, czy zalecenie dotyczy usługi, czy interfejsów API.

Recommendation Benefit
(Usługa) Dynamiczne skalowanie w celu dopasowania do zapotrzebowania. Skonfiguruj reguły automatycznego skalowania lub inne zautomatyzowane procesy, aby dostosować jednostki bramy do docelowej pojemności użycia. Elastyczność jest osiągana na podstawie współbieżnego użycia, co zapobiega wyczerpaniu zasobów aktualnie wdrożonych jednostek lub nadmiernej alokacji pojemności.
Zminimalizuj kosztowne zadania przetwarzania, takie jak generowanie dużych buforowanych rozmiarów ładunków, używając polityki walidacji zawartości na dużych ciałach żądań lub utrzymując dużą liczbę aktywnych połączeń WebSocket. Obciążenie jednostek skalowania jest zmniejszane, co umożliwia przetwarzanie większej liczby żądań jednocześnie przed koniecznością skalowania w poziomie.
(Usługa i interfejs API) Zbieranie metryk wydajności.

Typowe metryki wydajności interfejsu API obejmują:

— Czas przetwarzania żądań dla samej bramy i pełnej operacji.
— Metryki użycia zasobów jednostki bramy.
- Pomiary przepływności, takie jak żądania na sekundę lub megabity na sekundę.
- Współczynnik trafień pamięci podręcznej.		 Rzeczywista wydajność jest mierzona względem celów obciążenia.
(Usługa i interfejs API) Zdefiniuj procent próbkowania dla usługi Application Insights , która zapewnia wystarczającą widoczność bez wpływu na wydajność. Dane dotyczące monitorowania są spełniane bez wpływu na ogólną wydajność.
(Usługi i interfejsy API) Oceń wpływ na wydajność w związku z umiejscowieniem logiki między twoją bramą, zapleczem a publicznym punktem wejścia, takim jak usługa Azure Front Door. Te same zadania przetwarzania mogą często występować w dowolnej z tych warstw, z kompromisami wydajności i ograniczeniami w możliwościach optymalizacji dla każdego z nich. Jeśli zadanie, takie jak zasady interfejsu API zarządzania interfejsem API, wprowadza zbyt duże opóźnienie, rozważ, czy to zadanie może być uruchamiane gdzie indziej w bardziej zoptymalizowany sposób. Zadania, które dodają opóźnienie do interfejsów API, są uruchamiane na obliczeniach zoptymalizowanych pod kątem spełnienia wymagań dotyczących obciążenia.

Zasady platformy Azure

Platforma Azure udostępnia obszerny zestaw wbudowanych zasad związanych z usługą API Management i jej zależnościami. Niektóre z wcześniejszych zaleceń można poddawać audytowi za pomocą usługi Azure Policy. Możesz na przykład sprawdzić, czy:

  • Brama jest skonfigurowana dla redundancji strefowej.
  • Właściwe zabezpieczenia sieciowe są wprowadzone dla bramki zarządzania API, takie jak wdrożenie w sieci wirtualnej.
  • Punkty końcowe konfiguracji usługi nie są publicznie dostępne.
  • Bezpośrednie API REST zarządzania jest wyłączone.

Aby zapewnić kompleksowe zarządzanie, przejrzyj wbudowane definicje polityk Azure i inne polityki, które mogą wpłynąć na bezpieczeństwo bramy zarządzania API.

Rekomendacje usługi Azure Advisor

Azure Advisor to spersonalizowany konsultant ds. chmury, który pomaga stosować najlepsze rozwiązania w celu zoptymalizowania wdrożeń platformy Azure.

Aby uzyskać więcej informacji, zobacz Azure Advisor.

Tradeoffs

Jeśli używasz metod na listach kontrolnych filarów, może być konieczne wprowadzenie kompromisów projektowych. Oto kilka przykładów zalet i wad.

Wysoka dostępność dzięki redundancji i izolacji

  • Wysoka dostępność. Redundancja wpływa na koszty. Zapewnienie co najmniej trzech jednostek, aby uniknąć awarii strefy, może nie być finansowo opłacalne przy obecnym obciążeniu. Koszty rosną dodatkowo dzięki architekturze wieloregionowej, która wymaga co najmniej sześciu jednostek lub trzech jednostek na region. Konfiguracja wielu regionów dodaje również koszty operacyjne związane z koordynacją bezpiecznych wdrożeń, niezawodnym skalowaniem i mechanizmem awaryjnym z zapleczami.

  • Isolation. Izolowanie obciążeń między obszarami roboczymi lub wystąpieniami usługi API Management zwiększa złożoność operacyjną, ponieważ obejmuje zarządzanie wielodostępnym systemem z izolacją obliczeniową.

Dostosuj skalę do zapotrzebowania

  • Podczas automatycznego skalowania w celu zaspokojenia zapotrzebowania dla klientów działających zgodnie z oczekiwaniami, koszty te już są uwzględnione w modelach kosztowych. Jednak ta funkcja skalowania umożliwia również skalowanie usługi, aby obsłużyć ruch niepożądany i złośliwy.

  • Ograniczanie niepożądanego ruchu wiąże się z kosztami. Dodawanie usług, takich jak zapora aplikacji internetowej i ochrona przed atakami DDoS, zwiększa wydatki. Skalowanie usługi w celu obsługi ruchu zwiększa koszty z powodu dodanych jednostek. Ustawienie górnych limitów skalowania może ograniczyć wydatki, ale jednocześnie może prowadzić do problemów z niezawodnością dla prawidłowych użytkowników, jeśli złośliwy lub szkodliwy ruch przeciąży interfejs API.

Federacyjne a rozproszone podejście

Podstawową decyzją w usłudze API Management jest to, czy kolokować różne obciążenia w ramach jednego wystąpienia usługi API Management, czy izolować obciążenia w wielu wystąpieniach w całkowicie autonomicznej topologii.

Obszary robocze usługi API Management umożliwiają wydajną operację jako wielodostępną platformę kolokacji dla wielu zespołów interfejsów API. Modele cenowe warstwowe zostały zaprojektowane tak, aby umożliwić współdzielenie kosztów usług we wszystkich dzierżawach korzystających z bram. Jednak podobnie jak każda platforma kolokacji, awarie lub błędy konfiguracji mogą spowodować powszechny wpływ na niepowiązane obciążenia, które współdzielą tę samą infrastrukturę.

W pełni rozproszony model, w którym każdy zespół obciążeń zarządza własnymi wystąpieniami, wprowadza duplikacyjne koszty i nadmiarowość w rutynowych operacjach. Zapewnia jednak wbudowane ograniczenie zasięgu oddziaływania wybuchu w przypadku zdarzeń dotyczących niezawodności, bezpieczeństwa i wydajności.

Przykładowa architektura

Podstawowa architektura, która demonstruje kluczowe zalecenia: architektura strefy docelowej usługi API Management.

Dalsze kroki

Usługa API Management jest często łączona z następującymi usługami. Pamiętaj, aby przejrzeć przewodniki dotyczące usług lub dokumentację produktu, jeśli obciążenie obejmuje te usługi.

Następujące artykuły przedstawiają niektóre z zaleceń omówionych w tym artykule.

  • Last updated on