Service Mesh – ein bewährtes Architektur-Muster zur Integration von Microservices und zur Migration in die Cloud-Infrastruktur. In der heutigen, cloud-basierten Container-Welt ist es schwer, darauf zu verzichten. Mehrere Open-Source-Implementierungen von Service Mesh sind bereits auf dem Markt, aber ihre Funktionalität, Zuverlässigkeit und Sicherheit sind oft nicht ausreichend, insbesondere wenn es um die Anforderungen großer Finanzunternehmen von nationalem Maßstab geht. Deshalb haben wir bei Sbertech beschlossen, Service Mesh zu individualisieren, und möchten Ihnen zeigen, was an Service Mesh großartig ist, was weniger und welche Maßnahmen wir ergreifen wollen.
Die Beliebtheit des Service Mesh-Musters wächst mit der Verbreitung von Cloud-Technologien. Es handelt sich um eine dedizierte Infrastrukturebene, die die Interaktion zwischen verschiedenen Netzwerkdiensten vereinfacht. Moderne Cloud-Anwendungen bestehen aus Hunderten und sogar Tausenden solcher Dienste, von denen jeder Tausende von Kopien haben kann.
Die Interaktion und Verwaltung dieser Dienste ist die Schlüsselaufgabe von Service Mesh. Tatsächlich handelt es sich um ein Netzwerkmodell mit vielen Proxys, die zentral verwaltet werden und eine Reihe sehr nützlicher Funktionen ausführen.
Auf der Proxy-Ebene (Data Plane):
- Zuweisung und Verbreitung von Routing- und Lastenausgleichsrichtlinien
- Verbreitung von Schlüsseln, Zertifikaten, Tokens
- Erfassung von Telemetriedaten, Erstellung von Überwachungsmetriken
- Integration mit Sicherheits- und Überwachungsinfrastrukturen
Auf der Steuerungsebene (Control Plane):
- Anwendung von Routing- und Lastenausgleichsrichtlinien
- Verwaltung von Wiederholungen und Zeitüberschreitungen, Identifizierung von ‚toten‘ Knoten (Circuit Breaking), Handhabung von Fehlersituationen (Injecting Faults) und Gewährleistung der Resilienz von Diensten durch andere Mechanismen
- Authentifizierung/Autorisierung von Aufrufen
- Abweisung von Metriken (Observability)
Die Gruppe der Anwender, die an dieser Technologie interessiert ist, ist sehr breit gefächert — von kleinen Startups bis hin zu großen Internetunternehmen wie PayPal.
Wozu wird ein Service Mesh im Unternehmenssektor benötigt?
Die Nutzung eines Service Mesh bringt zahlreiche offensichtliche Vorteile mit sich. Vor allem ist es für Entwickler einfach praktisch: beim Programmieren entsteht eine technologische Plattform, das die Integration in die Cloud-Infrastruktur erheblich vereinfacht, da die Transportschicht vollständig von der Anwendungslogik isoliert ist.
Darüber hinaus, Service Mesh erleichtert die Beziehungen zwischen Anbietern und Verbrauchern. Heute ist es für API-Anbieter und -Verbraucher viel einfacher, sich selbstständig über Schnittstellen und Verträge zu einigen, ohne einen speziellen Integrationsvermittler oder Schiedsrichter – die Unternehmens-Service-Schicht – hinzuzuziehen. Dieser Ansatz hat erhebliche Auswirkungen auf zwei Kennzahlen. Die Markteinführungszeit (Time-to-Market) für neue Funktionalitäten wird verkürzt, gleichzeitig steigen jedoch die Kosten für die Lösung, da die Integration selbstständig durchgeführt werden muss. Der Einsatz von Service Mesh durch die Teams, die Business-Funktionalitäten entwickeln, ermöglicht es, hier ein Gleichgewicht zu wahren. Letztendlich können API-Anbieter sich ausschließlich auf die Anwendungsaspekte ihres Dienstes konzentrieren und ihn einfach im Service Mesh veröffentlichen – die API wird sofort für alle Kunden verfügbar, und die Integrationsqualität ist produktionsbereit und erfordert keinen zusätzlichen Code.
Ein weiterer Vorteil ist, dass Der Entwickler, der Service Mesh nutzt, konzentriert sich ausschließlich auf die geschäftliche Funktionalität — auf die Produktseite und nicht auf die technologische Grundlage seines Services. Zum Beispiel muss man sich keine Gedanken mehr darüber machen, dass es in einer Situation, in der der Service über das Netz aufgerufen wird, zu einem Verbindungsabbruch kommen könnte. Darüber hinaus hilft Service Mesh, den Traffic zwischen Kopien desselben Services auszugleichen: Wenn eine der Kopien ausfällt, wird das System den gesamten Traffic auf die verbliebenen aktiven Kopien umleiten.
Service Mesh — ist eine gute Grundlage für die Entwicklung verteilter Anwendungen, die dem Kunden die Details der Bereitstellung seiner Serviceaufrufe sowohl von innen als auch von außen verbergen. Alle Anwendungen, die Service Mesh verwenden, sind auf Transportebene sowohl vom Netzwerk als auch voneinander isoliert: Es gibt keine Verbindungen zwischen ihnen. Der Entwickler hat somit die volle Kontrolle über seine Services.
Es sei nicht unerwähnt, dass das Aktualisieren verteilter Anwendungen in einer Umgebung, in der Service Mesh eingesetzt wird, einfacher wird. Beispielsweise ein Blue/Green-Deployment, bei dem zwei Anwendungsumgebungen für die Installation zur Verfügung stehen, von denen eine nicht aktualisiert wird und im Standby-Betrieb bleibt. Die Rückkehr zur vorherigen Version im Falle einer fehlerhaften Veröffentlichung erfolgt über einen speziellen Router, für den das Service Mesh hervorragend geeignet ist.. Für das Testen einer neuen Version kann auch eine Canary-Version verwendet werden, bei der nur 10 % des Traffics oder Anfragen von einer Pilotgruppe von Kunden auf die neue Version umgeschaltet werden. Der Haupttraffic bleibt auf der alten Version, sodass nichts kaputtgeht.
Außerdem Das Service Mesh bietet uns die Kontrolle über SLA in Echtzeit. Das System verteilte Proxys lässt den Dienst nicht ausfallen, selbst wenn ein Kunde sein Kontingent überschreitet. Wenn die API-Bandbreite begrenzt ist, kann niemand den Dienst mit einer hohen Anzahl von Transaktionen überlasten: Das Service Mesh steht vor dem Dienst und blockiert unnötigen Traffic. Er wird einfach an der Integrationsschicht abgewiesen, während die Dienste weiterhin normal funktionieren, ohne es zu bemerken.
Wenn das Unternehmen die Ausgaben für die Entwicklung von Integrationslösungen senken möchte, ist das Service Mesh auch hilfreich: auf seine Open-Source-Version kann von kommerziellen Produkten umgestiegen werden.. Unser Enterprise Service Mesh basiert auf der Open-Source-Version von Service Mesh.
Ein weiterer Vorteil ist das Vorhandensein eines umfassenden Sets an Integrationsdiensten. Da die gesamte Integration über diese Zwischenschicht erfolgt, können wir den gesamten Integrationsverkehr und die Verbindungen zwischen den Anwendungen, die das Geschäfts-Kern bilden, verwalten. Das ist äußerst praktisch.
Und schließlich fördert das Service Mesh das Unternehmen, auf eine dynamische Infrastruktur umzusteigen. Aktuell neigen viele dazu, Containerisierung als Lösung in Betracht zu ziehen. Monolithen in Mikrodienste zu zerlegen und diese elegant zu implementieren, ist ein aufstrebendes Thema. Doch wenn man versucht, ein bereits seit vielen Jahren im Produktionsbetrieb befindliches System auf neue Schienen zu bringen, stehen einem sofort zahlreiche Herausforderungen gegenüber: Es ist nicht einfach, all das in Container zu packen und auf der Plattform bereitzustellen. Darüber hinaus ist die Implementierung, Synchronisierung und Interaktion dieser verteilten Komponenten ein weiteres komplexes Thema. Wie werden sie miteinander kommunizieren? Gibt es das Risiko von Kaskadenausfällen? Ein Service Mesh kann helfen, einen Teil dieser Probleme zu lösen und die Migration von einer alten Architektur zu einer neuen zu erleichtern, indem man die Logik des Datenaustauschs ausblendet.
Warum ist die Anpassung des Service Mesh erforderlich?
In unserem Unternehmen koexistieren Hunderte von Systemen und Modulen, und die Laufzeit ist stark belastet. Daher reicht ein einfaches Muster, bei dem ein System ein anderes aufruft und eine Antwort erhält, nicht aus, denn in der Produktion verlangen wir mehr. Was benötigen wir zusätzlich von einem Unternehmens-Service Mesh?
Ereignisverarbeitungsservice
Stellen wir uns vor, wir müssen eine Echtzeit-Eventverarbeitung einrichten – ein System, das in Echtzeit die Kundenaktionen analysiert und sofort ein relevantes Angebot unterbreiten kann. Um eine solche Funktionalität zu realisieren, wird ein architektonisches Muster namens Event-Driven Architecture (EDA) verwendet.Kein aktuelles Service Mesh unterstützt solche Muster nativ, was besonders für Banken von großer Bedeutung ist!
Es ist ziemlich seltsam, dass alle Versionen des Remote Procedure Call (RPC) von Service Mesh unterstützt werden, aber nicht mit EDA zusammenarbeiten. Denn Service Mesh ähnelt einer modernen verteilten Integration, während EDA ein sehr aktuelles architektonisches Muster ist, das einzigartige Möglichkeiten im Bereich des Kundenerlebens eröffnet.
Unser Enterprise Service Mesh sollte dieses Problem lösen. Außerdem möchten wir die Implementierung einer garantierten Zustellung, einer Streaming- und umfassenden Eventverarbeitung mit verschiedenen Filtern und Vorlagen darin sehen.
Dateiübertragungsdienst
Neben EDA wäre es vorteilhaft, auch die Möglichkeit der Dateitransfer zur Verfügung zu haben: Im Enterprise-Bereich ist häufig nur eine Datei-Integration möglich. Hierbei kommt oft das Architekturmuster ETL (Extract, Transform, Load — „Extrahieren, Transformieren, Laden“) zum Einsatz. In diesem Schema tauschen alle Beteiligten vorwiegend Dateien aus: Es werden große Datenmengen verwendet, die es nicht sinnvoll machen, sie über separate Anfragen zu übertragen. Die native Unterstützung für Dateitransfers im Enterprise Service Mesh bietet die notwendige Flexibilität für das Geschäft.
Orchestrierungsdienst
In großen Organisationen gibt es nahezu immer unterschiedliche Teams, die verschiedene Produkte entwickeln. Zum Beispiel arbeiten in einer Bank einige Teams an Einlagen, während andere sich mit Kreditprodukten beschäftigen, und solche Fälle gibt es viele. Es sind unterschiedliche Personen, unterschiedliche Teams, die ihre eigenen Produkte erstellen, ihre eigenen APIs entwickeln und diese anderen zur Verfügung stellen. Oft entsteht die Notwendigkeit, diese Dienste zu kombinieren sowie komplexe Logik für die sequenzielle Aufrufreihe einer Reihe von APIs zu implementieren. Um dieses Problem zu lösen, ist eine Lösung auf der Integrationsebene erforderlich, die es ermöglicht, diese gesamte Kompositionslogik zu vereinfachen (Ausführen mehrerer APIs, Beschreibung der Anfragepfade usw.). Dies ist der Orchestrierungsdienst im Enterprise Service Mesh.
AI und ML
Wenn Mikrodienste über eine einheitliche Integrationsschicht miteinander kommunizieren, weiß das Service Mesh natürlich alles über die Aufrufe jedes Dienstes. Wir sammeln Telemetrie: wer wen wann und wie oft aufgerufen hat und so weiter. Wenn es von diesen Diensten Hunderttausende gibt und die Aufrufe in die Milliarden gehen, häuft sich das alles und bildet Big Data. Diese Daten können mit Hilfe von KI, maschinellem Lernen und ähnlichem analysiert werden, um dann auf Basis der Analyseergebnisse nützliche Dinge zu entwickeln. Es wäre sinnvoll, zumindest teilweise die Kontrolle über den gesamten Netzwerkverkehr und die Anwendungsaufrufe, die im Service Mesh integriert sind, an die künstliche Intelligenz zu übergeben.
API-Gateway
In der Regel gibt es im Service Mesh Proxys und Dienste, die innerhalb eines vertrauenswürdigen Rahmens miteinander kommunizieren. Es gibt jedoch auch externe Partner. Die Anforderungen an die APIs, die dieser Nutzergruppe bereitgestellt werden, sind deutlich strenger. Diese Aufgabe teilen wir in zwei Hauptteile auf.
- Sicherheit. Fragen, die mit DDoS, Protokollanfälligkeiten, Anwendungs- und Betriebssystemschwächen usw. zu tun haben.
- Maßstäbe. Wenn es darum geht, dass die API-Abrechnung, die an Kunden weitergegeben werden muss, in die Tausende oder sogar Hunderttausende geht, entsteht der Bedarf an einem Management-Tool für dieses API-Set. Es ist notwendig, APIs ständig zu überwachen: ob sie funktionieren, in welchem Status sie sich befinden, welcher Datenverkehr läuft, welche Statistiken vorhanden sind usw. Das API-Gateway sollte in der Lage sein, diese Aufgabe zu bewältigen, um den gesamten Prozess steuerbar und sicher zu gestalten. Mit diesem Bestandteil lernt das Enterprise Service Mesh, interne sowie externe APIs ohne unnötige Komplikationen zu veröffentlichen.
Dienst zur Unterstützung spezifischer Protokolle und Datenformaten (API-Gateway)
Derzeit können die meisten Service-Mesh-Lösungen nativ nur mit HTTP- und HTTP2-Verkehr arbeiten oder leisten dies in einer eingeschränkten Form auf TCP/IP-Ebene. Das Enterprise Service Mesh bietet jedoch viele weitere spezifische Datenübertragungsprotokolle. Einige Systeme nutzen Nachrichtenbroker, während andere auf Datenbankebene integriert sind. Wenn ein Unternehmen SAP besitzt, kann es auch sein eigenes Integrationssystem verwenden. All dies funktioniert und ist ein wichtiger Teil des Geschäfts.
Es reicht nicht zu sagen: „Lassen Sie uns auf Legacy verzichten und neue Systeme schaffen, die Service Mesh nutzen können“. Um alle alten Systeme mit neuen (auf Mikrodiensten basierenden) zu verbinden, benötigen die Systeme, die Service Mesh nutzen können, einen Adapter, einen Vermittler, ein Gateway. Wäre es nicht großartig, wenn dies standardmäßig mit dem Service geliefert würde? Das AS-Gateway kann genau jede Integrationsoption unterstützen. Stellen Sie sich vor, Sie installieren einfach ein Enterprise Service Mesh, und es ist bereits bereit, mit all den Protokollen zu interagieren, die Sie benötigen. Dieser Ansatz ist für uns von großer Bedeutung.
So stellen wir uns die Unternehmensversion von Service Mesh (Enterprise Service Mesh) vor. Die beschriebene Anpassung löst die meisten Probleme, die bei dem Versuch auftreten, fertig entwickelte Open-Source-Versionen von Integrationsplattformen zu verwenden. Die Architektur von Service Mesh, die vor nur wenigen Jahren entstanden ist, entwickelt sich weiterhin, und wir freuen uns, einen Beitrag zu ihrer Weiterentwicklung leisten zu können. Wir hoffen, dass unsere Erfahrungen Ihnen nützlich sein werden.
Quelle: habr.com
