Service Mesh – ein bekannter Architekturmuster zur Integration von Microservices und zur Migration in die Cloud-Infrastruktur. Heute ist es im containerisierten Cloud-Umfeld ziemlich schwierig, darauf zu verzichten. Auf dem Markt sind bereits mehrere Open-Source-Implementierungen von Service Mesh verfügbar, aber deren Funktionalität, Zuverlässigkeit und Sicherheit sind oft nicht ausreichend, insbesondere wenn es um die Anforderungen großer Finanzunternehmen auf nationaler Ebene geht. Aus diesem Grund haben wir bei Sbertech beschlossen, Service Mesh anzupassen und möchten darüber berichten, was an Service Mesh gut ist, was nicht so gut ist und was wir damit vorhaben.
Die Popularität des Service Mesh-Musters wächst mit der Verbreitung von Cloud-Technologien. Es stellt eine separierte Infrastruktur-Schicht dar, 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 zentrale Aufgabe des Service Mesh. Tatsächlich handelt es sich um ein Netzwerkmodell aus zahlreichen Proxys, das zentral gesteuert wird und eine Reihe sehr nützlicher Funktionen erfüllt.
Auf der Proxy-Ebene (Datenebene):
- Zuweisung und Verteilung von Routing- und Verkehrsausgleichsrichtlinien
- Verteilung von Schlüsseln, Zertifikaten, Tokens
- Erfassung von Telemetrie, Erstellung von Überwachungsmetriken
- Integration mit Sicherheits- und Überwachungsinfrastruktur
Auf der Steuerungsebene:
- Anwendung von Routing- und Verkehrsausgleichsrichtlinien
- Verwaltung von Wiederholungen und Timeouts, Erkennung von "toten" Knoten (Circuit Breaking), Management von Fehlersituationen (Injecting Faults) und Gewährleistung der Resilienz von Diensten durch andere Mechanismen
- Authentifizierung/Autorisierung von Aufrufen
- Wegfall von Metriken (Observability)
Der Nutzerkreis, der an der Entwicklung dieser Technologie interessiert ist, ist sehr breit – von kleinen Startups bis hin zu großen Internetkonzernen wie PayPal.
Wozu ist Service Mesh im Unternehmenssektor gut?
Die Nutzung von Service Mesh bietet zahlreiche offensichtliche Vorteile. Vor allem ist es für Entwickler einfach praktisch: um Code zu schreiben entsteht eine technologische Plattform, die die Integration in die Cloud-Infrastruktur erheblich vereinfacht, da die Transportschicht vollständig von der Anwendungslogik isoliert ist.
Außerdem, Service Mesh vereinfacht die Beziehungen zwischen Anbietern und Verbrauchern. Heute können sich API-Anbieter und -Verbraucher viel einfacher selbst über Schnittstellen und Verträge einigen, ohne dabei einen speziellen Integrationsmittler und Schlichter – das Unternehmens-Service-Bus – hinzuzuziehen. Dieser Ansatz hat erhebliche Auswirkungen auf zwei Kennzahlen. Die Geschwindigkeit, mit der neue Funktionalitäten auf den Markt gebracht werden (Time-to-Market), steigt, während gleichzeitig die Kosten für die Lösung steigen, da die Integration selbst vorgenommen werden muss. Der Einsatz von Service Mesh durch Entwicklungsteams für Geschäfts-funktionalitäten 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 allen Kunden zugänglich sein, und die Integrationsqualität wird produktionsbereit sein und erfordert keinen zusätzlichen Code.
Ein weiterer Vorteil ist, dass der Entwickler, der Service Mesh nutzt, sich ausschließlich auf die Geschäfts-funktionalität konzentriert – auf die produktbezogene und nicht auf die technologische Dimension seines Dienstes. Zum Beispiel muss man sich nicht mehr darum kümmern, dass in Situationen, in denen der Dienst über das Netzwerk aufgerufen wird, irgendwo eine Verbindung unterbrochen werden kann. Darüber hinaus hilft Service Mesh, den Datenverkehr zwischen den Kopien desselben Dienstes auszugleichen: Wenn eine der Kopien „tot“ ist, wird das System den gesamten Datenverkehr auf die verbleibenden aktiven Kopien umleiten.
Service Mesh — das ist eine gute Grundlage für die Erstellung verteilter Anwendungen, die die Details der externen und internen Aufrufe ihrer Dienste vor dem Kunden verbergen. Alle Anwendungen, die Service Mesh nutzen, sind auf der Transportschicht sowohl von Netzwerken als auch untereinander isoliert: es gibt keine Verbindung zwischen ihnen. Dabei erhält der Entwickler die volle Kontrolle über seine Dienste.
Es ist nicht zu übersehen, dass das Aktualisieren verteilter Anwendungen in einer Umgebung, in der Service Mesh verwendet wird, einfacher wird. Zum Beispiel ein blue/green-Deployment, bei dem zwei Anwendungsumgebungen für die Installation verfügbar sind, von denen eine nicht aktualisiert wird und im Standby-Modus bleibt. Ein Rollback auf eine frühere Version im Falle eines fehlgeschlagenen Releases erfolgt über einen speziellen Router, dessen Rolle hervorragend von Service Mesh erfüllt wird.. Für das Testen einer neuen Version kann man auch einen Canary Release verwenden – dabei wird nur 10 % des Traffics oder Anfragen von einer Pilotgruppe von Kunden auf die neue Version umgeschaltet. Der Haupttraffic läuft auf die alte Version, es gibt keine Störungen.
Außerdem Service Mesh bietet uns eine Kontrolle der SLA in Echtzeit. Das System von verteilten Proxys wird den Service nicht überlasten, wenn ein Kunde sein ihm zugewiesenes Kontingent überschreitet. Wenn die Bandbreite über die API begrenzt ist, kann niemand den Service mit zu vielen Transaktionen überlasten: Service Mesh steht vor dem Dienst und lässt keinen überflüssigen Traffic durch. Dieser wird einfach in der Integrationsschicht abgewiesen, während die Dienste weiterhin ohne Probleme arbeiten.
Wenn ein Unternehmen die Entwicklungskosten von Integrationslösungen senken möchte, hilft auch Service Mesh: auf die Open-Source-Version kann man von kommerziellen Produkten umsteigen. Unser Enterprise Service Mesh basiert auf der Open-Source-Version von Service Mesh.
Ein weiterer Vorteil ist die Verfügbarkeit eines einheitlichen, vollständigen Satzes von Integrationsdiensten. Da die gesamte Integration über diese Zwischenschicht läuft, können wir den gesamten Integrationstraffic und die Beziehungen zwischen den Anwendungen steuern, die das Geschäftszentrum des Unternehmens bilden. Das ist sehr praktisch.
Und schließlich fordert Service Mesh das Unternehmen dazu auf, auf eine dynamische Infrastruktur umzusteigen. Derzeit interessieren sich viele für die Containerisierung. Ein Monolith in Mikrodienste aufzuteilen und dies elegant zu implementieren ist ein aufstrebendes Thema. Aber wenn du versuchst, ein System, das seit vielen Jahren in der Produktion ist, auf neue Gleise zu bringen, stößt du sofort auf eine Reihe von Problemen: Es ist nicht einfach, all dies in Container zu packen und auf einer Plattform zu implementieren. Die Implementierung, Synchronisierung und Interaktion dieser verteilten Komponenten ist ein weiteres äußerst komplexes Thema. Wie werden sie miteinander kommunizieren? Welche Kaskadenausfälle könnten auftreten? Service Mesh kann einen Teil dieser Probleme lösen und die Migration von der alten Architektur zur neuen erleichtern, indem man die Logik des Netzwerkverkehrs vergisst.
Warum ist die Anpassung eines Service Mesh notwendig?
In unserem Unternehmen koexistieren Hunderte von Systemen und Modulen, und die Laufzeit ist stark ausgelastet. Ein einfaches Muster, bei dem ein System ein anderes aufruft und eine Antwort erhält, reicht nicht aus, denn in der Produktion streben wir nach mehr. Was benötigen wir noch von einem Enterprise-Service-Mesh?
Ereignisverarbeitungsdienst
Stellen wir uns vor, wir müssen eine Echtzeit-Ereignisverarbeitungssystem erstellen, das in Echtzeit das Verhalten des Kunden analysiert und ihm sofort ein relevantes Angebot machen kann. Um eine solche Funktionalität zu realisieren, wird eingesetzt das architektonische Muster mit dem Namen event-driven architecture (EDA). Keine der aktuellen Service Mesh unterstützt solche Muster nativ, was besonders für Banken sehr wichtig ist!
Es ist ziemlich seltsam, dass der "Remote Procedure Call" (RPC) von allen Versionen des Service Mesh unterstützt wird, während EDA nicht kompatibel ist. Denn Service Mesh ist eine Art moderne verteilte Integration, während EDA ein sehr aktuelles architektonisches Muster ist, das einzigartige Möglichkeiten im Hinblick auf das Kundenerlebnis bietet.
Unser Enterprise Service Mesh sollte dieses Problem lösen. Darüber hinaus möchten wir, dass darin eine garantierte Lieferung, Streaming und umfassende Ereignisverarbeitung unter Verwendung verschiedener Filter und Muster implementiert wird.
Dateiübertragungsdienst
Neben EDA wäre es gut, die Möglichkeit zu haben, Dateien zu übertragen: In großen Unternehmen ist oft nur die Datei-Integration möglich. Insbesondere wird das Architektur-Muster ETL (Extract, Transform, Load – „Extrahieren, Transformieren, Laden“) verwendet. Dabei tauschen in der Regel alle ausschließlich Dateien aus: Große Datenmengen werden verwendet, die es nicht sinnvoll machen, sie über separate Anfragen zu senden. Die native Unterstützung für den Dateitransfer im Enterprise Service Mesh bietet die notwendige Flexibilität für das Geschäft.
Orchestrierungsdienst
In großen Organisationen gibt es fast immer verschiedene Teams, die unterschiedliche Produkte entwickeln. Zum Beispiel arbeiten in einer Bank einige Teams mit Einlagen, während andere mit Kreditprodukten arbeiten, und es gibt viele solcher Fälle. Das sind unterschiedliche Personen, unterschiedliche Teams, die ihre Produkte entwickeln, ihre APIs erstellen und sie anderen zur Verfügung stellen. Sehr oft besteht die Notwendigkeit, diese Dienste zu komponieren und komplexe Logik für aufeinanderfolgende API-Aufrufe zu implementieren. Um dieses Problem zu lösen, ist eine Lösung im Integrationsschicht erforderlich, die diese gesamte Kompositionslogik (Aufruf mehrerer APIs, Routenbeschreibung von Anfragen usw.) vereinfachen kann. Das ist der Orchestrierungsdienst im Enterprise Service Mesh.
KI und ML
Wenn Mikrodienste über eine einheitliche Integrationsschicht, das Service Mesh, kommunizieren, weiß der Service Mesh natürlich alles über die Aufrufe jedes Dienstes. Wir sammeln Telemetriedaten: wer wen wann aufgerufen hat, wie lange, wie oft usw. Wenn es Hunderte von Tausenden von Diensten und Milliarden von Aufrufen gibt, sammelt sich das alles an und bildet Big Data. Diese Daten können mit KI-, Machine Learning- und anderen Mitteln analysiert werden, und auf Basis der Analyseergebnisse können nützliche Dinge entwickelt werden. Es wäre sinnvoll, zumindest teilweise die Kontrolle über den gesamten Netzverkehr und die Anwendungsaufrufe, die im Service Mesh integriert sind, künstlicher Intelligenz zu übertragen.
API-Gateway-Dienst
In der Regel gibt es im Service Mesh Proxys und Dienste, die innerhalb eines vertrauenswürdigen Rahmens miteinander kommunizieren. Aber es gibt auch externe Partner. Die Anforderungen an die APIs, die dieser Gruppe von Verbrauchern zur Verfügung gestellt werden, sind viel strenger. Diese Aufgabe unterteilen wir in zwei Hauptteile.
- SicherheitFragen, die sich auf DDoS, Schwachstellen in Protokollen, Anwendungen, Betriebssystemen usw. beziehen.
- Maßstab. Wenn die API-Abrechnungen, die an Kunden ausgegeben werden müssen, in die Tausende oder sogar Hunderttausende gehen, entsteht der Bedarf an einem bestimmten Management-Tool für dieses API-Set. Es ist notwendig, die APIs ständig zu überwachen: Funktionieren sie oder nicht, welchen Status haben sie, welcher Datenverkehr läuft, welche Statistiken gibt es usw. Der API-Gateway sollte in der Lage sein, diese Aufgabe zu bewältigen und den gesamten Prozess verwaltbar und sicher zu machen. Mit dieser Komponente lernt das Enterprise Service Mesh, sowohl interne als auch externe APIs ohne unnötige Komplikationen zu veröffentlichen.
Dienst zur Unterstützung spezifischer Protokolle und Datenformate (AS-Gateway)
Derzeit können die meisten Service-Mesh-Lösungen nur nativ mit HTTP- und HTTP2-Datenverkehr arbeiten oder im reduzierten Modus auf TCP/IP-Ebene. Das Enterprise Service Mesh bietet viele andere sehr spezifische Datenübertragungsprotokolle. Einige Systeme können Nachrichtenbroker verwenden, während andere auf Datenbankebene integriert sind. Wenn das Unternehmen SAP hat, kann es auch ein eigenes Integrationssystem nutzen. All dies funktioniert und ist ein wichtiger Teil des Geschäfts.
Man kann nicht einfach sagen: „Lassen Sie uns das Legacy-System abschaffen und neue Systeme schaffen, die Service Mesh nutzen können“. Um alle alten Systeme mit den neuen (auf Mikroservices basierend) zu verbinden, benötigen die Systeme, die Service Mesh nutzen können, einen Adapter, einen Vermittler, ein Gateway. Es wäre großartig, wenn er zusammen mit dem Service in einer Box geliefert würde. Das AS-Gateway kann genau jede Art von Integration unterstützen. Stellen Sie sich vor, Sie installieren einfach das Enterprise Service Mesh, und es ist bereits bereit, mit all den Protokollen zu interagieren, die Sie benötigen. Dieser Ansatz ist für uns sehr wichtig.
So stellen wir uns die Unternehmensversion des Service Mesh (Enterprise Service Mesh) vor. Die beschriebene Anpassung löst die meisten Probleme, die beim Versuch entstehen, bereitgestellte Open-Source-Versionen von Integrationsplattformen zu nutzen. Die Architektur des Service Mesh, die vor nur wenigen Jahren entstanden ist, entwickelt sich weiterhin, und wir freuen uns, dass wir zu ihrer Entwicklung beitragen können. Wir hoffen, dass unsere Erfahrungen für Sie nützlich sein werden.
Quelle: habr.com
