Integrowanie systemów przedsiębiorstwa przy użyciu brokera komunikatów i zdarzeń

Azure Event Grid
Azure Service Bus

Ta architektura jest oparta na podstawowej architekturze integracji przedsiębiorstwa , ale obejmuje sposób integrowania systemów zaplecza przedsiębiorstwa. Ta architektura używa brokerów komunikatów i zdarzeń do oddzielenia usług w celu zwiększenia skalowalności i niezawodności. Upewnij się, że znasz projekt i składniki w podstawowej architekturze integracji. Te elementy zawierają podstawowe informacje o podstawowych składnikach tej architektury.

Architektura

Systemy zaplecza, do których odwołuje się ten projekt, obejmują systemy oprogramowania jako usługi (SaaS), usługi Azure, usługi oparte na komunikatach i istniejące usługi internetowe w przedsiębiorstwie.

Diagram przedstawiający architekturę odniesienia dla integracji przedsiębiorstwa, która wykorzystuje kolejki i zdarzenia.

Pobierz plik Visio tej architektury.

Szczegóły scenariusza

Poprzednia architektura opiera się na podstawowej architekturze integracji przedsiębiorstwa. Używa Azure Logic Apps do organizowania przepływów pracy bezpośrednio z systemami zaplecza i używa Azure API Management do tworzenia wykazów interfejsów API.

Ta wersja architektury dodaje dwa składniki, które pomagają uczynić system bardziej niezawodnym i skalowalnym:

Ta architektura używa komunikacji asynchronicznej za pośrednictwem brokera komunikatów zamiast bezpośrednich synchronicznych wywołań do usług zaplecza. Komunikacja asynchroniczna zapewnia następujące korzyści:

  • Używa wzorca wyrównywania obciążenia opartego na kolejce do obsługi wzrostów obciążeń.

  • Używa wzorcaPublisher-Subscriber , aby można było emitować komunikaty do wielu użytkowników

  • Śledzi postęp długotrwałych przepływów pracy niezawodnie, nawet jeśli obejmują one wiele kroków lub wiele aplikacji

  • Ułatwia oddzielenie aplikacji

  • Integruje się z istniejącymi systemami opartymi na komunikatach

  • Zapewnia możliwość kolejkowania komunikatów, gdy system zaplecza nie jest dostępny

Użyj Azure Event Grid, aby różne składniki systemu mogły reagować na zdarzenia podczas ich wystąpienia, zamiast polegać na sondowaniu lub zaplanowanych zadaniach. Podobnie jak w przypadku kolejki komunikatów i tematów, usługa Event Grid pomaga rozdzielić aplikacje i usługi. Jeśli aplikacja lub usługa publikuje zdarzenia, wszyscy zainteresowani subskrybenci są powiadamiani. Nowych subskrybentów można dodawać bez aktualizowania nadawcy.

Wiele usług Azure obsługuje wysyłanie zdarzeń do usługi Event Grid. Na przykład usługa Azure Logic Apps może nasłuchiwać zdarzeń, gdy do magazynu obiektów blob zostaną dodane nowe pliki. Ten wzorzec tworzy reaktywne przepływy pracy, w których przekazywanie pliku lub umieszczanie komunikatu w kolejce rozpoczyna serię procesów. Procesy mogą działać równolegle lub w określonej sekwencji.

Zalecenia

Weź pod uwagę następujące zalecenia. Aby uzyskać więcej zaleceń, zobacz Podstawowa architektura integracji dla przedsiębiorstw.

Magistrala usług

Service Bus oferuje dwa modele dostarczania: model pobierania i model pośredniczonego wypychania.

  • Model ściągania: Odbiornik stale sonduje pod kątem nowych komunikatów. Jeśli musisz zarządzać wieloma kolejkami i godzinami sondowania, sondowanie może być nieefektywne. Jednak ten model może uprościć architekturę, ponieważ usuwa dodatkowe składniki i przeskoki danych.

  • Model wypychania z proxy: Odbiorca początkowo subskrybuje określony typ zdarzenia na temat węzła Event Grid. Gdy jest dostępny nowy komunikat, Service Bus zgłasza i wysyła zdarzenie za pośrednictwem usługi Event Grid. Następnie to zdarzenie wyzwala odbiornik, aby pobrać następną partię komunikatów z Service Bus. Ten model umożliwia systemom odbieranie komunikatów niemal w czasie rzeczywistym, ale bez używania zasobów do ciągłego sondowania nowych komunikatów. Ta architektura używa dodatkowych składników, które należy wdrożyć, zarządzać i zabezpieczać.

Podczas tworzenia przepływu pracy usługi Logic Apps w warstwie Standard, który wykorzystuje komunikaty usługi Service Bus, użyj wyzwalaczy wbudowanego łącznika usługi Service Bus. Wbudowany łącznik abstrakcyjnie zarządza większością konfiguracji modelu pobierającego bez dodawania dodatkowych kosztów. Ta funkcja zapewnia właściwą równowagę między kosztami, zarządzaniem obszarem powierzchni i zabezpieczeniami, ponieważ konektor stale zapętla się w aparacie środowiska wykonawczego Logic Apps. Aby uzyskać więcej informacji, zobacz wbudowane wyzwalacze łącznika usługi Service Bus.

Użyj trybu PeekLock , aby uzyskać dostęp do grupy komunikatów. Gdy używasz aplikacji PeekLock, aplikacja logiki może wykonać kroki w celu zweryfikowania każdego komunikatu przed ukończeniem lub porzuceniem komunikatu. Takie podejście zapobiega przypadkowej utracie komunikatów.

Event Grid

Gdy wyzwalacz usługi Event Grid zostanie wyzwolony, oznacza to, że wystąpiło co najmniej jedno zdarzenie. Na przykład, gdy aplikacja logiczna otrzymuje wyzwalacz usługi Event Grid dla komunikatu Service Bus, może istnieć kilka komunikatów dostępnych do przetworzenia.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary struktury Azure Well-Architected, która jest zestawem wytycznych, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Well-Architected Framework.

Niezawodność

Niezawodność pomaga zapewnić, ż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.

Aby uzyskać informacje o gwarantowanej dostępności poszczególnych usług, zobacz SLAs for Usługi online (

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nieprawidłowym użyciem cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca zabezpieczeń.

Aby ułatwić zabezpieczanie Service Bus, połącz uwierzytelnianie Microsoft Entra z zarządzanymi tożsamościami. Integracja Entra ID z zasobami usługi Service Bus zapewnia kontrolę dostępu opartą na rolach platformy Azure (Azure RBAC), umożliwiając precyzyjne sterowanie dostępem klienta do zasobów. Możesz użyć Azure RBAC, aby udzielić uprawnień podmiotowi zabezpieczeń, takiemu jak użytkownik, grupa, lub jednostka usługi aplikacji. Główna jednostka usługi aplikacyjnej w tym scenariuszu jest tożsamością zarządzaną.

Jeśli nie możesz użyć Entra ID, użyj uwierzytelniania za pomocą sygnatury dostępu współdzielonego (SAS), aby przyznać użytkownikom dostęp i określone uprawnienia do zasobów usługi Service Bus.

Jeśli musisz udostępnić kolejkę Service Bus lub temat subskrypcyjny jako punkt końcowy HTTP, na przykład w celu opublikowania nowych komunikatów, użyj usługi zarządzania API, aby zabezpieczyć kolejkę poprzedzając punkt końcowy. Następnie możesz użyć certyfikatów lub uwierzytelniania OAuth, aby zabezpieczyć punkt końcowy. Najprostszym sposobem zabezpieczenia punktu końcowego jest użycie aplikacji logiki z wyzwalaczem żądania HTTP lub odpowiedzi jako pośrednika.

Usługa Event Grid pomaga zabezpieczyć dostarczanie zdarzeń za pośrednictwem kodu weryfikacji. Jeśli używasz usługi Logic Apps do korzystania ze zdarzenia, walidacja jest automatyczna. Aby uzyskać więcej informacji, zobacz Zabezpieczenia i uwierzytelnianie usługi Event Grid.

Bezpieczeństwo sieci

Rozważ bezpieczeństwo sieci w całym projekcie.

  • Możesz powiązać Service Bus Premium z punktem końcowym usługi podsieci sieci wirtualnej. Ta konfiguracja pomaga zabezpieczyć przestrzeń nazw, ponieważ akceptuje tylko ruch z autoryzowanych sieci wirtualnych. Możesz również użyć Azure Private Link, aby zezwolić tylko na ruch prywatny do sieci wirtualnej za pośrednictwem prywatnych punktów końcowych.

    Jeśli przestrzeń nazw usługi Service Bus działa w warstwie Standard i nie używa prywatnych punktów końcowych, użyj usługi Azure Network Security Perimeter dla Microsoft.ServiceBus/namespaces, aby ograniczyć ekspozycję publicznego punktu końcowego za pomocą jawnych reguł dostępu przychodzącego. W przypadku usługi Logic Apps i innych usług opartych na komunikatach, które publikują komunikaty w usłudze Service Bus lub je z niej odbierają, preferuj reguły ruchu przychodzącego oparte na subskrypcjach, ograniczone do subskrypcji platformy Azure, w których są hostowane te usługi.

  • Usługę Logic Apps Standard można skonfigurować tak, aby akceptowała ruch przychodzący za pośrednictwem prywatnych punktów końcowych i wysyłała ruch wychodzący za pośrednictwem integracji sieci wirtualnej.

  • Aby zabezpieczyć dostęp do wystąpienia i interfejsów API usługi API Management, możesz użyć sieci wirtualnej Azure. Ta metoda obsługuje prywatne punkty końcowe. Aby uzyskać więcej informacji, zobacz Używanie sieci wirtualnej z usługą API Management.

Optymalizacja kosztów

Optymalizacja kosztów koncentruje się na sposobach 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.

Aby oszacować koszty, użyj kalkulatora cen Azure. Oto kilka innych zagadnień.

API Management

Opłaty są naliczane za wszystkie wystąpienia usługi API Management po ich uruchomieniu. W przypadku skalowania w górę, a następnie nie potrzebujesz już tego poziomu wydajności, ręcznie skaluj w dół lub skonfiguruj skalowanie automatyczne.

Dla lekkich obciążeń roboczych należy wziąć pod uwagę warstwę Zużycia, która jest tanią opcją bezserwerową. Opłata za warstwę Konsumpcyjną jest naliczana za każde wywołanie interfejsu API. Opłaty za inne warstwy są naliczane za godzinę.

Logic Apps Standard

Usługa Logic Apps Standard używa elastycznego modelu obliczeniowego. Rozliczenia są obliczane na podstawie liczby procesorów CPU i pamięci używanej na godzinę. Aby uzyskać więcej informacji, zobacz Cennik usługi Logic Apps.

Kolejki Service Bus, tematy i subskrypcje

Service Bus kolejki i subskrypcje obsługują zarówno modele push z proxy, jak i modele pull w celu dostarczania wiadomości. W modelu ściągania każde żądanie sondowania jest mierzone jako akcja. Nawet jeśli ustawisz długie sondowanie na wartość domyślną 30 sekund, koszt może być wysoki. Jeśli nie potrzebujesz dostarczania komunikatów w czasie rzeczywistym, rozważ użycie modelu wypychania z proxy.

kolejki Service Bus są uwzględniane we wszystkich warstwach: Podstawowa, Standardowa i Premium. Tematy i subskrypcje w usłudze Service Bus są dostępne w wersjach Standard i Premium. Aby uzyskać więcej informacji, zobacz Service Bus cennik.

Event Grid

Usługa Event Grid używa modelu bezserwerowego. Rozliczenia są obliczane na podstawie liczby operacji. Operacje obejmują zdarzenia, które trafiają do domen lub tematów, zaawansowane dopasowania, próby dostarczenia i wywołania związane z zarządzaniem. Użycie do 100 000 operacji jest całkowicie bezpłatne.

Aby uzyskać więcej informacji, zobacz Cennik usługi Event Grid.

Sprawność operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i zapewniają jej działanie w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca doskonałości operacyjnej.

Podstawowa architektura referencyjna integracji przedsiębiorstwa zawiera wskazówki dotyczące wzorców DevOps, które są zgodne z filarem doskonałości operacyjnej platformy Well-Architected Framework.

Automatyzuj operacje odzyskiwania w jak największym stopniu, aby poprawić doskonałość operacyjną. Mając na uwadze automatyzację, można połączyć monitorowanie dzienników Azure z Azure Automation w celu zautomatyzowania przełączenia awaryjnego zasobów Service Bus. Aby zapoznać się z przykładem logiki automatyzacji w celu zainicjowania trybu failover, zobacz Przepływ trybu failover.

Efektywność operacyjna

Wydajność odnosi się do możliwości skalowania obciążenia w celu efektywnego zaspokojenia wymagań użytkowników. Aby uzyskać więcej informacji, zobacz listę kontrolną przeglądu projektu pod kątem wydajności.

Aby uzyskać większą skalowalność, warstwa Service Bus Premium może zwiększać liczbę jednostek obsługi komunikatów. Aby uzyskać więcej informacji, zobacz Warstwy obsługi wiadomości Service Bus Premium i Standard oraz Funkcja automatycznego skalowania.

Aby uzyskać więcej rekomendacji dotyczących Service Bus, zobacz Best practices for performance improvements by using Service Bus messaging (Rozwiązania dotyczące wydajności przy użyciu komunikatów Service Bus.

Następne kroki