Service Mesh: Was jeder Software Engineer über die angesagteste Technologie wissen sollte.

Hinweis.: Service Mesh — ein Konzept, das noch keinen stabilen deutschen Begriff hat (vor über 2 Jahren schlugen wir „Dienstnetz“ vor, während einige Kollegen später die Kombination „Dienstsieb“ aktiv propagierten). Ständige Gespräche über diese Technologie führten zu einer Situation, in der sich marketingtechnische und technische Aspekte zu eng vermischten. Dieses hervorragende Material eines der Autoren des Originalbegriffs soll Klarheit für Ingenieure und darüber hinaus schaffen.

Comic von Sebastian Caceres

Einführung

Wenn Sie ein Softwareingenieur sind, der in Backend-Systemen arbeitet, ist der Begriff „Service Mesh“ wahrscheinlich in den letzten Jahren fest in Ihrem Bewusstsein verankert worden. Durch eine seltsame Verkettung von Umständen gewinnt dieser Ausdruck in der Branche immer mehr an Bedeutung, während der Hype und die damit verbundenen Werbeangebote wie ein Schneeball an Fahrt aufnehmen und keine Anzeichen einer Verlangsamung zeigen.

Service Mesh hat seinen Ursprung in den undurchsichtigen, voreingenommenen Gewässern des Cloud-Native-Ökosystems. Leider bedeutet dies, dass ein erheblicher Teil der damit verbundenen Debatten von "oberflächlichem Gerede" bis hin zu – um einen technischen Begriff zu verwenden – purer Unsinn reicht. Doch wenn man den gesamten Lärm ausblendet, wird klar, dass Service Mesh eine durchaus echte, spezifische und wichtige Funktion hat.

In diesem Beitrag werde ich genau das versuchen: eine ehrliche, tiefgehende, ingenieurlastige Anleitung zu Service Mesh zu präsentieren. Ich werde nicht nur die Frage beantworten: „Was ist das?“, sondern auch „Warum?“, sowie „Warum gerade jetzt?“. Schließlich werde ich versuchen zu skizzieren, warum (meiner Meinung nach) gerade diese Technologie solch einen unglaublichen Hype ausgelöst hat – was an sich eine interessante Geschichte ist.

Wer bin ich?

Hallo zusammen! Mein Name ist William Morgan. Ich bin einer der Erfinder Linkerd – des allerersten Projekts für Service Mesh und des Projekts, das den Begriff Service Mesh in seiner heutigen Form geprägt hat (Entschuldigung, Jungs!). (Übersetzung:: Übrigens, zu Beginn dieser Begrifflichkeit, vor über 2,5 Jahren, haben wir bereits frühe Materialien des gleichen Autors mit dem Titel „Was ist ein Service Mesh und warum benötige ich es [für Cloud-Anwendungen mit Microservices]?».) Außerdem leite ich Buoyant — ein Startup, das coole Service-Mesh-Lösungen wie Linkerd und Dive.

Sie haben wahrscheinlich eine recht persönliche und subjektive Meinung zu diesem Thema. Dennoch werde ich versuchen, die Tendenz so gering wie möglich zu halten (mit einer Ausnahme: „Warum gibt es so viele Diskussionen über Service Mesh?“, — in dem ich jedoch meine voreingenommenen Gedanken teilen werde). Ich werde auch mein Bestes tun, um diesen Leitfaden so objektiv wie möglich zu gestalten. In konkreten Beispielen werde ich hauptsächlich auf die Erfahrungen mit Linkerd zurückgreifen und dabei bekannte Unterschiede (sofern vorhanden) bei der Implementierung anderer Arten von Service Meshs erwähnen.

Okay, kommen wir zu den interessanten Punkten.

Was ist ein Service Mesh?

Trotz des ganzen Hypes ist die Struktur eines Service Meshs ziemlich einfach. Es handelt sich lediglich um eine Vielzahl von Userspace-Proxys, die „neben“ den Diensten positioniert sind (darüber werden wir später noch sprechen, was „neben“ bedeutet), plus eine Reihe von Steuerungsprozessen. Die Proxys zusammen werden als Datenebenebezeichnet, während die Steuerungsprozesse als Steuerungsebene. Der Datenverkehrsbereich interceptiert Aufrufe zwischen Services und verarbeitet diese auf verschiedene Weise; der Steuerungsbereich koordiniert entsprechend das Verhalten des Proxys und verschafft Ihnen, also dem Betreiber, Zugriff auf die API, um das Netzwerk als Gesamtheit zu steuern und zu messen.

Was ist dieser Proxy? Es handelt sich um einen TCP-Proxy der Kategorie „Layer 7-aware“ (d.h. „berücksichtigend“ Schicht 7 des OSI-Modells) wie HAProxy und NGINX. Sie können den Proxy nach Ihrem Geschmack auswählen; Linkerd verwendet einen Proxy in Rust, der unaufwendig linkerd-proxy. Wir haben ihn speziell für das Service Mesh entwickelt. Andere Meshes bevorzugen andere Proxys (Envoy ist eine häufige Wahl). Doch die Wahl des Proxys ist letztendlich eine Frage der Implementierung.

Was machen diese Proxys? Offensichtlich leiten sie Aufrufe zu den Services und von diesen weiter (strikt gesprochen fungieren sie als Proxys sowie als Reverse-Proxys, indem sie sowohl eingehende als auch ausgehende Aufrufe behandeln). Dabei implementieren sie eine Reihe von Funktionen, die sich auf die Aufrufe zwischen Services konzentrieren. Dieser Fokus auf den Verkehr zwischen Services unterscheidet den Service Mesh-Proxy von beispielsweise API-Gates oder Ingress-Proxys (letztere konzentrieren sich auf Aufrufe, die aus der Außenwelt in das Cluster gelangen). (Hinweis.: Vergleich der bestehenden Ingress-Controller für Kubernetes, von denen viele bereits das erwähnte Envoy verwenden, siehe in in diesem Artikel.)

So, der Datenfluss ist geklärt. Der Kontrollfluss ist einfacher aufgebaut: Es handelt sich um eine Sammlung von Komponenten, die die gesamte Mechanik bereitstellen, die der Datenfluss benötigt, um koordiniert zu arbeiten, einschließlich Dienstentdeckung, Ausstellung von TLS-Zertifikaten, Aggregation von Metriken usw. Der Datenfluss informiert den Kontrollfluss über sein Verhalten; umgekehrt stellt der Kontrollfluss eine API bereit, die es ermöglicht, das Verhalten des Datenflusses als ein einheitliches Ganzes zu ändern und zu überwachen.

Im Folgenden ist das Schema des Kontrollflusses und des Datenflusses in Linkerd dargestellt. Wie zu sehen ist, umfasst der Kontrollfluss mehrere verschiedene Komponenten, darunter eine Instanz von Prometheus, die Metriken von den Proxies sammelt, sowie andere Komponenten wie abgekürzt werden (Dienstentdeckung), identity (Zertifizierungsstelle, CA) und public-api (Endpunkte für Web und CLI). Im Gegensatz dazu besteht der Datenfluss aus einem einfachen linkerd-proxy neben einer Anwendungsinstanz. Dies ist nur ein logisches Schema; im tatsächlichen Einsatz können Sie drei Replikate jeder Komponenten des Kontrollflusses und Hunderte oder Tausende von Proxies im Datenfluss haben.

(Die blauen Rechtecke in diesem Diagramm symbolisieren die Grenzen der Kubernetes-Pods. Es ist ersichtlich, dass die Container mit linkerd-proxy im selben Pod wie die Anwendungscontainer platziert sind. Solch ein Diagramm ist als Sidecar-Container.)

Die Architektur von Service Mesh hat mehrere wichtige Konsequenzen. Erstens, da es die Aufgabe des Proxys ist, Aufrufe zwischen den Diensten abzufangen, macht ein Service Mesh nur Sinn, wenn Ihre Anwendung auf einer bestimmten Anzahl von Diensten basiert. Mesh kann kann mit Monolithen verwendet werden, aber das ist eindeutig überflüssig für einen einzigen Proxy, und die Funktionalität wird wahrscheinlich nicht benötigt.

Eine weitere wichtige Konsequenz ist, dass ein Service Mesh eine enorme Anzahl an Proxys benötigt. Tatsächlich koppelt Linkerd den linkerd-proxy an jede Instanz jedes Dienstes (andere Implementierungen fügen Proxys zu jedem Knoten/Host/virtuellen Maschine hinzu. In jedem Fall ist das nicht wenig). Der extensive Einsatz von Proxys selbst bringt eine Reihe zusätzlicher Komplikationen mit sich:

1. Proxys im Data Plane müssen schnell sein, da auf jeden Aufruf mehrere Anfragen an den Proxy entfallen: eine auf der Client-Seite, eine auf der Server-Seite.
2. Auch müssen Proxys klein und leichtgewichtig. Jede wird Ressourcen für Speicher und CPU konsumieren, und dieser Verbrauch wird linear mit der Anwendung wachsen.
3. Sie benötigen einen Mechanismus, um eine große Anzahl von Proxys bereitzustellen und zu aktualisieren. Dies manuell zu tun, ist keine Option.

Im Allgemeinen sieht ein Service Mesh so aus (zumindest aus der Vogelperspektive): Sie setzen eine Vielzahl von Benutzerspace-Proxys ein, die „etwas tun“ mit dem internen, dienstübergreifenden Datenverkehr, und verwenden die Steuerungsebene zur Überwachung und Verwaltung dieser.

Jetzt stellt sich die Frage: „Warum?“

Wozu dient ein Service Mesh?

Es ist verständlich, wenn Neulinge auf dem Gebiet eines Service Meshs ein leichtes Unbehagen verspüren. Die Struktur eines Service Mesh bedeutet, dass sie nicht nur die Latenz der Anwendung erhöht, sondern auch Ressourcen verbrauchen und neue Mechanismen in die Infrastruktur einfügt. Zuerst installieren Sie das Service Mesh und stellen dann plötzlich fest, dass Sie Hunderte (wenn nicht Tausende) von Proxys verwalten müssen. Man fragt sich, wer freiwillig dafür bereit ist?

Die Antwort auf diese Frage besteht aus zwei Teilen. Erstens können die Betriebskosten, die mit der Bereitstellung dieser Proxys verbunden sind, durch einige Entwicklungen in der Umgebung erheblich gesenkt werden (darüber später mehr).

Zweitens ist ein solches Gerät tatsächlich eine ausgezeichnete Möglichkeit, zusätzliche Logik in das System einzuführen. Das liegt nicht nur daran, dass mit einem Service Mesh viele neue Funktionen hinzugefügt werden können, sondern auch daran, dass dies ohne Eingriffe in die bestehende Umgebung möglich ist. Tatsächlich basiert das gesamte Modell des Service Mesh auf diesem Postulat: In einem Multiservice-System, unabhängig davon, was die einzelnen Dienste tun, ist der Datenverkehr zwischen ihnen der ideale Punkt, um Funktionalität hinzuzufügen.

Beispielsweise konzentriert Linkerd (wie die meisten Meshes) die Funktionalität hauptsächlich auf HTTP-Anfragen, einschließlich HTTP/2 und gRPC*. Die Funktionalität ist recht umfangreich und lässt sich in drei Klassen unterteilen:

1. Funktionen, die mit Zuverlässigkeit. Wiederholte Anfragen, Zeitüberschreitungen, canary approach (Traffic-Shifting/Redirecting) usw.
2. Funktionen, die mit Überwachung. Aggregation von Leistungskennzahlen, Latenzen und Anfragenvolumen für jeden Dienst oder spezifische Bereiche; Erstellung von topologischen Karten der Dienste usw.
3. Funktionen, die mit Sicherheit. Mutual TLS, Zugangskontrolle usw.

* Aus der Perspektive von Linkerd unterscheidet sich gRPC praktisch nicht von HTTP/2: lediglich in der Nutzlast wird protobuf verwendet. Für den Entwickler sind diese beiden Dinge natürlich unterschiedlich.

Viele dieser Mechanismen arbeiten auf der Anfrageebene (daher der Begriff „L7-Proxy“). Wenn z. B. der Dienst Foo einen HTTP-Aufruf an den Dienst Bar sendet, kann der linkerd-proxy auf der Seite von Foo eine intelligente Lastverteilung durchführen und Anfragen von Foo je nach beobachteter Latenz an die Instanzen von Bar weiterleiten; er kann die Anfrage bei Bedarf wiederholen (sofern idempotent); er kann den Antwortcode und die Wartezeit protokollieren usw. Ebenso kann der linkerd-proxy auf der Seite von Bar die Anfrage ablehnen, wenn sie nicht genehmigt ist oder das Anfrage-Limit überschritten wurde; er kann die Latenz von seiner Seite protokollieren usw.

Proxys können auf Verbindungsebene "etwas tun". Zum Beispiel kann der linkerd-proxy auf der Foo-Seite eine TLS-Verbindung initiieren, während der linkerd-proxy auf der Bar-Seite diese trennt. Beide Seiten können die TLS-Zertifikate des jeweiligen Gegenübers überprüfen*. Damit wird nicht nur die Verschlüsselung zwischen den Diensten sichergestellt, sondern auch eine kryptografisch sichere Identifikation der Dienste: Foo und Bar können "beweisen", dass sie tatsächlich das sind, was sie vorgeben zu sein.

* "Gegeneinander" bedeutet, dass auch das Zertifikat des Clients überprüft wird (mutual TLS). In klassischem TLS, wie zum Beispiel zwischen Browser und Server, wird normalerweise nur das Zertifikat einer Seite (des Servers) überprüft.

Unabhängig davon, ob sie auf Anfrage- oder Verbindungsebene arbeiten, ist es wichtig zu betonen, dass alle Funktionen eines Service Mesh betrieblich sind. Linkerd kann die Semantik der Nutzlast nicht transformieren – zum Beispiel keine Felder zu einem JSON-Ausschnitt hinzufügen oder Änderungen an Protobuf vornehmen. Auf diese wichtige Besonderheit werden wir später eingehen, wenn es um ESB und Middleware geht.

Dies ist die Funktionalität, die ein Service Mesh bietet. Die Frage stellt sich: Warum nicht diese Funktionen direkt in der Anwendung implementieren? Und warum überhaupt mit einem Proxy arbeiten?

Warum ist ein Service Mesh eine gute Idee?

Obwohl die Möglichkeiten eines Service Mesh beeindruckend sind, liegt der wahre Wert nicht in den Funktionen selbst. Schließlich können wir sie direkt in der Anwendung implementieren (wir werden später sehen, dass genau dies der Ursprung des Service Mesh ist). Wenn man diesen Gedanken in einem Satz zusammenfassen möchte, besteht der Wert eines Service Mesh darin, dass es Funktionen bereitstellt, die für den Betrieb moderner Serveranwendungen entscheidend sind, einheitlich für den gesamten Stack und unabhängig vom Anwendungscode..

Lassen Sie uns dieses Statement analysieren.

«Funktionen, die für den Betrieb moderner Serveranwendungen entscheidend sind.Wenn Sie eine transaktionale Serveranwendung erstellen, die mit dem öffentlichen Internet verbunden ist, externe Anfragen entgegennimmt und innerhalb kurzer Zeit darauf reagiert – zum Beispiel ein Webanwendung, einen API-Server oder die überwiegende Mehrheit anderer moderner Anwendungen – und wenn Sie diese als eine Suite von Services implementieren, die synchron miteinander interagieren, wobei Sie die Software ständig aktualisieren, um neue Funktionen hinzuzufügen, und gezwungen sind, dieses System während der Modifikationen betriebsfähig zu halten – dann gratuliere ich Ihnen, denn Sie sind dabei, moderne Serversoftware zu entwickeln. All diese großartigen Funktionen sind tatsächlich entscheidend für Sie. Die Anwendung muss zuverlässig und sicher sein, und Sie müssen in der Lage sein, das Verhalten zu überwachen. Genau diese Fragen kann ein Service-Mesh beantworten.

(Okay, in den vorherigen Absatz hat sich dennoch meine Überzeugung geschlichen, dass dieser Ansatz eine moderne Methode ist, um Server-Software zu erstellen. Andere ziehen es vor, Monolithen, „reaktive Mikrodienste“ und andere Dinge zu entwickeln, die nicht der obigen Definition entsprechen. Diese Menschen haben sicherlich eine andere Meinung als ich. Ich persönlich glaube, dass sie „nicht recht haben“ — obwohl der Service-Mesh in jedem Fall für sie nicht besonders nützlich ist.)

«Einheitlich für den gesamten StackDie von Service Mesh bereitgestellten Funktionen sind nicht nur von entscheidender Bedeutung. Sie gelten für alle Dienste innerhalb der Anwendung, unabhängig davon, in welcher Sprache sie geschrieben sind, welches Framework verwendet wird, wer sie erstellt hat, wie sie implementiert wurden und all die anderen Feinheiten ihrer Entwicklung und Anwendung.

«Unabhängig vom Anwendungs-CodeLetztendlich bietet das Service Mesh nicht nur einheitliche Funktionen für den gesamten Stack – es geschieht auf eine Weise, die keine Änderungen am Anwendungscode erfordert. Die grundlegende Funktionalität des Service Mesh, einschließlich der Aufgaben wie Konfiguration, Aktualisierung, Betrieb, Wartung usw., liegt ausschließlich auf der Plattformebene und ist unabhängig von der Anwendung. Die Anwendung kann sich ändern, ohne das Service Mesh zu beeinträchtigen. Umgekehrt kann sich das Service Mesh ändern, ohne dass die Anwendung eingreift.

Kurz gesagt, das Service Mesh bietet nicht nur wesentliche Funktionen, sondern tut dies auf eine globale, einheitliche und anwendungsunabhängige Weise. Daher, obwohl die Funktionen des Service Mesh im Anwendungscode (zum Beispiel in Form einer Bibliothek, die in jeden Dienst integriert ist) implementiert werden können, gewährleistet dieser Ansatz nicht die Homogenität und Unabhängigkeit, die für ein Service Mesh so wertvoll sind.

Und alles, was dafür erforderlich ist, ist die Hinzufügung einer Reihe von Proxys! Ich verspreche, dass wir sehr bald die Betriebskosten betrachten werden, die mit der Hinzufügung dieser Proxys verbunden sind. Aber zuerst lassen Sie uns anhalten und diesen Gedanken der Unabhängigkeit aus der Perspektive verschiedener Aspekte betrachten. Menschen.

Wer profitiert von Service Mesh?

So unangenehm es auch sein mag, aber damit eine Technologie ein wichtiger Bestandteil eines Ökosystems wird, muss sie von den Menschen akzeptiert werden. Wer hat also ein Interesse an Service Mesh? Wer gewinnt durch deren Einsatz?

Wenn Sie moderne Serversoftware entwickeln, können Sie Ihr Team grob als eine Gruppe von Service-Besitzern, die gemeinsam die Geschäftslogik entwickeln und implementieren, sowie Plattformbesitzern, die sich mit der Entwicklung der internen Plattform beschäftigen, auf der diese Services betrieben werden. In kleinen Organisationen können das die gleichen Personen sein, aber mit dem Wachstum des Unternehmens werden diese Rollen in der Regel deutlicher und sogar in Unterrollen aufgeteilt… (Hier könnte man viel über die sich verändernde Natur von DevOps, den organisatorischen Einfluss von Microservices usw. sagen. Aber lassen Sie uns diese Beschreibungen vorerst als gegeben hinnehmen).

Aus dieser Perspektive sind die offensichtlichen Nutznießer des Service Mesh die Plattformbesitzer. Denn letztendlich besteht das Ziel des Plattformteams darin, eine interne Plattform zu schaffen, auf der die Servicebesitzer ihre Geschäftslogik umsetzen können – und zwar in einer Weise, die ihnen maximale Unabhängigkeit von den komplexen Details ihrer Verwaltung garantiert. Das Service Mesh bietet nicht nur die Möglichkeiten, die für das Erreichen dieses Ziels entscheidend sind, sondern tut dies auf eine Art und Weise, die keine Abhängigkeiten für die Servicebesitzer mit sich bringt.

Auch die Servicebesitzer profitieren, wenn auch auf eine indirektere Weise. Das Ziel eines Servicebesitzers ist es, so produktiv wie möglich bei der Umsetzung der Logik von Geschäftsprozessen zu sein. Je weniger er sich um Betriebsfragen kümmern muss, desto besser ist es. Anstatt sich beispielsweise mit der Implementierung von Wiederholungsrichtlinien oder TLS zu befassen, können sie sich ausschließlich auf ihre Geschäftstätigkeiten konzentrieren und darauf vertrauen, dass die Plattform sich um all das andere kümmert. Dies stellt einen erheblichen Vorteil für sie dar.

Der organisatorische Wert einer solchen Trennung zwischen den Besitzern von Plattformen und Diensten ist kaum zu überschätzen. Ich denke, dass er einen die Hauptdomain Beitrag zum Wert von Service Mesh leistet.

Wir haben diese Lektion gelernt, als einer der ersten Linkerd-Anhänger uns erzählte, warum sie sich für ein Service Mesh entschieden haben: weil es ihnen ermöglichte, "die Gespräche auf ein Minimum zu reduzieren". Hier sind einige Details: Die Jungs von einem großen Unternehmen migrierten ihre Plattform nach Kubernetes. Da die Anwendung mit vertraulichen Informationen arbeitete, wollten sie alle Kommunikation in den Clustern verschlüsseln. Die Situation wurde jedoch durch die hundert Dienste und hunderten Entwicklerteams kompliziert. Die Aussicht, sich mit allen in Verbindung zu setzen und sie davon zu überzeugen, TLS in ihre Pläne aufzunehmen, bereitete ihnen große Sorgen. Nachdem sie Linkerd installiert hatten, übertrugen sie die Verantwortung von den Entwicklern (für die es zusätzliche Mühe bedeutete) auf die Plattformverantwortlichen, für die dies eine oberste Priorität darstellte. Mit anderen Worten, Linkerd löste für sie weniger ein technisches als vielmehr ein organisatorisches Problem.

Kurz gesagt, ein Service Mesh ist eher eine Lösung für ein nicht-technisches sozio-technisches Problem. (Danke Cindy Sridharan um mit diesem Begriff vertraut zu werden.)

Löst ein Service Mesh all meine Probleme?

Ja. Ich meine, nein!

Wenn man sich die drei oben genannten Funktionskategorien ansieht: Zuverlässigkeit, Sicherheit und Überwachbarkeit, wird klar, dass ein Service Mesh keine vollständige Lösung für eines dieser Probleme ist. Obwohl Linkerd Wiederholungsanfragen senden kann (wenn es weiß, dass sie idempotent sind), ist es nicht in der Lage zu entscheiden, was dem Benutzer zurückgegeben werden soll, wenn der Service endgültig ausgefallen ist – solche Entscheidungen müssen von der Anwendung getroffen werden. Linkerd kann die Statistik der erfolgreichen Anfragen führen, doch es kann nicht in den Service eintauchen und seine internen Metriken bereitstellen – solche Werkzeuge müssen in der Anwendung vorhanden sein. Und obwohl Linkerd in der Lage ist, mTLS zu organisieren, erfordern vollständige Sicherheitslösungen weitaus mehr.

Ein Teil der in diesen Bereichen angebotenen Funktionen des Service Mesh gehört zu den Plattformfeatures. Damit meine ich Funktionen, die:

1. Unabhängig von der Geschäftslogik sind.Die Art und Weise, wie Histogramme von Aufrufen zwischen Foo und Bar erstellt werden, hängt überhaupt nicht davon ab, das ob Foo Bar aufruft.
2. Es ist schwierig, es richtig zu implementieren.. In Linkerd werden die Wiederholungsversuche mithilfe verschiedener ausgeklügelter Mechanismen wie Retry Budgets parametrisiert. (Retry Budgets), da ein naiver Ansatz bei der Umsetzung solcher Dinge mit Sicherheit zu einem sogenannten "Retry-Sturm" führen wird. (Retry-Sturm) und anderen Problemen, die typisch für verteilte Systeme sind.
3. Sie sind am effektivsten, wenn sie einheitlich angewendet werden.Ein TLS-Mechanismus macht nur dann Sinn, wenn er überall eingesetzt wird.

Da diese Funktionen auf Proxys (und nicht auf Anwendungsebene) implementiert sind, bietet das Service Mesh sie auf der Plattformebene an, der Plattformnicht auf Anwendungsebene. Es spielt also keine Rolle, in welcher Programmiersprache die Dienste geschrieben sind, welches Framework sie verwenden, wer sie geschrieben hat oder warum. Proxys arbeiten unabhängig von all diesen Details, und die grundlegende Basis dieser Funktionalität, einschließlich der Aufgaben im Zusammenhang mit Konfiguration, Aktualisierung, Betrieb, Wartung usw., liegt ausschließlich auf Plattformebene.

Beispiele für Funktionen des Service Mesh

Zusammenfassend möchte ich sagen, dass ein Service-Mesh keine vollständige Lösung für Zuverlässigkeit, Sichtbarkeit oder Sicherheit darstellt. Der Umfang dieser Bereiche erfordert das zwingende Engagement der Servicebesitzer, Ops/SRE-Teams und anderer Stakeholder im Unternehmen. Ein Service-Mesh bietet lediglich eine "Sicht" auf Plattformebene für jeden dieser Bereiche.

Warum ist das Service-Mesh gerade jetzt so populär geworden?

Wahrscheinlich fragen Sie sich gerade: Wenn das Service-Mesh so effektiv ist, warum haben wir dann nicht bereits vor zehn Jahren Millionen von Proxys im Stack bereitgestellt?

Es gibt eine offensichtliche Antwort auf diese Frage: Vor zehn Jahren baute jeder Monolithen, und niemand brauchte ein Service Mesh. Das ist zwar wahr, aber meiner Meinung nach wird in dieser Antwort das Wesentliche vernachlässigt. Selbst vor zehn Jahren wurde das Konzept der Mikrodienste als vielversprechender Ansatz zur Erstellung großangelegter Systeme weit diskutiert und in Unternehmen wie Twitter, Facebook, Google und Netflix angewendet. Der allgemeine Konsens – zumindest in den Teilen der Branche, mit denen ich in Kontakt war – war, dass Mikrodienste der 'richtige Weg' sind, große Systeme zu erstellen, auch wenn es extrem herausfordernd war.

Natürlich gab es vor zehn Jahren Unternehmen, die Mikrodienste einsetzten, doch sie haben nicht überall auf Proxy gesetzt, um ein Service Mesh zu bilden. Wenn man genauer hinsieht, haben sie jedoch etwas Ähnliches gemacht: In vielen dieser Unternehmen war es vorgeschrieben, eine bestimmte interne Bibliothek für die Netzwerkinteraktion zu verwenden (manchmal als dicke Client-Bibliothek bezeichnet, fat client library).

Netflix hatte Hysterix, Google hatte Stubby und Twitter – die Finagle-Bibliothek. Finagle war beispielsweise für jeden neuen Dienst bei Twitter unverzichtbar. Sie verwaltete sowohl die Client- als auch die Serverseite von Verbindungen, erlaubte Wiederholungsanforderungen, unterstützte die Anforderungsweiterleitung, die Lastverteilung und das Monitoring. Sie stellte eine einheitliche Schicht von Zuverlässigkeit und Sichtbarkeit für den gesamten Twitter-Stack bereit, unabhängig davon, womit der Dienst beschäftigt war. Natürlich funktionierte sie nur für JVM-Sprachen und basierte auf dem Programmieransatz, der für die gesamte Anwendung verwendet werden musste. Ihre Funktionalitäten waren jedoch nahezu identisch mit denen eines Service Mesh. (Die erste Version von Linkerd war tatsächlich nur Finagle, eingepackt in ein Proxy-Format.)

Vor zehn Jahren gab es also nicht nur Mikrodienste, sondern auch spezielle Proto-Service-Mesh-Bibliotheken, die dieselben Probleme lösten, die heute von einem Service Mesh gelöst werden. Aber ein echtes Service Mesh gab es damals noch nicht. Es musste noch eine weitere Verschiebung eintreten, bevor es erschien.

Und genau hier liegt die tiefere Antwort, verborgen in einer anderen Veränderung, die in den letzten 10 Jahren stattgefunden hat: Die Kosten für die Bereitstellung von Microservices sind drastisch gesunken. Die oben genannten Unternehmen, die vor zehn Jahren Microservices nutzten – Twitter, Netflix, Facebook, Google – waren riesige Unternehmen mit enormen Ressourcen. Sie hatten nicht nur den Bedarf, sondern auch die Mittel, große Anwendungen auf der Basis von Microservices zu entwickeln, bereitzustellen und zu betreiben. Die Energie und die Anstrengungen, die die Ingenieure von Twitter für den Übergang von einem monolithischen zu einem mikroservicesbasierten Ansatz aufgebracht haben, sind einfach beeindruckend. (Ehrlich gesagt, ebenso wie die Tatsache, dass es gelungen ist.) Solche infrastrukturellen Manöver waren damals für kleinere Unternehmen unmöglich.

Lassen Sie uns in die Gegenwart reisen. Heute gibt es Startups, bei denen das Verhältnis von Microservices zu Entwicklern 5:1 beträgt (oder sogar 10:1), und darüber hinaus meistern sie diese Herausforderung erfolgreich! Wenn ein Startup mit 5 Personen problemlos 50 Microservices betreiben kann, muss etwas die Kosten für deren Implementierung eindeutig gesenkt haben.

1500 Microservices in Monzo; jede Zeile ist eine festgelegte Netzwerkregel, die den Datenverkehr erlaubt.

Der drastische Rückgang der Betriebskosten von Microservices ist das Ergebnis eines Prozesses: des Anstiegs der Beliebtheit von Containern. und Orchestratoren. Genau hier liegt die tiefere Antwort auf die Frage, was zur Entstehung von Service Mesh beigetragen hat. Dieselbe Technologie hat sowohl Service Mesh als auch Microservices attraktiv gemacht: Kubernetes und Docker.

Warum? Nun, Docker löst ein großes Problem — das Problem der Verpackung. Indem es die Anwendung und ihre (nicht-netzwerkbezogenen) Laufzeitabhängigkeiten in einem Container verpackt, verwandelt Docker die Anwendung in eine austauschbare Einheit, die überall bereitgestellt und ausgeführt werden kann. Gleichzeitig vereinfacht es erheblich den Betrieb. multilingual Stacks: Da Container die atomare Ausführungseinheit sind, spielt es für Bereitstellung und Betrieb keine Rolle, was sich darin befindet, ob es sich um eine Anwendung in JVM, Node, Go, Python oder Ruby handelt. Sie starten sie einfach, und das war's.

Kubernetes hebt alles auf ein neues Level. Angesichts der Vielzahl an „ausführbaren Einheiten“ und der vielen Maschinen, auf denen sie laufen können, ergibt sich der Bedarf nach einem Tool, das diese miteinander verknüpfen kann. Im weitesten Sinne stellt man Kubernetes eine Menge Container und eine Vielzahl von Maschinen zur Verfügung, und es verbindet diese untereinander (natürlich ist das ein dynamischer und sich ständig ändernder Prozess: neue Container bewegen sich im System, Maschinen werden hoch- und heruntergefahren usw. Kubernetes berücksichtigt all das).

Nach der Einrichtung von Kubernetes unterscheiden sich die zeitlichen Aufwände für das Deployment und den Betrieb eines Dienstes kaum von denen für den Deployment und Betrieb von zehn Diensten (tatsächlich sind sie nahezu identisch, sogar bei 100 Diensten). Fügen Sie dazu Container als Verpackungsmechanismus hinzu, der mehrsprachige Implementierungen fördert, und Sie erhalten eine Vielzahl neuer Anwendungen, die in Form von Mikrodiensten in verschiedenen Sprachen implementiert sind – genau die Umgebung, für die Service Mesh so gut geeignet ist.

Jetzt können wir die Frage beantworten, warum die Idee des Service Mesh gerade jetzt an Popularität gewinnt: Die Homogenität, die Kubernetes für Dienste bereitstellt, lässt sich direkt auf die betrieblichen Herausforderungen anwenden, die ein Service Mesh mit sich bringt. Man packt Proxys in Container, lässt Kubernetes die Aufgabe übernehmen, sie überall anzubringen, und voilà! Am Ende erhält man ein Service Mesh, wobei Kubernetes die gesamte Mechanik des Rollouts steuert. (Zumindest aus einer Vogelperspektive. Natürlich gibt es in diesem Prozess viele Nuancen.)

Zusammenfassend lässt sich sagen, dass der Grund, warum das Service Mesh gerade jetzt populär ist und nicht vor zehn Jahren, darin besteht, dass Kubernetes und Docker nicht nur die Nachfrage deutlich erhöht haben, indem sie die Implementierung von Anwendungen als Sets von mehrsprachigen Mikrodiensten erleichtert haben, sondern auch die Betriebskosten wesentlich gesenkt haben, indem sie Mechanismen für die Bereitstellung und Unterstützung von Sidecar-Proxys bereitgestellt haben.

Warum gibt es so viele Gespräche über das Service Mesh?

Warnung: In diesem Abschnitt greife ich auf verschiedene Annahmen, Vermutungen, Überlegungen und interne Informationen zurück.

Wenn Sie nach dem Begriff „Service Mesh“ suchen, stoßen Sie auf eine Vielzahl von wiederaufbereitetem, kalorienarmem Inhalt, merkwürdigen Projekten und einem Kaleidoskop von Verzerrungen, die für Echokammern typisch sind. Jede neue, trendige Technologie hat das oft, doch im Falle von Service Mesh ist das Problem besonders ausgeprägt. Warum?

Nun, teilweise ist das meine Schuld. Ich habe alles in meiner Macht Stehende getan, um Linkerd und Service Mesh bei jeder Gelegenheit zu fördern, durch unzählige Blogbeiträge und Artikel wie diesen. Doch ich bin nicht so mächtig. Um diese Frage wirklich zu beantworten, sollten wir ein wenig über die allgemeine Situation sprechen. Dabei ist es unmöglich, ein Projekt zu ignorieren: Istio – ein Open-Source-Service-Mesh, das gemeinsam von Google, IBM und Lyft entwickelt wird.

(Diese drei Unternehmen haben völlig unterschiedliche Rollen: Lyft scheint nur namentlich beteiligt zu sein; sie sind die Autoren von Envoy, nutzen jedoch Istio nicht oder sind nicht an dessen Entwicklung beteiligt. IBM ist an der Entwicklung von Istio beteiligt und nutzt es. Google ist aktiv an der Entwicklung von Istio beteiligt, verwendet es jedoch meines Wissens nach tatsächlich nicht.)

Das Projekt Istio fällt durch zwei Merkmale auf. Erstens sind es die enormen Marketinganstrengungen, die Google, insbesondere, in seine Förderung steckt. Schätzungsweise haben die meisten Menschen, die heute mit dem Konzept des Service Mesh vertraut sind, erstmals dank Istio davon erfahren. Das zweite Merkmal ist, wie schlecht Istio aufgenommen wurde. In dieser Hinsicht bin ich offenbar befangen, aber ich versuche, so objektiv wie möglich zu bleiben, kann jedoch nicht umhin, markieren sehr negativ eingestellt, was nicht gerade charakteristisch ist (obwohl nicht einzigartig: systemd fällt mir ein, Vergleich wurde bereits mehrmals…) für ein Open-Source-Projekt.

(In der Praxis scheint Istio nicht nur Probleme mit der Komplexität und der Benutzerfreundlichkeit zu haben, sondern auch mit der Leistung. Zum Beispiel während der Leistungsbewertung von Linkerd, die von Dritten durchgeführt wurde, stellten die Experten Situationen fest, in denen die Tail-Latenz von Istio 100 Mal höher war als der entsprechende Wert von Linkerd, sowie Situationen mit Ressourcenmangel, bei denen Linkerd weiterhin erfolgreich funktionierte, während Istio völlig ausfiel.)

Ich lasse meine Theorien darüber beiseite, warum das so ist, aber ich denke, dass der enorme Hype um Service Mesh insbesondere durch das Engagement von Google erklärt wird. Genauer gesagt, durch die Kombination der folgenden drei Faktoren:

1. die aggressive Promotion von Istio durch Google;
2. eine entsprechende ablehnende, kritische Haltung gegenüber dem Projekt;
3. der jüngste rasante Aufstieg der Popularität von Kubernetes, dessen Erinnerungen noch frisch sind.

Diese Faktoren vereinen sich in einer Art berauschenden, sauerstoffarmen Umgebung, in der die Fähigkeit zu rationalem Urteilen schwindet und nur eine wunderbare Art von Tulpenmanie bleibt..

In Bezug auf Linkerd würde ich es als ein zwiespältiges Gut beschreiben. Es ist großartig, dass Service Mesh in den Mainstream eingedrungen ist – etwas, das 2016, als Linkerd erstmals erschien, nicht der Fall war und es durchaus schwierig war, die Aufmerksamkeit der Leute auf das Projekt zu lenken. Dieses Problem gibt es jetzt nicht mehr! Aber das Negative ist, dass die Situation mit Service Mesh heute so verworren ist, dass es praktisch unmöglich ist zu verstehen, welche Projekte wirklich zur Kategorie Service Mesh gehören (ganz zu schweigen davon, herauszufinden, welches am besten für den spezifischen Anwendungsfall geeignet ist). Das erschwert es allen, und in einigen Fällen passt Istio oder ein anderes Projekt besser als Linkerd, da letzteres nicht wirklich eine universelle Lösung darstellt.

Von Linkerd aus gesehen bestand unsere Strategie darin, den Lärm zu ignorieren, uns weiterhin auf die Lösung echter Probleme in der Community zu konzentrieren und im Grunde darauf zu warten, dass der Hype nachlässt. Letztendlich wird der Hype abnehmen und wir können ruhig weiterarbeiten.

Bis dahin müssen wir alle ein wenig Geduld haben.

Wird mir, einem bescheidenen Software-Ingenieur, Service Mesh nützlich sein?

Um diese Frage zu beantworten, hilft Ihnen der folgende Fragebogen:

Kümmern Sie sich ausschließlich um die Implementierung von Geschäftslogik? In diesem Fall ist ein Service Mesh für Sie nicht erforderlich. Natürlich können Sie sich dafür interessieren, aber idealerweise sollte ein Service Mesh keinen direkten Einfluss auf Ihre Umgebung haben. Konzentrieren Sie sich weiterhin auf das, wofür Sie bezahlt werden.

Unterstützen Sie eine Plattform in Ihrem Unternehmen, die Kubernetes verwendet? Ja, in diesem Fall benötigen Sie ein Service Mesh (es sei denn, Sie verwenden K8s nur zum Ausführen eines Monolithen oder für die batchverarbeitung – aber dann würde ich gerne wissen, warum Sie K8s verwenden). Wahrscheinlich befinden Sie sich in einer Situation mit vielen Mikrodiensten, die von verschiedenen Personen entwickelt wurden. Diese interagieren miteinander und sind in ein Netz von Laufzeitabhängigkeiten verwickelt, und Sie müssen einen Weg finden, damit umzugehen. Die Verwendung von Kubernetes ermöglicht es Ihnen, ein Service Mesh auszuwählen, das zu Ihnen passt. Informieren Sie sich über deren Möglichkeiten und Eigenschaften und prüfen Sie, ob eines der bestehenden Projekte für Sie geeignet ist (ich empfehle, mit Linkerd zu beginnen).

Leiten Sie eine Plattform in einem Unternehmen, das KEIN Kubernetes verwendet, aber Mikrodienste einsetzt? In diesem Fall könnte ein Service Mesh hilfreich für Sie sein, aber die Implementierung wird nicht trivial sein. Natürlich können Sie simulieren wie ein Service Mesh funktioniert, indem Sie eine Gruppe von Proxys einrichten, aber ein wichtiges Merkmal von Kubernetes ist gerade das Bereitstellungsmodell: Das manuelle Management dieser Proxys erfordert wesentlich mehr Zeit, Aufwand und Kosten.

Sind Sie verantwortlich für die Plattform in einem Unternehmen, das mit Monolithen arbeitet? In diesem Fall benötigen Sie wahrscheinlich kein Service Mesh. Wenn Sie mit Monolithen (oder sogar mit Sätzen von Monolithen) arbeiten, die klar definierte und selten wechselnde Interaktionsmuster aufweisen, wird Ihnen ein Service Mesh kaum etwas bieten können. Daher können Sie es einfach ignorieren und darauf hoffen, dass es wie ein böser Traum verschwindet…

Fazit

Wahrscheinlich sollte man service mesh nicht als „die angesagteste Technologie der Welt“ bezeichnen – dieser fragwürdige Titel gehört wahrscheinlich Bitcoin oder KI. Vielleicht gehört es jedoch zu den Top fünf. Wenn man durch die Schichten von Lärm und Hektik blickt, wird deutlich, dass service mesh echten Nutzen für diejenigen bietet, die Anwendungen in Kubernetes entwickeln.

Ich möchte, dass Sie Linkerd ausprobieren – die Installation in einem Kubernetes-Cluster (oder sogar in Minikube auf Ihrem Laptop) dauert etwa 60 Sekunden, und Sie können selbst sehen, worum es geht.

FAQ

— Wenn ich service mesh ignoriere, wird es dann verschwinden?
— Ich muss Sie enttäuschen: service mesh ist gekommen, um zu bleiben.

— Aber ich WILL service mesh nicht verwenden!
— Nun, das müssen Sie auch nicht! Lesen Sie einfach meinen Fragebogen oben, um herauszufinden, ob Sie sich zumindest mit den Grundlagen vertraut machen sollten.

— Ist das nicht einfach das altbekannte ESB/Middleware in neuem Gewand?
— Service mesh beschäftigt sich mit der Betriebslogik, nicht mit der Bedeutung. Das war das größte Manko der Unternehmensservicelinie (ESB). Diese Trennung zu wahren, hilft service mesh, das gleiche Schicksal zu vermeiden.

— Was unterscheidet service mesh von API-Gateways?
— Es gibt Millionen von Artikeln zu diesem Thema. Einfach mal googeln.

— Ist Envoy ein service mesh?
— Nein, Envoy ist kein Service Mesh, sondern ein Proxy-Server. Er kann verwendet werden, um ein Service Mesh zu organisieren (und noch vieles mehr – es handelt sich um einen universellen Proxy). Aber allein ist er kein Service Mesh.

— Ist Network Service Mesh ein Service Mesh?
— Nein. Trotz des Namens ist es kein Service Mesh (wie Marketingwunder landen?).

— Wird mir ein Service Mesh bei meinem reaktiven, asynchronen System auf Basis von Nachrichtenwarteschlangen helfen?
— Nein, ein Service Mesh wird Ihnen nicht helfen.

— Welches Service Mesh sollte ich verwenden?
— Linkerd, das versteht jeder.

— Der Artikel ist Mist! / Der Autor gehört ins Gefängnis!
— Bitte teilen Sie den Link mit all Ihren Freunden, damit sie sich davon überzeugen können!

Danksagungen

Wie Sie am Titel erkennen können, wurde dieser Artikel von dem fantastischen Traktat von Jay Kreps inspiriert „The Log: Was jeder Software-Ingenieur über die vereinheitlichende Abstraktion von Echtzeitdaten wissen sollte“. Ich habe Jay vor zehn Jahren bei einem Interview in LinkedIn getroffen, und seitdem ist er eine Inspiration für mich.

Obwohl ich mich gerne als „Linkerd-Entwickler“ bezeichne, ist die Realität so, dass ich eher der Verantwortliche für die README.md-Datei im Projekt bin. An Linkerd arbeiten heute sehr, sehr, sehr eine Menge Menschen, und dieses Projekt wäre ohne die Unterstützung der großartigen Gemeinschaft von Mitwirkenden und Nutzern nicht zustande gekommen.

Und abschließend ein besonderer Dank an den Schöpfer von Linkerd, Oliver Gould (primus inter pares), der zusammen mit mir vor vielen Jahren in das ganze Getümmel rund um Service Mesh eingetaucht ist.

P.S. vom Übersetzer

Lesen Sie auch in unserem Blog:

• «Was ist ein Service Mesh und warum benötige ich es [für Cloud-Anwendungen mit Microservices]?»;
• «Traefik 2.0: Aktualisierung des Service Mesh mit TCP-Unterstützung und einer neuen Benutzeroberfläche»;
• «Maesh – das neue einfache Service Mesh für Kubernetes von den Machern von Traefik»;
• «Zurück zu Microservices mit Istio. Teil 1»;
• «Conduit – ein leichtgewichtiges Service Mesh für Kubernetes.».

Quelle: habr.com