Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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.
In diesem Kapitel haben wir die Herausforderungen der Mikroservicekommunikation untersucht. Wir haben gesagt, dass Entwicklungsteams darauf achten müssen, wie Back-End-Dienste miteinander kommunizieren. Je weniger dienstübergreifende Kommunikation, desto besser. Die Vermeidung ist jedoch nicht immer möglich, da Back-End-Dienste häufig voneinander abhängig sind, um Vorgänge auszuführen.
Wir haben verschiedene Ansätze für die Implementierung synchroner HTTP-Kommunikation und asynchroner Messaging untersucht. In jedem Fall wird der Entwickler mit der Implementierung von Kommunikationscode belastet. Kommunikationscode ist komplex und zeitintensiv. Falsche Entscheidungen können zu erheblichen Leistungsproblemen führen.
Ein modernerer Ansatz für die Mikroservicekommunikation rund um eine neue und sich schnell entwickelnde Technologie mit dem Titel Service Mesh. Ein Service Mesh ist eine konfigurierbare Infrastrukturebene mit integrierten Funktionen zur Verwaltung der Dienst-zu-Dienst-Kommunikation, zur Gewährleistung der Resilienz und zur Behandlung vieler übergreifender Anforderungen. Sie verlagert die Verantwortung für diese Belange aus den Microservices in die Service-Mesh-Schicht. Die Kommunikation wird von Ihren Microservices abstrahiert.
Eine Schlüsselkomponente einer Service Mesh ist ein Dienst-Proxy. In einer cloudeigenen Anwendung wird eine Instanz eines Proxys in der Regel mit jedem Microservice verkettet. Während sie in separaten Prozessen ausgeführt werden, sind die beiden eng miteinander verknüpft und teilen denselben Lebenszyklus. Dieses Muster, das als Sidecar-Muster bezeichnet wird und in Abbildung 4-24 dargestellt ist.
Abbildung 4-24. Servicegitter mit einem Seitenwagen
Beachten Sie in der vorherigen Abbildung, wie Nachrichten von einem Proxy abgefangen werden, der zusammen mit jedem Microservice ausgeführt wird. Jeder Proxy kann mit Datenverkehrsregeln konfiguriert werden, die für den Microservice spezifisch sind. Es versteht Nachrichten und kann sie über Ihre Dienste und die Außenwelt weiterleiten.
Zusammen mit der Verwaltung der Dienst-zu-Dienst-Kommunikation bietet das Service Mesh Unterstützung für die Dienstermittlung und den Lastenausgleich.
Nach der Konfiguration ist ein Dienstgitter hoch funktionsfähig. Das Mesh ruft einen entsprechenden Pool von Instanzen von einem Dienstermittlungsendpunkt ab. Sie sendet eine Anforderung an eine bestimmte Dienstinstanz und zeichnet die Latenz und den Antworttyp des Ergebnisses auf. Es wählt die Instanz aus, die wahrscheinlich eine schnelle Antwort basierend auf verschiedenen Faktoren zurückgibt, einschließlich der beobachteten Latenz für aktuelle Anforderungen.
Ein Dienstgitter verwaltet Datenverkehr, Kommunikation und Netzwerkbedenken auf Anwendungsebene. Es versteht Nachrichten und Anforderungen. Ein Service-Mesh integriert sich typischerweise in einen Container-Orchestrator. Kubernetes unterstützt eine erweiterbare Architektur, in der ein Dienstgitter hinzugefügt werden kann.
In Kapitel 6 vertiefen wir uns mit Service Mesh-Technologien, einschließlich einer Diskussion über seine Architektur und verfügbaren Open-Source-Implementierungen.
Zusammenfassung
In diesem Kapitel haben wir cloudeigene Kommunikationsmuster erörtert. Zunächst untersuchen wir, wie Front-End-Clients mit Back-End-Microservices kommunizieren. Auf dem Weg haben wir über API-Gatewayplattformen und echtzeitbasierte Kommunikation gesprochen. Anschließend haben wir uns angesehen, wie Microservices mit anderen Back-End-Diensten kommunizieren. Wir haben sowohl synchrone HTTP-Kommunikation als auch asynchrones Messaging über Dienste hinweg betrachtet. Wir behandelten gRPC, eine bevorstehende Technologie in der cloud-nativen Welt. Schließlich haben wir eine neue und sich schnell entwickelnde Technologie mit dem Titel Service Mesh eingeführt, die die Mikroservice-Kommunikation optimieren kann.
Besonderer Schwerpunkt lag auf verwalteten Azure-Diensten, die bei der Implementierung der Kommunikation in cloudeigenen Systemen helfen können:
- Azure-Anwendungsgateway
- Azure-API-Verwaltung
- Azure SignalR-Dienst
- Azure Storage-Warteschlangen
- Azure Service Bus
- Azure-Ereignisraster
- Azure Event Hub
Als Nächstes wechseln wir zu verteilten Daten in cloudeigenen Systemen und zu den Vorteilen und Herausforderungen, die es darstellt.
Verweise
Zusammenarbeit auf GitHub
Die Quelle für diesen Inhalt finden Sie auf GitHub, wo Sie auch Issues und Pull Requests erstellen und überprüfen können. Weitere Informationen finden Sie in unserem Leitfaden für Mitwirkende.
