In dieser Referenzarchitektur wird Azure Integration Services zum Orchestrieren von Aufrufen an Back-End-Unternehmenssysteme verwendet. Die Backend-Systeme können Software-as-a-Service(SaaS)-Systeme, Azure-Dienste und vorhandene Web-Dienste in Ihrem Unternehmen enthalten.
Aufbau
Laden Sie eine Visio-Datei dieser Architektur herunter.
Workflow
Back-End-Systeme. Auf der rechten Seite des Diagramms befinden sich die verschiedenen Back-End-Systeme, die das Unternehmen bereitgestellt hat oder nutzt. Diese Systeme schließen beispielsweise SaaS-Systeme, andere Azure-Dienste oder Web-Dienste ein, die REST- oder SOAP-Endpunkte verfügbar machen.
Azur Logic Apps. In dieser Architektur werden die Logik-Apps durch HTTP-Anforderungen ausgelöst. Für eine komplexere Orchestrierung können Sie Workflows auch schachteln. Logic Apps verwendet Connectors für die Integration in häufig verwendete Dienste. Logic Apps bietet hunderte von Connectors, und Sie können benutzerdefinierte Connectors erstellen.
Azure API Management: API Management besteht aus zwei zugehörigen Komponenten:
API-Gateway. Das API-Gateway akzeptiert HTTP-Aufrufe und leitet sie an das Back-End weiter.
Entwicklerportal. Jede Instanz von Azure API Management bietet Zugriff auf ein Entwicklerportal. Über dieses Portal haben Ihre Entwickler Zugriff auf Dokumentation und Codebeispiele für das Aufrufen der APIs. Im Entwicklerportal können Sie außerdem APIs testen.
Azure DNS: Azure DNS bietet eine Namensauflösung mithilfe der Azure-Infrastruktur. Durch das Hosten Ihrer Domänen in Azure können Sie Ihre DNS-Einträge mithilfe der gleichen Anmeldeinformationen, APIs, Tools und Abrechnung wie für die anderen Azure-Dienste verwalten. Erstellen Sie zur Verwendung eines benutzerdefinierten Domänennamens (etwa contoso.com) DNS-Einträge, die den benutzerdefinierten Domänennamen der IP-Adresse zuordnen. Weitere Informationen finden Sie unter Konfigurieren eines benutzerdefinierten Domänennamens in API Management.
Microsoft Entra ID. Verwenden Sie Microsoft Entra ID zum Authentifizieren von Clients, die die Gateway-API aufrufen. Microsoft Entra ID unterstützt das OpenID Connect-Protokoll (OIDC). Clients rufen ein Zugriffstoken von Microsoft Entra ID ab, und das API-Gateway überprüft das Token, um die Anforderung zu autorisieren. Bei Verwendung des Standard- oder Premium-Tarifs von API Management kann Microsoft Entra ID auch Zugriff auf das Entwicklerportal sichern.
Komponenten
- Integration Services ist eine Sammlung von Diensten für die Integration von Anwendungen, Daten und Vorgängen.
- Logic Apps ist eine serverlose Plattform zum Erstellen von Unternehmensworkflows, die Anwendungen, Daten und Dienste integrieren.
- API Management ist ein verwalteter Dienst für das Veröffentlichen von HTTP-API-Katalogen. Sie können diesen Dienst verwenden, um die Wiederverwendung und Erkennbarkeit Ihrer APIs zu fördern und ein API-Gateway für Proxy-API-Anforderungen bereitzustellen.
- Azure DNS ist ein Hostingdienst für DNS-Domänen.
- Microsoft Entra ID ist ein cloudbasierter Identitäts- und Zugriffsverwaltungsdienst. Unternehmensmitarbeiter*innen können Microsoft Entra ID verwenden, um auf externe und interne Ressourcen zuzugreifen.
Szenariodetails
Integration Service ist eine Sammlung von Diensten für die Integration von Anwendungen, Daten und Vorgängen für Ihr Unternehmen. Diese Architektur verwendet zwei dieser Dienste: Logic Apps zum Orchestrieren von Workflows und API Management zum Erstellen von API-Katalogen.
In dieser Architektur werden Verbund-APIs durch das Importieren von Logik-Apps als APIs erstellt. Sie können auch vorhandene Webdienste importieren, indem Sie OpenAPI-Spezifikationen (Swagger) oder SOAP-APIs aus WSDL-Spezifikationen importieren.
Das API-Gateways unterstützt die Entkopplung von Front-End-Clients vom Back-End. Dazu kann es beispielsweise URLs umschreiben oder Anforderungen transformieren, bevor sie das Back-End erreichen. Es behandelt außerdem viele übergreifende Aspekte wie Authentifizierung, Unterstützung von Cross-Origin Resource Sharing (CORS) und Zwischenspeicherung von Antworten.
Mögliche Anwendungsfälle
Diese Architektur ist für einfache Integrationsszenarien konzipiert, in denen der Workflow durch synchrone Backend-Dienstaufrufe ausgelöst wird. Eine komplexere Architektur mit Warteschlangen und Ereignissen baut auf dieser einfachen Architektur auf.
Empfehlungen
Ihre individuellen Anforderungen können von der hier gezeigten generischen Architektur abweichen. Verwenden Sie die Empfehlungen in diesem Abschnitt als Ausgangspunkt.
API Management
Verwenden Sie die Tarife „Basic“, „Standard“ oder „Premium“ für API Management. Diese Tarife bieten eine Vereinbarung zum Servicelevel (SLA) für die Produktionsumgebung und unterstützen eine Aufskalierung innerhalb der Azure-Region. Die Durchsatzkapazität für API Management wird in Einheiten gemessen. Die horizontale Skalierung ist für jeden Tarif beschränkt. Der Tarif „Premium“ unterstützt zudem die Aufskalierung über mehrere Azure-Regionen hinweg. Wählen Sie Ihren Tarif basierend auf Ihrem Funktionsumfang und dem erforderlichen Durchsatz. Weitere Informationen finden Sie unter API Management-Preise und Kapazität einer Azure API Management-Instanz.
Jede Azure API Management-Instanz besitzt einen Standarddomänennamen. Dabei handelt es sich um eine Unterdomäne von azure-api.net, z. B. contoso.azure-api.net. Erwägen Sie die Konfiguration einer benutzerdefinierte Domäne für Ihre Organisation.
Logic Apps
Logic Apps eignet sich am besten für Szenarien, die keine Antworten mit geringer Wartezeit erfordern (etwa asynchrone API-Aufrufe oder API-Aufrufe mittlerer Dauer). Ist eine geringe Wartezeit erforderlich (beispielsweise bei einem Aufruf, der eine Benutzeroberfläche blockiert), muss eine andere Technologie verwendet werden. Verwenden Sie beispielsweise Azure Functions oder eine in Azure App Service bereitgestellte Web-API. Verwenden Sie API Management, um die API für Ihre API-Consumer verfügbar zu machen.
Region
Stellen Sie API Management und Logic Apps in der gleichen Region bereit, um die Netzwerklatenz zu minimieren. Wählen Sie grundsätzlich die Ihren Benutzern (oder Ihren Back-End-Diensten) am nächsten gelegene Region aus.
Überlegungen
Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.
Zuverlässigkeit
Zuverlässigkeit stellt sicher, dass die Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.
Lesen Sie die SLA für jeden Dienst:
Wenn Sie API Management in mindestens zwei Regionen mit Premium-Tarif bereitstellen, besteht Anspruch auf eine höhere Vereinbarung zum Servicelevel (Service Level Agreement, SLA). Siehe API Management-Preise.
Backups
Sichern Sie Ihre API Management-Konfiguration regelmäßig. Speichern Sie Ihre Sicherungsdateien an einem Ort oder in einer Azure-Region, an dem bzw. in der sich der Dienst nicht befindet. Wählen Sie basierend auf Ihrer RTO eine Strategie für die Notfallwiederherstellung:
Bei einer Notfallwiederherstellung stellen Sie eine neue API Management-Instanz bereit, stellen die Sicherung auf dieser neuen Instanz wieder her und leiten die DNS-Einträge um.
Behalten Sie eine passive Instanz des API Management-Diensts in einer anderen Azure-Region bei. Stellen Sie in dieser Instanz regelmäßig Sicherungen wieder her, um sie mit dem aktiven Dienst synchron zu halten. Bei einer Notfallwiederherstellung des Diensts müssen Sie lediglich die DNS-Einträge umleiten. Dieser Ansatz verursacht zwar zusätzliche Kosten, da Sie für die passive Instanz bezahlen, die Wiederherstellungszeit wird jedoch reduziert.
Für Logik-Apps empfehlen wir einen codebasierten Konfigurationsansatz für die Sicherung und Wiederherstellung. Da Logik-Apps serverlos sind, können Sie sie aus Azure Resource Manager-Vorlagen schnell wiederherstellen. Speichern Sie die Vorlagen in der Quellcodeverwaltung, und integrieren Sie die Vorlagen in Ihren CI/CD-Prozess (Continuous Integration/Continuous Deployment). Stellen Sie die Vorlage bei einer Notfallwiederherstellung in einer neuen Region bereit.
Wenn Sie eine Logik-App in einer anderen Region bereitstellen, aktualisieren Sie die Konfiguration in API Management. Sie können die Backend-Eigenschaft der API mithilfe eines einfachen PowerShell-Skripts aktualisieren.
Sicherheit
Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.
Obwohl diese Liste nicht alle bewährten Sicherheitsmethoden vollständig beschreibt, finden Sie hier einige Sicherheitshinweise, die insbesondere für diese Architektur gelten:
Der Azure API Management-Dienst weist eine feste öffentliche IP-Adresse auf. Beschränken Sie den Aufruf von Logic Apps-Endpunkten ausschließlich auf die IP-Adresse von API Management. Weitere Informationen finden Sie unter Beschränken eingehender IP-Adressen.
Verwenden Sie die rollenbasierte Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC), um sicherzustellen, dass Benutzer über entsprechende Zugriffsebenen verfügen.
Sichern Sie öffentliche API-Endpunkte in API Management mit OAuth oder OpenID Connect. Um öffentliche API-Endpunkte zu sichern, konfigurieren Sie einen Identitätsanbieter und fügen eine JSON Web Token (JWT)-Validierungsrichtlinie hinzu. Weitere Informationen finden Sie unter Schützen einer API über OAuth 2.0 mit Microsoft Entra ID und API Management.
Stellen Sie eine Verbindung zu Back-End-Diensten aus API Management her, indem Sie gemeinsame Zertifikate verwenden.
Erzwingen Sie HTTPS für die API Management-APIs.
Speichern von Geheimnissen
Checken Sie niemals Kennwörter, Zugriffsschlüssel oder Verbindungszeichenfolgen in die Quellcodeverwaltung ein. Wenn diese Werte benötigt werden, verwenden Sie die entsprechenden Verfahren, um sie bereitzustellen und zu sichern.
Wenn eine Logik-App vertrauliche Werte erfordert, die Sie nicht in einem Connector erstellen können, speichern Sie diese Werte in Azure Key Vault und verweisen in einer Resource Manager-Vorlage darauf. Verwenden Sie Vorlageparameter für die Bereitstellung und Parameterdateien für jede Umgebung. Weitere Informationen finden Sie unter Sichern von Parametern und Eingaben innerhalb eines Workflows.
API Management verwaltet Geheimnisse über Objekte, die als benannte Werte oder Eigenschaften bezeichnet werden. In diesen Objekten werden Werte sicher gespeichert, auf die Sie über API Management-Richtlinien zugreifen können. Weitere Informationen finden Sie unter Verwenden von benannten Werten in Azure API Management-Richtlinien.
Optimaler Betrieb
Die Säule „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 Übersicht über die Säule „Optimaler Betrieb“.
DevOps
Erstellen Sie separate Ressourcengruppen für Produktions-, Entwicklungs- und Testumgebungen. Separate Ressourcengruppen erleichtern das Verwalten von Bereitstellungen, das Löschen von Testbereitstellungen und das Zuweisen von Zugriffsrechten.
Berücksichtigen Sie beim Zuweisen von Ressourcen zu Ressourcengruppen diese Faktoren:
Lebenszyklus. Platzieren Sie Ressourcen mit gleichem Lebenszyklus im Allgemeinen in der gleichen Ressourcengruppe.
Zugriff. Sie können Zugriffsrichtlinien mithilfe der rollenbasierten Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC) auf die in einer Gruppe enthaltenen Ressourcen anwenden.
Abrechnung. Sie können die anfallenden Kosten für die Ressourcengruppe anzeigen.
Tarif für API Management. Verwenden Sie für Entwicklungs- und Testumgebungen den Developer-Tarif. Zur Kostenminimierung während der Präproduktion stellen Sie ein Replikat Ihrer Produktionsumgebung bereit, führen die Tests aus und fahren das Replikat dann herunter.
Bereitstellung
Verwenden Sie Azure Resource Manager-Vorlagen, um die Azure-Ressourcen gemäß dem IaC-Prozess (Infrastructure-as-Code) bereitzustellen. Vorlagen erleichtern das Automatisieren von Bereitstellungen mit Azure DevOps Services und anderen CI/CD-Lösungen.
Staging
Erwägen Sie ein Staging Ihrer Workloads. Hierbei erfolgt die Bereitstellung in verschiedenen Stufen, und für jede Stufe werden Überprüfungen durchgeführt, bevor zur nächsten Stufe gewechselt wird. Wenn Sie diesen Ansatz verwenden, können Sie bei umfassender Kontrolle Aktualisierungen in Ihre Produktionsumgebungen pushen und unerwartete Bereitstellungsprobleme minimieren. Die Blaugrün-Bereitstellung und Canary-Releases sind die empfohlenen Bereitstellungsstrategien, um Liveproduktionsumgebungen zu aktualisieren. Erwägen Sie auch die Verwendung einer guten Rollback-Strategie für den Fall, dass bei einer Bereitstellung ein Fehler auftritt. Beispielsweise könnten Sie automatisch eine frühere erfolgreiche Bereitstellung aus Ihrem Bereitstellungsverlauf erneut bereitstellen. Der Flag-Parameter --rollback-on-error in der Azure CLI ist hierfür ein gutes Beispiel.
Workloadisolation
Integrieren Sie Azure API Management und die einzelnen Logik-Apps in eigene separate Resource Manager-Vorlagen. Durch die Verwendung unterschiedlicher Vorlagen können Sie die Ressourcen in Quellcodeverwaltungs-Systemen speichern. Sie können die Vorlagen gemeinsam oder einzeln im Rahmen eines CI/CD-Prozesses bereitstellen.
Versionen
Bei jeder Konfigurationsänderung an einer Logik-App und jeder Bereitstellung eines Updates über eine Resource Manager-Vorlage bewahrt Azure eine Kopie dieser Version auf und speichert alle Versionen, die einen Ausführungsverlauf aufweisen. Sie können diese Versionen verwenden, um Änderungen im Verlauf zu verfolgen, oder eine Version als aktuelle Konfiguration der Logik-App höherzustufen. Beispielsweise können Sie für eine Logik-App ein Rollback auf eine vorherige Version ausführen.
API Management unterstützt zwei unterschiedliche, sich jedoch ergänzende Versionierungskonzepte:
Versionen bieten API-Consumern die Möglichkeit, eine API-Version basierend auf ihren Anforderungen zu wählen, z.B. v1, v2, Beta oder Produktion.
Revisionen ermöglichen API-Administratoren das Vornehmen geringfügiger Änderungen in einer API und das Bereitstellen dieser Änderungen zusammen mit einem Änderungsprotokoll, um API-Benutzer über die Änderungen zu informieren.
Sie können eine Revision in einer Entwicklungsumgebung erstellen und diese Änderung mithilfe von Resource Manager-Vorlagen in anderen Umgebungen bereitstellen. Weitere Informationen finden Sie unter Veröffentlichen mehrerer Versionen Ihrer API.
Sie können Revisionen auch zum Testen einer API verwenden, bevor Sie die Änderungen übernehmen und für Benutzer zugänglich machen. Diese Methode wird jedoch für Auslastungstests oder Integrationstests nicht empfohlen. Verwenden Sie stattdessen separate Test- oder Präproduktionsumgebungen.
Diagnose und Überwachung
Verwenden Sie Azure Monitor sowohl in API Management als auch Logic Apps für die betriebliche Überwachung. Azure Monitor liefert Informationen basierend auf den für die einzelnen Dienste konfigurierten Metriken und ist standardmäßig aktiviert. Weitere Informationen finden Sie unter
- Überwachen von veröffentlichten APIs
- Überwachen des Status, Einrichten der Diagnoseprotokollierung und Aktivieren von Warnungen für Azure Logic Apps
Jeder Dienst verfügt außerdem über folgende Optionen:
Zur eingehenderen Analyse und Dashboardanzeige senden Sie Logic Apps-Protokolle an Azure Log Analytics.
Zur Überwachung von DevOps konfigurieren Sie Azure Application Insights für API Management.
API Management unterstützt die Power BI-Lösungsvorlage für benutzerdefinierte API-Analysen. Sie können diese Lösungsvorlage zur Erstellung Ihrer eigenen Analyselösung verwenden. Für Geschäftskunden stellt Power BI Berichte zur Verfügung.
Effiziente Leistung
Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.
Fügen Sie gegebenenfalls Cachingrichtlinien hinzu, um die Skalierbarkeit von API Management zu erhöhen. Mit Caching können Sie zudem die Last für ihre Back-End-Dienste verringern.
Sie können die Tarife „Basic“, „Standard“ und „Premium“ von Azure API Management können in einer Azure-Region aufskalieren, um mehr Kapazität zu bieten. Zum Analysieren der Nutzung für Ihren Dienst wählen Sie im Menü Metriken die Option Kapazitätsmetrik aus, und nehmen Sie dann eine entsprechende Hoch- oder Herunterskalierung vor. Es kann zwischen 15 und 45 Minuten dauern, bis der Upgrade- bzw. Skalierungsprozess abgeschlossen ist.
Empfehlungen zur Skalierung eines API Management-Diensts:
Berücksichtigen Sie Datenverkehrsmuster bei der Skalierung. Kunden mit veränderlichen Datenverkehrsmustern benötigen mehr Kapazität.
Eine konstante Kapazität von mehr als 66% kann darauf hinweisen, dass eine Hochskalierung notwendig ist.
Eine konstante Kapazität von unter 20% kann darauf hinweisen, dass eine Herunterskalierung notwendig ist.
Führen Sie immer einen Auslastungstest mit einer repräsentativen Last für Ihren API Management-Dienst durch, bevor Sie die Last in der Produktion aktivieren.
Mit dem Premium-Tarif können Sie eine API Management-Instanz über mehrere Azure-Regionen hinweg skalieren. Dadurch ist API Management für eine höhere SLA berechtigt, und Sie können Dienste in mehreren Regionen in der Nähe von Benutzern bereitstellen.
Das serverlose Modell von Logic Apps bedeutet, dass Administratoren die Skalierbarkeit der Dienste nicht planen müssen. Der Dienst wird automatisch entsprechend den Anforderungen skaliert.
Kostenoptimierung
Im Allgemeinen sollten Sie den Azure-Preisrechner verwenden, um Ihre Kosten zu ermitteln. Hier finden Sie einige weitere Überlegungen dazu.
API Management
Es entstehen Kosten für alle API Management-Instanzen, sobald sie ausgeführt werden. Wenn Sie zentral hochskaliert haben, das entsprechende Leistungsniveau jedoch nicht durchgehend benötigen, können Sie manuell zentral herunterskalieren oder die automatische Skalierung konfigurieren.
Logic Apps
Logic Apps verwendet ein serverloses Modell. Die Abrechnung erfolgt basierend auf Aktionen und Connectorausführung. Weitere Informationen hierzu finden Sie unter Logic Apps – Preise.
Weitere Informationen finden Sie im Abschnitt zu Kosten im Microsoft Azure Well-Architected Framework.
Nächste Schritte
Zugehörige Ressourcen
Wenn Sie die Back-End-Systeme entkoppeln und eine höhere Zuverlässigkeit sowie eine bessere Skalierbarkeit erreichen möchten, verwenden Sie Nachrichtenwarteschlangen und Ereignisse. Diese Architektur wird im nächsten Artikel dieser Reihe gezeigt:
Möglicherweise interessieren Sie sich auch für die folgenden Artikel aus dem Azure Architecture Center: