Edytuj

Publikowanie wewnętrznych interfejsów API dla użytkowników zewnętrznych

Azure API Management
Azure Application Gateway
Azure DevOps
Azure Monitor
Azure Virtual Network

W tym scenariuszu organizacja wewnętrznie konsoliduje wiele interfejsów API przy użyciu usługi Azure API Management wdrożonej wewnątrz sieci Virtual Network.

Architektura

Diagram architektury przedstawiający pełny cykl życia wewnętrznych interfejsów API używanych przez użytkowników zewnętrznych.

Pobierz plik programu Visio z tą architekturą.

Powyższy diagram obejmuje pełny cykl życia wewnętrznych interfejsów API, które są używane przez użytkowników zewnętrznych.

Przepływ danych

Dane przepływa w następujący sposób:

  1. Deweloperzy sprawdzają kod w repozytorium GitHub połączonym z agentem potoku ciągłej integracji/ciągłego wdrażania zainstalowanym na maszynie wirtualnej platformy Azure.
  2. Agent wypycha kompilację do aplikacji interfejsu API hostowanej w środowisku ASE z wewnętrznym modułem równoważenia obciążenia.
  3. Usługa Azure API Management korzysta z powyższych interfejsów API za pośrednictwem nagłówków HOST określonych w zasadach API Management.
  4. API Management używa nazwy DNS App Service Environment dla wszystkich interfejsów API.
  5. Application Gateway uwidacznia portal deweloperów i interfejsów API API Management.
  6. Usługa Azure Prywatna strefa DNS służy do kierowania ruchu wewnętrznie między środowiskiem ASE, API Management i Application Gateway.
  7. Użytkownicy zewnętrzni korzystają z uwidocznionego portalu dla deweloperów, aby korzystać z interfejsów API za pośrednictwem publicznego adresu IP Application Gateway.

Składniki

  • Usługa Azure Virtual Network umożliwia zasobom platformy Azure bezpieczne komunikowanie się ze sobą, Internetem i sieciami lokalnymi.
  • Usługa Azure Prywatna strefa DNS umożliwia rozpoznawanie nazw domen w sieci wirtualnej bez konieczności dodawania niestandardowego rozwiązania DNS.
  • Usługa Azure API Management pomaga organizacjom publikować interfejsy API dla deweloperów zewnętrznych, partnerskich i wewnętrznych w celu korzystania z ich danych i usług.
  • Application Gateway to moduł równoważenia obciążenia ruchu internetowego, który ułatwia zarządzanie ruchem do aplikacji internetowych.
  • Wewnętrzna Load Balancer App Service Environment to funkcja Azure App Service, która zapewnia w pełni izolowane i dedykowane środowisko do bezpiecznego uruchamiania aplikacji App Service na dużą skalę.
  • Azure DevOps to usługa do zarządzania cyklem życia programowania i obejmuje funkcje planowania i zarządzania projektami, zarządzania kodem, kompilowania i wydawania.
  • Application Insights to rozszerzalna usługa zarządzania wydajnością aplikacji (APM) dla deweloperów sieci Web na wielu platformach.
  • Azure Cosmos DB to globalnie rozproszona, wielomodelowa usługa bazy danych firmy Microsoft.

Alternatywy

Szczegóły scenariusza

W tym scenariuszu organizacja hostuje wiele interfejsów API przy użyciu środowiska usług aplikacja systemu Azure (ILB ASE) i chce skonsolidować te interfejsy API wewnętrznie przy użyciu usługi Azure API Management (APIM) wdrożonej wewnątrz Virtual Network. Wewnętrzne wystąpienie API Management może być również uwidocznione dla użytkowników zewnętrznych, aby umożliwić wykorzystanie pełnego potencjału interfejsów API. Tę ekspozycję zewnętrzną można osiągnąć przy użyciu Azure Application Gateway przekazywania żądań do wewnętrznej usługi API Management, która z kolei korzysta z interfejsów API wdrożonych w środowisku ASE.

  • Internetowe interfejsy API są hostowane za pośrednictwem zabezpieczonego protokołu HTTPS i będą używać certyfikatu TLS.
  • Application Gateway jest również skonfigurowany za pośrednictwem portu 443 na potrzeby bezpiecznych i niezawodnych wywołań wychodzących.
  • Usługa API Management jest skonfigurowana do używania domen niestandardowych przy użyciu certyfikatów TLS.
  • Przejrzyj sugerowaną konfigurację sieci dla środowisk App Service
  • Musi istnieć jawna wzmianka o porcie 3443 umożliwiająca API Management zarządzanie za pośrednictwem Azure Portal lub programu PowerShell.
  • Korzystanie z zasad w usłudze APIM w celu dodania nagłówka HOST dla interfejsu API hostowanego w środowisku ASE. Dzięki temu moduł równoważenia obciążenia środowiska ASE prawidłowo przekaże żądanie.
  • API Management akceptuje wpis DNS środowiska ASE dla wszystkich aplikacji hostowanych w środowiskach App Service. Dodaj zasady usługi APIM, aby jawnie ustawić nagłówek HOST, aby umożliwić modułowi równoważenia obciążenia środowiska ASE rozróżnianie aplikacji w ramach App Service Environment.
  • Rozważ integrację z usługą aplikacja systemu Azure Insights, która udostępnia również metryki za pośrednictwem usługi Azure Monitor na potrzeby monitorowania.
  • Jeśli używasz potoków ciągłej integracji/ciągłego wdrażania do wdrażania wewnętrznych interfejsów API, rozważ utworzenie własnego hostowanego agenta na maszynie wirtualnej wewnątrz Virtual Network.

Potencjalne przypadki użycia

  • Synchronizuj informacje o adresie klienta wewnętrznie po wprowadzeniu zmiany przez klienta.
  • Przyciągaj deweloperów do swojej platformy, ujawniając unikatowe zasoby danych.

Zagadnienia do rozważenia

Te zagadnienia implementują filary platformy Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Niezawodność

Niezawodność zapewnia, że aplikacja może spełnić zobowiązania podjęte wobec klientów. Aby uzyskać więcej informacji, zobacz Omówienie filaru niezawodności".

Dostępność

Usługę Azure API Management można wdrożyć jako wdrożenie w wielu regionach w celu zwiększenia dostępności, a także zmniejszyć opóźnienia. Ta funkcja jest dostępna tylko w trybie Premium. Usługa API Management w tym konkretnym scenariuszu korzysta z interfejsów API ze środowisk App Service. Możesz również użyć usługi APIM dla interfejsów API hostowanych w wewnętrznej infrastrukturze lokalnej.

App Service Środowiska mogą korzystać z profilów usługi Traffic Manager w celu dystrybucji ruchu hostowanego w środowiskach App Service w celu uzyskania wyższej skali i dostępności.

Odporność

Chociaż w tym przykładowym scenariuszu omówiono więcej informacji o konfiguracji, interfejsy API hostowane w środowiskach App Service powinny być wystarczająco odporne, aby obsługiwać błędy w żądaniach, które są ostatecznie zarządzane przez usługę API Management i Application Gateway. Rozważ ponawianie prób i wzorce wyłącznika w projekcie interfejsu API. Aby uzyskać ogólne wskazówki dotyczące projektowania odpornych rozwiązań, zobacz Projektowanie odpornych aplikacji na platformę Azure.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru zabezpieczeń.

Ponieważ poprzedni przykładowy scenariusz jest hostowany całkowicie w sieci wewnętrznej, API Management i środowisko ASE są już wdrażane w zabezpieczonej infrastrukturze (sieci wirtualnej platformy Azure). Usługę Application Gateway można zintegrować z Microsoft Defender for Cloud, aby zapewnić bezproblemowy sposób zapobiegania zagrożeniom w środowisku, wykrywania ich i reagowania na nie. Aby uzyskać ogólne wskazówki dotyczące projektowania bezpiecznych rozwiązań, zobacz dokumentację zabezpieczeń platformy Azure.

Optymalizacja kosztów

Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.

API Management jest oferowana w czterech warstwach: deweloper, podstawowy, standardowy i premium. Szczegółowe wskazówki dotyczące różnic w tych warstwach można znaleźć w artykule Azure API Management pricing guidance (Wskazówki dotyczące cen usługi Azure API Management).

Klienci mogą skalować API Management, dodając i usuwając jednostki. Każda jednostka ma pojemność, która zależy od jej warstwy.

Uwaga

Warstwę Deweloper można użyć do oceny funkcji API Management. Nie należy używać warstwy Deweloper w środowisku produkcyjnym.

Aby wyświetlić przewidywane koszty i dostosować je do potrzeb związanych z wdrożeniem, możesz zmodyfikować liczbę jednostek skalowania i App Service wystąpień w kalkulatorze cen platformy Azure.

Podobnie można znaleźć wskazówki dotyczące cen App Service Environments.

Możesz skonfigurować Application Gateway ceny w zależności od wymaganej warstwy i zasobów.

Efektywność wydajności

Efektywność wydajności to możliwość skalowania obciążenia w celu zaspokojenia zapotrzebowania użytkowników w wydajny sposób. Aby uzyskać więcej informacji, zobacz Omówienie filaru wydajności wydajności.

Skalowalność

Możesz skalować w poziomie API Management wystąpień w zależności od wielu czynników, takich jak liczba i szybkość połączeń współbieżnych, rodzaj i liczba skonfigurowanych zasad, rozmiary żądań i odpowiedzi oraz opóźnienia zaplecza w interfejsach API. Opcje skalowania wystąpienia w poziomie są dostępne w warstwach Podstawowa, Standardowa i Premium, ale są ograniczone przez górny limit skali w warstwach Podstawowa i Standardowa. Wystąpienia są określane jako Jednostki i można je skalować w górę do maksymalnie dwóch jednostek w warstwie Podstawowa, cztery jednostki w warstwie Standardowa i dowolną liczbę jednostek w warstwie Premium. Dostępne są również opcje automatycznego skalowania w celu włączenia skalowania w poziomie na podstawie reguł.

App Service Środowiska są przeznaczone do skalowania z limitami opartymi na warstwie cenowej. Aplikacje hostowane w ramach środowisk App Service można skonfigurować do skalowania w poziomie (liczby wystąpień) lub skalowania w górę (rozmiar wystąpienia) w zależności od wymagań aplikacji.

Azure Application Gateway skalowanie automatyczne jest dostępne jako część jednostki SKU strefowo nadmiarowej we wszystkich regionach globalnych platformy Azure. Zobacz funkcję publicznej wersji zapoznawczej dotyczącą automatycznego skalowania usługi App Gateway.

Wdrażanie tego scenariusza

Wymagania wstępne i założenia

  1. Musisz kupić niestandardową nazwę domeny.
  2. Potrzebujesz certyfikatu TLS (użyliśmy certyfikatu wieloznacznego z usługi Certyfikaty platformy Azure), aby użyć go dla wszystkich naszych domen niestandardowych. Możesz również uzyskać certyfikat z podpisem własnym dla scenariuszy tworzenia testów.
  3. To konkretne wdrożenie używa nazwy domeny contoso.org i wieloznaczny certyfikat TLS dla domeny.
  4. Wdrożenie używa nazw zasobów i przestrzeni adresowych wymienionych w sekcji Wdrażanie. Nazwy zasobów i przestrzenie adresowe można skonfigurować.

Wdrażanie i łączenie elementów

Wdróż na platformie Azure

Należy jeszcze bardziej skonfigurować składniki wdrożone przy użyciu poprzedniego szablonu Resource Manager w następujący sposób:

  1. Sieć wirtualna z następującymi konfiguracjami:

    • Nazwa: ase-internal-vnet
    • Przestrzeń adresowa sieci wirtualnej: 10.0.0.0/16
    • Cztery podsieci
      • backendSubnet dla usługi DNS: 10.0.0.0/24
      • apimsubnetdla wewnętrznej usługi API Management: 10.0.1.0/28
      • asesubnet dla środowiska ASE z wewnętrznym modułem równoważenia obciążenia: 10.0.2.0/24
      • VmSubnet for Test VMs and Internal DevOps Hosted Agent VM: 10.0.3.0/24

  2. usługa Prywatna strefa DNS (publiczna wersja zapoznawcza), ponieważ dodanie usługi DNS wymaga, aby sieć wirtualna byłaby pusta.

  3. App Service Environment z opcją Wewnętrznego Load Balancer (ILB): aseinternal (DNS: aseinternal.contoso.org). Po zakończeniu wdrażania przekaż certyfikat wieloznaczny dla modułu równoważenia obciążenia

  4. plan App Service z usługą ASE jako lokalizacją

  5. Aplikacja interfejsu API (App Services dla uproszczenia) — srasprest (adres URL: https://srasprest.contoso.org) — ASP.NET internetowy interfejs API oparty na mvC. Po wdrożeniu skonfiguruj:

    • Aplikacja internetowa do używania certyfikatu TLS
    • Usługa Application Insights do powyższych aplikacji: api-insights
    • Utwórz usługę Azure Cosmos DB dla internetowych interfejsów API hostowanych w sieci wirtualnej: noderestapidb
    • Tworzenie wpisów DNS w utworzonej strefie Prywatna strefa DNS
    • Za pomocą usługi Azure Pipelines można skonfigurować agentów w Virtual Machines w celu wdrożenia kodu dla aplikacji internetowej w sieci wewnętrznej
    • Aby wewnętrznie przetestować aplikację interfejsu API, utwórz testową maszynę wirtualną w podsieci sieci wirtualnej

  6. Tworzenie usługi API Management:apim-internal

  7. Skonfiguruj usługę, aby nawiązać połączenie z wewnętrzną siecią wirtualną w podsieci: apimsubnet. Po zakończeniu wdrażania wykonaj następujące dodatkowe kroki:

    • Konfigurowanie domen niestandardowych dla usług APIM Przy użyciu protokołu TLS
      • Portal interfejsu API (api.contoso.org)
      • Portal deweloperski (portal.contoso.org)
      • W sekcji Interfejsy API skonfiguruj aplikacje ASE przy użyciu nazwy DNS środowiska ASE dodane zasady dla nagłówka HOSTA dla aplikacji internetowej
      • Użyj poprzedniej utworzonej testowej maszyny wirtualnej, aby przetestować wewnętrzną usługę API Management w Virtual Network

    Uwaga

    Testowanie interfejsów APIM z Azure Portal nie będzie działać, ponieważ api.contoso.org nie można rozpoznać publicznie.*

  8. Skonfiguruj Application Gateway (WAF V1), aby uzyskać dostęp do usługi interfejsu API: apim-gateway na porcie 80. Dodaj certyfikaty TLS do Application Gateway i odpowiednie sondy kondycji i ustawienia http. Skonfiguruj również reguły i odbiorniki, aby używać certyfikatu TLS.

Po pomyślnym zakończeniu powyższych kroków skonfiguruj wpisy DNS w wpisach CNAME rejestratora sieci Web api.contoso.org i portal.contoso.org za pomocą publicznej nazwy DNS Application Gateway: ase-appgtwy.westus.cloudapp.azure.com. Sprawdź, czy możesz uzyskać dostęp do portalu deweloperskiego z poziomu publicznego i czy możesz przetestować interfejsy API usług APIM przy użyciu Azure Portal.

Uwaga

Nie jest dobrym rozwiązaniem, aby użyć tego samego adresu URL dla wewnętrznych i zewnętrznych punktów końcowych dla usług APIM (choć w tym pokazie oba adresy URL są takie same). Jeśli zdecydujesz się mieć różne adresy URL dla wewnętrznych i zewnętrznych punktów końcowych, możesz skorzystać z Application Gateway zapory aplikacji internetowej w wersji 2, która obsługuje przekierowywanie http i wiele innych.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następującego współautora.

Główny autor:

Inni współautorzy:

Aby wyświetlić niepubliowe profile usługi LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Migrowanie aplikacji internetowej przy użyciu usługi Azure API Management