Robuste Kommunikation

In diesem Buch haben wir einen mikroservicebasierten Architekturansatz übernommen. Während eine solche Architektur wichtige Vorteile bietet, stellt sie viele Herausforderungen dar:

• Out-of-Process-Netzwerkkommunikation. Jeder Microservice kommuniziert über ein Netzwerkprotokoll, das Netzwerküberlastung, Latenz und vorübergehende Fehler einführt.

• Dienstermittlung: Wie erkennen und kommunizieren Microservices miteinander, wenn sie auf einem Cluster von Computern mit ihren eigenen IP-Adressen und Ports ausgeführt werden?

• Resilienz: Wie verwalten Sie kurzlebige Fehler und halten das System stabil?

• Lastenausgleich. Wie wird eingehender Datenverkehr über mehrere Instanzen eines Microservice verteilt?

• Sicherheit: Wie werden Sicherheitsbedenken wie Verschlüsselung und Zertifikatverwaltung auf Transportebene erzwungen?

• Verteilte Überwachung. – Wie korrelieren und erfassen Sie die Rückverfolgbarkeit und Überwachung für eine einzelne Anforderung über mehrere verbrauchende Microservices?

Sie können diese Probleme mit verschiedenen Bibliotheken und Frameworks beheben, aber die Implementierung kann teuer, komplex und zeitaufwändig sein. Sie enden auch mit Infrastrukturbedenken in Verbindung mit geschäftslogik.

Dienstnetz

Ein besserer Ansatz ist eine sich entwickelnde Technologie mit dem Titel Service Mesh. Ein Dienstgitter ist eine konfigurierbare Infrastrukturebene mit integrierten Funktionen zur Behandlung der Dienstkommunikation und der anderen oben genannten Herausforderungen. Sie entkoppelt diese Bedenken, indem sie in einen Dienstproxy verschoben werden. Der Proxy wird in einem separaten Prozess (als Sidecar bezeichnet) bereitgestellt, um eine Isolation von Geschäftscode bereitzustellen. Das Sidecar ist jedoch mit dem Dienst verknüpft – er wird mit ihm erstellt und teilt seinen Lebenszyklus. Abbildung 6-7 zeigt dieses Szenario.

Abbildung 6-7. Servicegitter mit einem Seitenwagen

Beachten Sie in der vorherigen Abbildung, wie der Proxy die Kommunikation zwischen den Microservices und dem Cluster abfangen und verwaltet.

Ein Dienstgitter wird logisch in zwei unterschiedlichen Komponenten unterteilt: eine Datenebene und eine Kontrollebene. Abbildung 6-8 zeigt diese Komponenten und deren Verantwortlichkeiten.

Abbildung 6-8. Dienstgittersteuerung und Datenebene

Nach der Konfiguration ist ein Dienstgitter hoch funktionsfähig. Er kann einen entsprechenden Pool von Instanzen von einem Dienstermittlungsendpunkt abrufen. Das Gitter kann dann eine Anforderung an eine bestimmte Instanz senden und die Latenz und den Antworttyp des Ergebnisses aufzeichnen. Ein Gitter kann die Instanz auswählen, die wahrscheinlich eine schnelle Antwort basierend auf vielen Faktoren zurückgibt, einschließlich der beobachteten Latenz für aktuelle Anforderungen.

Wenn eine Instanz nicht reagiert oder fehlschlägt, wiederholt das Gitter die Anforderung für eine andere Instanz. Wenn Fehler zurückgegeben werden, entfernt ein Gitter die Instanz aus dem Lastenausgleichspool und setzt sie nach dem Heilvorgang erneut ein. Wenn ein Anforderungsout ausfällt, kann ein Gitter fehlschlagen und dann die Anforderung erneut versuchen. Ein Gitter erfasst und gibt Metriken und verteilte Ablaufverfolgungen an ein zentralisiertes Metriksystem aus.

Istio und Envoy

Während derzeit einige Dienstgitteroptionen vorhanden sind, ist Istio zum Zeitpunkt dieses Schreibens die beliebteste. Istio ist ein Joint Venture von IBM, Google und Lyft. Es handelt sich um ein Open-Source-Angebot, das in eine neue oder vorhandene verteilte Anwendung integriert werden kann. Die Technologie bietet eine konsistente und komplette Lösung zum Sichern, Verbinden und Überwachen von Microservices. Zu den Features gehören:

• Sichere Dienst-zu-Service-Kommunikation in einem Cluster mit starker identitätsbasierter Authentifizierung und Autorisierung.
• Automatischer Lastenausgleich für HTTP-, gRPC-, WebSocket- und TCP-Datenverkehr.
• Differenzierte Steuerung des Datenverkehrsverhaltens mit umfangreichen Routingregeln, Wiederholungen, Failover und Fehlereinschleusung (Fault Injection).
• Eine austauschbare Richtlinienebene und Konfigurations-API, die Zugriffssteuerungen, Ratenbegrenzungen und Kontingente unterstützt.
• Automatische Metriken, Protokolle und Ablaufverfolgungen für den gesamten Datenverkehr innerhalb eines Clusters, einschließlich eingehender und ausgehender Datenverkehr im Cluster.

Eine Schlüsselkomponente für eine Istio-Implementierung ist ein Proxydienst mit dem Anspruch auf den Envoy-Proxy. Sie wird neben jedem Dienst ausgeführt und bietet eine plattformunabhängige Grundlage für die folgenden Features:

• Dynamische Dienstermittlung.
• Lastenausgleich.
• TLS-Beendigung.
• HTTP- und gRPC-Proxys.
• Ausfallsicherheit von Schaltkreisbrechern.
• Integritätsprüfungen.
• Rollupdates mit Canary-Bereitstellungen.

Wie bereits erwähnt, wird Envoy als Sidecar für jeden Microservice im Cluster bereitgestellt.

Integration in Azure Kubernetes Services

Die Azure-Cloud umfasst Istio und bietet direkte Unterstützung für sie in Azure Kubernetes Services. Die folgenden Links können Ihnen bei den ersten Schritten helfen:

• Installieren von Istio in AKS
• Verwenden von AKS und Istio

Verweise

• Polly

• Wiederholungsmuster

• Trennschalter-Muster

• Resilienz im Azure-Whitepaper

• Redundanz

• Georeplikation

• Azure Traffic Manager

• Richtlinien für die automatische Skalierung

• Istio

• Envoy-Proxy