Notiz. übersetzen: Der Autor dieses Artikels (Luc Perkins) ist ein Entwicklerbefürworter bei der CNCF-Organisation, die Open-Source-Projekte wie Linkerd, SMI (Service Mesh Interface) und Kuma beherbergt (haben Sie sich übrigens auch gefragt, warum Istio so ist?) nicht auf dieser Liste? .). Er versucht erneut, der DevOps-Community ein besseres Verständnis für den trendigen Hype namens „Service Mesh“ zu vermitteln, und listet 16 charakteristische Fähigkeiten auf, die solche Lösungen bieten.
Heute ― eines der heißesten Themen im Bereich Software Engineering (und das zu Recht!). Ich halte diese Technologie für unglaublich vielversprechend und würde mir wünschen, dass sie weit verbreitet ist (sofern es sinnvoll ist). Dennoch umgibt es für die meisten Menschen immer noch eine Aura des Geheimnisvollen. Gleichzeitig auch diejenigen, die sehr bekannt Dabei ist es oft schwierig, seine Vorteile und was genau es ist (einschließlich Ihrer eigenen) zu formulieren. In diesem Artikel werde ich versuchen, die Situation zu korrigieren, indem ich verschiedene aufführe Anwendungsfälle „Dienstnetze“*.
* Notiz Übers.: hier und weiter im Artikel wird genau diese Übersetzung („Service Mesh“) für den noch neuen Begriff Service Mesh verwendet.
Aber zuerst möchte ich ein paar Anmerkungen machen:
- Ich habe noch nie mit Service Meshes gearbeitet oder sie außerhalb von Projekten verwendet, die im Rahmen meiner eigenen Ausbildung begonnen wurden. Andererseits war ich derjenige, der 2015 eine Menge Dokumentation für das interne Service Mesh von Twitter geschrieben hat (es wurde damals noch nicht einmal „Service Mesh“ genannt) und an der Entwicklung der Website und Dokumentation dafür beteiligt war , das bedeutet also etwas.
- Meine Liste ist ungefähr und unvollständig. Möglicherweise gibt es Anwendungsfälle, die mir unbekannt sind, und wahrscheinlich werden sich im Laufe der Zeit neue Optionen ergeben, wenn sich die Technologie weiterentwickelt und ihre Popularität zunimmt.
- Gleichzeitig unterstützt nicht jede bestehende Service-Mesh-Implementierung alle aufgeführten Anwendungsfälle. Daher sollten meine Aussagen wie „Service Mesh kann…“ als „individuelle und vielleicht alle gängigen Service Mesh-Implementierungen können…“ gelesen werden.
- Die Reihenfolge der Beispiele macht keinen Unterschied.
Auswahlliste:
- Diensterkennung;
- Verschlüsselung;
- Authentifizierung und Autorisierung;
- Lastverteilung;
- Stromkreisunterbrechung;
- automatische Skalierung;
- Kanarische Einsätze;
- blau-grüne Einsätze;
- Gesundheitskontrolle;
- Lastabwurf;
- Verkehrsspiegelung;
- Isolierung;
- Begrenzung der Anforderungsrate, Wiederholungsversuche und Zeitüberschreitungen;
- Telemetrie;
- Prüfung;
- Visualisierung.
1. Diensterkennung
TL;DR: Stellen Sie über einfache Namen eine Verbindung zu anderen Diensten im Netzwerk her.
Dienste sollten in der Lage sein, einander mithilfe geeigneter Namen automatisch zu „finden“ – zum Beispiel service.api.production, pets/staging oder cassandra. Cloud-Umgebungen sind elastisch und ein einzelner Name kann viele Instanzen eines Dienstes verbergen. Es ist klar, dass es in einer solchen Situation physikalisch unmöglich ist, alle IP-Adressen fest zu kodieren.
Wenn ein Dienst einen anderen findet, sollte er außerdem in der Lage sein, Anfragen an diesen Dienst zu senden, ohne befürchten zu müssen, dass diese am Eingang seiner defekten Instanz landen. Mit anderen Worten: Das Service Mesh muss den Zustand aller Serviceinstanzen überwachen und die Liste der Hosts so aktuell wie möglich halten.
Jedes Service Mesh implementiert den Service Discovery-Mechanismus anders. Derzeit ist die Delegierung an externe Prozesse wie Kubernetes DNS die gängigste Methode. In der Vergangenheit haben wir auf Twitter zu diesem Zweck ein Benennungssystem verwendet . Darüber hinaus ermöglicht die Service-Mesh-Technologie die Entstehung benutzerdefinierter Benennungsmechanismen (obwohl ich noch keine SM-Implementierung mit einer solchen Funktionalität gesehen habe).
2. Verschlüsselung
TL;DR: Beseitigen Sie unverschlüsselten Datenverkehr zwischen Diensten und machen Sie diesen Prozess automatisiert und skalierbar.
Es ist gut 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? Wird er mit dem Intra-Service-Verkehr machen können, was er will? Hoffen wir, dass das doch nicht passiert. Um dieses Szenario zu verhindern, sollten Sie ein Zero-Trust-Netzwerk implementieren, in dem der gesamte Datenverkehr zwischen Diensten verschlüsselt ist. Die meisten modernen Servicenetze erreichen dies durch gegenseitige Unterstützung (gegenseitiges TLS, mTLS). In einigen Fällen funktioniert mTLS in ganzen Wolken und Clustern (ich denke, dass die interplanetare Kommunikation eines Tages ähnlich organisiert sein wird).
Natürlich für mTLS-Service-Mesh Optional. Jeder Dienst kann sich um sein eigenes TLS kümmern, aber das bedeutet, dass Sie eine Möglichkeit finden müssen, Zertifikate zu generieren, sie auf Diensthosts zu verteilen und Code in die Anwendung einzubinden, der diese Zertifikate aus Dateien lädt. Ja, vergessen Sie nicht, diese Zertifikate in regelmäßigen Abständen zu erneuern. Service Meshes automatisieren mTLS mit Systemen wie , die wiederum den Prozess der Ausstellung und Rotation von Zertifikaten automatisieren.
3. Authentifizierung und Autorisierung
TL;DR: Stellen Sie fest, wer der Anforderer ist, und legen Sie fest, was er tun darf, bevor die Anfrage überhaupt den Dienst erreicht.
Dienste wollen es oft wissen welche führt die Anfrage durch (Authentifizierung) und entscheidet anhand dieser Informationen dass eine bestimmte Entität tun darf (Autorisierung). In diesem Fall kann das Pronomen „who“ Folgendes verbergen:
- Andere Dienstleistungen. Dies wird als „Authentifizierung“ bezeichnet. Peer" Zum Beispiel Service
webmöchte auf den Dienst zugreifendb. Service Meshes lösen solche Probleme in der Regel mit mTLS: Zertifikate fungieren in diesem Fall als notwendige Kennung. - Einige menschliche Benutzer. Dies wird als „Authentifizierung“ bezeichnet. Verzicht" Beispiel: Benutzer
haxor69möchte eine neue Lampe kaufen. Service Meshes stellen verschiedene Mechanismen bereit, z.B. .Viele von uns haben dies im Anwendungscode getan. Eine Anfrage geht ein, wir schauen uns die Tabelle an
users, suchen Sie den Benutzer, vergleichen Sie das Passwort und überprüfen Sie dann die Spaltepermissionsusw. Im Falle eines Service Mesh geschieht dies, bevor die Anfrage überhaupt den Service erreicht.
Sobald wir festgestellt haben, von wem die Anfrage stammt, müssen wir festlegen, was diese Entität tun darf. Bei einigen Service Meshes können Sie grundlegende Richtlinien (darüber, wer was tun kann) als YAML-Dateien oder in der Befehlszeile festlegen, während andere eine Integration mit Frameworks wie z. B. bieten . Das ultimative Ziel besteht darin, dass Ihre Dienste jede Anfrage annehmen, vorausgesetzt, sie stammt von einer vertrauenswürdigen Quelle и Diese Aktion ist zulässig.
4. Balansirowka-Nagruzki
TL;DR: Verteilen Sie die Last nach einem bestimmten Muster auf die Dienstinstanzen.
Ein „Service“ innerhalb eines Serviceabschnitts besteht sehr oft aus vielen identischen Instanzen. Zum Beispiel heute der Service cache besteht aus 5 Exemplaren, und morgen kann sich ihre Zahl auf 11 erhöhen. Anfragen werden an gesendet cache, müssen zweckgebunden verteilt werden. Minimieren Sie beispielsweise die Latenz oder maximieren Sie die Wahrscheinlichkeit, zu einer funktionierenden Instanz zu gelangen. Der am häufigsten verwendete Algorithmus ist Round-Robin, es gibt jedoch noch viele andere – zum Beispiel die gewichtete Methode (gewichtet) Anfragen (Sie können bevorzugte Ziele auswählen), klingeln (Ring) Hashing (unter Verwendung konsistenten Hashings über Upstream-Hosts hinweg) oder Methode der geringsten Anforderung (die Instanz mit den wenigsten Anforderungen wird bevorzugt).
Klassische Balancer verfügen über weitere Funktionen wie HTTP-Caching und DDoS-Schutz, sind jedoch für den Ost-West-Verkehr (also für den innerhalb eines Rechenzentrums fließenden Verkehr) nicht sehr relevant (typischer Leistungsumfang eines Mesh). Natürlich ist es nicht notwendig, ein Service-Mesh für den Lastausgleich zu verwenden, aber es ermöglicht Ihnen, Ausgleichsrichtlinien für jeden Dienst von einer zentralen Kontrollschicht aus festzulegen und zu steuern, wodurch die Notwendigkeit entfällt, separate Lastausgleichsfunktionen im Netzwerkstapel auszuführen und zu konfigurieren .
5. Stromkreisunterbrechung
TL;DR: Stoppen Sie den Datenverkehr zum problematischen Dienst und kontrollieren Sie den Schaden im schlimmsten Fall.
Wenn der Dienst aus irgendeinem Grund den Datenverkehr nicht bewältigen kann, bietet das Service Mesh mehrere Optionen zur Lösung dieses Problems (andere werden in den entsprechenden Abschnitten besprochen). Die Unterbrechung eines Stromkreises ist die schwerwiegendste Möglichkeit, einen Dienst vom Verkehr zu trennen. Für sich genommen ergibt dies jedoch keinen Sinn – es ist ein Backup-Plan erforderlich. Gegendruck kann bereitgestellt werden () zu Diensten, die Anfragen stellen (vergessen Sie nur nicht, Ihr Service-Mesh dafür zu konfigurieren!), oder zum Beispiel die Statusseite rot zu färben und Benutzer mit einem „fallenden Wal“ („Twitter ist …“) auf eine andere Version der Seite umzuleiten runter").
Mit Service Meshes können Sie nicht nur definieren wenn Die Abschaltung wird folgen und dass das wird folgen. In diesem Fall kann „wann“ eine beliebige Kombination angegebener Parameter umfassen: die Gesamtzahl der Anfragen für einen bestimmten Zeitraum, die Anzahl paralleler Verbindungen, ausstehende Anfragen, aktive Wiederholungsversuche usw.
Sie möchten die Stromkreisunterbrechung wahrscheinlich nicht missbrauchen, aber es ist gut zu wissen, dass Sie für den Notfall einen Backup-Plan haben.
6. Autoskalierung
TL;DR: Erhöhen oder verringern Sie die Anzahl der Dienstinstanzen abhängig von den angegebenen Kriterien.
Service Meshes sind keine Scheduler, also auch nicht durchführen sich selbst skalieren. Sie können jedoch Aufschluss darüber geben, auf welche Planer sich ihre Entscheidungen stützen werden. Da Service Meshes Zugriff auf den gesamten Datenverkehr zwischen Diensten haben, verfügen sie über umfangreiche Informationen darüber, was passiert: Bei welchen Diensten treten Probleme auf, bei welchen Diensten ist die Auslastung sehr gering (die ihnen zugewiesene Kapazität wird verschwendet) usw.
Beispielsweise skaliert Kubernetes Dienste basierend auf der CPU- und Speichernutzung der Pods (siehe unseren Bericht „" - ca. übersetzt), aber wenn Sie sich für eine Skalierung basierend auf einer anderen Metrik (in unserem Fall verkehrsbezogen) entscheiden, benötigen Sie eine spezielle Metrik. Management zeigt, wie man das macht , и , aber der Prozess selbst ist ziemlich kompliziert. Wir möchten, dass das Service Mesh dies vereinfacht, indem es uns ermöglicht, einfach Bedingungen wie „Anzahl der Serviceinstanzen erhöhen“ festzulegen auth, wenn die Anzahl der ausstehenden Anfragen innerhalb einer Minute den Schwellenwert überschreitet.“
7. Kanarische Bereitstellungen
TL;DR: Testen Sie neue Funktionen oder Dienstversionen an einer Untergruppe von Benutzern.
Nehmen wir an, Sie entwickeln ein SaaS-Produkt und beabsichtigen, eine coole neue Version davon auf den Markt zu bringen. Sie haben es im Staging getestet und es hat großartig funktioniert. Es gibt jedoch immer noch gewisse Bedenken hinsichtlich ihres Verhaltens unter realen Bedingungen. Mit anderen Worten: Sie müssen die neue Version anhand realer Probleme testen, ohne das Vertrauen der Benutzer zu gefährden. Canary-Bereitstellungen eignen sich hierfür hervorragend. Sie ermöglichen es Ihnen, einer Untergruppe von Benutzern eine neue Funktion zu demonstrieren. Diese Untergruppe kann aus den treuesten Benutzern oder solchen bestehen, die mit der kostenlosen Version des Produkts arbeiten, oder aus Benutzern, die den Wunsch geäußert haben, „Versuchskaninchen“ zu sein.
Service Meshes implementieren dies, indem sie es Ihnen ermöglichen, Kriterien festzulegen, die bestimmen, wer welche Version der Anwendung sieht, und den Datenverkehr entsprechend weiterzuleiten. Für die Dienste selbst ändert sich jedoch nichts. Version 1.0 des Dienstes geht davon aus, dass alle Anfragen von Benutzern stammen, die ihn sehen sollten, und Version 1.1 geht davon aus, dass dies auch für seine Benutzer der Fall ist. In der Zwischenzeit können Sie den Prozentsatz des Datenverkehrs zwischen der alten und der neuen Version ändern und so eine wachsende Anzahl von Benutzern auf die neue umleiten, wenn diese stabil funktioniert und Ihre „Versuchskaninchen“ grünes Licht geben.
8. Blau-grüne Einsätze
TL;DR: Führen Sie eine coole neue Funktion ein, aber seien Sie bereit, alles sofort zurückzunehmen.
Bedeutung besteht darin, einen neuen „blauen“ Dienst parallel zum alten „grünen“ einzuführen. Wenn alles reibungslos läuft und der neue Dienst gut funktioniert, kann der alte nach und nach deaktiviert werden. (Leider wird dieser neue „blaue“ Dienst eines Tages das Schicksal des „grünen“ wiederholen und verschwinden ...) Blau-grüne Bereitstellungen unterscheiden sich von kanarischen Bereitstellungen darin, dass die neue Funktion Folgendes abdeckt auf einmal Benutzer (nicht Teil); Hier geht es darum, einen „sicheren Hafen“ parat zu haben, für den Fall, dass etwas schief geht.
Service Meshes bieten eine sehr komfortable Möglichkeit, einen „blauen“ Dienst zu testen und bei Problemen sofort auf einen funktionierenden „grünen“ umzuschalten. Ganz zu schweigen von der Tatsache, dass sie unterwegs viele Informationen (siehe „Telemetrie“ unten) über die Arbeit des „Blauen“ liefern, die helfen zu verstehen, ob es für den vollen Betrieb bereit ist.
Notiz. übersetzen: Weitere Informationen zu verschiedenen Bereitstellungsstrategien in Kubernetes (einschließlich der erwähnten Canary-, Blue/Green- und anderen) finden Sie in .
9. Gesundheitscheck
TL;DR: Verfolgen Sie, welche Dienstinstanzen funktionsfähig sind, und reagieren Sie auf diejenigen, die nicht mehr funktionsfähig sind.
Gesundheitskontrolle (Gesundheitskontrolle) Hilft bei der Entscheidung, ob Dienstinstanzen bereit sind, Datenverkehr anzunehmen und zu verarbeiten. Bei HTTP-Diensten könnte eine Integritätsprüfung beispielsweise wie eine GET-Anfrage an den Endpunkt aussehen /health... Antworten 200 OK bedeutet, dass die Instanz fehlerfrei ist, jede andere bedeutet, dass sie nicht bereit ist, Datenverkehr zu empfangen. Mit Service Meshes können Sie sowohl die Art und Weise der Funktionsprüfung als auch die Häufigkeit festlegen, mit der diese Prüfung durchgeführt wird. Diese Informationen können dann für andere Zwecke genutzt werden – beispielsweise zum Lastausgleich und zur Stromkreisunterbrechung.
Somit ist Health Checking kein eigenständiger Anwendungsfall, sondern wird in der Regel zur Erreichung anderer Ziele eingesetzt. Abhängig von den Ergebnissen der Gesundheitsprüfungen können außerdem Aktionen außerhalb anderer Service-Mesh-Ziele erforderlich sein: beispielsweise das Aktualisieren der Statusseite, das Erstellen eines Problems auf GitHub oder das Ausfüllen eines JIRA-Tickets. Und Service Mesh bietet einen praktischen Mechanismus, um all dies zu automatisieren.
10. Lastabwurf
TL;DR: Leiten Sie den Datenverkehr als Reaktion auf einen vorübergehenden Anstieg der Nutzung um.
Wenn ein bestimmter Dienst mit Datenverkehr überlastet ist, können Sie einen Teil dieses Datenverkehrs vorübergehend an einen anderen Ort umleiten (d. h. „Dump“, „Transfer“). (Baracke) ihn dort). Zum Beispiel an einen Backup-Dienst oder ein Rechenzentrum oder an eine permanente Thema. Infolgedessen verarbeitet der Dienst weiterhin einige Anfragen, anstatt abzustürzen und die Verarbeitung vollständig einzustellen. Ein Lastabwurf ist der Unterbrechung des Stromkreises vorzuziehen, es ist jedoch dennoch nicht ratsam, ihn zu missbrauchen. Es hilft, kaskadierende Fehler zu verhindern, die zum Absturz nachgelagerter Dienste führen.
11. Parallelisierung/Spiegelung des Datenverkehrs
TL;DR: Senden Sie eine Anfrage gleichzeitig an mehrere Orte.
Manchmal besteht die Notwendigkeit, eine Anfrage (oder eine bestimmte Auswahl von Anfragen) gleichzeitig an mehrere Dienste zu senden. Ein typisches Beispiel ist das Senden eines Teils des Produktionsverkehrs an einen Staging-Dienst. Der Hauptproduktions-Webserver sendet eine Anfrage an den Downstream-Dienst products.production und nur für ihn. Und das Service-Mesh kopiert diese Anfrage intelligent und sendet sie an products.staging, was dem Webserver nicht einmal bekannt ist.
Ein weiterer verwandter Service-Mesh-Anwendungsfall, der zusätzlich zur Verkehrsparallelisierung implementiert werden kann, ist . Dabei geht es darum, dieselben Anfragen an verschiedene Versionen des Dienstes zu senden und zu prüfen, ob sich alle Versionen gleich verhalten. Ich bin noch nicht auf eine Service-Mesh-Implementierung mit einem integrierten Regressionstestsystem wie dieser gestoßen , aber die Idee selbst scheint vielversprechend.
12. Isolierung
TL;DR: Teilen Sie Ihr Service-Mesh in Mini-Netzwerke auf.
Auch bekannt als SegmentierungIsolation ist die Kunst, ein Service Mesh in logisch unterschiedliche Segmente zu unterteilen, die nichts voneinander wissen. Isolation ist ein bisschen wie die Schaffung virtueller privater Netzwerke. Der grundlegende Unterschied besteht darin, dass Sie weiterhin alle Vorteile eines Service Mesh (wie Service Discovery) nutzen können, jedoch mit zusätzlicher Sicherheit. Wenn es einem Angreifer beispielsweise gelingt, in einen Dienst in einem Subnetz einzudringen, kann er nicht sehen, welche Dienste in anderen Subnetzen ausgeführt werden, oder deren Datenverkehr abfangen.
Darüber hinaus können die Vorteile auch organisatorischer Natur sein. Möglicherweise möchten Sie Ihre Dienste basierend auf Ihrer Unternehmensstruktur in Subnetze unterteilen und Entwicklern die kognitive Belastung ersparen, die mit der Berücksichtigung des gesamten Servicenetzes verbunden ist.
13. Begrenzung der Anforderungsrate, Wiederholungsversuche und Zeitüberschreitungen
TL;DR: Sie müssen die grundlegenden Aufgaben zur Anforderungsverwaltung nicht mehr in Ihre Codebasis aufnehmen.
Alle diese Dinge könnten als separate Anwendungsfälle betrachtet werden, aber ich habe mich aufgrund eines gemeinsamen Merkmals entschieden, sie zu kombinieren: Sie übernehmen die Aufgaben des Anforderungslebenszyklusmanagements, die normalerweise von Anwendungsbibliotheken erledigt werden. Wenn Sie einen Webserver in Ruby on Rails entwickeln (nicht in ein Service-Mesh integriert), der Anfragen an Backend-Dienste über sendet , muss die Anwendung entscheiden, was zu tun ist, wenn N Anfragen fehlschlagen. Sie müssen außerdem herausfinden, wie viel Datenverkehr diese Dienste verarbeiten können, und diese Parameter mithilfe einer speziellen Bibliothek fest codieren. Außerdem muss die Anwendung entscheiden, wann es Zeit ist aufzugeben und die Anfrage im Sande verlaufen zu lassen (basierend auf der Zeitüberschreitung). Und um einen der oben genannten Parameter zu ändern, muss der Webserver gestoppt, neu konfiguriert und erneut gestartet werden.
Die Auslagerung dieser Aufgaben in ein Service-Mesh bedeutet nicht nur, dass sich Service-Entwickler keine Gedanken darüber machen müssen, sondern auch, dass sie globaler betrachtet werden können. Wenn eine komplexe Kette von Diensten verwendet wird, beispielsweise A -> B -> C -> D -> E, muss der gesamte Lebenszyklus der Anfrage berücksichtigt werden. Wenn die Aufgabe darin besteht, Zeitüberschreitungen in Dienst C zu verlängern, ist es logisch, dies alles auf einmal und nicht in Teilen zu tun: indem Sie den Dienstcode aktualisieren und warten, bis die Pull-Anfrage akzeptiert wird und das CI-System den aktualisierten Dienst bereitstellt.
14. Telemetrie
TL;DR: Sammeln Sie alle notwendigen (und nicht ganz) Informationen von Diensten.
Telemetrie ist ein allgemeiner Begriff, der Metriken, verteilte Ablaufverfolgung und Protokolle umfasst. Service Meshes bieten Mechanismen zum Sammeln und Verarbeiten aller drei Datentypen. Hier wird es etwas unübersichtlich, weil die Zahl der möglichen Optionen zu groß ist. Um Metriken zu sammeln, gibt es und andere Tools, die zum Sammeln von Protokollen verwendet werden können , , usw. (zum Beispiel ClickHouse mit unserem für K8s - ca. übersetzt), für verteiltes Tracing gibt es usw. Jedes Service-Mesh unterstützt möglicherweise einige Tools, andere jedoch nicht. Es wird interessant sein zu sehen, ob das Projekt dies kann sorgen für eine gewisse Konvergenz.
Der Vorteil der Service-Mesh-Technologie besteht in diesem Fall darin, dass Sidecar-Container grundsätzlich alle oben genannten Daten aus ihren Diensten sammeln können. Mit anderen Worten: Ihnen steht ein einziges Telemetrie-Erfassungssystem zur Verfügung, und das Service-Mesh kann alle diese Informationen auf verschiedene Weise verarbeiten. Zum Beispiel:
- Tail-Logs von einem bestimmten Dienst in der CLI;
- Überwachen Sie das Anfragevolumen über das Service-Mesh-Dashboard.
- Sammeln Sie verteilte Spuren und leiten Sie sie an ein System wie Jaeger weiter.
Achtung, subjektives Urteil: Generell handelt es sich bei der Telemetrie um einen Bereich, in dem starke Störungen durch das Service Mesh unerwünscht sind. Das Sammeln grundlegender Informationen und das spontane Verfolgen einiger goldener Metriken wie der Erfolgsquote von Anfragen und der Latenz ist in Ordnung, aber hoffen wir, dass keine Frankenstein-Stacks auftauchen, die versuchen, spezialisierte Systeme zu ersetzen, von denen sich einige bereits bewährt und gut untersucht haben .
15. Audit
TL;DR: Wer die Lehren der Geschichte vergisst, ist dazu verdammt, sie zu wiederholen.
Auditing ist die Kunst, wichtige Ereignisse in einem System zu beobachten. Im Fall eines Service Mesh könnte dies bedeuten, dass nachverfolgt werden soll, wer Anfragen für bestimmte Dienste an bestimmte Endpunkte gestellt hat oder wie oft im letzten Monat ein sicherheitsrelevantes Ereignis aufgetreten ist.
Es ist klar, dass Auditing sehr eng mit Telemetrie verbunden ist. Der Unterschied besteht darin, dass Telemetrie normalerweise mit Dingen wie Produktivität und technischer Integrität verbunden ist, während sich Audits auf rechtliche und andere Themen beziehen können, die über den rein technischen Bereich hinausgehen (z. B. Einhaltung der DSGVO – der EU-Datenschutz-Grundverordnung).
16. Visualisierung
TL;DR: Es lebe React.js – eine unerschöpfliche Quelle ausgefallener Schnittstellen.
Es gibt vielleicht einen besseren Begriff, aber ich kenne ihn nicht. Ich meine einfach eine grafische Darstellung eines Service Mesh oder einiger seiner Komponenten. Diese Visualisierungen können Indikatoren wie durchschnittliche Latenzen, Informationen zur Sidecar-Konfiguration, Ergebnisse der Integritätsprüfung und Warnungen umfassen.
Die Arbeit in einer serviceorientierten Umgebung ist im Vergleich zu Seiner Majestät dem Monolithen mit einer viel höheren kognitiven Belastung verbunden. Daher sollte der kognitive Druck unbedingt reduziert werden. Eine einfache grafische Oberfläche für ein Service-Mesh mit der Möglichkeit, auf eine Schaltfläche zu klicken und das gewünschte Ergebnis zu erhalten, könnte entscheidend für die wachsende Beliebtheit dieser Technologie sein.
Wurden nicht in die Liste aufgenommen
Ursprünglich hatte ich vor, noch ein paar weitere Anwendungsfälle in die Liste aufzunehmen, habe mich dann aber dagegen entschieden. Hier sind sie, zusammen mit den Gründen für meine Entscheidung:
- Multi-Rechenzentrum. Meiner Meinung nach handelt es sich hierbei weniger um einen Anwendungsfall als vielmehr um einen engen und spezifischen Anwendungsbereich von Service Meshes oder einer Reihe von Funktionen wie der Service Discovery.
- Ein- und Ausstieg. Dies ist ein verwandter Bereich, aber ich habe mich (vielleicht künstlich) auf den Anwendungsfall „Ost-West-Verkehr“ beschränkt. Ingress und Egress verdienen einen separaten Artikel.
Fazit
Das ist alles für jetzt! Auch diese Liste ist sehr willkürlich und höchstwahrscheinlich unvollständig. Wenn Sie glauben, dass ich etwas übersehen habe oder etwas falsch gemacht habe, kontaktieren Sie mich bitte auf Twitter (). Bitte respektieren Sie die Regeln des Anstands.
PS vom Übersetzer
Die Titelillustration des Artikels basiert auf einem Bild aus dem Artikel „"(von Gregory MacKinnon). Es zeigt, wie einige Funktionen von Anwendungen (in Grün) in ein Service-Mesh verschoben wurden, das Verbindungen zwischen ihnen bereitstellt (in Blau).
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «".
Source: habr.com
