Front-End-Clientkommunikation

Tipp

Diese Inhalte sind ein Auszug aus dem E-Book „Architecting Cloud Native .NET Applications for Azure“, verfügbar in der .NET-Dokumentation oder als kostenlos herunterladbare PDF-Datei, die offline gelesen werden kann.

PDF herunterladen

In einem cloudnativen System benötigen Front-End-Clients (mobile, Web- und Desktopanwendungen) einen Kommunikationskanal zur Interaktion mit unabhängigen Back-End-Microservices.

Wie lauten die Optionen?

Der Einfachheit halber könnte ein Front-End Client direkt mit den Back-End Microservices kommunizieren, wie in Abbildung 4-2 dargestellt.

Abbildung 4-2. Direkte Kommunikation zwischen Client und Dienst

Bei diesem Ansatz verfügt jeder Microservice über einen öffentlichen Endpunkt, auf den Front-End-Clients zugreifen können. In einer Produktionsumgebung würden Sie einen Lastenausgleich vor den Microservices platzieren und den Datenverkehr anteilig weiterleiten.

Die direkte Kommunikation mit dem Client ist zwar einfach zu implementieren, aber nur für einfache Microserviceanwendungen akzeptabel. Dieses Muster koppelt die Front-End-Clients eng an die zentralen Back-End-Dienste und öffnet damit die Tür für viele Probleme, darunter:

• Anfälligkeit der Clients für das Refactoring von Back-End-Diensten.
• Eine größere Angriffsfläche, da die wichtigsten Back-End Dienste direkt verfügbar sind.
• Duplizierung von übergreifenden Belangen in jedem Microservice.
• Übermäßig komplexer Clientcode – Clients müssen den Überblick über mehrere Endpunkte behalten und Ausfälle auf resiliente Weise behandeln.

Stattdessen besteht ein weithin akzeptiertes Cloudentwurfsmuster darin, einen API-Gatewaydienst zwischen den Front-End-Anwendungen und den Back-End-Diensten zu implementieren. Das Muster ist in Abbildung 4-3 dargestellt.

Abbildung 4-3. Muster „API-Gateway“

Beachten Sie in der vorherigen Abbildung, wie der API-Gatewaydienst die Back-End-Kernmicroservices abstrahiert. Sie ist als Web-API implementiert und fungiert als Reverseproxy, der den eingehenden Datenverkehr an die internen Microservices weiterleitet.

Das Gateway isoliert den Client von der internen Partitionierung der Dienste und dem Refactoring. Wenn Sie einen Back-End-Dienst ändern, passen Sie ihn im Gateway an, ohne den Client zu beeinträchtigen. Es ist auch Ihre erste Verteidigungslinie für übergreifende Belange wie Identität, Zwischenspeicherung, Resilienz, Messung und Drosselung. Viele dieser bereichsübergreifenden Belange können von den Back-End-Kerndiensten auf das Gateway verlagert werden, wodurch die Back-End-Dienste vereinfacht werden.

Es muss darauf geachtet werden, dass das API-Gateway einfach und schnell bleibt. Normalerweise wird die Geschäftslogik vom Gateway getrennt. Ein komplexes Gateway läuft Gefahr, zu einem Engpass und schließlich selbst monolithisch zu werden. Größere Systeme verfügen oft über mehrere API-Gateways, die nach Clienttyp (mobil, Web, Desktop) oder Back-End-Funktionalität segmentiert sind. Das Muster Back-End für Front-Ends bietet eine Anleitung für die Implementierung mehrerer Gateways. Das Muster ist in Abbildung 4-4 dargestellt.

Abbildung 4-4. BFF-Muster (Back-End für Front-End)

Beachten Sie in der vorherigen Abbildung, wie der eingehende Datenverkehr an ein bestimmtes API-Gateway gesendet wird – je nach Clienttyp: Web-, Mobile- oder Desktop-App. Dieser Ansatz ist sinnvoll, da sich die Funktionen der einzelnen Geräte in Bezug auf Formfaktor, Leistung und Displayeinschränkungen erheblich unterscheiden. In der Regel machen mobile Anwendungen weniger Funktionen verfügbar als ein Browser oder Desktopanwendungen. Jedes Gateway kann so optimiert werden, dass es den Funktionen und der Funktionalität des entsprechenden Geräts entspricht.

Einfache Gateways

Für den Anfang könnten Sie Ihren eigenen API-Gatewaydienst erstellen. Eine schnelle Suche auf GitHub wird viele Beispiele liefern.

Für einfache cloudnative Anwendungen in .NET können Sie das Ocelot Gateway in Betracht ziehen. Es ist Open Source und wurde für .NET Microservices erstellt. Es ist zudem kompakt, schnell und skalierbar. Wie jedes API-Gateway besteht seine Hauptfunktion darin, eingehende HTTP-Anforderungen an nachgelagerte Dienste weiterzuleiten. Außerdem unterstützt es eine Vielzahl von Funktionen, die in einer .NET-Middleware-Pipeline konfigurierbar sind.

YARP (Yet Another Reverse Proxy) ist ein weiterer Open Source-Reverseproxy, der von einer Gruppe von Microsoft-Produktteams geleitet wird. YARP, das als NuGet-Paket heruntergeladen werden kann, fügt sich als Middleware in das ASP.NET-Framework ein und ist in hohem Maße anpassbar. Sie finden YARP gut dokumentiert mit verschiedenen Anwendungsbeispielen.

Für cloudnative Anwendungen in Unternehmen gibt es mehrere verwaltete Azure-Dienste, die Ihnen helfen können, Ihre Bemühungen zu beschleunigen.

Azure Application Gateway

Für einfache Gatewayanforderungen können Sie Azure Application Gateway in Betracht ziehen. Er ist als PaaS-Dienst in Azure verfügbar und umfasst grundlegende Gatewayfunktionen wie URL-Routing, SSL-Terminierung und eine Web Application Firewall. Der Dienst unterstützt Lastenausgleichsfunktionen der Ebene 7. Mit Ebene 7 können Sie Anforderungen auf der Grundlage des tatsächlichen Inhalts einer HTTP-Nachricht weiterleiten, nicht nur auf der Grundlage von TCP-Netzwerkpaketen auf niedriger Ebene.

In diesem Buch propagieren wir das Hosting cloudnativer Systeme in Kubernetes. Kubernetes ist ein Containerorchestrator und automatisiert die Bereitstellung, Skalierung und den Betrieb von containerisierten Workloads. Azure Application Gateway kann als API-Gateway für Azure Kubernetes Service-Cluster konfiguriert werden.

Der Eingangsdatencontroller des Anwendungsgateways ermöglicht es Azure Application Gateway, direkt mit Azure Kubernetes Service zu arbeiten. Abbildung 4.5 zeigt die Architektur.

Abbildung 4-5. Application Gateway-Eingangscontroller

Kubernetes enthält ein integriertes Feature, das den HTTP-Lastenausgleich (Ebene 7) unterstützt, der als Ingress (Eingang) bezeichnet wird. Ingress (Eingang) definiert eine Reihe von Regeln dafür, wie Microservice-Instanzen innerhalb von AKS nach außen hin sichtbar gemacht werden können. In der vorherigen Abbildung interpretiert der Eingangsdatencontroller die für den Cluster konfigurierten Eingangsdatenregeln und konfiguriert automatisch das Azure Application Gateway. Auf der Grundlage dieser Regeln leitet das Azure Application Gateway den Datenverkehr an die in AKS ausgeführten Microservices weiter. Der Eingangsdatencontroller lauscht auf Änderungen an den Eingangsregeln und nimmt die entsprechenden Änderungen am Azure Application Gateway vor.

Azure API Management

Für mittelgroße bis große cloudnative Systeme können Sie Azure API Management in Betracht ziehen. Es handelt sich um einen cloudbasierten Dienst, der nicht nur Ihre Anforderungen an das API-Gateway erfüllt, sondern auch eine umfassende Entwickler- und Verwaltungsumgebung bietet. API Management ist in Abbildung 4-6 dargestellt.

Abbildung 4–6. Azure API Management

Zunächst macht API Management einen Gatewayserver verfügbar, der den kontrollierten Zugriff auf Back-End-Dienste auf der Grundlage von konfigurierbaren Regeln und Richtlinien ermöglicht. Diese Dienste können sich in der Azure-Cloud, in Ihrem lokalen Rechenzentrum oder in anderen öffentlichen Clouds befinden. API-Schlüssel und JWT-Token bestimmen, wer welche Aktionen durchführen kann. Der gesamte Datenverkehr wird zu Analysezwecken protokolliert.

Für Entwickler bietet API Management ein Entwicklerportal, das Zugriff auf Dienste, Dokumentation und Beispielcode für den Aufruf der Dienste bietet. Entwickler können Swagger/Open API verwenden, um Dienstendpunkte zu untersuchen und ihre Nutzung zu analysieren. Der Dienst arbeitet mit den wichtigsten Entwicklungsplattformen zusammen: .NET, Java, Golang und mehr.

Das Herausgeberportal bietet ein Verwaltungsdashboard, über das Administratoren APIs verfügbar machen und deren Verhalten verwalten können. Der Dienstzugriff kann gewährt, die Dienstintegrität überwacht und die Diensttelemetriedaten gesammelt werden. Administratoren wenden Richtlinien auf jeden Endpunkt an, um das Verhalten zu beeinflussen. Richtlinien sind vordefinierte Anweisungen, die sequenziell für jeden Dienstaufruf ausgeführt werden. Richtlinien werden für einen ein- oder ausgehenden Aufruf konfiguriert oder bei einem Fehler aufgerufen. Richtlinien können auf verschiedene Dienste angewendet werden, um eine deterministische Reihenfolge bei der Kombination von Richtlinien zu ermöglichen. Das Produkt wird mit einer großen Anzahl vordefinierter Richtlinien ausgeliefert.

Hier finden Sie Beispiele dafür, wie Richtlinien sich auf das Verhalten Ihrer cloudnativen Dienste auswirken können:

• Einschränken des Dienstzugriffs.
• Erzwingen der Authentifizierung.
• Drosseln von Aufrufen aus einer einzigen Quelle, falls erforderlich.
• Aktivieren von Caching.
• Blockieren von Aufrufen von bestimmten IP-Adressen.
• Steuern des Dienstablaufs.
• Konvertieren von Anforderungen von SOAP in REST oder zwischen verschiedenen Datenformaten, z. B. von XML in JSON.

Azure API Management kann Back-End-Dienste verfügbar machen, die überall gehostet werden – in der Cloud oder in Ihrem Rechenzentrum. Für Legacy-Dienste, die Sie möglicherweise in Ihren cloudnativen Systemen verfügbar machen, unterstützt es sowohl REST- als auch SOAP-APIs. Auch andere Azure-Dienste können über API Management bereitgestellt werden. Sie könnten eine verwaltete API auf einen Azure Unterstützungsdienst wie Azure Service Bus oder Azure Logic Apps aufsetzen. Azure API Management enthält keine integrierte Unterstützung für den Lastausgleich und sollte mithilfe eines Lastenausgleichsdiensts verwendet werden.

Azure API Management ist in vier verschiedenen Tarifen verfügbar:

• Entwickler
• Grundlegend
• Standard
• Premium

Der Entwickler-Tarif ist für nicht produktive Workloads und Auswertungen gedacht. Die anderen Tarife bieten nach und nach mehr Leistung, Features und höhere Service Level Agreements (SLAs). Der Premium-Tarif bietet Azure Virtual Network und Unterstützung für mehrere Regionen. Alle Tarife weisen einen festen Preis pro Stunde auf.

Die Azure-Cloud bietet auch einen serverlosen Tarif für Azure API Management. Bei diesem als Verbrauchstarif bezeichneten Dienst handelt es sich um eine Variante von API Management, die auf dem Modell des serverlosen Computing basiert. Im Gegensatz zu den zuvor gezeigten „vorab zugewiesenen“ Tarifen (Prepaidtarif) bietet der Verbrauchstarif eine sofortige Bereitstellung und Preise mit Bezahlung pro Aktion.

Er ermöglicht API-Gatewayfeatures für die folgenden Anwendungsfälle:

• Microservices, die mit serverlosen Technologien wie Azure Functions und Azure Logic Apps implementiert werden.
• Azure-Ressourcen für Unterstützungsdienste wie Service Bus-Warteschlangen und -Themen, Azure-Speicher und andere.
• Microservices, bei denen der Datenverkehr gelegentlich große Spitzen aufweist, aber die meiste Zeit über gering bleibt.

Der Verbrauchstarif verwendet dieselben zugrundeliegenden API Management-Komponenten des Diensts, nutzt jedoch eine völlig andere Architektur, die auf dynamisch zugeordneten Ressourcen basiert. Er ist perfekt auf das Modell des serverlosen Computings abgestimmt.

• Es muss keine Infrastruktur verwaltet werden.
• Keine Kapazität im Leerlauf.
• Hochverfügbarkeit.
• Autoskalierung.
• Die Kosten basieren auf der tatsächlichen Nutzung.

Der neue Verbrauchstarif ist eine gute Wahl für cloudnative Systeme, die serverlose Ressourcen als APIs bereitstellen.

Echtzeitkommunikation

Die Echtzeit- oder Push-Kommunikation ist eine weitere Option für Front-End-Anwendungen, die mit cloudnativen Back-End-Systemen über HTTP kommunizieren. Anwendungen wie Finanzticker, Onlineunterricht, Spiele und Aktualisierungen zum Auftragsstatus erfordern sofortige Echtzeitreaktionen vom Back-End. Bei normaler HTTP-Kommunikation gibt es keine Möglichkeit für den Client zu wissen, wann neue Daten verfügbar sind. Der Client muss ständig Anforderungen an den Server senden oder ihn abfragen. Mit Echtzeitkommunikation kann der Server jederzeit per Push neue Daten an den Client übertragen.

Echtzeitsysteme sind oft durch hochfrequente Datenflüsse und eine große Anzahl von gleichzeitigen Clientverbindungen gekennzeichnet. Die manuelle Implementierung von Echtzeitkonnektivität kann schnell komplex werden und erfordert eine nicht triviale Infrastruktur, um Skalierbarkeit und zuverlässiges Messaging für verbundene Clients zu gewährleisten. Sie könnten eine Instanz von Azure Redis Cache und eine Reihe von Lastenausgleichen verwalten, die mit fixierten Sitzungen für die Clientaffinität konfiguriert sind.

Azure SignalR Service ist ein vollständig verwalteter Azure-Dienst, der die Echtzeitkommunikation für Ihre cloudnativen Anwendungen vereinfacht. Technische Implementierungsdetails wie Kapazitätsbereitstellung, Skalierung und dauerhafte Verbindungen werden abstrahiert. Sie werden für Sie mit einer Vereinbarung zum Servicelevel von 99,9 % abgewickelt. Sie konzentrieren sich auf die Anwendungsfeatures, nicht auf die Installation der Infrastruktur.

Nach der Aktivierung kann ein cloudbasierter HTTP-Dienst Aktualisierungen von Inhalten direkt an verbundene Clients weiterleiten, einschließlich Browser-, Mobil- und Desktopanwendungen. Clients werden aktualisiert, ohne dass der Server abgefragt werden muss. Azure SignalR abstrahiert die Transporttechnologien, die für Echtzeitkonnektivität sorgen, darunter WebSockets, Server-Side Events und Long Polling. Die Entwickler konzentrieren sich darauf, Nachrichten an alle oder bestimmte Teilmengen von verbundenen Clients zu senden.

Abbildung 4-7 zeigt eine Reihe von HTTP-Clients, die sich mit einer cloudnativen Anwendung mit aktiviertem Azure SignalR verbinden.

Abbildung 4–7. Azure SignalR

Ein weiterer Vorteil des Azure SignalR-Diensts besteht in der Implementierung von serverlosen cloudnativen Diensten. Möglicherweise wird Ihr Code bei Bedarf mit Azure Functions-Triggern ausgeführt. Dieses Szenario kann schwierig sein, da Ihr Code keine längeren Verbindungen mit Clients aufrecht erhält. Diese Situation kann mit dem Azure SignalR Service gelöst werden, da der Dienst bereits Verbindungen für Sie verwaltet.

Der Azure SignalR-Dienst ist eng in andere Azure-Dienste integriert, z. B. Azure SQL-Datenbank, Service Bus oder Redis Cache, was viele Möglichkeiten für Ihre cloudnativen Anwendungen eröffnet.

ZurückWeiter