🥇 Anwendungsfälle für Service Mesh

Hinweis.: Autor dieses Artikels (Luc Perkins) — Developer Advocate bei CNCF, dem Zuhause zahlreicher Open-Source-Projekte wie Linkerd, SMI (Service Mesh Interface) und Kuma. (Übrigens, haben Sie sich auch schon gefragt, warum Istio nicht in dieser Liste steht?) Wieder einmal versucht er, dem DevOps-Community ein besseres Verständnis für den angesagten Hype um „Service Mesh“ zu vermitteln, indem er 16 charakteristische Funktionen auflistet, die solche Lösungen bieten.

Heute Service Mesh ― eines der heißesten Themen in der Softwareentwicklung (und zu Recht!). Ich halte diese Technologie für unglaublich vielversprechend und träume davon, ihr breites Ansehen zu erleben (natürlich wenn es sinnvoll ist). Dennoch bleibt sie für die meisten Menschen nach wie vor von einem Hauch des Geheimnisvollen umgeben. Sogar diejenigen, die gut vertraut mit ihr sind, haben oft Schwierigkeiten, ihre Vorteile zu formulieren und was sie eigentlich darstellt (einschließlich mir selbst). In diesem Artikel werde ich versuchen, die Situation zu verbessern, indem ich verschiedene Anwendungsfälle für „Service Meshes“* aufliste.

* Hinweis: Im Folgenden wird der Begriff „Servicenetz“ für den noch neuen Ausdruck service mesh verwendet.

Zunächst möchte ich einige Anmerkungen machen:

Ich habe noch nie mit Servicenetzen gearbeitet und sie auch außerhalb von Projekten genutzt, die ich zu meinem eigenen Lernen initiiert habe. Andererseits habe ich jedoch eine Menge Dokumentation für das interne Servicenetz des Unternehmens Twitter im Jahr 2015 verfasst (zu diesem Zeitpunkt hieß es noch nicht einmal „Servicenetz“) und war an der Entwicklung der Website sowie der Dokumentation beteiligt für Linkerd, was vielleicht etwas bedeutet.
Meine Liste ist grob und unvollständig. Es sind durchaus auch mir unbekannte Nutzungsszenarien möglich, und mit der Weiterentwicklung der Technologie werden sicher neue Varianten entstehen.
Gleichzeitig unterstützt nicht jede bestehende Implementierung eines Servicenetzes alle aufgeführten Anwendungsfälle. Daher sollten meine Formulierungen wie „Servicenetz kann…“ als „einzelne, möglicherweise sogar alle gängigen Implementierungen eines Servicenetzes können…“ gelesen werden.
Die Reihenfolge der Beispiele hat keine besondere Bedeutung.

Kurze Liste:

Serviceerkennung;
Verschlüsselung;
Authentifizierung und Autorisierung;
Lastenausgleich;
Schaltkreisunterbrechung;
Automatische Skalierung;
Canary-Deployments;
Blue-Green-Deployments;
Gesundheitsprüfung;
Lastabwurf;
Traffic-Mirroring;
Isolation;
Anfragenrate-Limiting, Retry-Mechanismen und Zeitüberschreitungen;
Telemetrie;
Audit;
Visualisierung.

1. Dienstentdeckung

TL;DR: Verbinden Sie sich mit anderen Diensten im Netzwerk über einfache Namen.

Dienste müssen in der Lage sein, sich automatisch mit angemessenen Namen zu 'finden' – zum Beispiel, service.api.production, pets/staging oder cassandra. Cloud-Umgebungen zeichnen sich durch Elastizität aus, und hinter einem Namen können viele Instanzen eines Dienstes stecken. Es ist klar, dass es in dieser Situation physisch unmöglich ist, alle IP-Adressen hardcoded zu hinterlegen.

Zusätzlich muss ein Dienst, der einen anderen findet, in der Lage sein, Anfragen an diesen Dienst zu senden, ohne befürchten zu müssen, dass sie bei einer nicht funktionierenden Instanz empfangen werden. Mit anderen Worten, das Service Mesh muss die Verfügbarkeit aller Dienstinstanzen überwachen und die Liste der Hosts stets aktuell halten.

Jedes Service Mesh implementiert die Mechanismen zur Serviceerkennung auf seine eigene Weise. Der gängigste Ansatz ist derzeit die Delegation an externe Prozesse wie DNS in Kubernetes. Früher nutzten wir bei Twitter dafür ein Namenssystem. Finagle. Darüber hinaus ermöglicht die Technologie des Service Mesh die Einführung benutzerdefinierter Namensmechanismen (obwohl ich bisher noch keine Implementierung mit dieser Funktionalität gesehen habe).

2. Verschlüsselung

TL;DR: Vermeiden Sie unverschlüsselten Datenverkehr zwischen den Services und lassen Sie diesen Prozess automatisiert und skalierbar gestalten.

Es ist beruhigend zu wissen, dass Angreifer nicht in Ihr internes Netzwerk eindringen können. Firewalls leisten hier hervorragende Arbeit. Aber was passiert, wenn ein Hacker doch eindringt? Kann er mit dem internen Servicetrafik alles tun, was ihm beliebt? Lassen wir die Hoffnung, dass dies nicht geschieht. Um ein solches Szenario zu verhindern, sollte ein Zero-Trust-Netzwerk implementiert werden, in dem der gesamte Datenverkehr zwischen den Services verschlüsselt ist. Die meisten modernen Service Meshes erreichen dies durch gegenseitige TLS (mutual TLS, mTLS). In manchen Fällen funktioniert mTLS in ganzen Clouds und Clustern (ich denke, interplanetare Kommunikation wird eines Tages ähnlich organisiert sein).

Natürlich ist für das mTLS-Service-Mesh nicht erforderlich. Jeder Dienst kann selbst für sein TLS verantwortlich sein, aber das bedeutet, dass ein Weg gefunden werden muss, um Zertifikate zu generieren, sie auf die Hosts des Dienstes zu verteilen und den Anwendungscode einzufügen, der diese Zertifikate aus Dateien lädt. Und vergessen Sie nicht, diese Zertifikate in festgelegten Zeitabständen zu aktualisieren. Service-Meshes automatisieren mTLS mit Systemen wie SPIFFE, die wiederum den Prozess der Ausstellung und Rotation von Zertifikaten automatisieren.

3. Authentifizierung und Autorisierung

TL;DR: Bestimmen Sie, wer der Initiator der Anfrage ist, und legen Sie fest, was ihm erlaubt ist, bevor die Anfrage den Dienst erreicht.

Dienste möchten oft wissen, wer wer die Anfrage stellt (Authentifizierung), und nutzen diese Informationen, um zu entscheiden, was was diesem Subjekt erlaubt ist (Autorisierung). In diesem Fall könnten sich hinter dem Pronomen „wer“ verbergen:

Andere Dienste. Das wird als „Authentifizierung von Peers“ bezeichnet.». Zum Beispiel möchte der Dienst web auf den Dienst zugreifen db. Dienstgitter lösen solche Probleme in der Regel mithilfe von mTLS: In diesem Fall fungieren Zertifikate als notwendige Identifikatoren.
Einige Benutzer – Menschen. Dies wird als „Authentifizierung der Anfrage“ bezeichnet. Zum Beispiel möchte der Benutzer haxor69 eine neue Lampe kaufen. Dienstgitter bieten verschiedene Mechanismen, zum Beispiel JSON Web Tokens..
Viele von uns haben das in der Anwendungsprogrammierung gemacht. Ein Antrag kommt, wir durchsuchen die Tabelle users, finden den Benutzer und vergleichen das Passwort, dann überprüfen wir die Spalte Berechtigungen usw. Im Fall von Dienstgitter passiert dies, noch bevor die Anfrage den Dienst erreicht.

Nachdem wir festgestellt haben, von wem die Anfrage kam, müssen wir feststellen, was dieser Entität gestattet ist. Einige Dienstgitter ermöglichen es, grundlegende Richtlinien (wer was tun kann) in Form von YAML-Dateien oder in der Kommandozeile zu definieren, während andere eine Integration mit Frameworks wie Open Policy Agentangeboten werden. Das endgültige Ziel ist es, dafür zu sorgen, dass Ihre Dienste любую Anfrage akzeptieren, in dem Vertrauen, dass sie aus einer zuverlässigen Quelle stammen. und Diese Aktion ist erlaubt.

4. Lastenausgleich

TL;DR: Verteilen Sie die Last gemäß einem bestimmten Muster auf die Serviceinstanzen.

Ein "Service" besteht in der Regel aus vielen identischen Instanzen. Zum Beispiel besteht der Service heute aus 5 Kopien, morgen kann die Anzahl auf 11 steigen. Anfragen, die an cache , müssen entsprechend einem bestimmten Ziel verteilt werden. Zum Beispiel kann das Ziel sein, die Latenzzeit zu minimieren oder die Wahrscheinlichkeit zu maximieren, auf eine funktionierende Instanz zuzugreifen. Häufig wird der Round-Robin-Algorithmus verwendet, aber es gibt auch viele andere Methoden — wie das gewichtete cache(weighted) Anfragen (wozu bevorzugte Ziele ausgewählt werden können), ringförmiges (ring) Hashing (unter Verwendung von konsistentem Hashing für Upstream-Hosts) oder die Methode der geringsten Anzahl von Anfragen (wo die Instanz mit der geringsten Anzahl von Anfragen bevorzugt wird). Hashing (Verwendung von konsistentem Hashing für Upstream-Hosts) oder das Verfahren mit der geringsten Anzahl von Anfragen (bevorzugt wird die Instanz mit der geringsten Anzahl an Anfragen).

Klassische Lastenausgleicher bieten auch andere Funktionen wie HTTP-Caching und DDoS-Schutz, sind jedoch für den sogenannten East-West-Verkehr (d.h. Datenverkehr innerhalb eines Rechenzentrums) weniger relevant (typische Anwendungsfälle für ein Service Mesh). Natürlich ist es nicht zwingend erforderlich, ein Service Mesh zur Lastenverteilung zu verwenden; es ermöglicht jedoch, Lastverteilungsrichtlinien für jeden Dienst über eine zentralisierte Managementschicht festzulegen und zu steuern, wodurch die Notwendigkeit entfällt, separate Lastenausgleicher im Netzwerk-Stack zu betreiben und zu konfigurieren.

5. Circuit Breaking

TL;DR: Stoppen Sie den Verkehr zu problematischen Diensten und kontrollieren Sie Schäden in den schlimmsten Szenarien.

Wenn ein Dienst aus irgendeinem Grund mit dem Datenverkehr nicht umgehen kann, bietet das Service Mesh mehrere Lösungsansätze für dieses Problem (weitere werden in den entsprechenden Abschnitten behandelt). Circuit Breaking ist die rigoroseste Methode, um einen Dienst vom Datenverkehr abzuschneiden. Allein macht das jedoch keinen Sinn – ein Notfallplan ist erforderlich. Backpressure kann vorgesehen werden. (Backpressure) für Dienste, die Anfragen verarbeiten (vergessen Sie nicht, Ihr Service Mesh dafür zu konfigurieren!), oder beispielsweise um die Statusseite rot zu färben und die Nutzer auf eine alternative Seite mit dem Hinweis „Twitter ist nicht erreichbar“ umzuleiten.

Service Meshes ermöglichen nicht nur die Bestimmung, wann eine Abschaltung folgt und was was danach geschieht. In diesem Fall kann „wann“ jede Kombination von festgelegten Parametern umfassen: die Anzahl der Anfragen über einen bestimmten Zeitraum, die Anzahl paralleler Verbindungen, ausstehende Anfragen, aktive Wiederholungsversuche usw.

Sie möchten wahrscheinlich nicht übermäßig auf Circuit Breaking zurückgreifen, aber es ist beruhigend zu wissen, dass es einen Backup-Plan für den Notfall gibt.

6. Automatische Skalierung

TL;DR: Erhöhen oder verringern Sie die Anzahl der Instanzen des Dienstes basierend auf festgelegten Kriterien.

Service Meshes sind keine Scheduler, daher führen sie keine durch. skalierung selbstständig. Sie können jedoch Informationen bereitstellen, auf deren Grundlage die Planer Entscheidungen treffen. Da Service-Meshes Zugang zu allen Datenverkehr zwischen den Diensten haben, verfügen sie über umfangreiche Informationen darüber, was passiert: welche Dienste auf Probleme stoßen, welche kaum ausgelastet sind (die zugewiesenen Ressourcen werden vergeudet) usw.

Zum Beispiel skaliert Kubernetes Dienste basierend auf der Nutzung von CPU und Speicher durch Pods. (siehe unseren Bericht „Automatische Skalierung und Ressourcenmanagement in Kubernetes“ — Anm. d. Übers.), aber wenn Sie die Skalierung basierend auf einem anderen Maßstab (in unserem Fall bezogen auf den Datenverkehr) durchführen möchten, benötigen Sie eine spezielle Metrik. Eine Anleitung wie diese zeigt, wie das mit Hilfe von Envoy, Istio und Prometheusfunktioniert, aber der Prozess selbst ist ziemlich kompliziert. Wir würden uns wünschen, dass das Service-Mesh es vereinfacht, indem es einfach Bedingungen festlegt wie "erhöhe die Anzahl der Instanzen des Dienstes auth, wenn die Anzahl der ausstehenden Anfragen einen Schwellenwert von einer Minute überschreitet".

7. Canary Deployments

TL;DR: Testen Sie neue Funktionen oder Versionen des Dienstes mit einer Teilmenge der Nutzer.

Angenommen, Sie entwickeln ein SaaS-Produkt und planen, eine neue, aufregende Version zu veröffentlichen. Sie haben diese in der Staging-Umgebung getestet, und sie hat hervorragend funktioniert. Dennoch haben Sie Bedenken bezüglich ihres Verhaltens unter realen Bedingungen. Mit anderen Worten, Sie müssen die neue Version an echten Aufgaben testen, ohne das Vertrauen Ihrer Nutzer zu riskieren. Canary-Deployments sind dafür eine hervorragende Lösung. Sie ermöglichen es, eine neue Funktion einer ausgewählten Gruppe von Nutzern vorzustellen. Diese Gruppe kann aus den treuesten Nutzern bestehen, aus denen, die die kostenlose Version des Produkts verwenden, oder aus Nutzern, die bereit sind, als „Versuchskaninchen“ zu fungieren.

Service-Mesh-Technologien ermöglichen dies, indem sie Kriterien festlegen, die bestimmen, wer welche Version der Anwendung sieht, und den Datenverkehr entsprechend weiterleiten. Für die Services selbst bleibt dabei alles unverändert. Die Version 1.0 des Services geht davon aus, dass alle Anfragen von Benutzern kommen, die genau diese Version sehen sollten, während die Version 1.1 dasselbe für ihre Benutzer annimmt. In der Zwischenzeit können Sie den prozentualen Anteil des Traffics zwischen der alten und der neuen Version ändern und eine wachsende Anzahl von Benutzern auf die neue Version umleiten, wenn diese stabil läuft und Ihr Testpublikum zustimmt.

8. Blue-Green Deployments

TL;DR: Rollout einer neuen, coolen Funktion, aber seien Sie bereit, sofort alles zurückzudrehen.

Bedeutung von Blue-Green Deployments besteht darin, einen neuen "blauen" Service parallel zu dem alten, "grünen" Service einzuführen. Wenn alles gut läuft und der neue Service sich bewährt, kann der alte schrittweise abgeschaltet werden. (Leider wird irgendwann auch dieser neue "blaue" Service das Schicksal des "grünen" Services teilen und verschwinden…) Blue-Green Deployments unterscheiden sich von Canary Deployments, indem die neue Funktion mehr Benutzer erreicht. alle sofort Benutzer (nicht nur ein Teil); die Idee dahinter ist, eine „Backup-Lösung“ bereit zu haben, falls etwas schiefgeht.

Service-Meshes bieten eine sehr einfache Möglichkeit, den „blauen“ Dienst zu testen und bei Problemen sofort auf den funktionierenden „grünen“ Dienst umzuschalten. Ganz zu schweigen davon, dass sie dabei eine Fülle von Informationen (siehe Punkt „Telemetrie“ unten) über den „blauen“ Dienst bereitstellen, die helfen, zu verstehen, ob er bereit für den produktiven Einsatz ist.

Hinweis.: Mehr über verschiedene Bereitstellungsstrategien in Kubernetes (einschließlich der erwähnten Canary-, Blue/Green-Strategien und anderer) erfahren Sie in in diesem Artikel.

9. Gesundheitsüberprüfung

TL;DR: Behalten Sie im Auge, welche Dienstinstanzen funktionsfähig sind, und reagieren Sie auf diejenigen, die es nicht mehr sind.

Gesundheitsüberprüfung (health check) hilft dabei zu entscheiden, ob die Dienstinstanzen bereit sind, Verkehr zu empfangen und zu verarbeiten. Bei HTTP-Diensten könnte eine Gesundheitsüberprüfung beispielsweise wie ein GET-Request an den Endpoint aussehen /health. Antwort 200 OK Das bedeutet, dass die Instanz betriebsbereit ist; alles andere bedeutet, dass sie nicht bereit ist, Verkehr entgegenzunehmen. Service-Meshes ermöglichen es, sowohl die Methode zur Überprüfung der Betriebsbereitschaft als auch die Häufigkeit dieser Überprüfung festzulegen. Diese Informationen können dann für andere Zwecke genutzt werden – zum Beispiel für Lastverteilung und Circuit-Breaking.

Somit ist die Gesundheitsüberprüfung kein eigenständiges Nutzungsszenario, sondern wird meist verwendet, um andere Ziele zu erreichen. Abhängig von den Ergebnissen der Gesundheitschecks können externe Maßnahmen erforderlich werden (im Hinblick auf andere Ziele der Service-Meshes): beispielsweise die Aktualisierung des Statusberichts, das Erstellen eines Issues auf GitHub oder das Ausfüllen eines JIRA-Tickets. Das Service-Mesh bietet einen praktischen Mechanismus zur Automatisierung all dieser Prozesse.

10. Lastabwurf (Load Shedding)

TL;DR: Leiten Sie den Verkehr als Reaktion auf einen vorübergehenden Anstieg der Nutzung um.

Wenn ein bestimmter Dienst durch Verkehr überlastet ist, können Sie vorübergehend einen Teil dieses Verkehrs an einen anderen Ort umleiten (d.h. "abwerfen", "umleiten") (shed) dorthin). Zum Beispiel zu einem Backup-Service oder einem Rechenzentrum, oder zu einem permanenten Pulsar Thema. Dadurch kann der Dienst einen Teil der Anfragen weiterhin bearbeiten, anstatt ganz auszufallen und die Verarbeitung aller Anfragen einzustellen. Eine Lastverlagerung ist vorzuziehen, um Kettenausfälle zu vermeiden, dennoch sollte sie nicht überstrapaziert werden. Sie hilft, kaskadierende Ausfälle zu verhindern, bei denen nachgelagerte Dienste ausfallen.

11. Parallelisierung / Traffic-Spiegelung

TL;DR: Senden Sie eine Anfrage gleichzeitig an mehrere Stellen.

Manchmal ist es notwendig, eine Anfrage (oder eine Auswahl von Anfragen) gleichzeitig an mehrere Dienste zu senden. Ein typisches Beispiel ist das Senden eines Teils des Produktions-Traffics an den Staging-Dienst. Der Haupt-Web-Server der Produktion sendet eine Anfrage an den nachgelagerten Dienst products.production und nur an diesen. Der Service Mesh kopiert diese Anfrage intelligent und leitet sie an products.staging, ohne dass der Web-Server davon Kenntnis hat.

Ein weiteres verwandtes Anwendungszenario des Service Mesh, das über die Traffic-Parallelisierung realisiert werden kann, ist Regressionstest. Es ermöglicht das Senden derselben Anfragen an verschiedene Versionen des Dienstes und überprüft, ob sich alle Versionen gleich verhalten. Ich habe bisher noch keine Implementierung eines Service Mesh mit einem integrierten System für Regressionstests wie Diffy, aber die Idee selbst scheint vielversprechend.

12. Isolierung

TL;DR: Zerlegen Sie Ihr Service Mesh in Mini-Netzwerke.

Auch bekannt als Segmentierung, ist Isolierung die Kunst, ein Service Mesh in logisch getrennte Segmente zu unterteilen, die nichts voneinander wissen. Isolierung ähnelt dem Erstellen von virtuellen privaten Netzwerken. Der wesentliche Unterschied besteht jedoch darin, dass Sie weiterhin alle Vorteile eines Service Mesh (wie die Dienstentdeckung) nutzen können, jedoch mit zusätzlicher Sicherheit. Wenn ein Angreifer zum Beispiel in einen Dienst in einem der Subnetze eindringen kann, hat er keinen Zugriff auf die Dienste, die in anderen Subnetzen ausgeführt werden, oder kann deren Verkehr abfangen.

Darüber hinaus können auch organisatorische Vorteile entstehen. Möglicherweise möchten Sie die Dienste je nach Unternehmensstruktur in Subnetze aufteilen und die Entwickler von der kognitiven Belastung entlasten, die mit der Notwendigkeit verbunden ist, das gesamte Service-Mesh im Kopf zu behalten.

13. Begrenzung der Anfragen, Wiederholungsversuche und Zeitüberschreitungen

TL;DR: Es ist nicht mehr notwendig, dringende Aufgaben zur Anfragenverwaltung im Code zu integrieren.

All diese Dinge könnten als separate Anwendungsfälle betrachtet werden, aber ich habe mich entschieden, sie aufgrund einer gemeinsamen Eigenschaft zu vereinen: sie übernehmen die Aufgaben des Lebenszyklusmanagements von Anfragen, die normalerweise von Anwendungsbibliotheken übernommen werden. Wenn Sie einen Webserver in Ruby on Rails entwickeln (der nicht mit dem Service-Mesh integriert ist), der Anfragen an Backend-Dienste übermittelt, gRPC, die Anwendung muss selbst entscheiden, was zu tun ist, wenn N Anfragen fehlschlagen. Zudem muss ermittelt werden, welches Datenvolumen diese Dienste verarbeiten können, und diese Parameter müssen mit einer speziellen Bibliothek 'hardcodiert' werden. Darüber hinaus muss die Anwendung feststellen, wann es Zeit ist, aufzugeben und die Anfrage aufgrund eines Timeouts 'verfallen' zu lassen. Um einen der oben genannten Parameter zu ändern, muss der Webserver gestoppt, umkonfiguriert und neu gestartet werden.

Die Übertragung dieser Aufgaben an das Service-Netz bedeutet nicht nur, dass die Entwickler dieser Dienstleistungen nicht mehr darüber nachdenken müssen, sondern auch, dass sie aus einer globaleren Perspektive betrachtet werden können. Wenn eine komplexe Kette von Diensten verwendet wird, sagen wir A → B → C → D → E, muss der gesamte Lebenszyklus der Anfrage berücksichtigt werden. Wenn die Aufgabe darin besteht, die Timeouts im Dienst C zu verlängern, ist es sinnvoll, dies alles auf einmal zu tun, anstatt in Teilen: den Code des Dienstes zu aktualisieren und darauf zu warten, dass der Pull Request angenommen wird und das CI-System den aktualisierten Dienst bereitstellt.

14. Telemetrie

TL;DR: Sammeln Sie alle benötigten (und nicht unbedingt benötigten) Informationen von den Diensten.

Telemetrie ist ein Überbegriff, der Metriken, verteiltes Tracing und Protokolle umfasst. Service-Meshes bieten Mechanismen zur Sammlung und Verarbeitung aller drei Datentypen. Hier wird es etwas unklar, da die möglichen Optionen zu vielfältig sind. Um Metriken zu sammeln, gibt es Prometheus auch andere Werkzeuge, zur Protokollsammlung kann man fluentd, Loki, Vector usw. (zum Beispiel ClickHouse mit unserem loghouse für K8s – Anm. d. Ü., für verteiltes Tracing gibt es Jaeger usw. Jedes Service-Mesh kann bestimmte Werkzeuge unterstützen und andere nicht. Es wird interessant sein zu beobachten, ob das Projekt Open Telemetry eine gewisse Konvergenz erreichen kann.

In diesem Fall liegt der Vorteil der Service-Mesh-Technologie darin, dass Sidecar-Container im Prinzip alle oben genannten Daten von ihren Diensten sammeln können. Mit anderen Worten, Sie erhalten ein einheitliches System zur Sammlung von Telemetrie, und das Service-Mesh kann diese Informationen auf unterschiedliche Weise verarbeiten. Zum Beispiel:

Protokolle von einem bestimmten Dienst im CLI zur Anzeige bringen;
die Anzahl der Anfragen über das Dashboard des Service-Mesh überwachen;
Verteilte Tracing-Daten sammeln und sie in ein System wie Jaeger umleiten.

Achtung, subjektive Aussage: Im Allgemeinen sollten Telemetriedaten nicht stark durch das Service Mesh beeinflusst werden. Das Sammeln grundlegender Informationen und das Monitoring von einigen 'Goldenen Metriken' wie der Erfolgsquote und Latenzen ist in Ordnung, aber hoffen wir, dass wir keine Frankenstein-Stacks erleben, die versuchen, spezialisierte Systeme zu ersetzen, die sich bereits hervorragend bewährt haben und gut erforscht sind.

15. Audit

TL;DR: Wer die Lehren der Geschichte vergisst, ist dazu verurteilt, sie zu wiederholen.

Ein Audit ist die Kunst, wichtige Ereignisse im System zu beobachten. Im Falle eines Service Mesh kann dies das Nachverfolgen bedeuten, wer Anfragen an bestimmte Endpunkte bestimmter Dienste gestellt hat oder wie oft in den letzten Monaten ein sicherheitsrelevantes Ereignis aufgetreten ist.

Es ist offensichtlich, dass die Auditierung eng mit der Telemetrie verbunden ist. Der Unterschied besteht darin, dass Telemetrie normalerweise mit Aspekten wie Leistung und technischer Effizienz assoziiert wird, während die Auditierung sich auf rechtliche und andere Themen beziehen kann, die über den rein technischen Bereich hinausgehen (z. B. die Einhaltung der Datenschutz-Grundverordnung – DSGVO).

16. Visualisierung

TL;DR: Es lebe React.js – eine unerschöpfliche Quelle für kreative Benutzeroberflächen.

Vielleicht gibt es einen passenderen Begriff, aber ich kenne ihn nicht. Ich beziehe mich einfach auf eine grafische Darstellung des Service Mesh oder einiger seiner Komponenten. Diese Visualisierungen können Indikatoren wie durchschnittliche Latenzzeiten, Informationen zur Konfiguration von Sidecar-Containern, Ergebnisse von Gesundheitsprüfungen und Benachrichtigungen enthalten.

Die Arbeit in einer serviceorientierten Umgebung bringt eine deutlich höhere kognitive Belastung mit sich im Vergleich zu Ihrem Majestät, dem Monolithen. Daher sollte der kognitive Druck um jeden Preis reduziert werden. Eine einfache grafische Benutzeroberfläche für das Service Mesh, die es ermöglicht, auf einen Button zu klicken und das gewünschte Ergebnis zu erhalten, kann entscheidend für das Wachstum dieser Technologie sein.

Nicht in die Liste aufgenommen

Ursprünglich wollte ich noch einige Anwendungsfälle in die Liste aufnehmen, habe mich jedoch entschieden, dies nicht zu tun. Hier sind sie zusammen mit den Gründen für meine Entscheidung:

Multi-Data-Center. In meiner Vorstellung ist dies weniger ein Anwendungsfall als vielmehr ein enges und spezifisches Anwendungsgebiet von Service-Meshes oder einer bestimmten Funktionalität wie der Serviceerkennung.
Ingress und Egress. Dies ist ein verwandtes Gebiet, aber ich habe mich (möglicherweise künstlich) auf den Anwendungsfall „East-West-Traffic“ beschränkt. Ingress und Egress verdienen einen eigenen Artikel.

Fazit

Das ist vorerst alles! Nochmals, diese Liste ist ziemlich willkürlich und höchstwahrscheinlich nicht vollständig. Wenn Sie denken, dass ich etwas übersehen habe oder einen Fehler gemacht habe, kontaktieren Sie mich auf Twitter (@lucperkins). Bitte halten Sie sich an die Benimmregeln.

P.S. vom Übersetzer

Das Titelbild des Artikels basiert auf einem Bild aus dem Artikel „Was ist ein Service Mesh (und wann sollte man eines verwenden)?“ (Autor — Gregory MacKinnon). Es zeigt, wie ein Teil der Funktionalität von Anwendungen (in grün) zum Service Mesh übergegangen ist, das die Interaktionen zwischen ihnen (in blau) gewährleistet.

Lesen Sie auch in unserem Blog:

Quelle: habr.com