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
Application. Die Anwendung ist ein Client, der das API-Gateway nach der Authentifizierung mit Microsoft Entra aufruft. Die Anwendung kann eine Web-App, eine mobile App oder ein anderer Client sein, der HTTP-Anforderungen stellen kann.
Microsoft Entra ID. Wird verwendet, um die Clientanwendung zu authentifizieren. Die Clientanwendung ruft ein Zugriffstoken von der Microsoft Entra-ID ab und schließt es in die Anforderung an das API-Gateway ein.
Azure API Management: API Management besteht aus zwei zugehörigen Komponenten:
API-Gateway. Das API-Gateway akzeptiert HTTP-Aufruf von der Clientanwendung, überprüft das Token von Microsoft Entra ID und leitet die Anforderung an den Back-End-Dienst weiter. Das API-Gateway kann auch Anforderungen und Antworten transformieren und Antworten zwischenspeichern.
Entwicklerportal. Das Entwicklerportal wird von Entwicklern verwendet, um die APIs zu entdecken und zu interagieren. Das Entwicklerportal kann an das Branding Ihrer Organisation angepasst werden.
Azur Logic Apps. Logik-Apps werden verwendet, um die Aufrufe der Back-End-Dienste zu koordinieren. Logik-Apps können durch eine Vielzahl von Ereignissen ausgelöst werden und eine Vielzahl von Diensten aufrufen. In dieser Lösung wird Logic Apps verwendet, um die Back-End-Dienste aufzurufen und eine einfache Konnektivität über Connectors bereitzustellen, die Notwendigkeit von benutzerdefiniertem Code zu verringern.
Back-End-Dienste. Bei den Back-End-Diensten kann es sich um einen beliebigen Dienst oder eine Branchenanwendung handeln, z. B. eine Datenbank, einen Webdienst oder eine SaaS-Anwendung. Die Back-End-Dienste können in Azure oder lokal gehostet werden.
Komponenten
-
Integration Services ist eine Sammlung von Diensten für die Integration von Anwendungen, Daten und Vorgängen. In dieser Lösung werden zwei dieser Dienste verwendet: Logik-Apps und API-Verwaltung. Logik-Apps werden verwendet, um die nachrichtenbasierte Integration zwischen Systemen zu erleichtern und die Konnektivität mit Connectors zu erleichtern. Die API-Verwaltung wird verwendet, um eine Fassade für die Back-End-Dienste bereitzustellen, sodass Clients eine konsistente Schnittstelle für die Interaktion mit clients ermöglichen.
- Logic Apps ist eine serverlose Plattform zum Erstellen von Unternehmensworkflows, die Anwendungen, Daten und Dienste integrieren. In dieser Lösung wird Logic Apps verwendet, um die Aufrufe der Back-End-Dienste zu koordinieren und eine einfache Konnektivität durch Connectors zu ermöglichen, die den Bedarf an benutzerdefiniertem Code reduzieren.
- 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. In dieser Lösung bietet die API-Verwaltung zusätzliche Funktionen wie Ratelimiting, Authentifizierung und Zwischenspeicherung an die Back-End-Dienste. Darüber hinaus bietet die API-Verwaltung ein Entwicklerportal für Clients zum Ermitteln und Interagieren mit den APIs.
- Azure DNS ist ein Hostingdienst für DNS-Domänen. Azure DNS hosten die öffentlichen DNS-Einträge für den API-Verwaltungsdienst. Dadurch können Clients den DNS-Namen in die IP-Adresse des API-Verwaltungsdiensts auflösen.
- 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. Hier wird entra ID verwendet, um den API-Verwaltungsdienst mit OAuth 2.0- und dem Entwicklerportal mit Entra B2C-zu sichern.
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 Stufen bieten eine Vereinbarung zum Servicelevel für Die Produktion (Service Level Agreement, SLA) und unterstützen die Skalierung innerhalb der Azure-Region. Die Durchsatzkapazität für API Management wird in Einheiten gemessen. Jede Preisstufe verfügt über eine maximale Skalierung. Die Premium-Stufe unterstützt auch das Skalieren in mehreren Azure-Regionen. 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.
Die API-Verwaltungsnutzungsebene wird für diese Lösung nicht empfohlen, da sie das Entwicklerportal nicht unterstützt, das für diese Architektur erforderlich ist. Die Entwicklerebene ist speziell für Nichtproduktionsumgebungen vorgesehen und wird für Produktionsworkloads nicht empfohlen. Eine Featurematrix, die die Unterschiede zwischen den Ebenen enthält, finden Sie hier.
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 Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie an Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.
Lesen Sie die SLAs für jeden Dienst hier
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 Prüfliste zur Entwurfsüberprüfung für sicherheitsrelevante.
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 mithilfe von gegenseitigen Zertifikateneine Verbindung mit Back-End-Diensten aus der API-Verwaltung her.
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 mit vertraulichen Daten arbeitet, finden Sie unter sicheren Zugriff und Daten für Workflows in Azure Logic Apps ausführliche Anleitungen.
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.
Kostenoptimierung
Bei der Kostenoptimierung geht es um Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Prüfliste für die Überprüfung der 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.
Operative Exzellenz
Operational Excellence deckt die Betriebsprozesse ab, mit denen eine Anwendung bereitgestellt und in der Produktion ausgeführt wird. Weitere Informationen finden Sie unter Prüfliste für die Überprüfung von Operational Excellence.
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.
Leistungseffizienz
Die Leistungseffizienz ist die Fähigkeit Ihrer Arbeitsauslastung, um die Anforderungen zu erfüllen, die die Benutzer auf effiziente Weise an sie stellen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für die 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.
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: