Anmerkung des Übersetzers.: Service Mesh — ein Phänomen, für das es noch keine etablierte Übersetzung ins Deutsche gibt (vor mehr als 2 Jahren haben wir den Begriff „Service-Netz“ vorgeschlagen, während einige Kollegen später aktiv die Kombination „Service-Sieb“ förderten). Ständige Diskussionen über diese Technologie haben zu einer Situation geführt, in der sich Marketing- und technische Aspekte zu eng miteinander vermischt haben. Dieses hervorragende Material von einem der Urheber des Begriffs soll Klarheit für Ingenieure und andere bringen.
Comic von
Einführung
Wenn Sie ein Software-Ingenieur sind, der irgendwo im Bereich der Backend-Systeme arbeitet, hat sich der Begriff „Service Mesh“ wahrscheinlich in den letzten paar Jahren fest in Ihrem Bewusstsein verankert. Durch eine merkwürdige Verkettung von Umständen erobert dieser Begriff die Branche immer mehr, während der Hype und die damit verbundenen Werbeangebote wie ein Schneeball wachsen, der einen Hang hinunterrollt und keine Anzeichen von Verlangsamung zeigt.
Service Mesh entstand in den trüben, voreingenommenen Gewässern des Cloud-Native-Ökosystems. Leider bedeutet dies, dass ein erheblicher Teil der damit verbundenen Kontroversen von „kalorienarmer Plauderei“ bis hin zu — um ein technisches Wort zu verwenden — offenem Unsinn variiert. Aber wenn man all den Lärm herausfiltert, stellt man fest, dass Service Mesh eine absolut reale, definierte und wichtige Funktion hat.
In diesem Beitrag werde ich genau das versuchen: ein ehrliches, tiefgehendes, ingenieurgerechtes Handbuch zur 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) genau diese Technologie einen so verrückten Hype ausgelöst hat, was an sich schon eine interessante Geschichte ist.
Wer bin ich?
Hallo zusammen! Ich heiße . Ich bin einer der Schöpfer — des allerersten Service Mesh-Projekts und des Projekts, das für das Entstehen des Begriffs verantwortlich ist Service Mesh in der Form, wie wir ihn heute kennen (sorry, Leute!). (Übersetzungshinweis.: Übrigens, zu Beginn dieses Begriffs vor mehr als 2,5 Jahren haben wir bereits frühere Materialien desselben Autors mit dem Titel „».) Ich leite auch — ein Startup, das coole Dinge im Bereich Service Mesh entwickelt, wie Linkerd und .
Sie ahnen wahrscheinlich, dass ich eine ziemlich voreingenommene und subjektive Meinung zu diesem Thema habe. Ich werde jedoch versuchen, die Voreingenommenheit auf ein Minimum zu reduzieren (mit Ausnahme eines Abschnitts: „Warum wird so viel über Service-Mesh gesprochen?“, — in dem ich dennoch meine voreingenommenen Ideen teilen werde). Außerdem werde ich mein Bestes tun, um dieses Handbuch so objektiv wie möglich zu gestalten. Bei den konkreten Beispielen werde ich hauptsächlich auf die Erfahrungen mit Linkerd zurückgreifen und dabei auf mir bekannte Unterschiede (sofern vorhanden) bei der Implementierung anderer Arten von Service-Mesh hinweisen.
Okay, es ist Zeit, zu den Leckerbissen überzugehen.
Was ist ein Service-Mesh?
Trotz des ganzen Hypes ist ein Service-Mesh strukturell ziemlich einfach aufgebaut. Es handelt sich lediglich um eine Ansammlung von Userspace-Proxys, die „neben“ den Services positioniert sind (darüber werden wir später ein wenig sprechen, was „neben“ bedeutet), plus eine Reihe von Verwaltungsprozessen. Die Proxys zusammen werden als Datenebenebezeichnet, während die Verwaltungsprozesse als Steuerungsebenebezeichnet werden. Die Datenebene fängt die Aufrufe zwischen den Services ab und führt „verschiedene Operationen“ damit aus; die Steuerungsebene koordiniert entsprechend das Verhalten der Proxys und gibt Ihnen, d.h. dem Betreiber, Zugriff auf die API, mit der Sie das Netzwerk manipulieren und als ein Ganzes messen können.
Was sind diese Proxys? Es sind TCP-Proxys der Kategorie „Layer 7-aware“ (d.h. „berücksichtigend“ die 7. Schicht des OSI-Modells) , wie HAProxy und NGINX. Sie können einen Proxy nach Ihrem Geschmack wählen; Linkerd verwendet einen Proxy in Rust, der schlicht als bezeichnet wird. Wir haben ihn speziell für das Service-Mesh entwickelt. Andere Meshes ziehen andere Proxys vor (Envoy ist eine häufige Wahl). Dennoch ist die Wahl des Proxys lediglich eine Frage der Implementierung.
Was tun diese Proxys? Offensichtlich proxieren sie Aufrufe zu und von den Services (strikt genommen erfüllen sie die Funktion von Proxys und Reverse-Proxys, indem sie sowohl eingehende als auch ausgehende Aufrufe verwalten). Und sie implementieren eine Reihe von Funktionen, die sich auf die Aufrufe zwischen den Services konzentrieren. Diese Fokussierung auf den Verkehr zwischen den Services unterscheidet die Service-Mesh-Proxys von beispielsweise API-Gateways oder Ingress-Proxys (letztere konzentrieren sich auf die Aufrufe, die von außen in den Cluster kommen). (Anmerkung des Übersetzers.: einen Vergleich bestehender Ingress-Controller für Kubernetes, von denen viele bereits das erwähnte Envoy verwenden, finden Sie in .)
Also, mit dem Datenplan sind wir klargekommen. Der Kontrollplan ist einfacher aufgebaut: Er ist eine Sammlung von Komponenten, die die gesamte Mechanik bereitstellt, die der Datenplan benötigt, um koordiniert zu arbeiten, einschließlich der Dienstentdeckung, der Ausstellung von TLS-Zertifikaten, der Aggregation von Metriken usw. Der Datenplan informiert den Kontrollplan über sein Verhalten; im Gegenzug bietet der Kontrollplan eine API, um das Verhalten des Datenplans als Ganzes zu ändern und zu überwachen.
Im Folgenden ist das Schema für den Kontrollplan und den Datenplan in Linkerd dargestellt. Wie zu sehen ist, umfasst der Kontrollplan mehrere verschiedene Komponenten, darunter eine Instanz von Prometheus, die Metriken von den Proxy-Servern sammelt, sowie andere Komponenten wie Ziel (Dienstentdeckung), -Token, (Zertifizierungsstelle, CA) und public-api (Endpunkte für Web und CLI). Im Gegensatz dazu stellt der Datenplan einen einfachen linkerd-proxy neben einer Instanz der Anwendung dar. Dies ist nur ein logisches Schema; unter realen Bedingungen bei der Bereitstellung könnten Sie drei Replikate jeder Komponente des Kontrollplans und Hunderte oder Tausende von Proxys im Datenplan haben.
(Die blauen Rechtecke in diesem Diagramm symbolisieren die Grenzen der Kubernetes-Pods. Es ist zu erkennen, dass die Container mit dem linkerd-proxy im selben Pod wie die Anwendungscontainer sind. Solch ein Schema ist bekannt als Sidecar-Container..)
Die Architektur des Service Mesh hat mehrere wichtige Konsequenzen. Erstens, da die Aufgabe des Proxys darin besteht, Aufrufe zwischen Diensten abzufangen, macht ein Service Mesh nur dann Sinn, wenn Ihre Anwendung auf einer Gruppe von Diensten aufgebaut wurde. Mesh kann man verwendet man mit Monolithen, aber das ist offensichtlich überflüssig für einen einzigen Proxy, und ihre Funktionalität wird wahrscheinlich nicht benötigt.
Eine andere wichtige Folge ist, dass das Service Mesh eine enorme Anzahl von Proxys benötigt. Tatsächlich hängt Linkerd linkerd-proxy an jeder Instanz jedes Dienstes (andere Implementierungen fügen Proxys zu jedem Knoten/Hosten/virtuellen Maschine hinzu. In jedem Fall ist das nicht wenig). Der so aktive Einsatz von Proxys bringt von sich aus eine Reihe zusätzlicher Komplikationen mit sich:
- Proxys im Datenplan müssen schnellsein, da jede Aufrufkombination aus zwei Aufrufen zum Proxy besteht: einem auf der Clientseite und einem auf der Serverseite.
- Außerdem müssen Proxys klein und undleichtgewichtig sein. Jeder von ihnen verbraucht Ressourcen für Speicher und CPU, und dieser Verbrauch wird linear mit der Anwendung wachsen.
- Sie benötigen ein System zur Bereitstellung und Aktualisierung einer großen Anzahl von Proxys. Dies manuell zu tun, ist keine Option.
Im Allgemeinen sieht ein Service Mesh so aus (zumindest aus der Vogelperspektive): Sie stellen eine Menge von Userspace-Proxys bereit, die "irgendetwas tun" mit dem internen, zwischen den Diensten fließenden Datenverkehr, und verwenden die Steuerungsebene, um sie zu überwachen und zu verwalten.
Jetzt kommt die Frage „Warum?“
Wozu braucht man ein Service Mesh?
Es ist verständlich, dass diejenigen, die zum ersten Mal mit der Idee eines Service Meshs konfrontiert sind, ein gewisses Zögern empfinden. Die Struktur eines Service Meshs bedeutet, dass es nicht nur die Latenzen in der Anwendung erhöht, sondern auch Ressourcen verbrauchen , und hinzufügt viele neue Mechanismen zu der Infrastruktur. Zuerst installieren Sie das Service Mesh, und dann stellen Sie plötzlich fest, dass Sie Hunderte (wenn nicht Tausende) von Proxys verwalten müssen. Die Frage ist, wer sich freiwillig dafür meldet?
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 im Ökosystem erheblich gesenkt werden (darüber später mehr).
Zweitens ist ein solches System tatsächlich eine ausgezeichnete Möglichkeit, zusätzliche Logik in das System einzuführen. Und nicht nur, weil mit einem Service Mesh viele neue Funktionen hinzugefügt werden können, sondern auch, weil dies geschehen kann, ohne in das Ökosystem einzugreifen. Tatsächlich basiert das gesamte Modell des Service Meshs auf diesem Postulat: In einem Multidienstsystem, unabhängig davon, was die einzelnen Dienste tun, ist der Datenverkehr zwischen ihnen der ideale Punkt, um Funktionalität hinzuzufügen.
Zum Beispiel ist in Linkerd (wie in den meisten Meshes) die Funktionalität hauptsächlich auf HTTP-Anfragen fokussiert, einschließlich HTTP/2 und gRPC*. Die Funktionalität ist ziemlich umfangreich und lässt sich in drei Klassen unterteilen:
- Funktionen in Bezug auf Zuverlässigkeit.Wiederholte Anfragen, Zeitüberschreitungen, Canary-Ansatz (Traffic-Sharding/Routing) usw.
- Funktionen in Bezug auf Überwachung.Aggregation von Leistungskennzahlen, Latenzen und Anfragen für jeden Dienst oder bestimmte Pfade; Erstellung von topologischen Karten der Dienste usw.
- Funktionen in Bezug auf Sicherheit.Mutual TLS, Zugriffskontrolle usw.
* Aus Sicht von Linkerd unterscheidet sich gRPC praktisch nicht von HTTP/2: es wird einfach Protobuf in der Nutzlast verwendet. Aus Sicht des Entwicklers unterscheiden sich diese beiden Dinge natürlich.
Viele dieser Mechanismen arbeiten auf der Ebene von Anfragen (daher auch "L7-Proxy"). Wenn zum Beispiel 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 Aufrufe von Foo zu Instanzen von Bar je nach beobachteter Latenz weiterleiten; er kann die Anfrage bei Bedarf wiederholen (und wenn sie idempotent ist); er kann den Antwortcode und die Wartezeit protokollieren usw. In ähnlicher Weise kann der linkerd-proxy auf der Seite von Bar die Anfrage ablehnen, wenn sie nicht erlaubt ist oder das Anfrage-Limit überschritten wurde; er kann die Latenz auf seiner Seite protokollieren usw.
Proxys können "irgendetwas tun" und auf der Verbindungsebene. Beispielsweise kann der linkerd-proxy auf der Seite von Foo eine TLS-Verbindung initiieren, während der linkerd-proxy auf der Seite von Bar diese trennt, und beide Seiten können die TLS-Zertifikate des jeweils anderen überprüfen*. Dies sorgt nicht nur für eine Verschlüsselung zwischen den Diensten, sondern auch für eine kryptographisch sichere Möglichkeit zur Identifizierung der Dienste: Foo und Bar können "nachweisen", dass sie die sind, für die sie sich ausgeben.
* "Einander" bedeutet, dass das Client-Zertifikat ebenfalls überprüft wird (mutual TLS). Im "klassischen" TLS, zum Beispiel zwischen einem Browser und einem Server, wird normalerweise nur das Zertifikat einer Seite (des Servers) überprüft.
Unabhängig davon, ob sie auf der Ebene von Anfragen oder Verbindungen arbeiten, ist es wichtig zu betonen, dass alle Funktionen des Service Mesh betrieblich sind. Linkerd ist nicht in der Lage, die Semantik der Nutzlast zu transformieren – zum Beispiel Felder in ein JSON-Fragment hinzuzufügen oder Änderungen an Protobuf vorzunehmen. Auf diese wichtige Eigenschaft werden wir später eingehen, wenn es um ESB und Middleware geht.
Das ist die Funktionalität, die ein Service Mesh bietet. Die Frage stellt sich: Warum nicht diese Funktionen direkt in der Anwendung implementieren? Und warum sich überhaupt mit Proxys beschäftigen?
Warum ist ein Service Mesh eine gute Idee
Obwohl die Möglichkeiten eines Service Mesh die Vorstellungskraft anregen, liegt der eigentliche Wert nicht in den Funktionen. Schließlich sind wir können diese direkt in der Anwendung zu implementieren (später werden wir sehen, dass dies der Ursprung des Service Mesh war). Wenn man diesen Gedanken in einem Satz zusammenfassen möchte, besteht der Wert des Service Mesh darin: es bietet Funktionen, die für den Betrieb moderner Server-Software von entscheidender Bedeutung sind, einheitlich für den gesamten Stack und unabhängig vom Anwendungscode..
Lassen Sie uns diesen Satz analysieren.
«Funktionen, die für den Betrieb moderner Server-Software von entscheidender Bedeutung sind.». Wenn Sie eine transaktionale Serveranwendung erstellen, die mit dem öffentlichen Internet verbunden ist, Anfragen aus der Außenwelt entgegennimmt und innerhalb kurzer Zeit darauf reagiert — zum Beispiel eine Webanwendung, API-Server und die überwiegende Mehrheit der anderen modernen Anwendungen — und wenn Sie sie als eine Reihe von Diensten implementieren, die synchron miteinander interagieren, und wenn Sie diese Software ständig modernisieren, indem Sie neue Funktionen hinzufügen, und wenn Sie gezwungen sind, dieses System im Laufe der Modifizierung betriebsbereit zu halten — in diesem Fall gratuliere ich Ihnen, Sie beschäftigen sich mit der Erstellung moderner Server-Software. Und all diese wunderbaren Funktionen, die oben aufgeführt sind, erweisen sich tatsächlich als entscheidend für Sie. Die Anwendung muss zuverlässig und sicher sein, und Sie müssen in der Lage sein, zu beobachten, was sie tut. Genau diese Fragen hilft das Service Mesh zu lösen.
(Okay, in den vorherigen Absatz hat sich dennoch meine Überzeugung eingeschlichen, dass dieser Ansatz eine moderne Art ist, Server-Software zu erstellen. Andere ziehen es vor, Monolithen, »reaktive Mikrodienste« und andere Dinge zu entwickeln, die nicht unter die oben genannte Definition fallen. Diese Leute haben sicherlich eine andere Meinung als ich. Ich hingegen glaube, dass sie „nicht recht haben“ — obwohl das Service Mesh für sie in jedem Fall nicht besonders nützlich ist).
«Einheitlich für den gesamten Stack.». Die vom Service Mesh bereitgestellten Funktionen sind nicht nur entscheidend. Sie werden auf alle Dienste in der Anwendung angewendet, unabhängig davon, in welcher Sprache sie geschrieben sind, welches Framework sie verwenden, wer sie geschrieben hat, wie sie bereitgestellt wurden und von all den anderen Feinheiten ihrer Entwicklung und Anwendungen.
«Unabhängig vom Anwendungscode.Endlich bietet das Service Mesh nicht nur einheitliche Funktionalitäten für den gesamten Stack, sondern tut dies auf eine Weise, die keine Änderungen an der Anwendung erfordert. Die grundlegende Funktionsbasis des Service Mesh, einschließlich der Aufgaben wie Konfiguration, Aktualisierung, Betrieb und Wartung, 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. Im Gegenzug kann sich das Service Mesh ändern, ohne dass die Anwendung daran beteiligt ist.
Kurz gesagt, das Service Mesh bietet nicht nur lebenswichtige Funktionen, sondern tut dies auch global, konsistent und unabhängig von der Anwendung. Daher wird die Funktionalität des Service Mesh zwar im Code des Dienstes implementiert (zum Beispiel als Bibliothek, die in jeden Dienst integriert ist), dieser Ansatz gewährleistet jedoch nicht die Einheitlichkeit und Unabhängigkeit, die im Fall eines Service Mesh so wertvoll sind.
Und alles, was Sie dafür brauchen, ist eine Menge Proxies hinzuzufügen! Ich verspreche, dass wir sehr bald die Betriebskosten in Bezug auf das Hinzufügen dieser Proxies betrachten werden. Aber lassen Sie uns zunächst innehalten und diese Idee der Unabhängigkeit aus verschiedenen Perspektiven betrachten. Menschen.
Wem hilft das Service Mesh?
So unpraktisch es auch sein mag, um eine Technologie zu einer wesentlichen Bestandteile des Ökosystems zu machen, muss sie von Menschen angenommen werden. Wer also hat ein Interesse am Service Mesh? Wer profitiert von dessen Nutzung?
Wenn Sie moderne Serversoftware entwickeln, können Sie Ihr Team grob als Gruppe von Service-Besitzern, die gemeinsam die Geschäftslogik entwickeln und implementieren, und von Plattformbesitzern, die sich mit der Entwicklung der internen Plattform beschäftigen, auf der diese Dienste laufen. In kleinen Organisationen können dies dieselben Personen sein, aber mit dem Wachstum des Unternehmens werden diese Rollen typischerweise deutlicher und teilen sich sogar in Unterrollen... (Hier gibt es viel über die sich verändernde Natur von DevOps, den organisatorischen Einfluss von Mikrodiensten usw. zu sagen. Aber vorerst akzeptieren wir diese Beschreibungen als gegeben.)
Aus dieser Perspektive sind die offensichtlichen Begünstigten des Service Mesh die Plattformbesitzer. Letztendlich besteht das Ziel des Plattformteams darin, eine interne Plattform zu schaffen, auf der die Dienstbesitzer ihre Geschäftslogik implementieren können, und dies auf eine Weise, die ihnen maximale Unabhängigkeit von den düsteren Details ihrer Nutzung garantiert. Das Service Mesh bietet nicht nur die Möglichkeiten, die für das Erreichen dieses Ziels entscheidend sind: Es tut dies auf eine Weise, die wiederum keine Abhängigkeiten für die Dienstbesitzer schafft.
Die Dienstbesitzer profitieren ebenfalls, wenn auch auf eine indirektere Weise. Das Ziel eines Dienstbesitzers ist es, so produktiv wie möglich bei der Implementierung der Geschäftsprozesslogik zu sein, und je weniger er sich um Betriebsfragen kümmern muss, desto besser. Anstatt sich mit der Implementierung von beispielsweise Wiederholungsrichtlinien oder TLS zu beschäftigen, können sie sich ausschließlich auf geschäftliche Aufgaben konzentrieren und hoffen, dass die Plattform sich um alles andere kümmert. Das ist ein großer Vorteil für sie.
Den organisatorischen Wert dieser Trennung zwischen Plattform- und Dienstbesitzern kann man kaum überschätzen. Ich denke, dass es einen hauptsächlich Beitrag zum Wert des Service Mesh leistet.
Wir haben diese Lektion gelernt, als einer der ersten Anhänger von Linkerd uns erzählte, warum sie sich für das Service Mesh entschieden haben: weil es ihnen ermöglichte, „das Gerede auf ein Minimum zu reduzieren“. Hier sind einige Einzelheiten: Ein Team aus einem großen Unternehmen migrierte seine Plattform nach Kubernetes. Da die Anwendung mit sensiblen Informationen arbeitete, wollten sie alle Kommunikationen in den Clustern verschlüsseln. Die Situation wurde jedoch durch die Existenz von Hunderten von Diensten und Hunderten von Entwicklerteams kompliziert. Die Aussicht, sich mit allen in Verbindung zu setzen und zu überzeugen, TLS in ihre Pläne aufzunehmen, bereitete ihnen große Sorgen. Mit Linkerd übertrugen sie die Verantwortung von den Entwicklern (für die das eine zusätzliche Belastung war) auf die Plattformteams, für die dies eine höchste Priorität darstellte. Mit anderen Worten, Linkerd löste für sie weniger ein technisches, sondern vielmehr ein organisatorisches Problem.
Kurz gesagt, das Service Mesh ist eher eine Lösung für ein nicht-technisches, sondern eine soziotechnisches Problem. (Danke für die Einführung in diesen Begriff.)
Wird das Service Mesh all meine Probleme lösen?
Ja. Im Sinne von, nein!
Wenn man sich die drei oben genannten Funktionalitäten ansieht: Zuverlässigkeit, Sicherheit und Überwachbarkeit, wird klar, dass das Service-Mesh keine vollständige Lösung für eines dieser Probleme darstellt. Obwohl Linkerd erneute Anforderungen senden kann (wenn es weiß, dass diese idempotent sind), ist es nicht in der Lage zu entscheiden, was dem Nutzer zurückgegeben werden soll, wenn der Dienst endgültig ausgefallen ist – solche Entscheidungen muss die Anwendung treffen. Linkerd kann Statistiken über erfolgreiche Anfragen führen, aber es kann nicht in den Dienst schauen und dessen interne Metriken bereitstellen – solche Werkzeuge müssen in der Anwendung vorhanden sein. Und obwohl Linkerd mTLS organisieren kann, erfordert eine vollständige Sicherheitslösung wesentlich mehr.
Teilmengen von Funktionen in diesen Bereichen, die vom Service-Mesh angeboten werden, beziehen sich auf Plattform-Funktionen. Damit meine ich Funktionen, die:
- Unabhängig von der Geschäftslogik sind.Die Art und Weise, wie Histogramme von Aufrufen zwischen Foo und Bar erstellt werden, hängt völlig nicht davon ab, warum ob Foo Bar aufruft.
- Es ist schwierig, dies korrekt zu implementieren.In Linkerd werden erneute Versuche mit verschiedenen ausgeklügelten Mechanismen wie Retry Budgets parametrisiert, (Retry Budgets), da ein simpler Ansatz in der Implementierung solcher Dinge sicherlich zu einem sogenannten "Retry-Sturm" führen wird, (Retry-Sturm) und anderen Problemen, die für verteilte Systeme typisch sind.
- Sind am effektivsten, wenn sie einheitlich angewendet werden.Der TLS-Mechanismus hat nur dann Sinn, wenn er überall angewendet wird.
Da diese Funktionen auf Proxy-Ebene (und nicht auf Anwendungsebene) implementiert sind, bietet das Service-Mesh sie auf Ebene der der Plattform, und nicht auf Anwendungsebene. Daher ist es egal, in welcher Sprache die Dienste geschrieben sind, welches Framework sie verwenden, wer sie geschrieben hat und warum. Proxys arbeiten außerhalb all dieser Details, und die grundlegende Basis dieser Funktionalität, einschließlich der Aufgaben zu Konfiguration, Aktualisierung, Betrieb, Wartung usw., liegt ausschließlich auf der Plattformebene.
Beispiele für die Möglichkeiten eines Service-Mesh
Zusammenfassend möchte ich sagen, dass ein Service Mesh keine vollständige Lösung für Zuverlässigkeit, Beobachtbarkeit oder Sicherheit darstellt. Der Umfang dieser Bereiche erfordert die zwingende Beteiligung von Service-Eigentümern, Ops/SRE-Teams und anderen Akteuren des Unternehmens. Ein Service Mesh bietet lediglich einen «Schnitt» auf der Plattformebene für jeden dieser Bereiche.
Warum ist das Service Mesh gerade jetzt so populär geworden?
Wahrscheinlich fragen Sie sich gerade: In Ordnung, wenn das Service Mesh so gut ist, warum haben wir nicht vor etwa zehn Jahren Millionen von Proxys im Stack implementiert?
Es gibt eine banale Antwort auf diese Frage: Vor zehn Jahren hat jeder Monolithen aufgebaut, und das Service Mesh war für niemanden notwendig. Das ist wahr, aber meiner Meinung nach wird in dieser Antwort der Kern der Sache verfehlt. Selbst vor zehn Jahren wurde das Konzept der Microservices als vielversprechender Ansatz zur Erstellung großangelegter Systeme weit diskutiert und in Unternehmen wie Twitter, Facebook, Google und Netflix angewandt. Der allgemeine Konsens — zumindest in den Teilen der Branche, mit denen ich in Kontakt war — war, dass Microservices der «richtige Weg» sind, um große Systeme zu erstellen, auch wenn es verdammt schwierig war.
Natürlich gab es vor zehn Jahren Unternehmen, die Microservices einsetzten, aber sie platzierten nicht überall Proxys, um ein Service Mesh zu bilden. Wenn man jedoch genau hinsieht, machten sie etwas Ähnliches: In vielen dieser Unternehmen wurde vorgeschrieben, eine spezielle interne Bibliothek für die Netzwerkkommunikation zu verwenden (manchmal als dicke Clientbibliothek bezeichnet, fat client library).
Netflix hatte Hysterix, Google hatte Stubby, und Twitter hatte die Finagle-Bibliothek. Finagle war beispielsweise für jeden neuen Dienst bei Twitter obligatorisch. Sie verwaltete sowohl den Client- als auch den Serverteil der Verbindungen, ermöglichte Wiederholungsanfragen, unterstützte die Routenanfrage, Lastverteilung und Messungen. Sie bot eine konsistente Schicht für Zuverlässigkeit und Beobachtbarkeit über den gesamten Stack von Twitter, unabhängig davon, womit der Dienst beschäftigt war. Natürlich funktionierte sie nur für JVM-Sprachen und basierte auf dem Programmiermodell, das 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 eigentlich nur Finagle, verpackt in einer Proxy-Form.)
Vor zehn Jahren gab es also nicht nur Mikrodienste, sondern auch spezielle Proto-Service-Mesh-Bibliotheken, die dieselben Probleme lösten, die heute Service Mesh löst. Allerdings gab es zu dieser Zeit noch keinen Service Mesh. Es musste noch eine weitere Verschiebung stattfinden, bevor er erschien.
Und genau hier liegt die tiefere Antwort, die in einer anderen Veränderung verborgen ist, die in den letzten 10 Jahren stattfand: die Kosten für die Bereitstellung von Mikrodiensten sind stark gesunken. Die oben genannten Unternehmen, die vor zehn Jahren Mikrodienste verwendeten: Twitter, Netflix, Facebook, Google, waren Unternehmen von enormem Umfang und riesigen Ressourcen. Sie hatten nicht nur den Bedarf, sondern auch die Möglichkeit, große Anwendungen auf Basis von Mikrodiensten zu erstellen, bereitzustellen und zu betreiben. Die Energie und die Anstrengungen, die die Ingenieure von Twitter unternommen haben, um von einem monolithischen zu einem mikrodienstlichen Ansatz überzugehen, sind einfach beeindruckend. (Ehrlich gesagt, sowie die Tatsache, dass es gelungen ist.) Solche infrastrukturellen Manöver waren damals für kleinere Unternehmen unmöglich.
Lassen Sie uns in die Gegenwart springen. Heute gibt es Startups, bei denen das Verhältnis von Mikrodiensten zu Entwicklern 5:1 beträgt (oder sogar ), und darüber hinaus kommen sie damit erfolgreich zurecht! Wenn ein Startup mit 5 Personen problemlos 50 Mikrodienste betreiben kann, dann hat etwas eindeutig die Kosten für ihre Implementierung gesenkt.
1500 Mikrodienste bei Monzo; jede Zeile ist eine vorgeschriebene Netzwerkregel, die den Datenverkehr erlaubt.
Der dramatische Rückgang der Kosten für den Betrieb von Mikrodiensten ist das Ergebnis eines Prozesses: des Wachstums der Beliebtheit von Containern und von Orchestratoren. Dies ist die tiefere Antwort auf die Frage, was das Erscheinen von Service Mesh begünstigt hat. Dieselbe Technologie hat sowohl Service Mesh als auch Mikrodienste attraktiv gemacht: Kubernetes und Docker.
Warum? Nun, Docker löst ein großes Problem – das der Verpackung. Indem es eine Anwendung und ihre (nicht-netzwerkabhängigen) Laufzeitabhängigkeiten in einen Container packt, verwandelt Docker die Anwendung in eine austauschbare Einheit, die überall platziert und ausgeführt werden kann. Gleichzeitig vereinfacht es den Betrieb erheblich von Mehrsprachigkeit. Stack: Da der Container eine atomare Ausführungseinheit ist, spielt es für Bereitstellungs- und Betriebszwecke keine Rolle, was sich darin befindet, ob es sich um eine Anwendung auf JVM, Node, Go, Python oder Ruby handelt. Sie starten es einfach und das war's.
Kubernetes bringt alles auf eine neue Ebene. Nun, da es eine Vielzahl von "ausführbaren Objekten" und viele Maschinen gibt, auf denen man sie ausführen kann, entsteht der Bedarf an einem Tool, das diese zueinander in Beziehung setzen kann. Im weitesten Sinne geben Sie Kubernetes viele Container und viele Maschinen, und es verknüpft sie miteinander (natürlich ist dies ein dynamischer und ständig wechselnder Prozess: neue Container bewegen sich im System, Maschinen werden gestartet und gestoppt usw. Aber Kubernetes berücksichtigt all dies).
Nach der Einrichtung von Kubernetes sind die zeitlichen Aufwände für die Bereitstellung und den Betrieb eines Dienstes kaum von den Kosten für die Bereitstellung und den Betrieb von zehn Diensten zu unterscheiden (tatsächlich sind sie praktisch ähnlich für 100 Dienste). Fügen Sie dies 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 sich das Service Mesh so gut eignet.
Also sind wir zu der Antwort auf die Frage gekommen, warum die Idee des Service Mesh gerade jetzt populär geworden ist: Die Homogenität, die Kubernetes für Dienste bietet, ist direkt auf die Betriebsausforderungen anwendbar, die dem Service Mesh gegenüberstehen. Sie verpacken die Proxys in Container, geben Kubernetes die Aufgabe, sie wo immer möglich anzubringen, und voilà! Am Ende erhalten Sie ein Service Mesh, wobei Kubernetes die gesamte Mechanik der Bereitstellung steuert. (Zumindest aus der Vogelperspektive. Natürlich gibt es in diesem Prozess viele Nuancen.)
Zusammenfassend lässt sich sagen: Der Grund, warum Service Mesh gerade jetzt populär geworden ist und nicht vor zehn Jahren, liegt darin, dass Kubernetes und Docker nicht nur erheblich den Bedarf danach erhöht haben, indem sie die Implementierung von Anwendungen als Sets mehrsprachiger Mikrodienste erleichtert haben, sondern auch die Kosten für ihren Betrieb erheblich gesenkt haben, indem sie Mechanismen für die Bereitstellung und Wartung von Sidecar-Proxys bereitgestellt haben.
Warum gibt es so viele Gespräche über Service Mesh?
Warnung: In diesem Abschnitt greife ich auf alle Arten von Annahmen, Vermutungen, Überlegungen und Insider-Informationen zurück.
Wenn Sie nach dem Begriff „Service Mesh“ suchen, stoßen Sie auf eine Menge überarbeiteter, kalorienarmer Inhalte, seltsamer Projekte und eines Kaleidoskops an Verzerrungen, das einer Echokammer würdig ist. Solch ein Phänomen begegnet jeder angesagten neuen Technologie, aber im Fall von Service Mesh ist das Problem besonders ausgeprägt. Warum?
Nun, teilweise ist das meine Schuld. Ich habe mein Bestes gegeben, um Linkerd und Service Mesh bei jeder sich bietenden Gelegenheit voranzubringen, durch unzählige Blogbeiträge und Artikel wie diesen. Aber ich bin nicht so mächtig. Um diese Frage wirklich zu beantworten, müssen wir ein wenig über die allgemeine Situation sprechen. Und darüber kann man nicht reden, ohne ein Projekt zu erwähnen: — ein Open-Source-Service-Mesh, das gemeinsam von Google, IBM und Lyft entwickelt wird.
(Diese drei Unternehmen spielen ganz unterschiedliche Rollen: Das Engagement von Lyft scheint sich auf den Namen zu beschränken; sie sind die Autoren von Envoy, nutzen aber 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 aber, soweit ich beurteilen kann, tatsächlich nicht.)
Das Istio-Projekt zeichnet sich durch zwei Merkmale aus. Erstens durch die enormen Marketinganstrengungen, die insbesondere Google unternimmt, um es zu bewerben. Schätzungen zufolge haben die meisten Menschen, die heutzutage mit dem Konzept des Service Mesh vertraut sind, zum ersten Mal durch Istio davon erfahren. Das zweite Merkmal ist, wie schlecht Istio aufgenommen wurde. In dieser Hinsicht bin ich natürlich befangen, aber während ich versuche, so objektiv wie möglich zu bleiben, kann ich trotzdem nicht anders , was nicht sehr charakteristisch ist (obwohl nicht einzigartig: ein Beispiel wäre systemd, …) für ein Open-Source-Projekt.
(In der Praxis hat Istio anscheinend Probleme nicht nur mit der Komplexität und UX, sondern auch mit der Leistung. Beispielsweise entdeckten Spezialisten während der , die von einem Dritten durchgeführt wurde, Situationen, in denen die Schwanzlatenzen (tail latency) von Istio 100-mal höher waren als die entsprechenden Werte von Linkerd, sowie Situationen mit Ressourcenmangel, in denen Linkerd weiterhin erfolgreich funktionierte, während Istio komplett ausfiel.)
Wenn ich meine Theorien darüber, warum das so passiert ist, beiseite lasse, glaube ich, dass der übermäßige Hype um das Service Mesh gerade durch Googles Engagement erklärt wird. Genauer gesagt, durch die Kombination der folgenden drei Faktoren:
- die aufdringliche Förderung von Istio durch Google;
- die entsprechende ablehnende, kritische Haltung gegenüber dem Projekt;
- der kürzliche rasante Anstieg der Popularität von Kubernetes, dessen Erinnerungen noch frisch sind.
Diese Faktoren vereinen sich zu einer gewissen berauschenden, sauerstoffarmen Umgebung, in der die Fähigkeit zum rationalen Urteilen schwächer wird und nur eine wunderbare Art von .
Aus der Sicht von Linkerd würde ich das als ein zwiespältiges Gut beschreiben. Ich meine, es ist großartig, dass das Service Mesh in den Mainstream eingezogen ist – was 2016 nicht der Fall war, als Linkerd gerade aufkam und es wirklich schwierig war, die Aufmerksamkeit der Umgebung auf das Projekt zu lenken. Jetzt gibt es dieses Problem nicht mehr! Aber schlecht ist, dass die Situation mit dem Service Mesh heute so verworren ist, dass es praktisch unmöglich ist, zu verstehen, welche Projekte wirklich zur Kategorie Service Mesh gehören (geschweige denn zu verstehen, welches davon am besten für einen bestimmten Anwendungsfall geeignet ist). Das behindert definitiv alle (und in bestimmten Fällen eignet sich Istio oder ein anderes Projekt vielleicht besser als Linkerd, da letzteres schließlich keine universelle Lösung ist).
Von Seiten Linkerd bestand unsere Strategie darin, den Lärm zu ignorieren, weiterhin auf die Lösung echter Problems des Bereichs zu konzentrieren und im Grunde darauf zu warten, dass der Hype nachlässt. Letztendlich wird der Hype abnehmen und wir können weiterhin in Ruhe arbeiten.
Bis dahin müssen wir alle ein wenig Geduld haben.
Wird mir, einem bescheidenen Software-Ingenieur, das Service Mesh nützlich sein?
Bei der Beantwortung dieser Frage wird uns der folgende Fragebogen helfen:
Arbeiten Sie ausschließlich an der Implementierung von Geschäftslogik? In diesem Fall wird Ihnen das Service Mesh nicht nützen. Das heißt, Sie können sich natürlich dafür interessieren, aber idealerweise sollte das Service Mesh keinen direkten Einfluss auf irgendetwas in Ihrer Umgebung haben. Arbeiten Sie weiterhin an dem, wofür Sie bezahlt werden.
Unterstützen Sie eine Plattform in einem Unternehmen, das 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 Batch-Verarbeitung — 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 geschrieben wurden. Sie alle interagieren miteinander und sind zu einem Geflecht von Laufzeitabhängigkeiten verbunden, und Sie müssen einen Weg finden, damit umzugehen. Die Verwendung von Kubernetes ermöglicht es Ihnen, ein Service-Mesh "auf Ihre Bedürfnisse zugeschnitten" auszuwählen. Informieren Sie sich über ihre Möglichkeiten und Besonderheiten und beantworten Sie die Frage, ob Ihnen überhaupt ein Projekt aus den vorhandenen zur Verfügung steht (ich empfehle, mit Linkerd zu beginnen).
Verwalten Sie die Plattform in einem Unternehmen, das KEIN Kubernetes verwendet, aber Mikrodienste nutzt? In diesem Fall könnte Ihnen ein Service-Mesh nützlich sein, jedoch wird die Nutzung nicht trivial sein. Natürlich können Sie nachahmen die Funktionalität eines Service-Mesh, indem Sie viele Proxys einrichten, aber ein wichtiges Merkmal von Kubernetes ist das Bereitstellungsmodell: Die manuelle Wartung dieser Proxys erfordert wesentlich mehr Zeit, Mühe 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 Ansammlungen von Monolithen) arbeiten, die klar definierte und selten ändernde Interaktionsmuster haben, kann ein Service-Mesh Ihnen wenig bieten. Sie können es also einfach ignorieren und hoffen, dass es wie ein böser Traum verschwindet...
Fazit
Wahrscheinlich ist es doch nicht angebracht, das Service-Mesh als „die hype-trächtigste Technologie der Welt“ zu bezeichnen — diese fragwürdige Ehre gehört wahrscheinlich Bitcoin oder KI. Möglicherweise gehört es zu den Top Fünf. Doch wenn man durch die Schichten von Lärm und Gedöns bricht, wird klar, dass das Service-Mesh echten Nutzen für diejenigen bringt, die Anwendungen in Kubernetes entwickeln.
Ich würde Sie bitten, Linkerd auszuprobieren — die Installation in einem Kubernetes-Cluster (oder sogar in Minikube auf einem Laptop) , und Sie werden selbst sehen können, wovon ich spreche.
FAQ
— Wenn ich das Service-Mesh ignoriere, wird es verschwinden?
— Ich muss Sie enttäuschen: Das Service-Mesh ist für lange Zeit bei uns.
— Aber ich WILL kein Service-Mesh verwenden!
— Dann tun Sie es nicht! Lesen Sie einfach meinen Fragebogen oben, um zu verstehen, ob es sinnvoll ist, sich zumindest mit den Grundzügen vertraut zu machen.
— Ist das nicht das gute alte ESB/Middleware, nur unter einem neuen Namen?
— Service Mesh kümmert sich um die operationale Logik und nicht um die semantische. des Enterprise Service Bus (). Die Beibehaltung dieser Trennung hilft dem Service Mesh, dem gleichen Schicksal zu entkommen.
— Wie unterscheidet sich das Service Mesh von API-Gateways?
— Es gibt Millionen von Artikeln zu diesem Thema. Einfach googeln.
— Ist Envoy ein Service Mesh?
— Nein, Envoy ist kein Service Mesh, sondern ein Proxy-Server. Man kann ihn verwenden, um ein Service Mesh (und vieles mehr — es ist ein universeller Proxy) zu organisieren. Aber er ist für sich genommen kein Service Mesh.
— Ist Network Service Mesh ein Service Mesh?
— Nein. Trotz des Namens ist es kein Service Mesh (was für ein Marketingwunder!).
— Hilft mir ein Service Mesh mit meinem reaktiven, asynchronen System auf Basis von Nachrichtenwarteschlangen?
— Nein, ein Service Mesh wird Ihnen nicht helfen.
— Welches Service Mesh soll ich verwenden?
— , das ist offensichtlich.
— Der Artikel ist Müll! / Der Autor gehört bestraft!
— Bitte teilen Sie den Link mit all Ihren Freunden, damit sie sich davon überzeugen können!
Dank
Wie Sie am Titel erkennen können, wurde dieser Artikel von dem fantastischen Traktat von Jay Kreps „“ inspiriert. Ich habe Jay vor zehn Jahren getroffen, als ich ein Interview bei LinkedIn führte, und seitdem ist er eine Inspirationsquelle für mich.
Obwohl ich mich gerne als „Linkerd-Entwickler“ bezeichne, ist die Realität, dass ich eher der Maintainer der Datei README.md im Projekt bin. An Linkerd arbeiten heute , , Menschen, und dieses Projekt wäre ohne die Beiträge einer großartigen Gemeinschaft von Mitwirkenden und Nutzern nicht möglich gewesen.
Und abschließend ein besonderer Dank an den Schöpfer von Linkerd, (primus inter pares), der zusammen mit mir vor vielen Jahren kopfüber in das ganze Geschäfte mit dem Service Mesh eingetaucht ist.
P.S. vom Übersetzer
Lesen Sie auch in unserem Blog:
- «»;
- «»;
- «»;
- «»;
- «».
Quelle: habr.com
