Ta architektura referencyjna używa usług Azure Integration Services do organizowania wywołań do systemów zaplecza przedsiębiorstwa. Systemy zaplecza mogą obejmować systemy oprogramowania jako usługi (SaaS), usługi platformy Azure i istniejące usługi internetowe w przedsiębiorstwie.
Architektura
Pobierz plik programu Visio z tą architekturą.
Przepływ pracy
Systemy zaplecza. Po prawej stronie diagramu przedstawiono różne systemy zaplecza wdrożone lub zależne od przedsiębiorstwa. Te systemy mogą obejmować systemy SaaS, inne usługi platformy Azure lub usługi internetowe, które uwidaczniają punkty końcowe REST lub SOAP.
Usługa Azure Logic Apps. W tej architekturze aplikacje logiki są wyzwalane przez żądania HTTP. Można również zagnieżdżać przepływy pracy w celu bardziej złożonej aranżacji. Usługa Logic Apps używa łączników do integracji z powszechnie używanymi usługami. Usługa Logic Apps oferuje setki łączników i można tworzyć łączniki niestandardowe.
Azure API Management. Usługa API Management składa się z dwóch powiązanych składników:
Brama interfejsu API. Brama interfejsu API akceptuje wywołania HTTP i kieruje je do zaplecza.
Portal dla deweloperów. Każde wystąpienie usługi Azure API Management zapewnia dostęp do portalu deweloperów. Ten portal zapewnia deweloperom dostęp do dokumentacji i przykładów kodu do wywoływania interfejsów API. Interfejsy API można również przetestować w portalu dla deweloperów.
Azure DNS. Usługa Azure DNS zapewnia rozpoznawanie nazw przy użyciu infrastruktury platformy Azure. Hostując domeny na platformie Azure, możesz zarządzać rekordami DNS przy użyciu tych samych poświadczeń, interfejsów API, narzędzi i rozliczeń, które są używane dla innych usług platformy Azure. Aby użyć niestandardowej nazwy domeny, takiej jak contoso.com, utwórz rekordy DNS mapujące niestandardową nazwę domeny na adres IP. Aby uzyskać więcej informacji, zobacz Konfigurowanie niestandardowej nazwy domeny w usłudze API Management.
Microsoft Entra ID. Użyj identyfikatora Entra firmy Microsoft, aby uwierzytelnić klientów wywołujących bramę interfejsu API. Identyfikator Entra firmy Microsoft obsługuje protokół OpenID Connect (OIDC). Klienci uzyskują token dostępu z identyfikatora Entra firmy Microsoft, a usługa API Gateway weryfikuje token w celu autoryzowania żądania. Jeśli używasz warstwy Standardowa lub Premium usługi API Management, identyfikator Entra firmy Microsoft może również pomóc w zabezpieczeniu dostępu do portalu dla deweloperów.
Składniki
- Integration Services to kolekcja usług, których można używać do integrowania aplikacji, danych i procesów.
- Logic Apps to bezserwerowa platforma do tworzenia przepływów pracy przedsiębiorstwa, które integrują aplikacje, dane i usługi.
- USŁUGA API Management to zarządzana usługa do publikowania wykazów interfejsów API HTTP. Służy do promowania ponownego użycia i możliwości odnajdywania interfejsów API oraz wdrażania bramy interfejsu API do żądań interfejsu API serwera proxy.
- Usługa Azure DNS jest usługą hostingu dla domen DNS.
- Microsoft Entra ID to oparta na chmurze usługa zarządzania tożsamościami i dostępem. Pracownicy przedsiębiorstwa mogą używać identyfikatora Entra firmy Microsoft do uzyskiwania dostępu do zasobów zewnętrznych i wewnętrznych.
Szczegóły scenariusza
Integration Services to zbiór usług, których można używać do integrowania aplikacji, danych i procesów dla przedsiębiorstwa. Ta architektura używa dwóch z tych usług: Logic Apps do organizowania przepływów pracy i usługi API Management w celu tworzenia wykazów interfejsów API.
W tej architekturze złożone interfejsy API są tworzone przez importowanie aplikacji logiki jako interfejsów API. Istniejące usługi internetowe można również zaimportować, importując specyfikacje interfejsu OpenAPI (Swagger) lub importując interfejsy API protokołu SOAP ze specyfikacji WSDL.
Brama interfejsu API pomaga rozdzielić klientów frontonu z zaplecza. Może na przykład ponownie napisać adresy URL lub przekształcić żądania, zanim dotrą do zaplecza. Obsługuje również wiele zagadnień krzyżowych, takich jak uwierzytelnianie, obsługa współużytkowania zasobów między źródłami (CORS) i buforowanie odpowiedzi.
Potencjalne przypadki użycia
Ta architektura jest wystarczająca w przypadku podstawowych scenariuszy integracji, w których przepływ pracy jest wyzwalany przez synchroniczne wywołania usług zaplecza. Bardziej zaawansowana architektura korzystająca z kolejek i zdarzeń opiera się na tej podstawowej architekturze.
Zalecenia
Określone wymagania mogą różnić się od ogólnej architektury przedstawionej tutaj. Użyj zaleceń w tej sekcji jako punktu wyjścia.
API Management
Użyj warstwy Podstawowa, Standardowa lub Premium usługi API Management. Te warstwy oferują umowę dotyczącą poziomu usług produkcyjnych (SLA) i obsługę techniczną skalowaną w poziomie w regionie świadczenia usługi Azure. Pojemność przepływności usługi API Management jest mierzona w jednostkach. Każda warstwa cenowa ma maksymalną skalę w poziomie. Warstwa Premium obsługuje również skalowanie w poziomie w wielu regionach świadczenia usługi Azure. Wybierz warstwę na podstawie zestawu funkcji i poziomu wymaganej przepływności. Aby uzyskać więcej informacji, zobacz Cennik usługi API Management i Pojemność wystąpienia usługi Azure API Management.
Każde wystąpienie usługi Azure API Management ma domyślną nazwę domeny, która jest poddomeną azure-api.net, na przykład contoso.azure-api.net. Rozważ skonfigurowanie domeny niestandardowej dla organizacji.
Logic Apps
Usługa Logic Apps działa najlepiej w scenariuszach, które nie wymagają małych opóźnień dla odpowiedzi, takich jak asynchroniczne lub częściowo długotrwałe wywołania interfejsu API. Jeśli wymagane jest małe opóźnienie, na przykład w wywołaniu blokującym interfejs użytkownika, użyj innej technologii. Na przykład użyj usługi Azure Functions lub internetowego interfejsu API wdrożonego w usłudze aplikacja systemu Azure Service. Użyj usługi API Management, aby uruchomić interfejs API dla użytkowników interfejsu API.
Region (Region)
Aby zminimalizować opóźnienie sieci, umieść usługi API Management i Logic Apps w tym samym regionie. Ogólnie rzecz biorąc, wybierz region, który jest najbliżej Twoich użytkowników (lub najbliżej usług zaplecza).
Kwestie wymagające rozważenia
Te zagadnienia implementują filary platformy Azure Well-Architected Framework, która jest zestawem wytycznych, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.
Niezawodność
Niezawodność gwarantuje, że aplikacja może spełnić zobowiązania wobec klientów. Aby uzyskać więcej informacji, zobacz Omówienie filaru niezawodności.
Przejrzyj umowę SLA dla każdej usługi:
Jeśli wdrożysz usługę API Management w co najmniej dwóch regionach z warstwą Premium, kwalifikuje się ona do uzyskania wyższej umowy SLA. Zobacz Cennik usługi API Management.
Kopie zapasowe
Regularnie kopię zapasową konfiguracji usługi API Management. Przechowuj pliki kopii zapasowej w lokalizacji lub regionie świadczenia usługi Azure, które różnią się od regionu, w którym jest wdrażana usługa. Na podstawie celu odzyskiwania po awarii wybierz strategię odzyskiwania po awarii:
W przypadku odzyskiwania po awarii aprowizacja nowego wystąpienia usługi API Management, przywracanie kopii zapasowej do nowego wystąpienia i ponowne określanie rekordów DNS.
Zachowaj pasywne wystąpienie usługi API Management w innym regionie świadczenia usługi Azure. Regularnie przywracaj kopie zapasowe do tego wystąpienia, aby zachować synchronizację z aktywną usługą. Aby przywrócić usługę podczas zdarzenia odzyskiwania po awarii, musisz tylko ponownie wskazać rekordy DNS. Takie podejście wiąże się z dodatkowymi kosztami, ponieważ płacisz za wystąpienie pasywne, ale skraca czas odzyskiwania.
W przypadku aplikacji logiki zalecamy podejście konfiguracji jako kodu do tworzenia kopii zapasowych i przywracania. Ponieważ aplikacje logiki są bezserwerowe, można je szybko odtworzyć za pomocą szablonów usługi Azure Resource Manager. Zapisz szablony w kontroli źródła, zintegruj szablony z procesem ciągłej integracji/ciągłego wdrażania (CI/CD). W przypadku odzyskiwania po awarii wdróż szablon w nowym regionie.
Jeśli wdrożysz aplikację logiki w innym regionie, zaktualizuj konfigurację w usłudze API Management. Właściwość zaplecza interfejsu API można zaktualizować przy użyciu podstawowego skryptu programu PowerShell.
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ń.
Chociaż ta lista nie opisuje całkowicie wszystkich najlepszych rozwiązań w zakresie zabezpieczeń, poniżej przedstawiono niektóre zagadnienia dotyczące zabezpieczeń, które dotyczą konkretnie tej architektury:
Usługa Azure API Management ma stały publiczny adres IP. Ogranicz dostęp do wywoływania punktów końcowych usługi Logic Apps tylko do adresu IP usługi API Management. Aby uzyskać więcej informacji, zobacz Ograniczanie przychodzących adresów IP.
Aby upewnić się, że użytkownicy mają odpowiednie poziomy dostępu, użyj kontroli dostępu opartej na rolach (RBAC) platformy Azure.
Zabezpieczanie publicznych punktów końcowych interfejsu API w usłudze API Management przy użyciu protokołu OAuth lub OpenID Connect. Aby zabezpieczyć publiczne punkty końcowe interfejsu API, skonfiguruj dostawcę tożsamości i dodaj zasady weryfikacji tokenu internetowego JSON (JWT). Aby uzyskać więcej informacji, zobacz Protect an API by using OAuth 2.0 with Microsoft Entra ID and API Management (Ochrona interfejsu API przy użyciu protokołu OAuth 2.0 przy użyciu identyfikatora Entra firmy Microsoft i usługi API Management).
Nawiąż połączenie z usługami zaplecza z usługi API Management przy użyciu wspólnych certyfikatów.
Wymuszanie protokołu HTTPS na interfejsach API usługi API Management.
Przechowywanie wpisów tajnych
Nigdy nie ewidencjonuj haseł, kluczy dostępu ani parametrów połączenia w systemie kontroli kodu źródłowego. Jeśli te wartości są wymagane, należy zabezpieczyć je i wdrożyć przy użyciu odpowiednich technik.
Jeśli aplikacja logiki wymaga żadnych poufnych wartości, których nie można utworzyć w ramach łącznika, zapisz te wartości w usłudze Azure Key Vault i odwołaj się do nich z szablonu usługi Resource Manager. Użyj parametrów szablonu wdrożenia i plików parametrów dla każdego środowiska. Aby uzyskać więcej informacji, zobacz Zabezpieczanie parametrów i danych wejściowych w przepływie pracy.
Usługa API Management zarządza wpisami tajnymi przy użyciu obiektów nazywanych nazwanymi wartościami lub właściwościami. Te obiekty bezpiecznie przechowują wartości, do których można uzyskać dostęp za pośrednictwem zasad usługi API Management. Aby uzyskać więcej informacji, zobacz How to use Named Values in Azure API Management policies (Jak używać nazwanych wartości w zasadach usługi Azure API Management).
Doskonałość operacyjna
Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Omówienie filaru doskonałości operacyjnej.
DevOps
Utwórz oddzielne grupy zasobów dla środowisk produkcyjnych, programistycznych i testowych. Oddzielne grupy zasobów ułatwiają zarządzanie wdrożeniami, usuwanie wdrożeń testowych i przypisywanie praw dostępu.
Podczas przypisywania zasobów do grup zasobów należy wziąć pod uwagę następujące czynniki:
Cykl życia. Ogólnie rzecz biorąc, umieszczaj zasoby z tym samym cyklem życia w tej samej grupie zasobów.
Dostęp. Aby zastosować zasady dostępu do zasobów w grupie, możesz użyć kontroli dostępu na podstawie ról (RBAC) platformy Azure.
Rozliczenia. Możesz wyświetlić koszty zestawienia dla grupy zasobów.
Warstwa cenowa usługi API Management. Dla środowisk deweloperskich i testowych używaj warstwy Deweloper. Aby zminimalizować koszty środowiska przedprodukcyjnego, wdróż replikę środowiska produkcyjnego, przeprowadź testy, a następnie zamknij.
Wdrożenie
Użyj szablonów usługi Azure Resource Manager, aby wdrożyć zasoby platformy Azure, postępuj zgodnie z procedurą infrastruktury jako kod (IaC). Szablony ułatwiają automatyzowanie wdrożeń przy użyciu usług Azure DevOps Services lub innych rozwiązań ciągłej integracji/ciągłego wdrażania.
Przygotowanie
Rozważ przygotowanie obciążeń, co oznacza wdrożenie na różnych etapach i uruchomienie walidacji na każdym etapie przed przejściem do następnego. Jeśli używasz tego podejścia, możesz wypchnąć aktualizacje do środowisk produkcyjnych w wysoce kontrolowany sposób i zminimalizować nieprzewidziane problemy z wdrażaniem. Wdrożenia niebieskie i wydania Kanary są zalecanymi strategiami wdrażania aktualizacji środowisk produkcyjnych na żywo. Należy również wziąć pod uwagę dobrą strategię wycofywania w przypadku niepowodzenia wdrożenia. Można na przykład automatycznie ponownie wdrożyć wcześniejsze, pomyślne wdrożenie z historii wdrożenia. Parametr --rollback-on-error flagi w interfejsie wiersza polecenia platformy Azure jest dobrym przykładem.
Izolacja obciążeń
Umieść usługę API Management i wszystkie poszczególne aplikacje logiki we własnych oddzielnych szablonach usługi Resource Manager. Za pomocą oddzielnych szablonów można przechowywać zasoby w systemach kontroli źródła. Szablony można wdrażać razem lub indywidualnie w ramach procesu ciągłej integracji/ciągłego wdrażania.
Wersje
Za każdym razem, gdy zmieniasz konfigurację aplikacji logiki lub wdrażasz aktualizację za pomocą szablonu usługi Resource Manager, platforma Azure przechowuje kopię tej wersji i przechowuje wszystkie wersje, które mają historię uruchamiania. Za pomocą tych wersji można śledzić zmiany historyczne lub podwyższyć poziom wersji jako bieżącą konfigurację aplikacji logiki. Na przykład możesz wycofać aplikację logiki do poprzedniej wersji.
Usługa API Management obsługuje dwa odrębne, ale uzupełniające pojęcia dotyczące przechowywania wersji:
Wersje umożliwiają użytkownikom interfejsu API wybór wersji interfejsu API na podstawie ich potrzeb, na przykład w wersji 1, wersji 2, beta lub produkcyjnej.
Poprawki umożliwiają administratorom interfejsu API wprowadzanie niezwiązanych zmian w interfejsie API i wdrażanie tych zmian wraz z dziennikiem zmian w celu informowania użytkowników interfejsu API o zmianach.
Możesz wprowadzić poprawkę w środowisku projektowym i wdrożyć zmianę w innych środowiskach przy użyciu szablonów usługi Resource Manager. Aby uzyskać więcej informacji, zobacz Publikowanie wielu wersji interfejsu API
Możesz również użyć poprawek do przetestowania interfejsu API przed wprowadzeniem zmian bieżących i dostępnych dla użytkowników. Jednak ta metoda nie jest zalecana do testowania obciążenia ani testowania integracji. Zamiast tego użyj oddzielnych środowisk testowych lub przedprodukcyjnych.
Diagnostyka i monitorowanie
Usługa Azure Monitor służy do monitorowania operacyjnego zarówno w usłudze API Management, jak i w usłudze Logic Apps. Usługa Azure Monitor udostępnia informacje na podstawie metryk skonfigurowanych dla każdej usługi i jest domyślnie włączona. Aby uzyskać więcej informacji, zobacz:
- Monitorowanie opublikowanych interfejsów API
- Monitor status, set up diagnostics logging, and turn on alerts for Azure Logic Apps (Monitorowanie stanu, konfigurowania rejestrowania diagnostycznego i włączanie alertów w usłudze Azure Logic Apps)
Każda usługa ma również następujące opcje:
Aby uzyskać dokładniejsze analizy i pulpity nawigacyjne, wyślij dzienniki usługi Logic Apps do usługi Azure Log Analytics.
W przypadku monitorowania metodyki DevOps skonfiguruj usługę aplikacja systemu Azure Insights dla usługi API Management.
Usługa API Management obsługuje szablon rozwiązania Power BI na potrzeby niestandardowej analizy interfejsu API. Możesz użyć tego szablonu rozwiązania do tworzenia własnego rozwiązania analitycznego. W przypadku użytkowników biznesowych usługa Power BI udostępnia raporty.
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.
Aby zwiększyć skalowalność usługi API Management, w razie potrzeby dodaj zasady buforowania. Buforowanie pomaga również zmniejszyć obciążenie usług zaplecza.
Aby zapewnić większą pojemność, możesz skalować w poziomie warstwy Podstawowa, Standardowa i Premium usługi Azure API Management w regionie świadczenia usługi Azure. Aby przeanalizować użycie usługi, wybierz pozycję Metryka pojemności w menu Metryki , a następnie odpowiednio przeprowadź skalowanie w górę lub w dół. Ukończenie procesu uaktualniania lub skalowania może potrwać od 15 do 45 minut.
Zalecenia dotyczące skalowania usługi API Management:
Podczas skalowania należy wziąć pod uwagę wzorce ruchu. Klienci z bardziej niestabilnymi wzorcami ruchu potrzebują większej pojemności.
Spójna pojemność większa niż 66% może wskazywać na konieczność skalowania w górę.
Spójna pojemność poniżej 20% może wskazywać na możliwość skalowania w dół.
Przed włączeniem obciążenia w środowisku produkcyjnym zawsze przetestuj usługę API Management przy użyciu reprezentatywnego obciążenia.
Warstwa Premium umożliwia skalowanie wystąpienia usługi API Management w wielu regionach świadczenia usługi Azure. Dzięki temu usługa API Management kwalifikuje się do wyższej umowy SLA i umożliwia aprowizację usług w pobliżu użytkowników w wielu regionach.
Model bezserwerowy usługi Logic Apps oznacza, że administratorzy nie muszą planować skalowalności usługi. Usługa jest automatycznie skalowana w celu spełnienia wymagań.
Optymalizacja kosztów
Ogólnie rzecz biorąc, możesz szacować koszty za pomocą kalkulatora cen platformy Azure. Oto kilka innych zagadnień.
API Management
Opłaty są naliczane za wszystkie wystąpienia usługi API Management, gdy są uruchomione. Jeśli skalowanie w górę i nie jest wymagane przez cały czas tego poziomu wydajności, ręczne skalowanie w dół lub konfigurowanie skalowania automatycznego.
Logic Apps
Usługa Logic Apps używa modelu bezserwerowego. Rozliczenia są obliczane na podstawie akcji i wykonywania łącznika. Aby uzyskać więcej informacji, zobacz Cennik usługi Logic Apps.
Aby uzyskać więcej informacji, zapoznaj się z sekcją kosztów w temacie Dobrze zaprojektowana struktura platformy Microsoft Azure.
Następne kroki
Powiązane zasoby
Aby zapewnić większą niezawodność i skalowalność, użyj kolejek komunikatów i zdarzeń, aby rozdzielić systemy zaplecza. Ta architektura jest pokazana w następnym artykule z tej serii:
Możesz również zainteresować się następującymi artykułami z Centrum architektury platformy Azure: