🎆 🧑🏿‍🤝‍🧑🏻 🦅 Anwendungsfälle für Service-Mesh 🚱 🍰 🛎️

Ca. übers. : Der Autor dieses Artikels (Luc Perkins) ist ein Entwickleranwalt für CNCF, der Open Source-Projekte wie Linkerd, SMI (Service Mesh Interface) und Kuma beheimatet. Haben Sie sich übrigens auch gefragt, warum Istio nicht auf dieser Liste steht? .). In einem weiteren Versuch, der DevOps-Community ein besseres Verständnis für den modischen Hype namens Service Mesh zu vermitteln, nennt er 16 charakteristische Funktionen, die solche Lösungen bieten. Service - Mesh ist eines der heißesten Themen inSoftwaretechnik

heute(undRecht!). Ich finde diese Technologie unglaublich vielversprechend und träume davon, Zeuge ihrer weit verbreiteten Akzeptanz zu werden (natürlich, wenn es Sinn macht). Für die meisten Menschen ist es jedoch immer noch von einem geheimnisvollen Heiligenschein umgeben. Darüber hinaus auch diejenigen, dieist gut damit vertraut , es ist oft schwierig, seine Vorteile zu formulieren und was genau es ist (einschließlich Ihres bescheidenen Dieners). In diesem Artikel werde ich versuchen, Abhilfe zu schaffen, indem ich verschiedene Szenarien für die Verwendung von "Service Grids" * aufführe.

* Ca. transl .: hier und weiter im Artikel wird die Übersetzung ("Service Mesh") für den noch neuen Begriff Service Mesh verwendet.

Aber zuerst möchte ich ein paar Kommentare abgeben:

, . , service mesh Twitter 2015 ( « ») Linkerd, - .
— . , , .
Gleichzeitig unterstützt nicht jede vorhandene Service-Mesh-Implementierung alle diese Anwendungsfälle. Daher sollten meine Ausdrücke wie "Service Mesh Can ..." als "separat" gelesen werden, und möglicherweise können alle gängigen Service Mesh-Implementierungen ... ".
Die Reihenfolge der Beispiele spielt keine Rolle.

Auswahlliste:

Serviceerkennung;
Verschlüsselung;
Authentifizierung und Autorisierung;
Lastverteilung;
Unterbrechung des Stromkreises;
Autoscaling;
kanarische Einsätze;
blaugrüne Bereitstellungen;
Gesundheitskontrolle;
Lastabwurf;
Verkehrsspiegelung;
Isolierung;
Ratenbegrenzung, Wiederholungsversuche und Zeitüberschreitungen;
Telemetrie;
Prüfung;
Visualisierung.

1. Serviceerkennung

TL; DR: Stellen Sie mit einfachen Namen eine Verbindung zu anderen Diensten im Netzwerk her.

Dienstleistungen sollten in der Lage sein, automatisch „entdecken“ sie über entsprechende Namen - zum Beispiel service.api.production, pets/stagingoder cassandra. Cloud-Umgebungen sind stabil und ein einzelner Name kann mehrere Instanzen eines Dienstes verbergen. Es ist klar, dass es in einer solchen Situation physikalisch unmöglich ist, alle IP-Adressen fest zu codieren.

Wenn ein Dienst einen anderen findet, sollte er in der Lage sein, Anforderungen an diesen Dienst zu senden, ohne befürchten zu müssen, dass sie am Eingang seiner inaktiven Instanz landen. Mit anderen Worten, das Dienstnetz muss den Zustand aller Dienstinstanzen überwachen und die Liste der Hosts auf dem neuesten Stand halten.

Jedes Service-Mesh implementiert einen Service-Erkennungsmechanismus anders. Derzeit wird am häufigsten an externe Prozesse wie DNS-Kubernetes delegiert. In der Vergangenheit haben wir auf Twitter das Finagle- Benennungssystem für diesen Zweck verwendet . Darüber hinaus ermöglicht die Service-Mesh-Technologie das Entstehen von benutzerdefinierten Namensmechanismen (obwohl ich noch keine SM-Implementierung mit dieser Funktionalität gefunden habe).

2. Verschlüsselung

TL; DR: Beseitigen Sie unverschlüsselten Datenverkehr zwischen Diensten und machen Sie den Prozess automatisiert und skalierbar.

Es ist schön zu wissen, dass Angreifer nicht in Ihr internes Netzwerk eindringen können. Firewalls leisten hier hervorragende Arbeit. Aber was passiert, wenn ein Hacker hineinkommt? Kann er mit Intraservice-Verkehr machen, was er will? Hoffen wir, dass es nicht passiert. Um dieses Szenario zu verhindern, sollten Sie ein Netzwerk ohne Vertrauenswürdigkeit implementieren, in dem der gesamte Datenverkehr zwischen Diensten verschlüsselt ist. Die meisten modernen Service-Meshes erreichen dies durch gegenseitiges TLS.(gegenseitiges TLS, mTLS). In einigen Fällen funktioniert mTLS in ganzen Clouds und Clustern (ich denke, dass die interplanetare Kommunikation eines Tages ähnlich angeordnet sein wird).

Für mTLS ist das Service-Mesh natürlich optional . Jeder Dienst kann sich um sein eigenes TLS kümmern. Dies bedeutet jedoch, dass ein Weg gefunden werden muss, um Zertifikate zu generieren, diese auf Diensthosts zu verteilen und Code in die Anwendung aufzunehmen, der diese Zertifikate aus Dateien lädt. Ja, denken Sie auch daran, diese Zertifikate in regelmäßigen Abständen zu erneuern. Service Grids 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 die Anforderung initiiert, und legen Sie fest, was sie tun dürfen, bevor die Anforderung den Dienst erreicht.

Dienste möchten häufig wissen, wer die Anforderung stellt (Authentifizierung), und anhand dieser Informationen entscheiden, was der Betreff tun darf (Autorisierung). In diesem Fall kann sich das Pronomen "wer" verstecken:

Sonstige Dienstleistungen. Dies wird als " Peer- Authentifizierung " bezeichnet. Ein Dienst webmöchte beispielsweise auf einen Dienst zugreifen db. Service-Meshes lösen diese Probleme normalerweise mit mTLS: Zertifikate fungieren in diesem Fall als notwendige Kennung.
-. « ». , haxor69 . , , JSON Web Tokens.

. , users, , permissions .. service mesh , .

Nachdem wir festgestellt haben, von wem die Anfrage stammt, müssen wir festlegen, was das betreffende Thema tun darf. In einigen Service-Meshes können Sie Basisrichtlinien (darüber, wer was tun kann) als YAML-Dateien oder in der Befehlszeile definieren, während andere die Integration in Frameworks wie den Open Policy Agent bieten . Das ultimative Ziel ist es, sicherzustellen, dass Ihre Dienste alle Anfragen annehmen, vorausgesetzt, sie stammen aus einer zuverlässigen Quelle und diese Aktion ist zulässig.

4. Lastausgleich

TL; DR: Verteilen Sie die Last nach einem bestimmten Muster auf die Dienstinstanzen.

Ein "Dienst" innerhalb einer Dienstsekte besteht sehr oft aus vielen identischen Instanzen. Zum Beispiel cachebesteht der Dienst heute aus 5 Exemplaren, und morgen kann sich ihre Anzahl auf 11 erhöhen. Anfragen, an die gerichtet wird, cachesollten gemäß einem bestimmten Zweck verteilt werden. Minimieren Sie beispielsweise die Latenz oder maximieren Sie die Wahrscheinlichkeit, zu einer fehlerfreien Instanz zu gelangen. Der am häufigsten verwendete Round-Robin-Algorithmus (Round-Robin), aber es gibt viele andere - zum Beispiel die Methode der gewichteten (gewichteten) Anforderungen (Sie können das bevorzugte Ziel auswählen), ringförmig (Ring)Hashing (unter Verwendung von konsistentem Hashing für Upstream-Hosts) oder die Methode mit der geringsten Anforderung (die Instanz mit der geringsten Anzahl von Anforderungen wird bevorzugt).

Klassische Load Balancer verfügen über andere Funktionen wie HTTP-Caching und DDoS-Schutz, sind jedoch für den Ost-West-Verkehr (d. H. Für den innerhalb eines Rechenzentrums fließenden Verkehr - ca. Transl.) Nicht sehr relevant (typische Nutzung des Dienstes) Gittergewebe). Natürlich ist es nicht erforderlich, ein Dienstnetz für den Lastausgleich zu verwenden, aber Sie können Ausgleichsrichtlinien für jeden Dienst von einer zentralen Verwaltungsebene aus definieren und steuern, sodass Sie keine einzelnen Ausgleicher im Netzwerkstapel starten und konfigurieren müssen.

5. Unterbrechung des Stromkreises

TL; DR: Stoppen Sie den Datenverkehr zu problematischen Diensten und kontrollieren Sie Schäden im schlimmsten Fall.

Wenn der Dienst aus irgendeinem Grund den Datenverkehr nicht verarbeiten kann, bietet das Dienstnetz verschiedene Optionen zur Lösung dieses Problems (andere werden in den entsprechenden Abschnitten erläutert). Das Unterbrechen von Stromkreisen ist der schwerwiegendste Weg, um einen Dienst vom Verkehr zu trennen. Es macht jedoch allein keinen Sinn - Sie benötigen einen Sicherungsplan. Kann Gegendruck ( Gegendruck ) auf Dienste erzeugen , die abfragen (vergessen Sie nur nicht, Ihr Dienstnetz dafür einzurichten!), Oder beispielsweise den Status der Seite in Rot färben und Benutzer mit dem "fallenden Wal" («Twitter» zu einer anderen Version der Seite umleiten ist unten ").

Service Grids bestimmen nicht nur, wann und was als nächstes passieren wird. In diesem Fall kann "wann" eine beliebige Kombination der angegebenen Parameter enthalten: die Gesamtzahl der Anforderungen für einen bestimmten Zeitraum, die Anzahl der parallelen Verbindungen, ausstehende Anforderungen, aktive Wiederholungsversuche usw.

Sie möchten wahrscheinlich keine Unterbrechungen des Stromkreises missbrauchen, aber es ist schön zu wissen, dass es einen Notfallplan für Notfälle gibt.

6. Automatischer Zoom

TL; DR: Erhöhen oder verringern Sie die Anzahl der Dienstinstanzen basierend auf den angegebenen Kriterien.

Service-Meshes sind keine Scheduler, daher skalieren sie nicht von selbst. Sie können jedoch Informationen bereitstellen, auf deren Grundlage Planer Entscheidungen treffen. Da Dienstnetze Zugriff auf den gesamten Datenverkehr zwischen Diensten haben, verfügen sie über eine Fülle von Informationen darüber, was gerade passiert: Welche Dienste haben Probleme, welche sind sehr schwach ausgelastet (die ihnen zugewiesene Energie wird verschwendet) usw.

Zum Beispiel skaliert Kubernetes Dienste abhängig von der CPU- und Speicherauslastung der Pods (siehe unseren Vortrag " Autoscaling und Ressourcenmanagement in Kubernetes " - ca. übersetzt).Wenn Sie sich jedoch für eine Skalierung auf der Grundlage einer anderen Metrik entscheiden (in unserem Fall in Bezug auf den Datenverkehr), benötigen Sie eine spezielle Metrik. Ein Tutorial wie dieses zeigt Ihnen, wie man das mit Envoy , Istio und Prometheus macht , aber der Prozess selbst ist ziemlich komplex. Wir möchten, dass das Service-Mesh es vereinfacht, indem Sie einfach Bedingungen wie "Erhöhen Sie die Anzahl der Service-Instanzen, authwenn die Anzahl der ausstehenden Anforderungen den Schwellenwert für eine Minute überschreitet " festlegen .

7. Kanarische Einsätze

TL; DR: Probieren Sie neue Funktionen oder Dienstversionen für eine Untergruppe von Benutzern aus.

Angenommen, Sie entwickeln ein SaaS-Produkt und beabsichtigen, eine coole neue Version davon herauszubringen. Sie haben es in der Inszenierung getestet und es hat großartig funktioniert. Dennoch gibt es gewisse Bedenken hinsichtlich ihres Verhaltens unter realen Bedingungen. Mit anderen Worten, es ist erforderlich, die neue Version an realen Aufgaben zu testen, ohne das Vertrauen der Benutzer zu gefährden. Kanarische Einsätze sind dafür großartig. Mit ihnen können Sie einer Untergruppe von Benutzern eine neue Funktion demonstrieren. Diese Untergruppe sind möglicherweise die loyalsten Benutzer oder diejenigen, die die kostenlose Version des Produkts verwenden, oder diejenigen, die den Wunsch geäußert haben, Meerschweinchen zu sein.

Service Meshes tun dies, indem Sie Kriterien angeben können, die bestimmen, wer welche Version Ihrer Anwendung sieht, und den Datenverkehr entsprechend weiterleiten. Gleichzeitig ändert sich für die Dienste selbst nichts. Version 1.0 des Dienstes geht davon aus, dass alle Anforderungen von Benutzern stammen, die ihn sehen sollten, und Version 1.1 geht davon aus, dass dies auch für seine Benutzer gilt. In der Zwischenzeit können Sie den Prozentsatz des Datenverkehrs zwischen der alten und der neuen Version ändern und eine wachsende Anzahl von Benutzern auf die neue umleiten, wenn dies stabil funktioniert und Ihr "Experiment" den Startschuss gibt.

8. Blaugrüne Bereitstellungen

TL; DR: Führen Sie die coole neue Funktion ein, aber seien Sie bereit, sie sofort wieder einzusetzen.

Bei blaugrünen Bereitstellungen wird ein neuer blauer Dienst eingeführt, indem er parallel zum alten grünen Dienst ausgeführt wird. Wenn alles reibungslos läuft und sich der neue Dienst als gut erweist, kann der alte nach und nach ausgeschaltet werden. (Leider wird dieser neue "blaue" Dienst eines Tages das Schicksal des "grünen" wiederholen und verschwinden ...) Blaugrüne Bereitstellungen unterscheiden sich von kanarischen Bereitstellungen darin, dass die neue Funktion alle Benutzer gleichzeitig abdeckt (nicht nur einen Teil). Hier geht es darum, einen "Ersatzhafen" bereit zu haben, falls etwas schief geht.

Service-Meshes bieten eine sehr bequeme Möglichkeit, einen blauen Service zu testen und im Falle eines Problems sofort auf ein funktionierendes Grün umzuschalten. Ganz zu schweigen von der Tatsache, dass sie auf ihrem Weg viele Informationen (siehe Punkt "Telemetrie" unten) über die Arbeit des "Blauen" geben, die helfen zu verstehen, ob er für eine vollwertige Ausbeutung bereit ist.

Ca. übers. : Lesen Sie in diesem Artikel mehr über die verschiedenen Bereitstellungsstrategien in Kubernetes (einschließlich der genannten Kanarienvögel, Blau / Grün und andere) .

9. Gesundheitscheck

TL; DR: Verfolgen Sie, welche Dienstinstanzen aktiv sind, und reagieren Sie auf diejenigen, die dies nicht mehr tun.

Ein Gesundheits - Check hilft Ihnen , zu entscheiden , ob Service - Instanzen bereit und Prozessdatenverkehr zu empfangen. Im Fall von HTTP-Diensten kann eine Integritätsprüfung beispielsweise wie eine GET-Anforderung an einen Endpunkt aussehen /health. Die Antwort 200 OKbedeutet, dass die Instanz fehlerfrei ist - jede andere - dass sie nicht bereit ist, Datenverkehr zu empfangen. Mit Service-Meshes können Sie sowohl die Art und Weise angeben, in der der Zustand überprüft wird, als auch die Häufigkeit, mit der diese Überprüfung durchgeführt wird. Diese Informationen können dann für andere Zwecke verwendet werden, z. B. zum Lastausgleich und zum Unterbrechen des Stromkreises.

Daher ist der Gesundheitscheck kein unabhängiger Anwendungsfall, sondern wird normalerweise zur Erreichung anderer Ziele verwendet. Abhängig von den Ergebnissen der Integritätsprüfungen können auch externe Aktionen (in Bezug auf andere Ziele der Service-Grids) erforderlich sein: Aktualisieren Sie beispielsweise die Statusseite, erstellen Sie ein Problem auf GitHub oder füllen Sie ein JIRA-Ticket aus. Und das Service-Mesh bietet einen praktischen Mechanismus, um all dies zu automatisieren.

10. Lastabwurf

TL; DR: Leiten Sie den Datenverkehr als Reaktion auf vorübergehende Nutzungsspitzen um.

Wenn ein bestimmter Dienst mit Datenverkehr überlastet ist, können Sie einen Teil dieses Datenverkehrs vorübergehend an einen anderen Speicherort umleiten (dh "Dump", " Shed" dort). Zum Beispiel zu einem Sicherungsdienst oder Rechenzentrum oder zu einem permanenten Pulsar- Thema. Infolgedessen verarbeitet der Dienst weiterhin einen Teil der Anforderungen, anstatt abzustürzen, und beendet die Verarbeitung aller Daten. Das Ablassen der Last ist dem Unterbrechen des Stromkreises vorzuziehen, es ist jedoch immer noch nicht wünschenswert, sie zu überbeanspruchen. Es hilft, Kaskadenfehler zu vermeiden, die zum Absturz von Downstream-Diensten führen.

11. Verkehrsparallelisierung / Spiegelung

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

Manchmal ist es erforderlich, eine Anfrage (oder ein Beispiel von Anfragen) gleichzeitig an mehrere Dienste zu senden. Ein typisches Beispiel ist das Senden eines Teils des Produktionsverkehrs an einen Staging-Dienst. Der Hauptproduktionswebserver sendet eine Anforderung an products.productionund nur an den nachgeschalteten Dienst . Und das Service-Mesh kopiert diese Anfrage intelligent und sendet sie an products.staging, von dem der Webserver nicht einmal weiß.

Ein weiterer verwandter Anwendungsfall für das Service-Grid, der zusätzlich zur Verkehrsparallelisierung implementiert werden kann, sind Regressionstests... Dabei werden dieselben Anforderungen an verschiedene Versionen eines Dienstes gesendet und überprüft, ob sich alle Versionen gleich verhalten. Ich bin noch nicht auf eine Service-Mesh-Implementierung mit einem integrierten Regressionstestsystem wie Diffy gestoßen , aber die Idee selbst scheint vielversprechend.

12. Isolierung

TL; DR: Teilen Sie Ihr Service-Mesh in Mini-Netzwerke auf. Isolation,

auch als Segmentierung bezeichnet , ist die Kunst, ein Servicegitter in logisch unterschiedliche Segmente zu unterteilen, die nichts voneinander wissen. Isolation ist ein bisschen wie das Erstellen virtueller privater Netzwerke. Der grundlegende Unterschied besteht darin, dass Sie das Service-Mesh (wie die Service-Erkennung) weiterhin voll ausnutzen können, jedoch mit zusätzlicher Sicherheit. Wenn es einem Angreifer beispielsweise gelingt, einen Dienst in einem der Subnetze zu durchdringen, kann er nicht erkennen, welche Dienste in anderen Subnetzen ausgeführt werden, oder deren Datenverkehr abfangen.

Darüber hinaus können die Vorteile organisatorisch sein. Möglicherweise möchten Sie Ihre Services basierend auf der Struktur Ihres Unternehmens subnetzieren und die Entwickler von der kognitiven Belastung entlasten, das gesamte Service-Mesh im Auge zu behalten.

13. Ratenbegrenzung, Wiederholungsversuche und Zeitüberschreitungen

TL; DR: Die dringenden Aufgaben zum Verwalten von Anforderungen müssen nicht mehr in die Codebasis aufgenommen werden.

All diese Dinge könnten als separate Anwendungsfälle angesehen werden, aber ich habe mich aus einem gemeinsamen Grund entschlossen, sie zu kombinieren: Sie übernehmen die Aufgaben der Verwaltung des Anforderungslebenszyklus, die normalerweise von Anwendungsbibliotheken ausgeführt werden. Wenn Sie einen Ruby on Rails-Webserver entwickeln (nicht in das Service-Mesh integriert), der Anforderungen an Backend-Services über gRPC stelltmuss die Anwendung entscheiden, was zu tun ist, wenn N Anforderungen fehlschlagen. Sie müssen auch herausfinden, wie viel Verkehr diese Dienste verarbeiten können, und diese Parameter mithilfe einer speziellen Bibliothek fest codieren. Außerdem muss die Anwendung entscheiden, wann sie aufgeben soll, und die Anfrage wird schlecht (nach Zeitüberschreitung). Um einen der oben genannten Parameter zu ändern, muss der Webserver gestoppt, neu konfiguriert und neu gestartet werden.

Das Übertragen dieser Aufgaben auf das Service-Grid bedeutet nicht nur, dass Service-Entwickler nicht über sie nachdenken müssen, sondern dass sie auch globaler angezeigt werden können. Wenn eine komplexe Dienstkette verwendet wird, z. B. A -> B -> C -> D -> E, muss der gesamte Lebenszyklus der Anforderung berücksichtigt werden. Wenn die Aufgabe darin besteht, Zeitüberschreitungen in Dienst C zu verlängern, ist es logisch, alles auf einmal und nicht in Teilen zu tun: indem Sie den Dienstcode aktualisieren und darauf warten, dass die Pull-Anforderung akzeptiert wird und das CI-System den aktualisierten Dienst bereitstellt.

14. Telemetrie

TL; DR: Sammeln Sie alle erforderlichen (und nicht ganz) Informationen von Diensten.

Telemetrie ist ein Oberbegriff, der Metriken, verteilte Ablaufverfolgung und Protokollierung umfasst. Service Grids bieten Mechanismen zum Sammeln und Verarbeiten aller drei Datentypen. Hier wird es etwas unscharf, da so viele Optionen zur Verfügung stehen. Zum Sammeln von Metriken gibt es Prometheus und andere Tools, zum Sammeln von Protokollen können Sie fluentd , Loki , Vector usw. verwenden (z. B. ClickHouse mit unserem Blockhaus für K8s - ca. Übersetzung) . Für die verteilte Verfolgung gibt es Jaegerusw. Jedes Service-Mesh unterstützt möglicherweise einige Tools und andere nicht. Es wird gespannt sein, ob das Open Telemetry- Projekt eine gewisse Konvergenz bewirken kann .

In diesem Fall besteht der Vorteil der Service-Mesh-Technologie darin, dass Beiwagencontainer im Prinzip alle oben genannten Daten von ihren Diensten erfassen können. Mit anderen Worten, Ihnen steht ein einziges Telemetrie-Erfassungssystem zur Verfügung, und das Service-Mesh kann all diese Informationen auf unterschiedliche Weise verarbeiten. Zum Beispiel:

Schwanzprotokolle von einem bestimmten Dienst in der CLI;
Verfolgen Sie das Anforderungsvolumen über das Service-Mesh-Dashboard.
Sammeln Sie verteilte Spuren und leiten Sie sie an ein System wie Jaeger weiter.

Achtung, subjektive Beurteilung: Im Allgemeinen ist die Telemetrie ein Bereich, in dem eine starke Interferenz des Dienstnetzes unerwünscht ist. Es ist in Ordnung, grundlegende Informationen zu sammeln und einige der "goldenen Metriken" wie Erfolgsraten und Latenzen im laufenden Betrieb zu verfolgen. Wir hoffen jedoch, dass keine Frankenstein-Stapel entstehen, die versuchen, spezialisierte Systeme zu ersetzen, von denen sich einige bereits als ausgezeichnet erwiesen haben. und gut studiert.

15. Prüfung

TL; DR: Diejenigen, die die Lehren aus der Geschichte vergessen, sind dazu verdammt, sie zu wiederholen.

Auditing ist die Kunst, wichtige Ereignisse im System zu beobachten. Im Fall eines Servicenetzes kann dies bedeuten, zu verfolgen, wer Anforderungen an bestimmte Endpunkte bestimmter Services gestellt hat oder wie oft im letzten Monat ein sicherheitsrelevantes Ereignis aufgetreten ist.

Es ist klar, dass die Prüfung sehr eng mit der Telemetrie zusammenhängt. Der Unterschied besteht darin, dass Telemetrie normalerweise mit Dingen wie Leistung und technischer Korrektheit verbunden ist, während Audits mit rechtlichen und anderen Fragen in Verbindung gebracht werden können, die über den rein technischen Bereich hinausgehen (z. B. Einhaltung der Anforderungen der DSGVO - Allgemeine EU-Verordnung zum Datenschutz).

16. Visualisierung

TL; DR: Es lebe React.js - eine unerschöpfliche Quelle für ausgefallene Schnittstellen.

Vielleicht gibt es einen besseren Begriff, aber ich weiß es nicht. Ich meine nur eine grafische Darstellung des Service-Netzes oder einiger seiner Komponenten. Diese Visualisierungen können Indikatoren wie durchschnittliche Latenzen, Informationen zur Seitenwagenkonfiguration, Ergebnisse der Integritätsprüfung und Warnungen enthalten.

Das Arbeiten in einer serviceorientierten Umgebung ist mit einer viel höheren kognitiven Belastung verbunden als Seine Majestät der Monolith. Daher sollte der kognitive Druck um jeden Preis reduziert werden. Eine abgedroschene grafische Oberfläche für ein Service-Mesh mit der Möglichkeit, auf eine Schaltfläche zu klicken und das gewünschte Ergebnis zu erzielen, kann für das Wachstum dieser Technologie von entscheidender Bedeutung sein.

Nicht in der Liste enthalten

Ich hatte ursprünglich vor, ein paar weitere Anwendungsfälle in die Liste aufzunehmen, entschied mich dann aber dagegen. Hier sind sie zusammen mit den Gründen für meine Entscheidung:

Multi-Rechenzentrum . Meiner Ansicht nach ist dies weniger ein Anwendungsfall als vielmehr ein enger und spezifischer Bereich von Service Grids oder eine Reihe von Funktionen wie die Serviceerkennung.
Ein- und Ausstieg . Dies ist ein verwandter Bereich, aber ich habe mich (vielleicht künstlich) auf das Ost-West-Verkehrsszenario beschränkt. Ein- und Ausstieg verdienen einen separaten Artikel.

Fazit

Das ist alles für jetzt! Auch diese Liste ist sehr vorläufig und höchstwahrscheinlich unvollständig. Wenn Sie glauben, dass mir etwas fehlt oder ich mich in etwas irre, kontaktieren Sie mich bitte auf Twitter ( @lucperkins ). Bitte beachten Sie die Regeln des Anstands.

PS vom Übersetzer

Als Grundlage für die Titelillustration des Artikels ein Bild aus dem Artikel „ Was ist ein Service Mesh (und wann sollte eines verwendet werden)? "(Von Gregory MacKinnon). Es zeigt, wie einige der Funktionen von Anwendungen (in Grün) in das Service-Mesh verschoben wurden, das Verbindungen zwischen ihnen herstellt (in Blau).

Lesen Sie auch in unserem Blog:

Anwendungsfälle für Service-Mesh