Front-End-Clientkommunikation

Tipp

Dieser Inhalt ist ein Auszug aus dem eBook, Architecting Cloud Native .NET Applications for Azure, verfügbar auf .NET Docs oder als kostenlose herunterladbare PDF, die offline gelesen werden kann.

PDF herunterladen

In einem cloudeigenen System erfordern Front-End-Clients (mobile, Web- und Desktopanwendungen) einen Kommunikationskanal für die Interaktion mit unabhängigen Back-End-Microservices.

Was sind die Optionen?

Um die Dinge einfach zu halten, könnte ein Front-End-Client direkt mit den Back-End-Microservices kommunizieren , wie in Abbildung 4-2 dargestellt.

Abbildung 4-2. Direkte Client-zu-Dienst-Kommunikation

Bei diesem Ansatz verfügt jeder Microservice über einen öffentlichen Endpunkt, der von Front-End-Clients zugänglich ist. In einer Produktionsumgebung platzieren Sie ein Lastenausgleichsmodul vor den Microservices, wobei der Datenverkehr proportional weitergeleitet wird.

Die direkte Clientkommunikation wäre zwar einfach zu implementieren, wäre jedoch nur für einfache Microservice-Anwendungen akzeptabel. Dieses Muster koppelt Front-End-Clients eng mit kernigen Back-End-Diensten und öffnet die Tür für viele Probleme, darunter:

• Anfälligkeit des Clients für die Refaktorierung des Back-End-Dienstes.
• Eine breitere Angriffsfläche, da Kern-Back-End-Dienste direkt verfügbar gemacht werden.
• Duplizierung von übergreifenden Anliegen in jedem Mikroservice.
• Übermäßig komplexer Clientcode – Clients müssen mehrere Endpunkte nachverfolgen und Fehler auf robuste Weise behandeln.

Stattdessen besteht ein allgemein akzeptiertes Clouddesignmuster darin, einen API-Gatewaydienst zwischen den Front-End-Anwendungen und 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-Kern-Microservices abstrahiert. Als Web-API implementiert, fungiert sie als Reverseproxy, um eingehenden Datenverkehr an die internen Microservices weiterzuleiten.

Das Gateway isoliert den Client von der internen Dienstpartitionierung und -umgestaltung. Wenn Sie einen Back-End-Dienst ändern, können Sie ihn in das Gateway aufnehmen, ohne den Client zu unterbrechen. Es ist auch Ihre erste Verteidigungslinie für querschneidende Bedenken, z. B. Identität, Zwischenspeichern, Resilienz, Metering und Drosselung. Viele dieser übergreifenden Anliegen können von den Backend-Kerndiensten auf das Gateway ausgelagert werden, was die Backend-Dienste vereinfacht.

Achten Sie darauf, das API-Gateway einfach und schnell zu halten. In der Regel wird die Geschäftslogik außerhalb des Gateways gehalten. Ein komplexes Gateway läuft Gefahr, zu einem Engpass zu werden und schließlich selbst zu einem Monolithen. Größere Systeme machen häufig mehrere API-Gateways verfügbar, die nach Clienttyp (mobil, Web, Desktop) oder Back-End-Funktionalität segmentiert sind. Das Backend-for-Frontends-Muster liefert Hinweise zur 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 eingehender Datenverkehr an ein bestimmtes API-Gateway gesendet wird – basierend auf dem Clienttyp: Web, Mobil oder Desktop-App. Dieser Ansatz ist sinnvoll, da sich die Funktionen jedes Geräts hinsichtlich Formfaktor, Leistung und Anzeigeeinschrä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 Fähigkeiten und Funktionen des entsprechenden Geräts entspricht.

Einfache Gateways

Zunächst könnten Sie Ihren eigenen API-Gatewaydienst erstellen. Eine schnelle Suche von GitHub enthält viele Beispiele.

Bei einfachen .NET Cloud-nativen Anwendungen können Sie das Ocelot-Gateway in Betracht ziehen. Open Source und erstellt für .NET Microservices, es ist leicht, schnell, skalierbar. Wie jedes API-Gateway besteht die primäre Funktionalität darin, eingehende HTTP-Anforderungen an nachgeschaltete Dienste weiterzuleiten. Darüber hinaus unterstützt sie 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. Als NuGet-Paket herunterladbar, wird YARP als Middleware in das ASP.NET Framework eingebunden und ist hochgradig anpassbar. Sie finden YARP gut dokumentiert mit verschiedenen Verwendungsbeispielen.

Für cloudeigene Unternehmensanwendungen gibt es mehrere verwaltete Azure-Dienste, die Ihnen helfen können, Ihre Bemühungen zu starten.

Azure-Anwendungsgateway

Für einfache Gatewayanforderungen können Sie Das Azure-Anwendungsgateway in Betracht ziehen. Als Azure PaaS-Dienst verfügbar, enthält es grundlegende Gatewayfunktionen wie URL-Routing, SSL-Beendigung und eine Webanwendungsfirewall. Der Dienst unterstützt Layer-7-Lastenausgleichsfunktionen . 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 evangelisieren wir das Hosten von Cloud-nativen Systemen in Kubernetes. Kubernetes ist ein Container-Orchestrator, der die Bereitstellung, Skalierung und betrieblichen Aspekte von containerisierten Workloads automatisiert. Das Azure-Anwendungsgateway kann als API-Gateway für Azure Kubernetes-Dienstcluster konfiguriert werden.

Der Application Gateway Ingress Controller ermöglicht, dass das Azure Application Gateway direkt mit Azure Kubernetes Service arbeitet. 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" bezeichnet wird. Ingress definiert eine Reihe von Regeln, wie Microservice-Instanzen innerhalb von AKS für die Außenwelt verfügbar gemacht werden können. In der vorherigen Abbildung interpretiert der Eingangscontroller die für den Cluster konfigurierten Eingangsregeln und konfiguriert automatisch das Azure-Anwendungsgateway. Basierend auf diesen Regeln leitet das Anwendungsgateway Datenverkehr an Microservices weiter, die innerhalb von AKS ausgeführt werden. Der Eingangscontroller lauscht auf Änderungen an Eingangsregeln und nimmt die entsprechenden Änderungen am Azure-Anwendungsgateway vor.

Azure-API-Verwaltung

Für moderate bis große cloudeigene Systeme können Sie azure API Management in Betracht ziehen. Es ist ein cloudbasierter Dienst, der nicht nur Ihre API-Gatewayanforderungen erfüllt, sondern eine umfassende Entwickler- und Verwaltungserfahrung bietet. Die API-Verwaltung ist in Abbildung 4-6 dargestellt.

Abbildung 4-6. Azure-API-Verwaltung

Zunächst macht die API-Verwaltung einen Gatewayserver verfügbar, der den kontrollierten Zugriff auf Back-End-Dienste basierend auf konfigurierbaren Regeln und Richtlinien ermöglicht. Diese Dienste können sich in der Azure-Cloud, in Ihrem lokalen Rechenzentrum oder in anderen öffentlichen Clouds befindet. API-Schlüssel und JWT-Token bestimmen, wer was tun kann. Der gesamte Datenverkehr wird zu analytischen Zwecken protokolliert.

Für Entwickler bietet DIE API-Verwaltung ein Entwicklerportal, das Zugriff auf Dienste, Dokumentationen und Beispielcode zum Aufrufen bietet. Entwickler können Swagger/Open API verwenden, um Dienstendpunkte zu prüfen und ihre Nutzung zu analysieren. Der Dienst funktioniert auf den wichtigsten Entwicklungsplattformen: .NET, Java, Golang und vieles mehr.

Das Herausgeberportal macht ein Verwaltungsdashboard verfügbar, in dem Administratoren APIs verfügbar machen und ihr Verhalten verwalten. Der Dienstzugriff kann gewährt, der Dienststatus überwacht und die Telemetrie des Diensts 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 Dienstbereiche angewendet werden, um die deterministische Sortierung beim Kombinieren von Richtlinien zu aktivieren. Das Produkt wird mit einer großen Anzahl vordefinierter Richtlinien ausgeliefert.

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

• Einschränken des Dienstzugriffs.
• Authentifizierung erzwingen.
• Drosseln von Aufrufen aus einer einzigen Quelle, falls erforderlich.
• Zwischenspeichern aktivieren.
• Blockieren von Anrufen von bestimmten IP-Adressen.
• Steuern des Dienstflusses.
• Konvertieren Sie 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. Bei älteren Diensten, die Sie in Ihren cloudeigenen Systemen verfügbar machen können, werden sowohl REST- als auch SOAP-APIs unterstützt. Auch andere Azure-Dienste können über die API-Verwaltung verfügbar gemacht werden. Sie können eine verwaltete API auf einem Azure-Sicherungsdienst wie Azure Service Bus oder Azure Logic Apps platzieren. Azure API Management enthält keine integrierte Unterstützung für den Lastenausgleich und sollte in Verbindung mit einem Lastenausgleichsdienst verwendet werden.

Azure API Management ist auf vier verschiedenen Ebenen verfügbar:

• Entwickler
• Grundlegend
• Norm
• Prämie

Die Entwicklerebene ist für Nichtproduktionsworkloads und -auswertungen vorgesehen. Die anderen Stufen bieten schrittweise mehr Leistungsfähigkeit, Features und Vereinbarungen auf höherem Servicelevel (SLAs). Die Premium-Stufe bietet ein virtuelles Azure-Netzwerk und Unterstützung für mehrere Regionen. Alle Stufen weisen einen festen Preis pro Stunde auf.

Die Azure-Cloud bietet auch eine serverlose Ebene für Azure API Management. Der Dienst wird als Verbrauchspreisstufe bezeichnet und ist eine Variante der API-Verwaltung, die um das serverlose Computermodell herum entworfen wurde. Im Gegensatz zu den zuvor gezeigten „vorab zugewiesenen“ Tarifen (Prepaidtarif) bietet der Verbrauchstarif eine sofortige Bereitstellung und Preise mit Bezahlung pro Aktion.

Es 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-unterstützende Dienstressourcen wie Service-Bus-Warteschlangen und -Themen, Azure-Speicher und andere.
• Microservices, bei denen der Datenverkehr gelegentlich große Spitzen aufweist, aber die meiste Zeit niedrig bleibt.

Die Verbrauchsebene verwendet dieselben zugrunde liegenden Dienst-API-Verwaltungskomponenten, verwendet jedoch eine völlig andere Architektur basierend auf dynamisch zugeordneten Ressourcen. Es richtet sich perfekt an das serverlose Computermodell:

• Keine Zu verwaltende Infrastruktur.
• Keine Leerlaufkapazität.
• Hohe Verfügbarkeit.
• Automatische Skalierung.
• Die Kosten basieren auf der tatsächlichen Nutzung.

Die neue Verbrauchsstufe ist eine großartige Wahl für cloudeigene Systeme, die serverlose Ressourcen als APIs verfügbar machen.

Echtzeitkommunikation

Die Kommunikation in Echtzeit oder Push ist eine weitere Option für Front-End-Anwendungen, die mit systemeigenen Back-End-Systemen über HTTP kommunizieren. Anwendungen, z. B. Finanzticker, Online-Ausbildung, Spiele und Statusaktualisierungen, erfordern sofortige Echtzeitantworten 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 kontinuierlich den Server abfragen oder Anfragen senden. Mit Echtzeitkommunikation kann der Server jederzeit neue Daten an den Client übertragen.

Echtzeitsysteme zeichnen sich häufig durch Hochfrequenzdatenflüsse und große Anzahl gleichzeitiger Clientverbindungen aus. Die manuelle Implementierung von Echtzeitkonnektivität kann schnell komplex werden, was eine nicht triviale Infrastruktur erfordert, um Skalierbarkeit und zuverlässiges Messaging an verbundene Clients sicherzustellen. 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 cloudeigenen Anwendungen vereinfacht. Details zur technischen Implementierung wie Kapazitätsbereitstellung, Skalierung und persistente 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 Inhaltsupdates direkt an verbundene Clients übertragen, einschließlich Browser-, Mobile- und Desktopanwendungen. Clients werden aktualisiert, ohne dass der Server abgefragt werden muss. Azure SignalR abstrahiert die Transporttechnologien, die Echtzeitkonnektivität herstellen, einschließlich WebSockets, Server-Side-Ereignisse und Long Polling. Entwickler konzentrieren sich auf das Senden von Nachrichten an alle oder bestimmte Teilmengen verbundener Clients.

Abbildung 4-7 zeigt eine Reihe von HTTP-Clients, die eine Verbindung mit einer cloudeigenen Anwendung herstellen, wobei Azure SignalR aktiviert ist.

Abbildung 4-7. Azure SignalR

Ein weiterer Vorteil des Azure SignalR-Diensts besteht in der Implementierung von serverlosen Cloud-nativen Diensten. Möglicherweise wird Ihr Code bei Bedarf mit Azure Functions-Triggern ausgeführt. Dieses Szenario kann schwierig sein, da Ihr Code keine langen Verbindungen mit Clients aufrecht erhält. Der Azure SignalR-Dienst kann diese Situation verarbeiten, 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 cloudeigenen Anwendungen eröffnet.

ZurückWeiter