Notiz. übersetzen: Service Mesh ist ein Phänomen, für das es noch keine stabile Übersetzung ins Russische gibt (vor mehr als zwei Jahren haben wir die Option „Mesh for Services“ vorgeschlagen, und wenig später begannen einige Kollegen, die Kombination „Service Sieve“ aktiv zu fördern). Das ständige Gerede über diese Technologie hat dazu geführt, dass die Marketing- und Technikkomponenten zu eng miteinander verflochten sind. Dieses wunderbare Material von einem der Autoren des ursprünglichen Begriffs soll Ingenieuren und anderen Klarheit schaffen.
Comic von
Einführung
Wenn Sie als Softwareentwickler irgendwo im Backend-Systembereich arbeiten, hat sich der Begriff „Service Mesh“ in den letzten Jahren wahrscheinlich bereits fest in Ihrem Gedächtnis verankert. Dank eines seltsamen Zufalls erobert dieser Satz die Branche immer mehr und der damit verbundene Hype und die Werbeangebote wachsen wie ein Schneeball, der bergab fliegt und keine Anzeichen einer Verlangsamung zeigt.
Service Mesh wurde in den trüben, voreingenommenen Gewässern des cloudnativen Ökosystems geboren. Leider bedeutet dies, dass ein Großteil der Kontroversen darüber von „kalorienarmem Gerede“ bis hin zu – um einen Fachbegriff zu verwenden – völligem Unsinn reicht. Aber wenn Sie all das Gerede durchgehen, werden Sie feststellen, dass das Service-Mesh eine sehr reale, definierte und wichtige Funktion hat.
In diesem Beitrag werde ich genau das versuchen: einen ehrlichen, ausführlichen und ingenieurorientierten Leitfaden für Service Mesh bereitzustellen. Ich werde nicht nur die Frage beantworten: "Was ist das?", - aber auch "Wozu?", und auch "Warum jetzt?". Abschließend versuche ich darzulegen, warum (meiner Meinung nach) diese spezielle Technologie so viel Aufsehen erregt hat, was an sich schon eine interessante Geschichte ist.
Wer bin ich?
Hallo an alle! Ich heiße . Ich bin einer der Schöpfer – das allererste Service-Mesh-Projekt und das Projekt, das für das Auftauchen des Begriffs verantwortlich ist Service-Mesh als solches (sorry Leute!). (Anmerkung übersetzt.: Übrigens haben wir bereits zu Beginn des Erscheinens dieses Begriffs, vor mehr als 2,5 Jahren, das frühe Material desselben Autors mit dem Titel „. ") Ich gehe auch ist ein Startup, das coole Service-Mesh-Dinge wie Linkerd und erstellt .
Sie können sich wahrscheinlich vorstellen, dass ich zu diesem Thema eine sehr voreingenommene und subjektive Meinung habe. Ich werde jedoch versuchen, die Voreingenommenheit auf ein Minimum zu beschränken (mit Ausnahme eines Abschnitts: „Warum wird so viel über Service Mesh geredet?“, - in dem ich noch meine vorgefassten Meinungen mitteilen werde). Ich werde auch mein Bestes tun, um diesen Leitfaden so objektiv wie möglich zu gestalten. Für konkrete Beispiele verlasse ich mich in erster Linie auf die Erfahrung von Linkerd und weise auf die mir bekannten Unterschiede (falls vorhanden) bei der Implementierung anderer Service-Mesh-Typen hin.
Okay, es ist Zeit, zu den Leckereien überzugehen.
Was ist ein Service Mesh?
Trotz allem Hype ist der Aufbau des Service Mesh recht einfach. Hierbei handelt es sich lediglich um eine Reihe von Userspace-Proxys, die sich „neben“ den Diensten befinden (wir werden später ein wenig darüber sprechen, was „nächster“ ist) sowie eine Reihe von Kontrollprozessen. Die Proxys werden gemeinsam aufgerufen Datenebene, und die Kontrollprozesse werden aufgerufen Steuerebene. Die Datenebene fängt Anrufe zwischen Diensten ab und macht „alle möglichen Dinge“ mit ihnen; Die Kontrollebene koordiniert dementsprechend das Verhalten des Proxys und stellt Ihnen den Zugriff bereit, d. h. Operator an die API weiter, sodass das Netzwerk als Ganzes manipuliert und gemessen werden kann.
Was ist das für ein Proxy? Dies ist ein Layer-7-fähiger TCP-Proxy (also „Berücksichtigung“ der Schicht 7 des OSI-Modells) wie HAProxy und NGINX. Sie können einen Proxy nach Ihren Wünschen auswählen. Linkerd verwendet einen einfach benannten Rust-Proxy . Wir haben es speziell für Service Mesh zusammengestellt. Andere Meshes bevorzugen andere Proxys (Envoy ist eine häufige Wahl). Allerdings ist die Wahl eines Proxys nur eine Frage der Umsetzung.
Was machen diese Proxyserver? Offensichtlich leiten sie Anrufe von und zu Diensten weiter (streng genommen fungieren sie als Proxys und Reverse-Proxys und verarbeiten sowohl eingehende als auch ausgehende Anrufe). Und sie implementieren einen Funktionsumfang, der sich auf Anrufe konzentriert между Dienstleistungen. Dieser Fokus auf den Datenverkehr zwischen Diensten unterscheidet einen Service-Mesh-Proxy beispielsweise von API-Gateways oder Ingress-Proxys (letztere konzentrieren sich auf Anrufe, die von der Außenwelt in den Cluster kommen). (Notiz. übersetzen: Einen Vergleich bestehender Ingress-Controller für Kubernetes, von denen viele den bereits erwähnten Envoy verwenden, finden Sie unter .)
Wir haben also die Datenebene geklärt. Die Steuerungsebene ist einfacher: Es handelt sich um eine Reihe von Komponenten, die alle Mechanismen bereitstellen, die die Datenebene für einen koordinierten Betrieb benötigt, einschließlich Diensterkennung, Ausstellung von TLS-Zertifikaten, Metrikaggregation usw. Die Datenebene informiert die Steuerungsebene darüber sein Verhalten; Im Gegenzug stellt die Steuerebene eine API bereit, mit der Sie das Verhalten der Datenebene als Ganzes ändern und überwachen können.
Unten finden Sie ein Diagramm der Steuerebene und der Datenebene in Linkerd. Wie Sie sehen können, umfasst die Steuerungsebene mehrere verschiedene Komponenten, darunter eine Prometheus-Instanz, die Metriken von Proxyservern sammelt, sowie andere Komponenten wie z destination (Diensterkennung), identity (Zertifizierungsstelle, CA) und public-api (Endpunkte für Web und CLI). Im Gegensatz dazu ist die Datenebene ein einfacher Linker-Proxy neben der Anwendungsinstanz. Dies ist nur ein Logikdiagramm; In einer realen Bereitstellung verfügen Sie möglicherweise über drei Replikate jeder Komponente der Steuerungsebene und Hunderte oder Tausende von Proxys auf der Datenebene.
(Die blauen Rechtecke in diesem Diagramm symbolisieren die Grenzen von Kubernetes-Pods. Sie können sehen, dass sich die Container mit Linkerd-Proxy im selben Pod wie die Anwendungscontainer befinden. Dieses Schema wird als bezeichnet Beiwagencontainer.)
Die Service-Mesh-Architektur hat mehrere wichtige Auswirkungen. Erstens: Da die Aufgabe eines Proxys darin besteht, Anrufe zwischen Diensten abzufangen, ist ein Service-Mesh nur dann sinnvoll, wenn Ihre Anwendung für einen bestimmten Satz von Diensten erstellt wurde. Gittergewebe kann man Verwendung mit Monolithen, aber dies ist im Interesse eines einzelnen Proxys eindeutig überflüssig und seine Funktionalität wird wahrscheinlich nicht gefragt sein.
Eine weitere wichtige Konsequenz ist, dass das Service-Mesh benötigt wird enorm Anzahl der Proxys. Tatsächlich fügt Linkerd einen Linkerd-Proxy an jede Instanz jedes Dienstes an (andere Implementierungen fügen jedem Knoten/Host/jeder virtuellen Maschine einen Proxy hinzu. Das ist sowieso viel). Eine solche aktive Nutzung von Proxys bringt an sich eine Reihe zusätzlicher Komplikationen mit sich:
- Proxys in der Datenebene müssen vorhanden sein schnell, da für jeden Aufruf mehrere Aufrufe an den Proxy erfolgen: einer auf der Clientseite, einer auf der Serverseite.
- Auch Proxys sollten vorhanden sein klein и Leicht. Jeder verbraucht Speicher- und CPU-Ressourcen, und dieser Verbrauch wächst linear mit der Anwendung.
- Sie benötigen einen Mechanismus zum Bereitstellen und Aktualisieren einer großen Anzahl von Proxys. Es ist keine Option, dies manuell zu tun.
Im Allgemeinen sieht ein Service Mesh so aus (zumindest aus der Vogelperspektive): Sie stellen eine Reihe von Userspace-Proxys bereit, die mit dem internen, dienstübergreifenden Datenverkehr „etwas tun“, und verwenden eine Steuerungsebene, um sie zu überwachen und zu verwalten.
Jetzt ist es an der Zeit, die Frage „Warum?“ zu stellen.
Wozu dient ein Service Mesh?
Wer zum ersten Mal mit der Idee eines Service-Meshs in Berührung kam, war vielleicht etwas ängstlich. Das Service-Mesh-Design bedeutet, dass es nicht nur die Latenz in der Anwendung erhöht, sondern auch zu konsumieren Ressourcen und werde hinzufügen eine Reihe neuer Mechanismen in der Infrastruktur. Zuerst richten Sie ein Service-Mesh ein und plötzlich müssen Sie Hunderte (wenn nicht Tausende) von Proxys bedienen. Die Frage ist: Wer wird das freiwillig tun?
Die Antwort auf diese Frage besteht aus zwei Teilen. Erstens können die mit der Bereitstellung dieser Proxys verbundenen Transaktionskosten dank einiger Änderungen im Ökosystem erheblich gesenkt werden (mehr dazu später).
Zweitens ist ein Gerät wie dieses tatsächlich eine großartige Möglichkeit, zusätzliche Logik in das System einzuführen. Nicht nur, weil ein Service Mesh viele neue Funktionen hinzufügen kann, sondern auch, weil dies ohne Eingriff in das Ökosystem möglich ist. Tatsächlich basiert das gesamte Service-Mesh-Modell auf dieser Prämisse: In einem Multiservice-System, egal was passiert machen Einzelleistungen, Verkehr zwischen ihnen ist der ideale Punkt, um Funktionalität hinzuzufügen.
Beispielsweise konzentriert sich die Funktionalität in Linkerd (wie in den meisten Meshes) hauptsächlich auf HTTP-Aufrufe, einschließlich HTTP/2 und gRPC*. Die Funktionalität ist recht umfangreich – sie lässt sich in drei Klassen einteilen:
- Funktionen im Zusammenhang mit Zuverlässigkeit. Wiederholte Anfragen, Zeitüberschreitungen, Canary-Ansatz (Verkehrsaufteilung/-umleitung) usw.
- Funktionen im Zusammenhang mit Überwachung. Aggregation von Erfolgsquoten, Verzögerungen und Anfragevolumen für jeden Dienst oder einzelne Richtungen; Erstellung topologischer Karten von Diensten usw.
- Funktionen im Zusammenhang mit Sicherheit. Gegenseitiges TLS, Zugriffskontrolle usw.
* Aus der Sicht von Linkerd unterscheidet sich gRPC praktisch nicht von HTTP/2: Es verwendet lediglich Protobuf in der Nutzlast. Aus Entwicklersicht sind die beiden Dinge natürlich unterschiedlich.
Viele dieser Mechanismen funktionieren auf Anforderungsebene (daher der „L7-Proxy“). Wenn der Foo-Dienst beispielsweise einen HTTP-Aufruf an den Bar-Dienst tätigt, kann der Linkerd-Proxy auf der Foo-Seite einen intelligenten Lastausgleich durchführen und Anrufe von Foo an Bar-Instanzen basierend auf der beobachteten Latenz weiterleiten; es kann die Anfrage bei Bedarf wiederholen (und wenn es idempotent ist); Es kann den Antwortcode und das Timeout usw. aufzeichnen. Ebenso kann der Linker-Proxy auf der Bar-Seite eine Anfrage ablehnen, wenn sie nicht zulässig ist oder das Anfragelimit überschritten wird; kann eine Verzögerung seinerseits usw. verzeichnen.
Proxys können auch auf Verbindungsebene „etwas tun“. Beispielsweise kann der Linkerd-Proxy auf der Foo-Seite eine TLS-Verbindung initiieren und der Linkerd-Proxy auf der Bar-Seite sie beenden, und beide Seiten können die TLS-Zertifikate des anderen überprüfen*. Dies bietet nicht nur eine Verschlüsselung zwischen Diensten, sondern auch eine kryptografisch sichere Möglichkeit, Dienste zu identifizieren: Foo und Bar können „beweisen“, dass sie die sind, für die sie sich ausgeben.
* „Gegenseitig von einem Freund“ bedeutet, dass auch das Client-Zertifikat überprüft wird (gegenseitiges TLS). Bei „klassischem“ TLS, beispielsweise zwischen einem Browser und einem Server, wird in der Regel nur das Zertifikat einer Seite (des Servers) überprüft.
Unabhängig davon, ob sie auf Anforderungs- oder Verbindungsebene arbeiten, ist es wichtig zu betonen, dass alle Service-Mesh-Funktionen dies tun betriebsbereit Charakter. Linkerd ist nicht in der Lage, die Semantik der Nutzlast zu transformieren – beispielsweise durch das Hinzufügen von Feldern zu einem JSON-Fragment oder das Vornehmen von Änderungen an Protobuf. Wir werden später auf diese wichtige Funktion eingehen, wenn wir über ESB und Middleware sprechen.
Dabei handelt es sich um die Funktionen, die ein Service Mesh bietet. Es stellt sich die Frage: Warum diese nicht direkt in der Anwendung implementieren? Und warum sollte man sich überhaupt mit einem Proxy herumschlagen?
Warum Service Mesh eine gute Idee ist
Auch wenn die Fähigkeiten eines Service Mesh spannend sind, liegt sein Kernwert nicht wirklich in seinen Funktionen. Am Ende wir kann Implementieren Sie sie direkt in der Anwendung (wir werden später sehen, dass dies der Ursprung des Service Mesh war). Um es in einem Satz zusammenzufassen: Der Wert eines Service Mesh ist: Es bietet Funktionen, die für die konsistente Ausführung moderner Serversoftware im gesamten Stack und unabhängig vom Anwendungscode von entscheidender Bedeutung sind.
Lassen Sie uns diesen Vorschlag analysieren.
«Funktionen, die für die Ausführung moderner Serversoftware von entscheidender Bedeutung sind" Wenn Sie eine Transaktionsserveranwendung erstellen, die mit dem öffentlichen Internet verbunden ist, Anfragen von der Außenwelt annimmt und innerhalb kurzer Zeit darauf reagiert – zum Beispiel eine Webanwendung, einen API-Server und die überwiegende Mehrheit anderer moderner Anwendungen - und wenn Sie es als eine Reihe von Diensten implementieren, die synchron miteinander interagieren, und wenn Sie diese Software ständig aktualisieren, neue Funktionen hinzufügen und wenn Sie gezwungen sind, dieses System während des Änderungsprozesses funktionsfähig zu halten - in diesem Fall Herzlichen Glückwunsch, Sie erstellen moderne Serversoftware. Und all diese oben aufgeführten großartigen Funktionen erweisen sich tatsächlich als entscheidend für Sie. Die Anwendung muss zuverlässig und sicher sein und Sie müssen beobachten können, was sie tut. Genau diese Fragen hilft Service Mesh bei der Lösung.
(Okay, der vorherige Absatz enthält immer noch meine Überzeugung, dass dieser Ansatz die moderne Art ist, Serversoftware zu erstellen. Andere ziehen es vor, Monolithen, „reaktive Microservices“ und andere Dinge zu entwickeln, die nicht unter die oben angegebene Definition fallen. Diese Leute haben wahrscheinlich ihre Die Meinung ist eine andere als meine. Ich wiederum denke, dass sie „falsch“ sind (obwohl das Service-Mesh für sie ohnehin nicht sehr nützlich ist).
«Einheitlich für den gesamten Stapel" Die von einem Service Mesh bereitgestellte Funktionalität ist nicht nur geschäftskritisch. Sie gelten für alle Dienste in der Anwendung, unabhängig davon, in welcher Sprache sie geschrieben sind, welches Framework sie verwenden, wer sie geschrieben hat, wie sie bereitgestellt wurden und alle anderen Feinheiten ihrer Entwicklung und Verwendung.
«Unabhängig vom Anwendungscode" Schließlich bietet ein Service Mesh nicht nur konsistente Funktionalität über den gesamten Stack hinweg, sondern auch auf eine Weise, die keine Bearbeitung der Anwendung erfordert. Die grundlegende Basis der Service-Mesh-Funktionalität, einschließlich Aufgaben für Konfiguration, Aktualisierung, Betrieb, Wartung usw., liegt vollständig auf Plattformebene und ist unabhängig von der Anwendung. Die Anwendung kann sich ändern, ohne dass sich dies auf das Service Mesh auswirkt. Das Service-Mesh wiederum kann sich ohne Beteiligung der Anwendung ändern.
Kurz gesagt: Ein Service Mesh stellt nicht nur wichtige Funktionen bereit, sondern tut dies auch auf globale, einheitliche und anwendungsunabhängige Weise. Obwohl die Service-Mesh-Funktionalität in Service-Code implementiert werden kann (z. B. als in jedem Dienst enthaltene Bibliothek), bietet dieser Ansatz nicht die Einheitlichkeit und Unabhängigkeit, die im Fall eines Service-Mesh so wertvoll ist.
Und alles, was Sie tun müssen, ist eine Reihe von Proxys hinzuzufügen! Ich verspreche, dass wir uns bald mit den Betriebskosten befassen werden, die mit dem Hinzufügen dieser Proxys verbunden sind. Aber lassen Sie uns zunächst innehalten und diese Idee der Unabhängigkeit aus verschiedenen Perspektiven betrachten. Menschen.
Wem hilft Service Mesh?
So unbequem es auch sein mag: Damit eine Technologie ein wichtiger Teil des Ökosystems wird, muss sie von den Menschen akzeptiert werden. Wer interessiert sich also für Service Mesh? Wer profitiert von der Nutzung?
Wenn Sie moderne Serversoftware entwickeln, können Sie sich Ihr Team grob als Gruppe vorstellen Dienstinhaberdie gemeinsam Geschäftslogiken entwickeln und umsetzen, und Plattformbesitzer, Entwicklung der internen Plattform, auf der diese Dienste betrieben werden. In kleinen Organisationen sind dies möglicherweise dieselben Personen, aber wenn das Unternehmen wächst, neigen diese Rollen dazu, stärker ausgeprägt zu sein und sogar in Unterrollen aufgeteilt zu werden ... (Hier gibt es viel zu sagen über die sich verändernde Natur von Entwicklern, die organisatorischen Auswirkungen von Microservices usw.) n. Aber nehmen wir diese Beschreibungen zunächst als gegeben an).
Aus dieser Sicht sind die Plattformeigentümer die klaren Nutznießer des Service Mesh. Letztendlich besteht das Ziel des Plattformteams darin, eine interne Plattform zu schaffen, auf der Serviceeigentümer die Geschäftslogik so implementieren können, dass sie möglichst unabhängig von den unklaren Details ihres Betriebs sind. Ein Service-Mesh bietet nicht nur Funktionen, die für die Erreichung dieses Ziels von entscheidender Bedeutung sind, sondern tut dies auch auf eine Art und Weise, die wiederum keine Abhängigkeiten von den Service-Eigentümern mit sich bringt.
Auch Serviceeigentümer profitieren, wenn auch auf indirektere Weise. Das Ziel des Service-Eigentümers besteht darin, die Logik des Geschäftsprozesses so produktiv wie möglich umzusetzen. Je weniger er sich um betriebliche Probleme kümmern muss, desto besser. Anstatt sich beispielsweise mit der Implementierung von Wiederholungsrichtlinien oder TLS befassen zu müssen, können sie sich ausschließlich auf Geschäftsziele konzentrieren und hoffen, dass die Plattform den Rest erledigt. Für sie ist das ein großer Vorteil.
Der organisatorische Wert einer solchen Trennung zwischen den Eigentümern von Plattformen und Diensten kann nicht hoch genug eingeschätzt werden. Ich denke, sie trägt dazu bei основной Beitrag zum Wert des Service Mesh.
Diese Lektion haben wir gelernt, als uns ein früher Linkerd-Fan erzählte, warum sie sich für Service Mesh entschieden haben: weil es ihnen ermöglichte, „die Diskussionen auf ein Minimum zu beschränken“. Hier einige Details: Die Mitarbeiter eines großen Unternehmens haben ihre Plattform auf Kubernetes migriert. Da die Anwendung vertrauliche Informationen verarbeitete, wollte man die gesamte Kommunikation zwischen den Clustern verschlüsseln. Die Situation wurde jedoch durch die Anwesenheit von Hunderten von Diensten und Hunderten von Entwicklungsteams erschwert. Die Aussicht, alle zu kontaktieren und davon zu überzeugen, die TLS-Unterstützung in ihre Pläne einzubeziehen, machte sie überhaupt nicht glücklich. Nach der Installation von Linkerd erfolgten die Übertragungen Verantwortung von Entwicklern (aus deren Sicht war das unnötiger Ärger) bis hin zu Plattformspielern, für die dies oberste Priorität hatte. 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, keine technische, sondern soziotechnisch Probleme. (Danke für die Einführung dieses Begriffs.)
Wird ein Service Mesh alle meine Probleme lösen?
Ja. Ich meine nein!
Wenn Sie sich die drei oben beschriebenen Funktionsklassen ansehen – Zuverlässigkeit, Sicherheit und Beobachtbarkeit – wird deutlich, dass ein Service Mesh keine vollständige Lösung für eines dieser Probleme darstellt. Während Linkerd Anfragen erneut ausgeben kann (wenn es weiß, dass sie idempotent sind), ist es nicht in der Lage, Entscheidungen darüber zu treffen, was an den Benutzer zurückgegeben werden soll, wenn der Dienst dauerhaft ausgefallen ist – diese Entscheidungen müssen von der Anwendung getroffen werden. Linkerd kann Statistiken über erfolgreiche Anfragen führen, ist jedoch nicht in der Lage, den Dienst zu untersuchen und seine internen Metriken bereitzustellen – die Anwendung muss über solche Tools verfügen. Und obwohl Linkerd in der Lage ist, mTLS zu organisieren, erfordern vollwertige Sicherheitslösungen viel mehr.
Eine Teilmenge der vom Service Mesh angebotenen Funktionen in diesen Bereichen bezieht sich auf Plattformfunktionen. Damit meine ich Funktionen, die:
- Unabhängig von der Geschäftslogik. Die Art und Weise, wie Anrufhistogramme zwischen Foo und Bar erstellt werden, ist völlig unabhängig von warum Foo ruft Bar an.
- Schwierig, es richtig umzusetzen. In Linkerd werden Wiederholungsversuche mit allen möglichen ausgefallenen Dingen wie Wiederholungsbudgets parametrisiert (Budgets erneut versuchen), denn ein unkomplizierter, frontaler Ansatz zur Umsetzung solcher Dinge wird sicherlich zur Entstehung einer sogenannten „Lawine von Anfragen“ führen. (Sturm erneut versuchen) und andere Probleme, die für verteilte Systeme charakteristisch sind.
- Am wirksamsten bei gleichmäßiger Anwendung. Der TLS-Mechanismus macht nur dann Sinn, wenn er überall angewendet wird.
Da diese Funktionen auf der Proxy-Ebene (und nicht auf der Anwendungsebene) implementiert werden, stellt das Service Mesh sie auf der Ebene bereit Plattform, keine Anwendungen. Daher spielt es keine Rolle, 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 Grundlage dieser Funktionalität, einschließlich Aufgaben für Konfiguration, Aktualisierung, Betrieb, Wartung usw., liegt ausschließlich auf der Plattformebene.
Beispiele für Service-Mesh-Funktionen
Zusammenfassend lässt sich sagen, dass ein Service Mesh keine vollständige Lösung für Zuverlässigkeit, Beobachtbarkeit oder Sicherheit ist. Der Umfang dieser Bereiche erfordert die Beteiligung von Serviceeigentümern, Ops/SRE-Teams und anderen Unternehmenseinheiten. Das Service Mesh stellt für jeden dieser Bereiche nur einen „Slice“ auf Plattformebene bereit.
Warum ist Service Mesh gerade jetzt beliebt?
Inzwischen fragen Sie sich wahrscheinlich: Ok, wenn das Service Mesh so gut ist, warum haben wir dann nicht schon vor zehn Jahren damit begonnen, Millionen von Proxys im Stack bereitzustellen?
Auf diese Frage gibt es eine banale Antwort: Vor zehn Jahren baute jeder Monolithen, und niemand brauchte ein Servicenetz. Das stimmt, aber meiner Meinung nach geht diese Antwort am Kern der Sache vorbei. Bereits vor zehn Jahren wurde das Konzept von Microservices als vielversprechender Weg zum Aufbau großer Systeme vielfach diskutiert und bei Unternehmen wie Twitter, Facebook, Google und Netflix angewendet. Die allgemeine Ansicht – zumindest in den Teilen der Branche, mit denen ich in Kontakt kam – war, dass Microservices der „richtige Weg“ seien, große Systeme aufzubauen, auch wenn es verdammt schwierig sei.
Obwohl es vor zehn Jahren Unternehmen gab, die Microservices betrieben, setzten sie natürlich nicht überall Proxys ein, um ein Service-Mesh zu bilden. Wenn Sie jedoch genau hinschauen, haben sie etwas Ähnliches getan: Viele dieser Unternehmen verlangten die Verwendung einer speziellen internen Bibliothek für die Netzwerkkommunikation (manchmal auch als Thick-Client-Bibliothek bezeichnet). Fat-Client-Bibliothek).
Netflix hatte Hysterix, Google hatte Stubby, Twitter hatte die Finagle-Bibliothek. Finagle beispielsweise war für jeden neuen Dienst auf Twitter Pflicht. Es verwaltete sowohl die Client- als auch die Serverseite von Verbindungen, ermöglichte wiederholte Anforderungen, unterstützte Anforderungsrouting, Lastausgleich und Messung. Es sorgte für eine konsistente Ebene der Zuverlässigkeit und Beobachtbarkeit im gesamten Twitter-Stack, unabhängig davon, was der Dienst tat. Es funktionierte natürlich nur für JVM-Sprachen und basierte auf einem Programmiermodell, das für die gesamte Anwendung verwendet werden musste. Die Funktionalität entsprach jedoch nahezu der des Service Mesh. (Tatsächlich war die erste Version von Linkerd einfach Finagle, verpackt in Proxy-Form.)
So gab es vor zehn Jahren nicht nur Microservices, sondern auch spezielle Proto-Service-Mesh-Bibliotheken, die die gleichen Probleme lösten, die Service Mesh heute löst. Allerdings existierte das Service Mesh selbst damals noch nicht. Es musste noch eine Schicht dauern, bis sie auftauchte.
Und hier liegt die tiefere Antwort, verborgen in einer weiteren Veränderung, die in den letzten 10 Jahren stattgefunden hat: Die Kosten für die Bereitstellung von Microservices sind dramatisch gesunken. Die oben genannten Unternehmen, die vor zehn Jahren Microservices nutzten – Twitter, Netflix, Facebook, Google – waren Unternehmen von enormer Größe und enormen Ressourcen. Sie hatten nicht nur den Bedarf, sondern auch die Fähigkeit, große, auf Microservices basierende Anwendungen zu erstellen, bereitzustellen und zu betreiben. Die Energie und Mühe, die Twitter-Ingenieure in den Übergang von einem monolithischen zu einem Microservices-Ansatz stecken, ist erstaunlich. (Um fair zu sein, gilt das auch für die Tatsache, dass es gelungen ist.) Für kleinere Unternehmen waren solche Infrastrukturmaßnahmen damals unmöglich.
Schneller Vorlauf in die Gegenwart. Heutzutage gibt es Startups, bei denen das Verhältnis von Microservices zu Entwicklern 5:1 (oder sogar) beträgt ), und darüber hinaus meistern sie diese erfolgreich! Wenn ein 5-Personen-Startup problemlos 50 Microservices betreiben kann, dann hat etwas die Kosten für deren Implementierung deutlich gesenkt.
1500 Mikrodienste in Monzo; Jede Zeile ist eine vorgeschriebene Netzwerkregel, die Datenverkehr zulässt
Die dramatische Reduzierung der Betriebskosten von Microservices ist das Ergebnis eines Prozesses: wachsende Beliebtheit von Containern и Orchestratoren. Dies ist genau die tiefgreifende Antwort auf die Frage, was zur Entstehung des Service Mesh beigetragen hat. Dieselbe Technologie machte sowohl Service Meshes als auch Microservices attraktiv: Kubernetes und Docker.
Warum? Nun, Docker löst ein großes Problem – das Verpackungsproblem. Durch das Packen einer Anwendung und ihrer (nicht netzwerkbezogenen) Laufzeitabhängigkeiten in einen Container verwandelt Docker die Anwendung in eine austauschbare Einheit, die überall gehostet und ausgeführt werden kann. Gleichzeitig vereinfacht es die Bedienung enorm mehrsprachig Stack: Da ein Container eine atomare Ausführungseinheit ist, spielt es für Bereitstellungs- und Betriebszwecke keine Rolle, was sich darin befindet, sei es eine JVM-, Node-, Go-, Python- oder Ruby-Anwendung. Sie starten es einfach und das war's.
Kubernetes bringt alles auf die nächste Ebene. Da es nun Unmengen von „Dingen zum Ausführen“ und Unmengen von Maschinen gibt, auf denen sie ausgeführt werden können, besteht Bedarf an einem Tool, das sie miteinander korrelieren kann. Im weitesten Sinne geben Sie Kubernetes viele Container und viele Maschinen und es ordnet sie einander zu (natürlich ist dies ein dynamischer und sich ständig ändernder Prozess: Neue Container bewegen sich im System, Maschinen starten und stoppen). usw. Kubernetes berücksichtigt jedoch all dies.
Sobald Kubernetes konfiguriert ist, unterscheiden sich die Zeitkosten für die Bereitstellung und den Betrieb eines Dienstes kaum von den Kosten für die Bereitstellung und den Betrieb von zehn Diensten (tatsächlich sind sie für 100 Dienste fast gleich). Fügen Sie dazu noch Container als Verpackungsmechanismus hinzu, der die mehrsprachige Implementierung fördert, und Sie haben eine Vielzahl neuer Anwendungen, die in Form von Microservices implementiert werden, die in verschiedenen Sprachen geschrieben sind – genau die Art von Umgebung, für die ein Service Mesh so gut geeignet ist.
Damit kommen wir zur Antwort auf die Frage, warum die Idee eines Service Mesh mittlerweile populär geworden ist: Die Homogenität, die Kubernetes für Services bietet, gilt direkt für die betrieblichen Herausforderungen, denen sich ein Service Mesh gegenübersieht. Sie packen die Proxys in Container, geben Kubernetes die Aufgabe, sie überall dort unterzubringen, wo es kann, und voilà! Als Ergebnis erhalten Sie ein Service-Mesh, während alle Mechanismen seiner Bereitstellung von Kubernetes verwaltet werden. (Zumindest aus der Vogelperspektive. Natürlich gibt es bei diesem Prozess viele Nuancen.)
Um es zusammenzufassen: Der Grund dafür, dass Service Meshes jetzt und nicht vor zehn Jahren populär geworden sind, liegt darin, dass Kubernetes und Docker nicht nur deutlich zugenommen haben потребность Darin wurde die Implementierung von Anwendungen als Sätze mehrsprachiger Mikrodienste vereinfacht, aber auch erheblich reduziert Kosten für seinen Betrieb, Bereitstellung von Mechanismen für den Einsatz und die Unterstützung von Sidecar-Proxy-Flotten.
Warum wird so viel über Service Mesh gesprochen?
Warnung: In diesem Abschnitt verwende ich alle Arten von Annahmen, Vermutungen, Erfindungen und Insiderinformationen.
Wenn Sie nach „Service Mesh“ suchen, werden Sie auf eine Menge recycelter, kalorienarmer Inhalte, seltsame Projekte und ein Kaleidoskop an Verzerrungen stoßen, die einer Echokammer würdig sind. Jede neue Technologie macht das, aber im Fall eines Service Mesh ist das Problem besonders akut. Warum?
Nun, ein Teil davon ist meine Schuld. Ich habe hart daran gearbeitet, Linkerd und das Service Mesh bei jeder Gelegenheit durch unzählige Blogbeiträge und Artikel wie diesen zu bewerben. Aber ich bin nicht so mächtig. Um diese Frage wirklich zu beantworten, müssen wir ein wenig über die Gesamtsituation sprechen. Und es ist unmöglich, darüber zu sprechen, ohne ein Projekt zu erwähnen: ist ein Open-Source-Service-Mesh, das gemeinsam von Google, IBM und Lyft entwickelt wurde.
(Die drei Unternehmen haben sehr unterschiedliche Rollen: Die Beteiligung von Lyft scheint nur dem Namen nach zu bestehen; sie sind die Autoren von Envoy, nutzen aber weder die Entwicklung von Istio noch beteiligen sie sich daran. IBM ist an Istio beteiligt und nutzt es. Google ist aktiv an der Entwicklung von Istio beteiligt development , nutzt es aber, soweit ich das beurteilen kann, nicht wirklich.)
Das Istio-Projekt zeichnet sich durch zwei Dinge aus. Da wäre zum einen der enorme Marketingaufwand, den vor allem Google in die Werbung steckt. Ich schätze, dass die meisten Menschen, die heute mit dem Service-Mesh-Konzept vertraut sind, erstmals über Istio davon erfahren haben. Die zweite Sache ist, wie schlecht Istio aufgenommen wurde. In dieser Angelegenheit bin ich natürlich ein Interessent, aber um so objektiv wie möglich zu bleiben, kann ich trotzdem nicht helfen , nicht sehr markant (wenn auch nicht eindeutig: systemd fällt mir ein, ...) für ein Open-Source-Projekt.
(In der Praxis scheint Istio nicht nur Probleme mit der Komplexität und UX, sondern auch mit der Leistung zu haben. Beispielsweise während In einer Studie Dritter fanden Forscher Situationen, in denen die Tail-Latenz von Istio 100-mal höher war als die von Linkerd, sowie Situationen mit Ressourcenknappheit, in denen Linkerd weiterhin erfolgreich funktionierte, während Istio vollständig aufhörte.)
Abgesehen von meinen Theorien darüber, warum das passiert ist, glaube ich, dass die überwältigende Aufregung rund um das Service Mesh durch die Beteiligung von Google erklärt wird. Nämlich eine Kombination der folgenden drei Faktoren:
- Googles aufdringliche Werbung für Istio;
- eine entsprechende missbilligende, kritische Haltung gegenüber dem Projekt;
- der jüngste kometenhafte Anstieg der Popularität von Kubernetes, an den man sich noch frisch erinnert.
Zusammengenommen schaffen diese Faktoren eine betäubende, sauerstofffreie Umgebung, in der die Fähigkeit zu rationalem Urteilsvermögen geschwächt ist und nur die seltsame Variante übrig bleibt. .
Aus Linkerds Sicht würde ich das als gemischten Segen bezeichnen. Ich meine, es ist großartig, dass Service Mesh auf eine Weise in den Mainstream gelangt ist, wie dies 2016, als Linkerd anfing, nicht der Fall war, und es war wirklich schwierig, die Leute für das Projekt zu gewinnen. Jetzt gibt es kein solches Problem mehr! Die schlechte Nachricht ist jedoch, dass die Service-Mesh-Landschaft heutzutage so verwirrend ist, dass es nahezu unmöglich ist, zu verstehen, welche Projekte tatsächlich in die Service-Mesh-Kategorie gehören (ganz zu schweigen davon, welches für einen bestimmten Anwendungsfall am besten geeignet ist). Dies ist definitiv ein Dealbreaker für alle (und es gibt definitiv einige Fälle, in denen Istio oder ein anderes Projekt besser geeignet ist als Linkerd, da letzteres immer noch keine universelle Lösung ist).
Auf Linkerds Seite bestand unsere Strategie darin, den Lärm zu ignorieren, uns weiterhin auf die Lösung echter Community-Probleme zu konzentrieren und im Grunde darauf zu warten, dass der Hype nachlässt. Letztendlich wird der Hype nachlassen und wir können in Ruhe weiterarbeiten.
In der Zwischenzeit müssen wir uns alle noch ein wenig gedulden.
Wird ein Service Mesh für mich als bescheidenen Softwareentwickler nützlich sein?
Der folgende Fragebogen hilft Ihnen bei der Beantwortung dieser Frage:
Sind Sie ausschließlich an der Implementierung der Geschäftslogik beteiligt? In diesem Fall ist das Service-Mesh für Sie nicht von Nutzen. Das bedeutet natürlich, dass Sie daran interessiert sein könnten, aber im Idealfall sollte das Service Mesh nichts direkt in Ihrer Umgebung beeinflussen. Arbeiten Sie weiter an dem, wofür Sie bezahlt werden.
Unterstützen Sie die Plattform bei einem Unternehmen, das Kubernetes nutzt? Ja, in diesem Fall benötigen Sie ein Service-Mesh (es sei denn, Sie verwenden K8s natürlich nur zum Ausführen eines Monolithen oder einer Stapelverarbeitung – aber dann würde ich gerne fragen, warum Sie K8s benötigen). Am Ende werden Sie wahrscheinlich viele Microservices haben, die von verschiedenen Leuten geschrieben wurden. Sie alle interagieren miteinander und sind in ein Gewirr von Laufzeitabhängigkeiten eingebunden, und Sie müssen einen Weg finden, mit all dem umzugehen. Durch die Verwendung von Kubernetes können Sie ein Service-Mesh „für sich selbst“ auswählen. Machen Sie sich dazu mit deren Fähigkeiten und Funktionen vertraut und beantworten Sie die Frage, ob eines der verfügbaren Projekte für Sie geeignet ist (ich empfehle, Ihre Recherche mit Linkerd zu beginnen).
Sind Sie ein Plattformunternehmen bei einem Unternehmen, das NICHT Kubernetes, sondern Microservices nutzt? In diesem Fall wird ein Service-Mesh für Sie nützlich sein, aber seine Verwendung wird nicht trivial sein. Natürlich kannst du nachzuahmen Durch die Platzierung einer Reihe von Proxys lässt sich das Service-Mesh-System zwar besser bedienen, aber ein wichtiger Vorteil von Kubernetes ist das Bereitstellungsmodell: Die manuelle Verwaltung dieser Proxys erfordert viel mehr Zeit, Aufwand und Kosten.
Sind Sie in einem Unternehmen, das mit Monolithen arbeitet, für die Plattform verantwortlich? In diesem Fall benötigen Sie wahrscheinlich kein Service Mesh. Wenn Sie mit Monolithen (oder sogar Sammlungen von Monolithen) arbeiten, die klar definierte und sich selten ändernde Interaktionsmuster aufweisen, wird Ihnen ein Service Mesh wenig zu bieten haben. Sie können es also einfach ignorieren und hoffen, dass es wie ein böser Traum verschwindet ...
Fazit
Wahrscheinlich sollte Service Mesh immer noch nicht als „die am meisten gehypte Technologie der Welt“ bezeichnet werden – diese zweifelhafte Ehre gebührt wahrscheinlich Bitcoin oder KI. Sie ist wahrscheinlich unter den ersten fünf. Aber wenn man die Schichten des Rauschens durchbricht, wird klar, dass das Service Mesh denjenigen, die Anwendungen auf Kubernetes erstellen, echte Vorteile bringt.
Ich möchte, dass Sie Linkerd ausprobieren – indem Sie es auf einem Kubernetes-Cluster (oder sogar Minikube auf einem Laptop) installieren. , und Sie können selbst sehen, wovon ich spreche.
FAQ
— Wenn ich das Service-Mesh ignoriere, verschwindet es dann?
— Ich muss Sie enttäuschen: Service Mesh begleitet uns schon lange.
- Aber ich möchte kein Service-Mesh verwenden!
- Nun, das ist nicht nötig! Lesen Sie einfach meinen Fragebogen oben, um zu verstehen, ob Sie sich zumindest mit den Grundlagen vertraut machen sollten.
— Ist das nicht die gute alte ESB/Middleware mit einer neuen Soße?
— Service Mesh befasst sich mit der operativen Logik, nicht mit der semantischen. Dienstbus eines Unternehmens (). Die Beibehaltung dieser Trennung hilft dem Service-Mesh, das gleiche Schicksal zu vermeiden.
— Wie unterscheidet sich ein Service Mesh von API-Gateways?
— Es gibt eine Million Artikel zu diesem Thema. Google es einfach.
— Ist Envoy ein Service-Mesh?
- Nein, Envoy ist kein Service Mesh, sondern ein Proxyserver. Es kann zum Organisieren eines Service Mesh verwendet werden (und noch viel mehr – es ist ein Allzweck-Proxy). Aber an sich ist es kein Service-Mesh.
— Ist Network Service Mesh ein Service Mesh?
- Nein. Trotz des Namens handelt es sich hier nicht um ein Servicenetz (wie gefällt Ihnen Marketingwunder?).
— Hilft ein Service Mesh bei meinem auf Nachrichtenwarteschlangen basierenden reaktiven asynchronen System?
- Nein, Service Mesh hilft Ihnen nicht weiter.
— Welches Service-Mesh soll ich verwenden?
- , Klacks.
- Der Artikel ist scheiße! / Der Autor ist herzlich willkommen!
— Bitte teilen Sie den Link dazu mit allen Ihren Freunden, damit sie ihn sehen können!
Danksagung
Wie Sie vielleicht anhand des Titels erraten haben, wurde dieser Artikel von Jay Kreps' fantastischer Abhandlung inspiriert." Ich habe Jay vor zehn Jahren kennengelernt, als ich ihn auf Linked In interviewte, und seitdem ist er eine Inspiration für mich.
Obwohl ich mich gerne als „Linkerd-Entwickler“ bezeichne, bin ich in Wirklichkeit eher der Betreuer der README.md-Datei eines Projekts. An Linkerd wird heute gearbeitet , , Menschen, und dieses Projekt wäre ohne die Beteiligung einer wunderbaren Gemeinschaft von Mitwirkenden und Benutzern nicht zustande gekommen.
Und zum Schluss noch ein besonderer Dank an den Schöpfer von Linkerd, (primus inter pares), der sich vor vielen Jahren zusammen mit mir Hals über Kopf in die ganze Aufregung um Service Mesh gestürzt hat.
PS vom Übersetzer
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «";
- «";
- «".
Source: habr.com
