Edytuj

Udostępnij za pośrednictwem

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

Azure API Management
Azure Monitor
Azure App Service

W tym scenariuszu firma handlu elektronicznego w branży podróży migruje starszą aplikację internetową przy użyciu usługi Azure API Management. Nowy interfejs użytkownika będzie hostowany jako aplikacja typu platforma jako usługa (PaaS) na platformie Azure i będzie zależeć zarówno od istniejących, jak i nowych interfejsów API PROTOKOŁU HTTP. Te interfejsy API będą dostarczane z lepiej zaprojektowanym zestawem interfejsów, co umożliwi lepszą wydajność, łatwiejszą integrację i rozszerzalność w przyszłości.

Architektura

Diagram architektury

Pobierz plik programu Visio tej architektury.

Przepływ pracy

  1. Istniejąca lokalna aplikacja internetowa nadal korzysta bezpośrednio z istniejących lokalnych usług sieci Web.
  2. Wywołania z istniejącej aplikacji internetowej do istniejących usług HTTP pozostają niezmienione. Te wywołania są wewnętrzne w sieci firmowej.
  3. Wywołania przychodzące są wykonywane z platformy Azure do istniejących usług wewnętrznych:
  4. Nowy interfejs API:
  5. Nowa aplikacja internetowa oparta na przeglądarce zależy od wystąpienia usługi Azure API Management zarówno dla istniejącego interfejsu API HTTP, jak i nowego interfejsu API.
  6. Firma zajmująca się handlem elektronicznym może teraz skierować niektórych użytkowników do nowego interfejsu użytkownika (w wersji zapoznawczej lub testowania), zachowując stary interfejs użytkownika i istniejące funkcje obok siebie.

Wystąpienie usługi API Management jest skonfigurowane do mapowania starszych usług HTTP na nowy kontrakt interfejsu API. W tej konfiguracji nowy interfejs użytkownika sieci Web nie jest świadomy integracji z zestawem starszych usług/interfejsów API i nowych interfejsów API.

W przyszłości zespół projektu będzie stopniowo przenosić funkcje do nowych interfejsów API i wycofać oryginalne usługi. Zespół będzie obsługiwał te zmiany w konfiguracji usługi API Management, pozostawiając interfejs użytkownika frontonu bez wpływu i unikając prac nad przebudową.

Składniki

  • Usługa Azure API Management abstrakcję interfejsów API zaplecza oraz dodawanie funkcji i odnajdywania krzyżowego dla deweloperów i aplikacji. W tym scenariuszu zmiana położenia istniejących starszych interfejsów API zaplecza i dodanie nowych funkcji interfejsu API jest możliwe przy użyciu usługi API Management jako fasady dla nowej aplikacji klienckiej w celu spójnego korzystania z nowoczesnych standardów. Ponieważ fasady usługi API Management są zarówno istniejące, jak i nowe interfejsy API, deweloperzy mogą zmodernizować starsze zaplecza za fasadą usługi API Management w sposób iteracyjny i z minimalnym do zerowym wpływem na nowe programowanie frontonu.
  • aplikacja systemu Azure Service to kompleksowa usługa platformy jako usługi (PaaS) do hostowania w Internecie, która udostępnia gotowe funkcje, takie jak zabezpieczenia, równoważenie obciążenia, skalowanie automatyczne i zautomatyzowane zarządzanie. aplikacja systemu Azure Service to doskonały wybór dla nowych interfejsów API opracowywanych dla tego rozwiązania, ponieważ zapewnia elastyczny hosting klucza, umożliwiając zespołowi DevOps skoncentrowanie się na dostarczaniu funkcji.

Alternatywy

  • Jeśli organizacja planuje przenieść swoją infrastrukturę całkowicie na platformę Azure, w tym maszyny wirtualne, które hostuje starsze aplikacje, usługa API Management jest nadal doskonałym rozwiązaniem, ponieważ może działać jako fasada dla dowolnego adresowego punktu końcowego HTTP.

  • Jeśli organizacja zdecydowała się zachować istniejące punkty końcowe jako prywatne i nie uwidocznić ich publicznie, wystąpienie usługi API Management organizacji może być połączone z usługą Azure Virtual Network:

  • Organizacja może zachować prywatne wystąpienie usługi API Management, wdrażając je w trybie wewnętrznym. Organizacja może następnie używać wdrożenia z usługą aplikacja systemu Azure Gateway, aby umożliwić dostęp publiczny dla niektórych interfejsów API, podczas gdy inne pozostają wewnętrzne. Aby uzyskać więcej informacji, zobacz Integrowanie usługi API Management w wewnętrznej sieci wirtualnej z usługą Application Gateway.

  • Organizacja może zdecydować się na hostowanie lokalnych interfejsów API. Jedną z przyczyn tej zmiany może być to, że organizacja nie może przenieść zależności podrzędnej bazy danych, które znajdują się w zakresie tego projektu do chmury. Jeśli tak jest, organizacja nadal może korzystać z usługi API Management lokalnie przy użyciu własnej bramy.

    Brama hostowana samodzielnie jest konteneryzowanym wdrożeniem bramy usługi API Management, które łączy się z platformą Azure w gniazdie wychodzącym. Pierwszym wymaganiem wstępnym jest to, że nie można wdrożyć bram hostowanych samodzielnie bez zasobu nadrzędnego na platformie Azure, co wiąże się z dodatkową opłatą. Po drugie, wymagana jest warstwa Premium usługi API Management.

Szczegóły scenariusza

Firma zajmująca się handlem elektronicznym w branży podróży modernizuje swój starszy stos oprogramowania oparty na przeglądarce. Chociaż istniejący stos jest głównie monolityczny, niektóre usługi HTTP oparte na protokole SIMPLE Object Access Protocol (SOAP) istnieją w ostatnim projekcie. Firma rozważa utworzenie dodatkowych strumieni przychodów, aby zarobić na niektórych z wewnętrznych własności intelektualnej, które opracowała.

Cele projektu obejmują rozwiązywanie problemów technicznych, poprawę ciągłej konserwacji i przyspieszanie opracowywania funkcji przy mniejszej liczbie usterek regresji. W projekcie zostanie użyty proces iteracyjny, aby uniknąć ryzyka, a niektóre kroki wykonywane równolegle:

  • Zespół deweloperów zmodernizuje zaplecze aplikacji, które składa się z relacyjnych baz danych hostowanych na maszynach wirtualnych.
  • Zespół deweloperów w firmie napisze nowe funkcje biznesowe, które zostaną ujawnione za pośrednictwem nowych interfejsów API HTTP.
  • Zespół deweloperów kontraktów utworzy nowy interfejs użytkownika oparty na przeglądarce, który będzie hostowany na platformie Azure.

Nowe funkcje aplikacji zostaną dostarczone na etapach. Te funkcje będą stopniowo zastępować istniejącą funkcję interfejsu użytkownika klienta/serwera opartą na przeglądarce (hostowaną lokalnie), która obecnie obsługuje firmę zajmującą się handlem elektronicznym.

Członkowie zespołu zarządzającego nie chcą niepotrzebnie modernizować. Chcą również zachować kontrolę nad zakresem i kosztami. W tym celu zdecydowali się zachować istniejące usługi PROTOKOŁU HTTP protokołu SOAP. Zamierzają również zminimalizować zmiany istniejącego interfejsu użytkownika. Mogą oni używać usługi Azure API Management , aby spełnić wiele wymagań i ograniczeń projektu.

Potencjalne przypadki użycia

Ten scenariusz wyróżnia modernizację starszych stosów oprogramowania opartych na przeglądarce.

Tego scenariusza można użyć do:

  • Zobacz, jak Twoja firma może korzystać z ekosystemu platformy Azure.
  • Planowanie migracji usług na platformę Azure.
  • Dowiedz się, jak przejście na platformę Azure wpłynie na istniejące interfejsy API.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary platformy Azure Well-Architected Framework, która jest zestawem wytycznych, które pomagają poprawić jakość 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 przez klientów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca niezawodności.

  • Rozważ wdrożenie wystąpienia usługi Azure API Management z włączonymi strefami dostępności. Opcja wdrażania usługi API Management w strefach dostępności jest dostępna tylko w warstwie usługi Premium.
  • Strefy dostępności mogą być używane w połączeniu z dodatkowymi wystąpieniami bramy wdrożonym w różnych regionach. Zwiększa to dostępność usługi, jeśli jeden region przejdzie w tryb offline. Wdrożenie w wielu regionach jest również dostępne tylko w warstwie usługi Premium.
  • 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. Na przykład metryka pojemności może służyć do określenia ogólnego obciążenia zasobu usługi API Management i określenia, czy są wymagane dodatkowe jednostki skalowania w poziomie. Śledzenie pojemności zasobów i kondycji zwiększa niezawodność.
  • Upewnij się, że zależności podrzędne, na przykład usługi zaplecza hostujące interfejsy API, które są odporne na fasady usługi API Management.

Optymalizacja kosztów

Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca optymalizacji kosztów.

Usługa API Management jest oferowana w czterech warstwach: Developer, Basic, Standard i Premium. Aby uzyskać szczegółowe wskazówki dotyczące różnic w tych warstwach, zobacz wskazówki dotyczące cen usługi Azure API Management.

Usługę API Management można skalować, dodając i usuwając jednostki. Każda jednostka ma pojemność zależną od jej warstwy.

Uwaga

Warstwę Deweloper można użyć do oceny funkcji usługi API Management. Nie używaj go do produkcji.

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

Współautorzy

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

Główny autor:

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

Następne kroki

Dokumentacja produktu:

Moduły szkoleniowe: