Service Mesh ist ein bekanntes Architekturmuster für die Integration von Microservices und die Migration zur Cloud-Infrastruktur. Heutzutage ist es in der Cloud-Container-Welt ziemlich schwierig, darauf zu verzichten. Auf dem Markt sind bereits mehrere Open-Source-Service-Mesh-Implementierungen verfügbar, deren Funktionalität, Zuverlässigkeit und Sicherheit jedoch bei weitem nicht immer ausreichen, insbesondere wenn es um die Anforderungen großer Finanzunternehmen im ganzen Land geht. Deshalb haben wir bei Sbertech beschlossen, Service Mesh anzupassen und möchten darüber sprechen, was an Service Mesh cool ist, was nicht sehr gut und was wir damit machen werden.
Die Popularität des Service Mesh-Musters wächst mit der Popularität von Cloud-Technologien. Es handelt sich um eine dedizierte Infrastrukturschicht, die die Interaktion zwischen verschiedenen Netzwerkdiensten vereinfacht. Moderne Cloud-Anwendungen bestehen aus Hunderten oder sogar Tausenden solcher Dienste, von denen jeder Tausende von Kopien haben kann.
Die Interaktion zwischen diesen Diensten und deren Verwaltung ist eine Schlüsselaufgabe von Service Mesh. Tatsächlich handelt es sich um ein Netzwerkmodell aus vielen Proxys, die zentral verwaltet werden und eine Reihe sehr nützlicher Funktionen ausführen.
Auf Proxy-Ebene (Datenebene):
- Zuweisung und Verbreitung von Routing- und Traffic-Balancing-Richtlinien
- Verteilung von Schlüsseln, Zertifikaten, Token
- Erfassung von Telemetriedaten, Bildung von Überwachungsmetriken
- Integration mit Sicherheits- und Überwachungsinfrastruktur
Auf der Ebene der Steuerungsebene:
- Anwenden von Routing- und Traffic-Balancing-Richtlinien
- Verwaltung von Wiederholungen und Zeitüberschreitungen, Erkennung „toter“ Knoten (Stromkreisunterbrechung), Verwaltung von Fehlersituationen (Injektion von Fehlern) und Gewährleistung der Stabilität (Resilienz) von Diensten durch andere Mechanismen
- Anrufauthentifizierung/Autorisierung
- Wegfallende Metriken (Beobachtbarkeit)
Der Kreis der an der Entwicklung dieser Technologie interessierten Nutzer ist sehr breit – von kleinen Startups bis hin zu großen Internetkonzernen wie PayPal.
Warum brauchen Sie Service Mesh im Unternehmensbereich?
Die Verwendung eines Service Mesh bringt viele offensichtliche Vorteile mit sich. Erstens ist es für Entwickler einfach praktisch: zum Schreiben von Code aufstrebende technologische Plattform, was die Integration in die Cloud-Infrastruktur erheblich vereinfacht, da die Transportschicht vollständig von der Anwendungslogik isoliert ist.
Außerdem, Service Mesh vereinfacht die Beziehung zwischen Lieferanten und Verbrauchern. Heutzutage ist es für API-Anbieter und Verbraucher viel einfacher, Schnittstellen und Verträge selbst zu vereinbaren, ohne dafür einen speziellen Integrationsvermittler und Schiedsrichter – einen Corporate Service Bus – einzubeziehen. Dieser Ansatz hat erhebliche Auswirkungen auf zwei Indikatoren. Die Geschwindigkeit, mit der neue Funktionalität auf den Markt gebracht wird (Time-to-Market), erhöht sich, gleichzeitig steigen aber auch die Kosten der Lösung, da die Integration eigenständig erfolgen muss. Der Einsatz von Service Mesh durch Business-Feature-Teams trägt hier dazu bei, das Gleichgewicht zu halten. Dadurch können sich API-Anbieter ausschließlich auf die Anwendungskomponente ihres Dienstes konzentrieren und diese einfach im Service Mesh veröffentlichen – die API steht sofort allen Kunden zur Verfügung und die Integrationsqualität ist produktionsbereit und erfordert keine einzige Zeile von zusätzlichem Code.
Der nächste Vorteil ist dieser Entwickler, die Service Mesh verwenden, konzentrieren sich ausschließlich auf Geschäftsfunktionen - auf dem Produkt und nicht auf der technologischen Komponente ihrer Dienstleistung. Sie müssen beispielsweise nicht mehr daran denken, dass es in einer Situation, in der der Dienst über das Netzwerk aufgerufen wird, irgendwo zu einer Verbindungsunterbrechung kommen kann. Darüber hinaus hilft Service Mesh dabei, den Datenverkehr zwischen Kopien desselben Dienstes auszugleichen: Wenn eine der Kopien „ausgefallen“ ist, leitet das System den gesamten Datenverkehr auf die verbleibenden Live-Kopien um.
Service-Mesh - Es ist eine gute Grundlage für die Erstellung verteilter Anwendungen, das dem Kunden die Einzelheiten der Bereitstellung von Anrufen zu seinen Diensten sowohl von innen als auch von außen verbirgt. Alle Anwendungen, die das Service Mesh nutzen, sind auf der Transportebene vom Netzwerk und voneinander isoliert: Es besteht keine Verbindung zwischen ihnen. Dadurch erhält der Entwickler die volle Kontrolle über seine Dienste.
Das muss beachtet werden Die Aktualisierung verteilter Anwendungen in einer Umgebung, in der Service Mesh verwendet wird, wird einfacher. Beispielsweise eine Blau/Grün-Bereitstellung, bei der zwei Anwendungsumgebungen zur Installation verfügbar sind, von denen eine nicht aktualisiert wird und sich im Leerlauf befindet. Das Rollback auf die vorherige Version im Falle einer erfolglosen Veröffentlichung wird von einem speziellen Router durchgeführt, dessen Rolle das Service Mesh perfekt übernimmt. Um die neue Version zu testen, können Sie auch verwenden Kanarische Freilassung - Wechseln Sie nur 10 % des Datenverkehrs oder der Anfragen einer Pilotgruppe von Kunden auf die neue Version. Der Hauptverkehr geht zur alten Version, nichts geht kaputt.
Auch Service Mesh ermöglicht uns die SLA-Kontrolle in Echtzeit. Das System verteilter Proxys verhindert, dass der Dienst überlastet wird, wenn einer der Kunden das ihm zugewiesene Kontingent überschreitet. Wenn die Bandbreite der API begrenzt ist, kann niemand sie mit einer großen Anzahl von Transaktionen pushen: Service Mesh steht vor dem Dienst und lässt keinen zusätzlichen Datenverkehr zu. Es wehrt sich einfach in der Integrationsschicht und die Dienste selbst funktionieren weiterhin, ohne es zu merken.
Wenn ein Unternehmen die Kosten für die Entwicklung von Integrationslösungen senken möchte, hilft Service Mesh außerdem: Sie können von kommerziellen Produkten auf die Open-Source-Versionen umsteigen. Unser Enterprise Service Mesh basiert auf der Open-Source-Version von Service Mesh.
Ein weiterer Vorteil ist Verfügbarkeit eines einzigen vollwertigen Satzes von Integrationsdiensten. Da die gesamte Integration über diese mittlere Schicht erfolgt, können wir den gesamten Integrationsverkehr und die Kommunikation zwischen Anwendungen verwalten, die den Geschäftskern des Unternehmens bilden. Es ist sehr bequem.
Und endlich Service Mesh ermutigt ein Unternehmen, auf eine dynamische Infrastruktur umzusteigen. Jetzt streben viele nach Containerisierung. Einen Monolithen in Microservices zu zerlegen, das lässt sich wunderbar umsetzen – das Thema ist auf dem Vormarsch. Wenn man jedoch versucht, ein System, das schon seit vielen Jahren in Produktion ist, auf eine neue Grundlage zu stellen, stößt man sofort auf eine Reihe von Problemen: Es ist nicht einfach, alles in Container zu packen und auf einer Plattform bereitzustellen. Und die Implementierung, Synchronisierung und Interaktion dieser verteilten Komponenten ist ein weiteres komplexes Thema. Wie werden sie miteinander kommunizieren? Wird es kaskadierende Ausfälle geben? Mit Service Mesh können Sie einige dieser Probleme lösen und die Migration von der alten auf die neue Architektur erleichtern, da Sie die Netzwerkaustauschlogik vergessen können.
Warum eine Service-Mesh-Anpassung notwendig ist
In unserem Unternehmen existieren Hunderte von Systemen und Modulen nebeneinander und die Laufzeit ist sehr ausgelastet. Ein einfaches Muster, bei dem ein System ein anderes aufruft und eine Antwort erhält, reicht also nicht aus, denn in der Produktion wollen wir mehr. Was benötigen Sie sonst noch von einem Corporate Service Mesh?
Event-Handling-Service
Stellen wir uns vor, dass wir eine Echtzeit-Ereignisverarbeitung benötigen – ein System, das die Aktionen des Kunden in Echtzeit analysiert und ihm sofort ein relevantes Angebot unterbreiten kann. Um diese Funktionalität zu implementieren, verwenden Sie Architekturmuster namens ereignisgesteuerte Architektur (EDA). Keines der aktuellen Service Mesh unterstützt solche Muster nativ, und das ist sehr wichtig, insbesondere für eine Bank!
Es ist ziemlich seltsam, dass der „Remote Call“ Remote Procedure Call (RPC) von allen Versionen von Service Mesh unterstützt wird, sie aber nicht mit EDA befreundet sind. Denn Service Mesh ist eine Art moderne verteilte Integration und EDA ein sehr relevantes Architekturmuster, das Ihnen einzigartige Dinge im Hinblick auf das Kundenerlebnis ermöglicht.
Unser Enterprise Service Mesh soll dieses Problem lösen. Darüber hinaus möchten wir darin die Umsetzung von garantierter Zustellung, Streaming und komplexer Ereignisverarbeitung mithilfe verschiedener Filter und Vorlagen sehen.
Dateiübertragungsdienst
Zusätzlich zu EDA wäre es schön, Dateien übertragen zu können: Im Unternehmensmaßstab ist sehr oft nur die Dateiintegration möglich. Insbesondere wird das ETL-Architekturmuster (Extract, Transform, Load) verwendet. Darin tauscht in der Regel jeder ausschließlich Dateien aus: Es werden große Datenmengen verwendet, die nicht mit separaten Anfragen verschoben werden können. Die Möglichkeit, die Dateiübertragung in Enterprise Service Mesh nativ zu unterstützen, gibt Ihnen die Flexibilität, die Ihr Unternehmen benötigt.
Orchestrierungsdienst
Große Unternehmen haben fast immer unterschiedliche Teams, die unterschiedliche Produkte herstellen. In einer Bank arbeiten beispielsweise einige Teams mit Einlagen, während andere mit Kreditprodukten arbeiten, und es gibt viele solcher Fälle. Dabei handelt es sich um unterschiedliche Personen, unterschiedliche Teams, die ihre Produkte herstellen, ihre eigenen APIs entwickeln und sie anderen zur Verfügung stellen. Und sehr oft besteht Bedarf an der Zusammensetzung dieser Dienste sowie an der Implementierung komplexer Logik zum sequentiellen Aufruf einer Reihe von APIs. Um dieses Problem zu lösen, ist eine Lösung in der Integrationsschicht erforderlich, die die gesamte zusammengesetzte Logik vereinfacht (Aufruf mehrerer APIs, Beschreibung der Anforderungsroute usw.). Dies ist der Orchestrierungsdienst im Enterprise Service Mesh.
KI und ML
Wenn Microservices über eine einzige Integrationsschicht kommunizieren, weiß das Service Mesh natürlich alles über die Aufrufe der einzelnen Services. Wir erfassen Telemetriedaten: Wer hat wen wann, wie lange, wie oft usw. angerufen. Wenn es Hunderttausende dieser Dienste und Milliarden von Anrufen gibt, dann sammelt sich all das an und bildet Big Data. Diese Daten können mithilfe von KI, maschinellem Lernen usw. analysiert werden, und dann können basierend auf den Ergebnissen der Analyse einige nützliche Dinge getan werden. Es wäre sinnvoll, die Kontrolle über den gesamten Netzwerkverkehr und die im Service Mesh integrierten Anwendungsaufrufe zumindest teilweise der künstlichen Intelligenz zu übertragen.
API-Gateway-Dienst (API-Gateway)
Typischerweise verfügt ein Service Mesh über Proxys und Dienste, die innerhalb eines vertrauenswürdigen Perimeters miteinander kommunizieren. Es gibt aber auch externe Partner. Die Anforderungen an APIs, die dieser Verbrauchergruppe zugänglich gemacht werden, sind viel strenger. Wir unterteilen diese Aufgabe in zwei Hauptteile.
- Sicherheit. Probleme im Zusammenhang mit DDoS, Protokollschwachstellen, Anwendungen, Betriebssystemen usw.
- Umfang. Wenn die Anzahl der APIs, die den Kunden zur Verfügung gestellt werden sollen, in die Tausende oder sogar Hunderttausende geht, besteht Bedarf an einer Art Verwaltungstool für diesen API-Satz. Sie müssen die API ständig überwachen: ob sie funktioniert oder nicht, in welchem Status, welcher Datenverkehr ankommt, welche Statistiken usw. Das API Gateway sollte diese Aufgabe bewältigen können und den gesamten Prozess überschaubar und sicher machen. Dank dieser Komponente lernt das Enterprise Service Mesh, wie es sowohl interne APIs als auch externe APIs einfach veröffentlichen kann.
Support-Service für spezifische Protokolle und Datenformate (AS-Gateway)
Derzeit können die meisten Service Mesh-Lösungen nativ nur mit HTTP- und HTTP2-Verkehr oder in einem verkürzten Modus auf TCP/IP-Ebene arbeiten. Das Enterprise Service Mesh verfügt über viele weitere sehr spezifische Datenübertragungsprotokolle. Einige Systeme verwenden möglicherweise Nachrichtenbroker, andere sind auf Datenbankebene integriert. Verfügt das Unternehmen über SAP, kann es auch ein eigenes Integrationssystem nutzen. Und das alles funktioniert und ist ein wichtiger Teil des Geschäfts.
Man kann nicht einfach sagen: „Lasst uns das Vermächtnis aufgeben und neue Systeme schaffen, die das Service Mesh nutzen können.“ Um alle alten Systeme mit neuen anzufreunden (auf einer Microservice-Architektur), benötigen Systeme, die Service Mesh verwenden können, eine Art Adapter, Vermittler oder Gateway. Stimmen Sie zu, es wäre schön, wenn es in einer Box mit dem Service käme. Das AC-Gateway kann einfach jede Integrationsoption unterstützen. Stellen Sie sich vor, Sie installieren Enterprise Service Mesh und es ist bereits bereit, mit allen Protokollen zu interagieren, die Sie benötigen. Für uns ist dieser Ansatz sehr wichtig.
So präsentieren wir die Unternehmensversion von Service Mesh (Enterprise Service Mesh). Die beschriebene Anpassung löst die meisten Probleme, die beim Versuch auftreten, vorgefertigte Open-Source-Versionen der Integrationsplattform zu verwenden. Obwohl die Service Mesh-Architektur erst vor ein paar Jahren auf den Markt kam, entwickelt sie sich ständig weiter und wir freuen uns, zu ihrer Entwicklung beitragen zu können. Wir hoffen, dass unsere Erfahrung für Sie von Nutzen sein wird.
Source: habr.com