Verwenden Sie einen Nachrichtenbroker und Ereignisse zur Integration von Unternehmenssystemen.

Azure Event Grid
Azure Service Bus

Diese Architektur basiert auf der grundlegenden Unternehmensintegrationsarchitektur , umfasst jedoch die Integration von Enterprise-Back-End-Systemen. Diese Architektur verwendet Nachrichtenbroker und Ereignisse, um Dienste für eine höhere Skalierbarkeit und Zuverlässigkeit zu entkoppeln. Stellen Sie sicher, dass Sie mit dem Entwurf und den Komponenten in der grundlegenden Integrationsarchitektur vertraut sind. Diese Elemente enthalten grundlegende Informationen zu den Kernkomponenten dieser Architektur.

Aufbau

Zu den Back-End-Systemen, auf die dieses Design verweist, gehören Software as a Service (SaaS)-Systeme, Azure Dienste, nachrichtenbasierte Dienste und vorhandene Webdienste in Ihrem Unternehmen.

Diagramm, das eine Referenzarchitektur für die Unternehmensintegration zeigt, die Warteschlangen und Ereignisse verwendet.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Details zum Szenario

Die vorangehende Architektur basiert auf der grundlegenden Unternehmensintegrationsarchitektur. Es verwendet Azure Logic Apps, um Workflows direkt mit Back-End-Systemen zu koordinieren und verwendet Azure API Management zum Erstellen von APIs-Katalogen.

Bei der vorliegenden Version der Architektur werden zwei Komponenten hinzugefügt, um das System zuverlässiger und besser skalierbar zu machen:

Diese Architektur verwendet eine asynchrone Kommunikation über einen Nachrichtenbroker, anstatt direkte, synchrone Aufrufe an Back-End-Dienste auszuführen. Die asynchrone Kommunikation bietet die folgenden Vorteile:

  • Verwendet das Queue-Based Load Leveling-Muster, um Arbeitslastspitzen mittels Lastenausgleich zu verarbeiten.

  • Verwendet das Publisher-Subscriber Muster , sodass Sie Nachrichten an mehrere Verbraucher übertragen können.

  • Verfolgt den Fortschritt lang ausgeführter Workflows zuverlässig, auch wenn sie mehrere Schritte oder mehrere Anwendungen umfassen

  • Hilft beim Decoupieren von Anwendungen

  • Integriert sich in vorhandene nachrichtenbasierte Systeme

  • Bietet die Möglichkeit, Nachrichten in die Warteschlange zu stellen, wenn ein Back-End-System nicht verfügbar ist

Verwenden Sie Azure Event Grid, damit verschiedene Komponenten im System auf Ereignisse reagieren können, sobald sie eintreten, anstatt sich auf regelmäßige Abfragen oder geplante Aufgaben zu verlassen. Ähnlich wie bei Nachrichtenwarteschlangen und Themen hilft Event Grid dabei, Anwendungen und Dienste zu entkoppeln. Wenn eine Anwendung oder ein Dienst Ereignisse veröffentlicht, werden alle interessierten Abonnenten benachrichtigt. Sie können neue Abonnenten hinzufügen, ohne den Absender zu aktualisieren.

Viele Azure-Dienste unterstützen das Senden von Ereignissen an Event Grid. Beispielsweise kann ein Azure Logic Apps auf ein Ereignis lauschen, wenn neue Dateien einem Blobspeicher hinzugefügt werden. Dieses Muster erstellt reaktive Workflows, in denen das Hochladen einer Datei oder das Ablegen einer Nachricht in einer Warteschlange eine Reihe von Prozessen startet. Die Prozesse können parallel oder in einer bestimmten Sequenz ausgeführt werden.

Empfehlungen

Beachten Sie die folgenden Empfehlungen. Weitere Empfehlungen finden Sie unter Grundlegende Unternehmensintegrationsarchitektur.

Service Bus

Service Bus bietet zwei Liefermodelle: das Pullmodell und das proxiierte Pushmodell.

  • Pullmodell: Der Empfänger fragt kontinuierlich neue Nachrichten ab. Wenn Sie mehrere Warteschlangen und Polling-Intervalle verwalten müssen, könnte das Polling möglicherweise ineffizient sein. Dieses Modell kann Ihre Architektur jedoch vereinfachen, da zusätzliche Komponenten und Datenhüpfen entfernt werden.

  • Proxied Push-Modell: Der Empfänger abonniert zunächst einen bestimmten Ereignistyp auf einem Event Grid-Thema. Wenn eine neue Nachricht verfügbar ist, löst Service Bus ein Ereignis aus und sendet es über Event Grid. Dieses Ereignis veranlasst den Empfänger dann, den nächsten Stapel von Nachrichten aus dem Service Bus abzurufen. Mit diesem Modell können Systeme Nachrichten fast in Echtzeit empfangen, ohne jedoch Ressourcen zum kontinuierlichen Abfragen neuer Nachrichten zu verwenden. Diese Architektur verwendet zusätzliche Komponenten, die Sie bereitstellen, verwalten und schützen müssen.

Wenn Sie einen Standard-Logic-Apps-Workflow erstellen, der Service Bus-Nachrichten verarbeitet, verwenden Sie die integrierten Service Bus-Connectortrigger. Die integrierten Konnektortrigger abstrahieren den Großteil der Konfiguration des Pull-Modells, ohne zusätzliche Kosten zu verursachen. Diese Funktion bietet das richtige Gleichgewicht zwischen Kosten, Oberflächenbereichsverwaltung und Sicherheit, da der Konnektor kontinuierlich innerhalb der Logic Apps Runtime Engine loopt. Weitere Informationen finden Sie unter integrierte Trigger des Service Bus Connectors.

Verwenden Sie den PeekLock-Modus , um auf eine Gruppe von Nachrichten zuzugreifen. Mit PeekLock kann die Logik-App dann Schritte ausführen, um die einzelnen Nachrichten zu überprüfen, bevor sie abgeschlossen oder verworfen werden. Dieser Ansatz verhindert versehentlichen Nachrichtenverlust.

Ereignisraster

Wenn ein Ereignisraster ausgelöst wird, bedeutet dies, dass mindestens ein Ereignis aufgetreten ist. Wenn beispielsweise eine Logik-App einen Ereignisrastertrigger für eine Service Bus Nachricht abruft, stehen möglicherweise mehrere Nachrichten zur Verfügung, die verarbeitet werden können.

Überlegungen

Diese Überlegungen implementieren die Säulen des Azure Well-Architected-Frameworks, die eine Reihe von Leitsätzen sind, die Sie verwenden können, um die Qualität einer Arbeitsauslastung zu verbessern. Weitere Informationen finden Sie unter Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Informationen zu den Details zur garantierten Verfügbarkeit der einzelnen Dienste finden Sie unter SLAs für Onlinedienste.

Sicherheit

Sicherheit bietet Schutz vor absichtlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Entwurfsprüfliste für die Sicherheit.

Um Service Bus zu sichern, koppeln Sie Microsoft Entra Authentifizierung mit verwalteten Identitäten. Die Entra ID-Integration für Service Bus-Ressourcen bietet Azure-rollenbasierte Zugriffssteuerung (Azure RBAC) zur differenzierten Steuerung des Zugriffs eines Clients auf Ressourcen. Sie können Azure RBAC verwenden, um einem Sicherheitsprinzipal, z. B. einem Benutzer, einer Gruppe oder einem Anwendungsdienstprinzipal, Berechtigungen zu erteilen. Der Anwendungsdienstprinzipal in diesem Szenario ist eine verwaltete Identität.

Wenn Sie Entra ID nicht verwenden können, verwenden Sie die SAS-Authentifizierung (Shared Access Signature), um Benutzern Zugriff und bestimmte Rechte für Service Bus Ressourcen zu gewähren.

Wenn Sie z. B. eine Service Bus Warteschlange oder ein Thema als HTTP-Endpunkt verfügbar machen müssen, um neue Nachrichten zu veröffentlichen, verwenden Sie die API-Verwaltung, um die Warteschlange zu schützen, indem Sie den Endpunkt frontieren. Anschließend können Sie Zertifikate oder OAuth-Authentifizierung verwenden, um den Endpunkt zu sichern. Die einfachste Möglichkeit zum Sichern eines Endpunkts besteht darin, eine Logik-App zu verwenden, die über einen HTTP-Anforderungs- oder Antworttrigger als Zwischenlösung verfügt.

Der Event Grid-Dienst hilft beim Sichern der Ereignisübermittlung über einen Validierungscode. Wenn Sie Logic Apps verwenden, um das Ereignis zu nutzen, wird die Überprüfung automatisch erfolgen. Weitere Informationen finden Sie unter Event Grid – Sicherheit und Authentifizierung.

Netzwerksicherheit

Berücksichtigen Sie die Netzwerksicherheit im gesamten Design.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Design Review-Checkliste für die Kostenoptimierung.

Verwenden Sie den Azure Preisrechner, um Kosten zu schätzen. Hier finden Sie einige weitere Überlegungen dazu.

API-Verwaltung

Es entstehen Kosten für alle API Management-Instanzen, sobald sie ausgeführt werden. Wenn Sie erweitern und dann nicht mehr diese Performance benötigen, skalieren Sie manuell herunter oder konfigurieren Sie die automatische Skalierung.

Berücksichtigen Sie bei Workloads für die leichte Nutzung die Nutzungsstufe, bei der es sich um eine kostengünstige, serverlose Option handelt. Die Nutzungsstufe wird pro API-Aufruf abgerechnet. Andere Stufen werden pro Stunde abgerechnet.

Logic Apps Standard

Logic Apps Standard verwendet ein elastisches Computemodell. Die Abrechnung wird anhand der Anzahl der CPUs und des pro Stunde verwendeten Arbeitsspeichers berechnet. Weitere Informationen hierzu finden Sie unter Logic Apps – Preise.

Service Bus Warteschlangen, Themen und Abonnements

Service Bus-Warteschlangen und -Abonnements unterstützen das Pushmodell mit Proxy und das Pullmodell für die Übermittlung von Nachrichten. Beim Pullmodell wird jede Abrufanforderung als Aktion gemessen. Selbst wenn Sie eine lange Abfrage auf den Standardwert von 30 Sekunden festlegen, können die Kosten hoch sein. Sofern Sie keine Echtzeitnachrichtenübermittlung benötigen, sollten Sie das vermittelte Push-Modell in Betracht ziehen.

Service Bus Warteschlangen sind in allen Stufen enthalten: Basis, Standard und Premium. Service Bus Themen und Abonnements sind in den Stufen "Standard" und "Premium" verfügbar. Weitere Informationen finden Sie unter Service Bus Pricing.

Ereignisraster

Event Grid verwendet ein serverloses Modell. Die Abrechnung wird basierend auf der Anzahl der Vorgänge berechnet. Zu den Vorgängen gehören Ereignisse für Domänen oder Themen, erweiterte Übereinstimmungen, Übermittlungsversuche und Verwaltungsaufrufe. Die Nutzung von bis zu 100.000 Vorgängen ist kostenlos.

Weitere Informationen finden Sie unter Event Grid-Preise.

Optimaler Betrieb

„Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie in der Checkliste zur Designüberprüfung für operationale Exzellenz.

Die grundlegende Referenzarchitektur für die Unternehmensintegration enthält Anleitungen zu DevOps-Mustern, die sich an der Säule Well-Architected Framework Operational Excellence ausrichten.

Automatisieren Sie Wiederherstellungsvorgänge so weit wie möglich, um die operative Exzellenz zu verbessern. Im Hinblick auf die Automatisierung können Sie Azure Log Monitoring mit Azure Automation kombinieren, um das Failover Ihrer Service Bus Ressourcen zu automatisieren. Ein Beispiel für Automatisierungslogik zum Initiieren eines Failovers finden Sie unter Failover-Flow.

Leistungseffizienz

Leistungseffizienz bezieht sich auf die Fähigkeit Ihrer Workload, effizient auf die Anforderungen der Benutzer zu skalieren. Weitere Informationen finden Sie in der Checkliste zur Entwurfsüberprüfung für die Leistungseffizienz.

Um eine höhere Skalierbarkeit zu erreichen, kann die Service Bus Premium-Stufe die Anzahl der Messagingeinheiten skalieren. Weitere Informationen finden Sie unter Service Bus Premium- und Standardnachrichtentypen und automatische Skalierungsfunktion.

Weitere Empfehlungen für die Service Bus Nutzung finden Sie unter Best Practices zur Leistungsverbesserung durch Einsatz von Service Bus-Nachrichten.

Nächste Schritte