Consul: Auf und davon

Kapitel 1. Dienst Mesh 101

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Um deine Reise durch das Service Mesh zu beginnen, musst du drei Dinge wissen: was ein Service Mesh ist, wie es funktioniert und warum du es nutzen solltest (und wann nicht).

Es gibt keine allgemeingültige Definition für ein Dienstnetz, aber ich definiere es wie folgt:

Ein Service Mesh ist eine Infrastrukturebene, die es dir ermöglicht, die Netzwerkkommunikation deiner Workloads von einer einzigen Kontrollebene aus zu steuern.

Wir können diese Definition in Teile zerlegen, um sie besser zu verstehen:

Mit Infrastrukturebene meine ich, dass ein Dienstnetz nicht Teil deiner Dienste ist; es wird unabhängig eingesetzt und betrieben. Da es die dienstspezifische Geschäftslogik nicht kennt, aber jeden Dienst beeinflusst, wird es als Infrastruktur oder Middleware betrachtet.

Abbildung 1-1 zeigt einen typischen Software-Stack. Dienste und Anwendungen laufen über der Infrastruktur. Das Service Mesh befindet sich auf der ersten Infrastrukturebene mit Speicherung, Metriken und anderen übergeordneten Infrastrukturanforderungen. Darunter befinden sich VMs, Kubernetes oder ein beliebiger Compute Provider oder Orchestrator, auf dem alles läuft. Die unterste Ebene ist die eigentliche Hardware (Bare Metal).

Mit der Kontrolle der Netzwerkkommunikation deiner Workloads meine ich , dass ein Service Mesh den Datenverkehr kontrolliert, der bei einem Microservice, einer Datenbank oder einem anderen Gerät, das über das Netzwerk kommuniziert, ein- und ausgeht. Ein Service Mesh kann z. B. eingehenden Datenverkehr aufgrund einer Regel verbieten (z. B. weil ein erforderlicher Header fehlt) oder ausgehenden Datenverkehr verschlüsseln. Ein Service Mesh hat die vollständige Kontrolle über den gesamten Datenverkehr, der die Dienste erreicht und verlässt.

Abbildung 1-1. Ein typischer Software-Stack

Schließlich meine ich mit einer einzigen Kontrollebene einen einzigen Standort, von dem aus die Betreiber des Dienstnetzes mit dem Dienstnetz interagieren können. Angenommen, die Betreiber wollen die Konfiguration für mehrere Dienste ändern. In diesem Fall müssen sie nicht ein Dutzend Subsysteme neu konfigurieren oder die Dienste selbst ändern, sondern sie konfigurieren das Service Mesh einmal, und es übernimmt die Weitergabe aller Änderungen.

Ich hoffe, diese Definition gibt dir eine Vorstellung davon, was ein Servicenetz ist, aber ich stelle oft fest, dass ich erst verstehen muss, wie etwas tatsächlich funktioniert, bevor ich es ganz begreife.

Wie ein Service Mesh funktioniert

Ein Service Mesh besteht aus Sidecar Proxies und der Kontrollebene.

Seitenwagen Proxies

Ein Proxy ist eine Anwendung, über die der Datenverkehr auf dem Weg zu seinem Ziel geleitet wird. Beliebte Proxys, von denen du vielleicht schon gehört hast, sind NGINX, HAProxy und Envoy. In den meisten Servicenetzen wird der gesamte Datenverkehr (eingehend und ausgehend) über einen lokalen Proxy geleitet, der für jede Service-Instanz zuständig ist.¹

Abbildung 1-2 zeigt, wie ein Dienstnetz mit zwei Dienstinstanzen aussieht: frontend und backend. Wenn frontend backend aufruft, fängt der lokale Proxy von frontenddie ausgehende Anfrage ab. frontendDer Proxy von backend leitet die Anfrage dann an den Dienst weiter. Wenn die Anfrage den Dienst backend erreicht, wird sie wiederum vom lokalen Proxy von backendabgefangen und geprüft. Wenn die Anfrage zulässig ist, leitet der Proxy von backendsie an den eigentlichen backend Dienst weiter.

Abbildung 1-2. Zwei Dienstinstanzen kommunizieren über das Dienstnetz

Jede Instanz eines Dienstes muss auf mit einem eigenen lokalen Proxy bereitgestellt werden.² Das Muster, bei dem eine Hilfsanwendung - in diesem Fall ein Proxy - neben dem Hauptdienst eingesetzt wird, ist als Sidecar-Muster bekannt, weshalb lokale Proxys auch als Sidecar-Proxys bezeichnet werden.

Sidecar-Proxys sind eine wichtige Komponente des Dienstnetzes, denn sie ermöglichen die Kontrolle des Dienstverkehrs, ohne dass die zugrunde liegenden Dienste verändert oder neu eingerichtet werden müssen. Da Sidecar-Proxys als von den Diensten getrennte Prozesse laufen, können sie umkonfiguriert werden, ohne die Dienste zu beeinflussen. Der Sidecar-Proxy des Dienstes backend aus Abbildung 1-2 kann beispielsweise so umkonfiguriert werden, dass er den Datenverkehr des Dienstes frontend zurückweist, ohne dass der Code geändert oder der Dienst backend selbst neu eingerichtet werden muss.

Wer kümmert sich um die Rekonfiguration von Proxys? Die Kontrollebene.

Kontrollebene

Die Steuerebene hat die Aufgabe, die Sidecar-Proxys zu verwalten und zu konfigurieren. Wie du in Abbildung 1-3 sehen kannst, ist die Steuerebene ein separater Dienst, der eigenständig eingerichtet werden muss; er wird nicht als Sidecar eingerichtet. In der Steuerebene befindet sich der Großteil der komplexen Logik des Dienstnetzes: Sie muss das Starten und Stoppen von Diensten überwachen, Zertifikate signieren und verteilen, Proxys neu konfigurieren usw. Die Sidecar-Proxys selbst sind relativ einfach: Sie erhalten von der Steuerebene eine Konfiguration, die angibt, welche Aktionen sie beim Datenverkehr durchführen sollen, und führen diese Aktionen aus.

Abbildung 1-3. Die Kontrollebene verwaltet die Sidecar-Proxys

Wenn wir noch einmal auf meine Definition eines Service Mesh zurückkommen - "eine Infrastrukturschicht, die es dir ermöglicht, die Netzwerkkommunikation deiner Workloads von einer einzigen Kontrollebene aus zu steuern" -, kannst du jetzt sehen, wie die Proxys und die Kontrollebene hineinpassen.

Die Kontrollebene ist der einzige Standortdienst, mit dem Mesh-Betreiber interagieren. Sie konfiguriert wiederum die Proxys, die die Netzwerkkommunikation steuern. Die Kontrollebene und die Proxys bilden zusammen die Infrastrukturschicht.

Konkretes Beispiel

Gehen wir ein konkretes Beispiel durch, um zu zeigen, wie ein Dienstnetz in der Praxis funktioniert. Abbildung 1-4 zeigt die Architektur für dieses Beispiel.

Abbildung 1-4. Beispiel für eine Service-Mesh-Architektur

Wenn frontend backend aufruft, fängt der frontendSidecar-Proxy die Anfrage ab. In Abbildung 1-5 wurde der Proxy von frontendso konfiguriert, dass er den Datenverkehr ohne Änderungen an den backend Dienst weiterleitet. Der Sidecar-Proxy, der neben backend läuft, fängt den eingehenden Datenverkehr ab und leitet die Anfrage an die eigentliche backend Service-Instanz weiter. Die Service-Instanz backend verarbeitet die Anfrage und sendet eine Antwort, die auf demselben Weg zurückkommt.

Abbildung 1-5. frontendDie Anfrage von backend und die Antwort von backendwerden durch beide Proxys geleitet.

Stell dir nun vor, du möchtest wissen, wie viele Anfragen pro Sekunde frontend an backend stellt. Du könntest den Code von frontend und backend ändern, um diese Daten zu übermitteln, aber mit dem bestehenden Service Mesh gibt es einen einfacheren Weg, wie in Abbildung 1-6 gezeigt. Zuerst konfigurierst du die Kontrollebene mit der URL deiner Metadatenbank (Schritt 1). Sofort konfiguriert die Kontrollebene beide Sidecar-Proxys neu und weist sie an, Metriken zu übermitteln (Schritt 2). Wenn frontend nun backend aufruft (Schritt 3), sendet jeder Proxy Metriken an die Metrikdatenbank (Schritt 4), und du kannst die Anfragen pro Sekunde in deinem Metrik-Dashboard sehen.

Abbildung 1-6. Das Dienstnetz, das Metriken aussendet

Beachte, dass du weder den Code der beiden Dienste ändern noch irgendetwas umstellen musstest. Mit einer einzigen Konfigurationsänderung hast du sofort Metriken für die Dienste frontend und backend erhalten.

Dieses konkrete Beispiel soll dir helfen zu verstehen, wie ein Service Mesh in der Praxis funktioniert, aber es ist ein vereinfachtes Bild. In einer typischen Service-Mesh-Implementierung verwaltet die Steuerungsebene Hunderte von Diensten und Arbeitslasten, sodass die Architektur eher wie in Abbildung 1-7 aussieht. Es sieht aus wie ein Mesh, daher der Name!

Abbildung 1-7. Ein typisches Dienstnetz mit vielen zu verwaltenden Diensten

Bei einem größeren Mesh kannst du sehen, dass es unglaublich leistungsfähig ist, die Vernetzung all dieser Dienste von einem einzigen Standort aus zu steuern, ohne dass irgendwelche Dienste neu einrichten oder den Code ändern muss. Das bringt uns zu dem Punkt, warum du ein Service Mesh nutzen solltest.

Warum ein Servicenetz nutzen?

Ein Service Mesh bietet Funktionen in vier Bereichen: Sicherheit, Beobachtbarkeit, Zuverlässigkeit und Verkehrssteuerung. Das grundlegende Leistungsversprechen eines Service Mesh ist die Fähigkeit, diese Funktionen für jeden Dienst und jede Arbeitslast bereitzustellen , ohne den Dienstcode zu ändern.

In den folgenden Abschnitten werde ich auf diese Bereiche näher eingehen, aber es ist wichtig zu wissen, dass die Funktionen, die ein Service Mesh bietet, auch im Service Code implementiert werden können! Die Frage, die man sich stellen muss, ist: Wenn diese Funktionen im Servicecode implementiert werden können, warum sollte man dann überhaupt ein Service Mesh einsetzen? Die Antwort ist, dass ab einer bestimmten Größenordnung die Neukodierung jedes Dienstes mehr Entwicklungszeit kostet als der Einsatz eines Service Mesh. Darauf wird in "Wann ein Service Mesh eingesetzt werden sollte" näher eingegangen.

Sicherheit

Einer der Hauptgründe, warum Unternehmen Service Meshes einsetzen, ist die Sicherung ihrer Netzwerke. Das bedeutet in der Regel, dass der Datenverkehr zwischen allen Workloads verschlüsselt und Authentifizierung und Autorisierung implementiert werden.

Die Lösung dieses Problems kann in einer Microservices-Architektur ohne ein Service-Mesh sehr schwierig sein. Wenn jede Anfrage verschlüsselt werden muss, bedeutet das, dass jeder Dienst mit sicheren TLS-Zertifikaten (Transport Layer Security) ausgestattet werden muss und dass du deine eigene Infrastruktur zum Signieren von Zertifikaten verwalten musst. Jede Anfrage zu authentifizieren und zu autorisieren bedeutet, den Authentifizierungscode in jedem Dienst zu aktualisieren und zu pflegen.

Ein Service Mesh erleichtert diese Arbeit sehr weil es Zertifikate ausstellen und Sidecar Proxies konfigurieren kann, um den Datenverkehr zu verschlüsseln und die Autorisierung durchzuführen - und das alles ohne Änderungen an den zugrunde liegenden Diensten (siehe Abbildung 1-8).

Abbildung 1-8. Ein Dienstnetz, das Zertifikate ausstellt und den Datenverkehr verschlüsselt

Fallstudie Sicherheit

Annika ist die leitende Ingenieurin in ihrem Plattformteam. Der Chief Information Security Officer hat die Anforderung gestellt, dass der gesamte Datenverkehr zwischen den Microservices bis Ende des Jahres TLS-verschlüsselt sein muss.

Annika weiß, dass es eine gewaltige Aufgabe ist, jeden Dienst so zu verändern, dass er TLS-Anfragen stellen und empfangen kann. Es gibt 30 Entwicklungsteams, die Hunderte von Diensten besitzen, von denen einige seit Jahren nicht mehr aktualisiert wurden. Es wird extrem schwierig sein, auf der Roadmap jedes Teams Platz zu finden, um alle Dienste zu aktualisieren, die sie besitzen, wenn man bedenkt, wie viele Funktionen für dieses Jahr geplant sind. Und selbst wenn es gelänge, die Teams davon zu überzeugen, alle ihre Dienste zu ändern und neu bereitzustellen, müssten sie immer noch ein Tool entwickeln, um die TLS-Zertifikate sicher zu verteilen und auszutauschen.

Zum Glück hat Annika von Service Meshes gehört. Annika braucht die Teams nicht, um den Code der Dienste mit einem Service Mesh zu aktualisieren. Stattdessen können die Sidecar-Proxys die Ver- und Entschlüsselung automatisch durchführen, ohne dass die zugrunde liegenden Dienste davon etwas mitbekommen. Das Service Mesh kümmert sich auch um die sichere Verteilung und Rotation von TLS-Zertifikaten. Das Plattformteam muss die Proxys nur noch neben den einzelnen Diensten einrichten; Annika ist zuversichtlich, dass ihr Team das in ein paar Monaten schaffen wird.

Beobachtbarkeit

Beobachtbarkeit ist die Fähigkeit zu verstehen, was mit deinen Diensten passiert, während sie laufen. Beobachtungsdaten sind wichtig, um Microservices-Architekturen zu verstehen und Fehler zu diagnostizieren, aber es kann eine Herausforderung sein, alle deine Dienste so zu konfigurieren, dass sie Metriken und andere Daten auf einheitliche Weise ausgeben.

Die Erfassung von Beobachtungsdaten ist die perfekte Aufgabe für ein Service Mesh, da alle Anfragen über seine Proxys laufen. Das Service Mesh kann seine Proxys so konfigurieren, dass sie Metriken für alle deine Dienste in einem einheitlichen Format ausgeben, ohne dass die zugrunde liegenden Dienste verändert oder neu bereitgestellt werden müssen.

Fallstudie zur Beobachtbarkeit

Geordi befindet sich in einer Zwickmühle. Er ist gerade in das Betriebsteam eines Start-ups eingestiegen, das vor drei Jahren gegründet wurde und in rasantem Tempo neue Funktionen entwickelt hat. Das Startup floriert und zieht jeden Tag Tausende neuer Nutzer an. Leider haben all diese neuen Nutzer das System stark belastet, so dass das Betriebsteam immer häufiger Ausfälle zu verzeichnen hat.

Das Schlimmste daran ist, dass die Entwicklungsteams so schnell Funktionen entwickelt haben, dass sie ihre Microservices nie mit Metriken versehen haben. Das bedeutet, dass das Betriebsteam im Blindflug unterwegs ist, wenn die Website ausfällt. Sie müssen sich durch Tausende von Protokollen wühlen, um herauszufinden, wo das Problem liegt und welcher Dienst nicht funktioniert.

Geordi würde gerne alle Entwicklungsteams dazu bringen, ihre Dienste zu aktualisieren, um die Antwortzeiten und Fehler zu messen, aber das könnte Monate oder sogar ein ganzes Jahr dauern, wenn man bedenkt, wie viel Arbeit die Entwicklungsteams derzeit haben.

Stattdessen schlägt Geordi vor, dass das Team ein Service Mesh einsetzt. Ein Service Mesh gibt automatisch detaillierte Metriken für jede Anfrage im System aus - ohne die zugrunde liegenden Dienste zu verändern. Das Betriebsteam kann dann Dashboards für jeden Dienst erstellen und sehen, welche Dienste Fehler zurückgeben und langsam laufen. Sie können sogar Warnschwellen einbauen, um Probleme zu erkennen, bevor sie zu einem Totalausfall führen.

Verlässlichkeit

In verteilten Systemen schlägt oft etwas fehl . Der Aufbau zuverlässiger verteilter Systeme bedeutet, Ausfälle so weit wie möglich zu reduzieren und mit Ausfällen elegant umzugehen, wenn sie unweigerlich auftreten.

Die Reduzierung von Fehlern kann bedeuten, dass eine Gesundheitsprüfung implementiert wird, damit der Datenverkehr nur an gesunde Dienste gesendet wird. Die Behandlung von Fehlschlägen kann bedeuten, dass Anfragen, die fehlgeschlagen sind, wiederholt werden (siehe Abbildung 1-9) oder dass ein Timeout implementiert wird, damit ein Dienst nicht ewig auf eine Antwort warten muss.

Diese Techniken im Code zu implementieren, ist zeitaufwändig, fehleranfällig und schwierig, wenn man sie für alle Dienste einheitlich anwenden will. Mit einem Service Mesh können die Proxys diese Techniken für jeden deiner Dienste anwenden - du musst nur mit der Kontrollebene interagieren. Außerdem kannst du die Einstellungen in Echtzeit anpassen, wenn sich die Auslastung der Dienste ändert.

Abbildung 1-9. Das Dienstnetz kann so konfiguriert werden, dass fehlgeschlagene Anfragen an andere Instanzen wiederholt werden

Fallstudie zur Zuverlässigkeit

Miles ist gerade aufgewacht, als ihn die PagerDuty-App schrill anpiepst. Er hat Bereitschaftsdienst, also rollt er sich müde aus dem Bett und geht zu seiner Arbeitstasche, um seinen Laptop herauszuholen. Die Meldung lautet, dass die Hauptseite nicht erreichbar ist. Das ist nicht gut.

Er lädt die Homepage selbst und sein Browser dreht sich nur. Er sieht sich die Überwachungs-Dashboards an und stellt fest, dass die Latenzzeit für die Anfragen an den Homepage-Dienst extrem hoch ist. Es dauert fünf Minuten für jede Anfrage! Das Seltsame ist, dass die CPU-Last für die Knoten, die die Homepage hosten, normal aussieht. Er fragt sich, ob vielleicht eine Abhängigkeit der Homepage langsam läuft?

Sein Unternehmen betreibt ein Service Mesh, also öffnet er die Benutzeroberfläche und prüft den Status des Homepagedienstes. Ihm fällt sofort auf, dass der Analysedienst als Abhängigkeit des Homepagedienstes aufgeführt ist und eine durchschnittliche Latenzzeit von fünf Minuten aufweist. Das könnte die Ursache für den Ausfall sein! Der Homepagedienst protokolliert jede Anfrage an den Analysedienst. Wenn der Homepagedienst keine Zeitüberschreitung für seine Anfrage an den Analysedienst implementiert hat, wartet er einfach, bis die Anfrage abgeschlossen ist.

Das Frustrierende daran ist, dass die Anfrage an den Analysedienst nicht einmal so wichtig ist. Dem Unternehmen ist es viel lieber, dass die Website funktioniert und einige Analysen nicht aufgezeichnet werden, als dass die gesamte Website ausfällt!

Ohne ein Service Mesh müsste Miles die Entwickler der Homepage aufwecken und sie dazu bringen, eine Zeitüberschreitung in den Code zu implementieren und dann eine vollständige Neuverteilung vorzunehmen. Glücklicherweise kann Miles mit dem Service Mesh den Datenverkehr für jeden Dienst von der Kontrollebene aus steuern. Miles verschiebt eine neue Konfiguration, die den Timeout für Anfragen an den Analysedienst auf 100 Millisekunden setzt. Dann versucht er erneut, die Homepage zu laden: Sie wird fast sofort geladen. Miles schickt eine Nachricht an den Chat-Kanal der Rufbereitschaft, dass sie sich morgen früh unter ansehen sollen, was mit dem Analysedienst los ist. Dann geht er zurück ins Bett.

Verkehrskontrolle

Bei der Verkehrskontrolle geht es darum, zu kontrollieren, wohin der Verkehr zwischen den Diensten geleitet wird. Die Verkehrskontrolle löst viele Probleme:

• Implementierung von Bereitstellungsstrategien wie z. B. Canary Deployments, bei denen eine kleine Menge an "Canary"-Verkehr auf die neue Version eines Dienstes geleitet wird, um zu sehen, ob sie funktioniert, bevor die neue Version vollständig eingeführt wird

• Migrationen von Monolithen zu Microservices Migrationen, bei denen Dienste vom Monolithen abgespalten werden und der Datenverkehr, der zuvor zum Monolithen geleitet wurde, nahtlos zu den neuen Microservices umgeleitet wird

• Multicluster-Failover, bei dem der Datenverkehr zu Diensten in anderen gesunden Clustern umgeleitet wird, wenn der lokale Cluster ausfällt

Fallstudie Verkehrskontrolle

B'Elanna ist aufgeregt. Sie hat endlich grünes Licht bekommen, einen Teil des großen monolithischen Dienstes, an dem sie arbeitet, in Microservices aufzuteilen. Der Rest ihrer Organisation nutzt bereits Microservices, aber ihr Dienst ist der älteste und ist groß und aufgebläht geworden.

Ihr Team plant, zwei Microservices aus dem Monolithen herauszulösen, einen Mitgliederservice und einen Warenkorbservice, und das ohne Ausfallzeiten. Viele andere Microservices hängen von dem Monolithen ab. Wenn sie ihn aufteilen, müssen sie also sicherstellen, dass diese Microservices die neu aufgeteilten Services aufrufen.

Ohne ein Dienstnetz müsste B'Elanna alle abhängigen Dienste aktualisieren, um die neuen Mitglieder- und Warenkorbservices anstelle des Monolithen aufzurufen. Zum Beispiel müssen Anfragen an den Endpunkt /members jetzt an den neuen Mitgliederdienst und Anfragen an den Endpunkt /cart an den neuen Warenkorbdienst gehen. Das bedeutet, dass eine Menge Code in vielen Diensten aktualisiert werden muss.

Glücklicherweise verfügt B'Elannas Unternehmen über ein Service-Netz. Wie in Abbildung 1-10 zu sehen ist, kann sie das Service Mesh so konfigurieren, dass alle Anfragen, die auf /members passen, automatisch an den neuen Mitgliedsdienst weitergeleitet werden, und das Gleiche gilt für den Warenkorbdienst. Die abhängigen Dienste können ihre Anfragen wie gewohnt stellen und das Service Mesh kümmert sich um die Weiterleitung. Das bedeutet, dass B'Elanna sich darauf konzentrieren kann, den Monolithen aufzuspalten, anstatt alle abhängigen Dienste zu aktualisieren.

Abbildung 1-10. Das Dienstnetz kann so konfiguriert werden, dass bestimmte Anfragen an verschiedene Dienste weitergeleitet werden

Merkmale in Kombination

Jetzt solltest du wissen, welche Funktionen ein Service Mesh bietet: Sicherheit, Beobachtbarkeit, Zuverlässigkeit und Verkehrskontrolle. Diese Funktionen sind für sich genommen schon hilfreich, aber in Kombination sind sie noch leistungsfähiger.

Die vom Service Mesh bereitgestellten Beobachtungsdaten können zum Beispiel mit Funktionen zur Zuverlässigkeit und Verkehrssteuerung kombiniert werden. Wenn das Mesh feststellt, dass eine Service-Instanz Fehler zurückgibt, kann es den Datenverkehr auf gesunde Instanzen oder einen anderen Cluster umleiten. Oder die Sicherheitsfunktionen des Mesh können mit den Observability-Funktionen kombiniert werden, um zu erkennen, wenn ein Dienst versucht, Anfragen zu stellen, für die er keine Berechtigung hat - ein möglicher Hinweis auf eine Sicherheitsverletzung. Wenn du Consul selbst einsetzt, wirst du viele Anwendungsfälle sehen, in denen du die Service-Mesh-Funktionen kombinieren kannst.

Wenn dein Unternehmen diese Funktionen benötigt, musst du entscheiden, ob es die zusätzliche Komplexität eines Service Meshes wert ist oder ob du sie im Service Code implementieren solltest. Der Schlüssel zur Beantwortung dieser Frage ist die Untersuchung deines Umfangs.

Wann sollte man ein Servicenetz nutzen?

Es besteht kein Zweifel, dass der Einsatz eines Service Mesh zusätzliche Komplexität mit sich bringt. Du musst jetzt Sidecar-Proxys und die Service-Mesh-Kontrollebene verwalten. Außerdem benötigst du mehr Rechenressourcen (CPU und Arbeitsspeicher), um die Proxys und die Steuerungsebene zu betreiben, und der gesamte Datenverkehr muss nun einen zusätzlichen Sprung durch die lokalen Sidecar-Proxys machen, was die Latenzzeit erhöht. Die Implementierung von Service-Mesh-Funktionen im Code würde Ressourcen sparen und die Komplexität der Infrastruktur verringern (auch wenn der Code dadurch komplexer wird). Damit sich ein Service Mesh lohnt, muss es einen großen Nutzen für dein Unternehmen haben.

Eine einfache Formel, um herauszufinden, wann ein Service Mesh eingesetzt werden sollte, ist, wenn du (a) Netzwerkprobleme in den zuvor beschriebenen Bereichen (Sicherheit, Beobachtbarkeit, Zuverlässigkeit und Verkehrssteuerung) lösen musst und (b) dein Unternehmen eine Größe erreicht hat oder bald erreichen wird, bei der es zu kostspielig ist, diese Probleme mit Service Code zu lösen.

Angenommen, dein Unternehmen stellt auf eine so genannte Zero-Trust-Sicherheitsarchitektur um, bei der der gesamte interne Datenverkehr verschlüsselt, authentifiziert und autorisiert ist. Wenn du nur zwei Microservices betreibst, kannst du diese Dienste leicht umprogrammieren. Wenn du jedoch 400 Microservices betreibst, ist es unwahrscheinlich, dass du all diese Dienste in einer angemessenen Zeit umprogrammieren kannst. In diesem Fall macht ein Service Mesh sehr viel Sinn.

Darüber hinaus gibt es ab einer bestimmten Größenordnung Dienste und Arbeitslasten, die du kontrollieren möchtest, ohne dass du die Möglichkeit hast, ihren Code zu bearbeiten. Vielleicht setzt du zum Beispiel ein Open-Source-Paket ein oder du verwendest eine Cloud-verwaltete Datenbank. Idealerweise hättest du über diese Workloads die gleiche Kontrolle wie über deine anderen Dienste.

Letztendlich hängt es von deiner Organisation und den Problemen, die du zu lösen versuchst, ab, in welchem Umfang der Einsatz eines Servicenetzes sinnvoll ist. Ich hoffe, dass dieses Buch dir hilft, die Probleme zu verstehen, die ein Service-Netz löst, und dir dabei hilft, zu beurteilen, ob es in deiner Situation sinnvoll ist.

Gemeinsame Bibliotheken?

Viele Ingenieure, die die Frage "Wie soll ich das in allen Diensten umsetzen?" hören, denken sofort an gemeinsam genutzte Bibliotheken. Eine gemeinsam genutzte Bibliothek ist eine gute Lösung für kleinere Organisationen, aber ab einer bestimmten Größe hat sie viele Probleme.

Zunächst muss jemand die gemeinsame Bibliothek schreiben oder eine gute Bibliothek aus den Open-Source-Angeboten auswählen. Wenn du mehrere Programmiersprachen verwendest, muss deine Bibliothek alle unterstützen (und alle zukünftigen Sprachen). Zweitens musst du alle deine Dienste so umprogrammieren, dass sie diese Bibliothek verwenden, und sie neu bereitstellen. In großen Unternehmen ist das ein gewaltiges Unterfangen. Drittens: Wenn du die Bibliothek jemals aktualisieren musst (und das wirst du), musst du jeden Dienst erneut aktualisieren und bereitstellen.

Für einige Nischenanwendungen sind gemeinsam genutzte Bibliotheken eine gute Option, aber sie sind eine schlechte Lösung für die Probleme, die ein Service Mesh löst.

Zusammenfassung

In diesem Kapitel hast du gelernt, was ein Servicenetz ist, wie es funktioniert und warum du es benutzen solltest.

Ich habe meine Definition eines Dienstleistungsnetzes vorgestellt:

Eine Infrastrukturebene, die es dir ermöglicht, die Netzwerkkommunikation deiner Workloads von einer einzigen Kontrollebene aus zu steuern.

Und ich habe erklärt, wie die beiden Komponenten eines Service Mesh, die Proxys und die Kontrollebene, die Kontrolle der Netzwerkkommunikation ermöglichen. Du bist durch ein reales Beispiel eines funktionierenden Service Mesh gegangen, und ich habe die vier Kategorien von Service Mesh-Funktionen besprochen: Sicherheit, Beobachtbarkeit, Zuverlässigkeit und Verkehrssteuerung.

Zum Schluss bin ich darauf eingegangen, wann du ein Service Mesh verwenden solltest: wenn du diese Funktionen brauchst und du eine Größenordnung erreicht hast, bei der es zu kostspielig ist, sie im Service Code zu implementieren.

Bisher war alles, was in diesem Kapitel besprochen wurde, auf die meisten Dienstnetze anwendbar und nicht speziell auf Consul. Das nächste Kapitel ist Consul im Besonderen gewidmet. Du erfährst, wie es funktioniert, wie es aufgebaut ist, welche Protokolle es verwendet und was es einzigartig macht.

¹ Einige Netze verwenden andere Technologien wie iptables oder eBPF, um den Verkehr zu kontrollieren, anstatt einen separaten Proxy-Prozess zu verwenden.

² Wenn es nicht möglich ist, einen lokalen Proxy einzurichten - zum Beispiel bei einem verwalteten Service wie Amazon Relational Database Service - kannst du ein terminierendes Gateway verwenden, wie in Kapitel 10 beschrieben.