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.
Laden Sie eine Visio-Datei dieser Architektur herunter.
Szenariodetails
Die vorangehende Architektur basiert auf der einfacheren grundlegenden Unternehmensintegrationsarchitektur, die Azure Logic Apps verwendet, um Workflows direkt mit Back-End-Systemen zu koordinieren und Azure API Management zum Erstellen von KATALOGen von APIs zu verwenden.
Bei der vorliegenden Version der Architektur werden zwei Komponenten hinzugefügt, um das System zuverlässiger und besser skalierbar zu machen:
Azure Service Bus ist ein sicherer, zuverlässiger Nachrichtenbroker.
Azure Event Grid ist ein Ereignisroutingdienst. Es verwendet ein Veröffentlichungs - und Abonnementereignismodell .
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 Muster "Warteschlangenbasiertes Lastenausgleich" zum Verarbeiten von Platzen in Arbeitslasten über das Lastenausgleichsmuster
Verwendet das Publisher-Subscriber-Muster , sodass Sie Nachrichten an mehrere Consumer ü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
Integration 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 das Ereignisraster, sodass verschiedene Komponenten im System auf Ereignisse reagieren können, wenn sie stattfinden, anstatt sich auf abfragende oder geplante Vorgänge zu verlassen. Ähnlich wie bei einer Nachrichtenwarteschlange und -themen hilft Das Ereignisraster 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.
Das Senden von Ereignissen an Event Grid wird von zahlreichen Azure-Diensten unterstützt. So kann beispielsweise eine Logik-App auf ein Ereignis lauschen, wenn einem Blobspeicher neue Dateien 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 verfügt über zwei Liefermodelle, das Pullmodell und das proxiierte Pushmodell :
Pullmodell: Der Empfänger ruft kontinuierlich neue Nachrichten ab. Wenn Sie mehrere Warteschlangen und Abrufzeiten verwalten müssen, ist die Abfrage möglicherweise ineffizient. Dieses Modell kann Ihre Architektur jedoch vereinfachen, da zusätzliche Komponenten und Datenhüpfen entfernt werden.
Proxied-Pushmodell: Der Empfänger abonniert zunächst einen bestimmten Ereignistyp in einem Ereignisrasterthema. Wenn eine neue Nachricht verfügbar ist, löst Service Bus ein Ereignis über Das Ereignisraster aus und sendet es. Dieses Ereignis löst dann den Empfänger aus, um den nächsten Batch von Nachrichten aus 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 Standardlogik-Apps-Workflow erstellen, der Service Bus-Nachrichten nutzt, empfehlen wir, die integrierten Service Bus-Connectortrigger zu verwenden. Der integrierte Verbinder löst die meisten Pullmodellkonfigurationen ab, ohne zusätzliche Kosten hinzuzufügen. Diese Funktion bietet das richtige Gleichgewicht zwischen Kosten, Oberflächenbereichsverwaltung und Sicherheit, da der Verbinder kontinuierlich innerhalb des Logic Apps-Laufzeitmoduls schleift. Weitere Informationen finden Sie unter integrierte Service Bus-Connectortrigger.
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.
Event Grid
Wenn ein Ereignisraster ausgelöst wird, bedeutet dies, dass mindestens ein Ereignis aufgetreten ist. Wenn beispielsweise eine Logik-App einen Ereignisrastertrigger für eine ServiceBus-Nachricht abruft, stehen möglicherweise mehrere Nachrichten zum Verarbeiten zur Verfügung.
Überlegungen
Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.
Zuverlässigkeit
Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.
Microsoft Entra ID ist eine global verteilte, hoch verfügbare SaaS-Plattform.
Sie können die API-Verwaltung in mehreren hochverwendbarten Konfigurationen gemäß den Geschäftlichen Anforderungen und der Kostentoleranz bereitstellen. Weitere Informationen finden Sie unter Sicherstellen der Verfügbarkeit und Zuverlässigkeit der API-Verwaltung.
Die Speicherebene "Logic Apps Consumption" unterstützt den georedundanten Speicher. Weitere Informationen finden Sie unter Geschäftskontinuität und Notfallwiederherstellung für Logik-Apps.
Ereignisrasterressourcendefinitionen für Themen, Systemthemen, Domänen und Ereignisabonnements und Ereignisdaten werden automatisch über Verfügbarkeitszonen in einer Region repliziert. Wenn in einer der Verfügbarkeitszonen ein Fehler auftritt, erfolgt für Event Grid-Ressourcen ohne Eingreifen des Benutzers ein automatisches Failover auf eine andere Verfügbarkeitszone. Weitere Informationen finden Sie unter Regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität.
Service Bus Premium unterstützt Geo-Notfallwiederherstellung und Verfügbarkeitszonen. Service Bus Standard unterstützt die Replikation.
Informationen zu garantierten Verfügbarkeitsdetails der einzelnen Dienste finden Sie unter SLAs für Onlinedienste.
Sicherheit
Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.
Um den Servicebus zu sichern, koppeln Sie die Microsoft Entra-Authentifizierung mit verwalteten Identitäten. Die Microsoft Entra-ID-Integration für Service Bus-Ressourcen bietet Azure role-based access control (RBAC) für eine differenzierte Kontrolle über den Zugriff eines Clients auf Ressourcen. Sie können Azure RBAC verwenden, um Einem Sicherheitsprinzipal Berechtigungen zu erteilen, z. B. einem Benutzer, einer Gruppe oder einem Anwendungsdienstprinzipal. Der Anwendungsdienstprinzipal in diesem Szenario ist eine verwaltete Identität.
Wenn Sie die Microsoft 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 beispielsweise eine ServiceBus-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 sichern, indem Sie den Endpunkt vorstellen. 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 Ereignisrasterdienst hilft beim Sichern der Ereignisübermittlung über einen Überprüfungscode. 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.
Sie können Service Bus Premium an einen Endpunkt des virtuellen Netzwerks binden. Diese Konfiguration schützt den Namespace, da er nur Datenverkehr von autorisierten virtuellen Netzwerken akzeptiert. Sie können auch Azure Private Link verwenden, um nur privaten Datenverkehr zu Ihrem virtuellen Netzwerk über private Endpunkte zuzulassen.
Sie können Logic Apps Standard und Premium konfigurieren, um eingehenden Datenverkehr über private Endpunkte zu akzeptieren und ausgehenden Datenverkehr über die Integration des virtuellen Netzwerks zu senden.
Sie können ein virtuelles Azure-Netzwerk verwenden, um den Zugriff auf Ihre API-Verwaltungsinstanz und APIs zu sichern. Diese Methode unterstützt private Endpunkte. Weitere Informationen finden Sie unter Verwenden eines virtuellen Netzwerks mit API-Verwaltung.
Kostenoptimierung
Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Kostenoptimierung.
Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln. Hier finden Sie einige weitere Überlegungen dazu.
API Management
Sie werden für alle API-Verwaltungsinstanzen in Rechnung gestellt, wenn sie ausgeführt werden. Wenn Sie hochskalieren und dann nicht mehr diese Leistungsstufe benötigen, skalieren Sie die automatische Skalierung manuell 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
Logic Apps verwendet ein serverloses Modell. Die Abrechnung wird basierend auf der Anzahl der Aktionen und Connectoraufrufe berechnet. Weitere Informationen hierzu finden Sie unter Logic Apps – Preise.
Service Bus-Warteschlangen, -Themen und -Abonnements
Servicebuswarteschlangen und Abonnements unterstützen sowohl Push- als auch Pullmodelle zum Übermitteln 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. Wenn Sie keine Echtzeitnachrichtenübermittlung benötigen, sollten Sie das pushbasierte Modell verwenden.
Servicebuswarteschlangen sind in allen Ebenen enthalten: Basic, Standard und Premium. ServiceBus-Themen und Abonnements sind in den Stufen "Standard" und "Premium" verfügbar. Weitere Informationen finden Sie unter Service Bus – Preise.
Event Grid
Event Grid verwendet ein serverloses Modell. Die Abrechnung wird basierend auf der Anzahl der Vorgänge berechnet. Vorgänge umfassen Ereignisse, die zu Domänen oder Themen wechseln, erweiterte Übereinstimmungen, Übermittlungsversuche und Verwaltungsaufrufe. Die Nutzung von bis zu 100.000 Vorgängen ist kostenlos.
Weitere Informationen finden Sie unter "Event Grid Pricing " und "Well-Architected Framework Cost Optimization".
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 unter Erstellen einer Checkliste zur Überprüfung des optimalen Betriebs.
Die grundlegende Referenzarchitektur für die Unternehmensintegration enthält Anleitungen zu DevOps-Mustern, die sich an der Säule "Operational Excellence" des Well-Architected Framework ausrichten.
Automatisieren Sie Wiederherstellungsvorgänge so weit wie möglich, um die operative Exzellenz zu verbessern. Unter Berücksichtigung der Automatisierung können Sie die Azure-Protokollüberwachung 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 Failoverfluss.
Effiziente Leistung
Die Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Leistungseffizienz.
Mit dem Service Bus-Premium-Tarif lässt sich die Anzahl von Nachrichteneinheiten aufskalieren, um eine höhere Skalierbarkeit zu erreichen. Weitere Informationen finden Sie unter Service Bus Premium und Standard messaging tiers and Autocaling feature.
Weitere Empfehlungen für Service Bus finden Sie unter Bewährte Methoden für Leistungsverbesserungen mithilfe von Service Bus Messaging.
Nächste Schritte
- Übersicht über die Integration von Service Bus zu Event Grid
- Lernprogramm, das Messaging verwendet, um Nicht-Microsoft-Systeme über NServiceBus zu integrieren