Derzeit gibt es viele vorgefertigte Frameworks für die Entwicklung von Anwendungen mithilfe einer Microservice-Architektur. In der Regel werden Frameworks in zwei Typen unterteilt - für eine Sprache, die mit verschiedenen Plattformen arbeiten kann, die Entwicklung jedoch in einer Sprache erfolgt - ein Beispiel für SpringBoot, Nancy usw. Der zweite Typ - für die Plattform - kann mit verschiedenen Programmiersprachen arbeiten, der Code kann jedoch nur auf der ausgewählten Plattform ausgeführt werden - ein Beispiel für ServiceFabric, AWS Lambda. Es gibt jedoch praktisch keine mehrsprachigen Frameworks, die auf verschiedenen Plattformen arbeiten können.
Unser Team entwickelt Unternehmenssysteme auf der Basis von Microservices, die Komponenten enthalten, die in verschiedenen Sprachen geschrieben sind und häufig auf verschiedenen Plattformen arbeiten müssen. Daher ist das oben beschriebene Problem für uns mehr als relevant. Da wir keine vorgefertigten Lösungen finden konnten, die diese Anforderungen erfüllen, haben wir unsere eigene Lösung entwickelt - Pip.Services Toolkit . Mit diesem Tool konnten wir Microservices in vielen Programmiersprachen entwickeln und uns nicht zu viele Gedanken darüber machen, wo diese Anwendung ausgeführt wird - in der Cloud oder vor Ort.
Der Zweck des Artikels besteht darin, den Leser mit den Funktionen des Projekts vertraut zu machen, ohne auf die Details der Implementierung einzugehen. Wenn Sie mehr über dieses Tool erfahren möchten, klicken Sie bitte auf ...
Was ist Pip.Services?
Während der Entwicklung wollten wir ein ziemlich vielseitiges Tool entwickeln, das viele Aufgaben abdecken kann. Während des Designprozesses wurden die Hauptprinzipien festgelegt, die die Grundlage des Produkts bildeten:
- Systemkomponenten sollten wenig verbunden sein, um sie leicht zu ändern und neue Funktionen hinzuzufügen
- Sehr langer Lebenszyklus - Ziel war es, ein Tool zu entwickeln, mit dem es für die maximal mögliche Zeit in verschiedenen Sprachen unterstützt werden kann.
- die Fähigkeit, Anwendungen sowohl für die Mikroservice-Architektur als auch für die monolithische Architektur zu entwickeln
- Die entwickelten Anwendungen sollten auf jeder Plattform bereitgestellt werden können, sei es vor Ort oder in einer Cloud-Lösung, und die Cloud sollte auch nicht vom Betreiber abhängig sein
- Unterstützung der maximalen Anzahl von Programmiersprachen, die in der Entwicklung verwendet werden, unter Beibehaltung der Prinzipien des Tools selbst sowie der Kompatibilität von Diensten, die während der Kommunikation in verschiedenen Sprachen geschrieben wurden
Das Pip.Services Toolkit stellt eine umfangreiche Reihe von Tools dar, mit denen Sie Microservices und monolithische Anwendungen mit gängigen Programmiersprachen entwickeln können. Das Pip.Services Toolkit hat Tools entwickelt, mit denen Sie mit allen erforderlichen Funktionen und Datenstrukturen arbeiten können, deren Bedarf ein Entwickler haben kann. Wenn die erforderlichen Dinge fehlen, können sie problemlos unabhängig voneinander hinzugefügt werden.
Das Pip.Services Toolkit ist ein echtes Polyglot, das die folgenden Konzepte befolgt:
Symmetrische Implementierung in Code
- , , . ,
- — ,
- —
- — ,
Für eine visuellere Darstellung der Struktur wenden wir uns dem Strukturdiagramm des Toolkits zu.
Wie am Anfang des Artikels erwähnt, ist das Toolkit mehrsprachig. Im Moment gibt es Implementierungen in 6 Programmiersprachen, darunter sowohl beliebte (Java, Node.js, Python, .Net Core) als auch Entwicklungsprogramme (Go, Dart) - dies ist eine graue Ebene im Diagramm.
Wie Sie sehen können, basiert es auf einer Reihe von Paketen mit sprachübergreifenden Grundelementen und allgemeinen Vorlagen, die für die schnelle Entwicklung Ihrer eigenen Komponenten vorgesehen sind - der grünen Ebene im Diagramm. Auf ihrer Basis wird eine Bibliothek der Hauptkomponenten des Toolkits implementiert.
Bereits auf Basis der Basiskomponenten werden Benutzer- und Systemkomponenten implementiert - dies ist die zweite grüne Schicht.
Die blaue Ebene des Diagramms besteht aus einer Reihe grundlegender Bibliotheken für die Arbeit in bestimmten Richtungen - Implementierung von Containern (IoC), Arbeiten mit Daten, synchroner Austausch (RPC) und asynchroner Austausch (Messaging). Sie können als eigenständige Komponenten arbeiten, bieten jedoch auch grundlegende Schnittstellen und Prinzipien für die Erstellung spezifischer Implementierungen zusätzlicher Komponenten für die Arbeit mit bestimmten Technologien. Wie im Diagramm oben im Stapel gezeigt, implementieren Sie beispielsweise Container für AWS und Azure, implementieren Sie die Datenmanipulation in MongoDb und das verteilte Caching und Sperren in Memcached und Redis.
Microservices auf Pip.Services Toolkit - ein Einblick
Die Entwicklungspraxis zeigt, dass unter vielen verschiedenen Arten von Designs der Aufbau eines Mikrodienstes aus lose gekoppelten Komponenten bevorzugt wird. Das Pip.Services Toolkit legt den Entwicklern keine Einschränkungen für die Microservice-Struktur auf.
Jeder Entwickler kann seinen eigenen Weg wählen. Das Komponentendesign wird jedoch vom Pip.Services Toolkit stark unterstützt. Dank dieses Ansatzes werden eine Reihe von Aufgaben gelöst:
- Die Entwicklung und Erprobung einzelner Komponenten wird vereinfacht.
- Jede Komponente kann vom Rest des Codes isoliert werden, und ihre Abhängigkeiten in Tests können durch einfache Mocks ersetzt werden.
- Es wird möglich, einen Microservice für eine bestimmte Plattform neu zu konfigurieren, Infrastrukturdienste, Kommunikation oder Datenbanken zu ersetzen, indem einfach die Zusammensetzung der Microservice-Komponenten in der Konfigurationsdatei ohne Codeänderung geändert wird.
- . . , .
- , , :
- . :
- , ( ).
- , , ( ).
- Zusätzliche Komponenten für Caching, Überwachung, Konfiguration, Synchronisation usw. Diese Komponenten werden in der Regel aus dem Standardsatz hinzugefügt, der eine große Auswahl für die Integration in verschiedene Infrastrukturdienste und -plattformen bietet (grau).
- Eine Clientbibliothek kann implementiert werden, um die Verwendung des Mikrodienstes zu vereinfachen. Es bietet eine benutzerfreundliche Oberfläche für die Arbeit mit dem Microservice und verbirgt die Details der Kommunikation auf niedriger Ebene (blau).
Das Pip.Services Toolkit verwendet eine Konfigurationsdatei, um den Microservice zu erstellen und die Komponenten zu konfigurieren. Hier ist ein Beispiel für eine solche Konfiguration:
config.yml
--- # Container descriptor - descriptor: "pip-services:context-info:default:default:1.0" name: "hello-world" description: "HelloWorld microservice" # Console logger - descriptor: "pip-services:logger:console:default:1.0" level: "trace" # Performance counter that post values to log - descriptor: "pip-services:counters:log:default:1.0" # Controller - descriptor: "hello-world:controller:default:default:1.0" default_name: "World" # Shared HTTP Endpoint - descriptor: "pip-services:endpoint:http:default:1.0" connection: protocol: http host: 0.0.0.0 port: 8080 # HTTP Service V1 - descriptor: "hello-world:service:http:default:1.0" # Heartbeat service - descriptor: "pip-services:heartbeat-service:http:default:1.0" # Status service - descriptor: "pip-services:status-service:http:default:1.0"
Der Container, in den der Microservice eingeschlossen ist, liest eine solche Konfiguration basierend auf Deskriptoren unter Verwendung von Fabriken, erstellt die erforderlichen Komponenten, übergibt ihnen Konfigurationsparameter, bindet die Komponenten aneinander und startet aktive Prozesse.
Mit diesem Ansatz können Sie einheitliche Dienste entwerfen und mithilfe von Umgebungsvariablen direkt in der ausführbaren Umgebung eine Feinabstimmung für eine bestimmte Aufgabe durchführen.
Übergang vom Monolithen zu Microservices ohne Änderung des Codes
Wir sollten auch die Möglichkeit beachten, die von der Anwendung verwendete Architektur zu ändern, ohne Änderungen am Quellcode vorzunehmen. Betrachten wir diese Gelegenheit anhand eines Beispiels.
Angenommen, es gibt eine Fassade, mit der ein Kunde mit einem Dienst arbeitet. Zum Beispiel mit einem Dienst, der die Logik der Arbeit mit Bluetooth-Beacons (Beacons) implementiert. Beim Start im monolithischen Anwendungsmodus enthält die Konfigurationsdatei die folgenden Abschnitte mit Komponentendeskriptoren:
# Beacons components - descriptor: "pip-services-beacons:persistence:mongodb:default:*" - descriptor: "pip-services-beacons:controller:default:default:*" - descriptor: "pip-services-beacons:client:direct:default:*"
Diese Konfiguration erstellt den Beacons-Service tatsächlich als Teil der Fassade in Form von monolithischem Code, und die Interaktion zwischen ihnen erfolgt über den direkten Client, jedoch innerhalb eines einzelnen Containers, wie Sie aus der folgenden Abbildung sehen können.
Wenn Sie den Konfigurationstext jedoch ein wenig ändern, wird der Beacons-Dienst zu einem separaten Microservice, und die Fassade arbeitet über den http-Client damit. Entfernen Sie dazu die Abschnitte mit Controller und Persistenz in der Fassadenkonfiguration und ändern Sie den Client-Typ von direkt in http: Für einen korrekten Betrieb müssen Sie die Adresse und den Port der jetzt separat ausgeführten Microservice-Beacons angeben und die Fassade neu starten, damit die neue Konfiguration gelesen wird. Sie müssen auch einen separaten Microservice mit Beacons ausführen. Dazu können Sie die folgende Konfiguration verwenden:
# Beacons components
- descriptor: "pip-services-beacons:client:http:default:*"
connection:
protocol: "http"
host: "any.where.com"
port: 8086
# Http Endpoint - descriptor: "pip-services:endpoint:http:default:*" root_path: "" connection: protocol: "http" host: "0.0.0.0" port: 8086 # Beacons API V1 - descriptor: "pip-services-beacons:service:http:default:1.0" # Hearbeat service - descriptor: "pip-services:heartbeat-service:http:default:1.0" # Status service - descriptor: "pip-services:status-service:http:default:1.0"
Aus architektonischer Sicht sieht es jetzt so aus:
Wie Sie sehen, ist es auf diese Weise möglich, Anwendungen zuerst in Form von Monolithen zu erstellen, ohne viel Ressourcen für die Bereitstellung aufzuwenden. Sobald Sie jedoch skalieren müssen, müssen Sie nur noch die Konfiguration ändern und dies einfach Die Umstellung auf Microservices ist einer der Hauptvorteile des Pip.Services Toolkit.
Zusätzliche Tools aus dem Pip.Services-Projekt
Pip.Services enthält nicht nur das Pip.Services Toolkit. Im Laufe unserer Arbeit haben wir eine Reihe zusätzlicher Tools entwickelt, um die Entwicklung von Microservices zu vereinfachen:
- Bibliothek vorgefertigter Microservices - Enthält einen Katalog gebrauchsfertiger Microservices, der in sechs Kategorien unterteilt ist :
- – . , , , ..
- – , , ,
- – ,
- – , , .
- – , ,
- — , , ;
- Benchmarks sind eine Reihe von Dienstprogrammen zum Testen der Leistung entwickelter Anwendungen und Mikrodienste.
- Vorlagenbibliothek - Enthält mehrere Kategorien mit Vorlagen, darunter Vorlagen für die Entwicklung von Microservices, Arbeitsbereichseinstellungen, CI / CD-Vorlagen und Fassadenvorlagen.
- PowerShell Selenium WebDriver - Entwickelter Treiber für die Arbeit mit Selenium von PowerShell.
Alle diese Tools sind auf der Pip.Services-Website verfügbar.
Fazit
Am Ende des Artikels möchte ich hinzufügen, dass das Pip.Services Toolkit eine Reihe von Mustern und Komponenten ist, die die Entwicklung von Microservice-Systemen unter Verwendung einer Vielzahl von Programmiersprachen vereinfachen und die Bereitstellung auf verschiedenen lokalen und Cloud-Plattformen ermöglichen. Das Set enthält Muster, die die Erstellung hochgradig anpassbarer Mikrodienste mit lose gekoppelten Komponenten erleichtern, die typische Funktionen bei der Datenübertragung und -verarbeitung implementieren, mit Datenbanken arbeiten, Informationen über verschiedene synchrone und asynchrone Protokolle übertragen, Funktionen überwachen, Fehler behandeln und vieles mehr. Gleichzeitig ist das Pip.Services Toolkit leicht erweiterbar und kann aufgrund seines auf Komposition und nicht auf Vererbung basierenden Designs mit anderen Bibliotheken und Frameworks koexistieren.
Die allgemeinen Prinzipien und Strukturen sowie die Symmetrie der Implementierung ermöglichen es Entwicklern, in kürzester Zeit problemlos von einer Sprache in eine andere zu wechseln. Die Interoperabilität bietet die vollständige Kompatibilität von Microservices, die sofort in verschiedenen Sprachen geschrieben wurden.
Alle Microservices in unserer Bibliothek werden auf realen Systemen getestet und verwendet. Dank der Verwendung der Pip.Services Library in unseren Projekten konnten wir die Entwicklungszeit des Backends um bis zu 30% reduzieren.
Pip.Services entwickelt sich aktiv weiter, fast jeden Monat werden neue Tools und Microservices hinzugefügt oder erweitert.
Die meisten erforderlichen Informationen befinden sich bereits auf der Website, aber wir ergänzen sie weiterhin aktiv mit neuen Materialien und arbeiten weiter daran.
Bis November 2020 wurden basierend auf diesem Toolkit mehr als tausend Microservices mit einem hohen Maß an Zuverlässigkeit, hoher Entwicklungsgeschwindigkeit und einfacher Integration implementiert. Infolgedessen beschlossen die Führungskräfte des Unternehmens, das Produkt vollständig in den Open Source-Status zu versetzen, um erfolgreiche Architekturlösungen mit der Öffentlichkeit zu teilen und die Weiterentwicklung des Projekts durch eine größere Anzahl erfahrener Entwickler sicherzustellen.
Der Artikel war nur als Übersicht gedacht, ohne detaillierte Beispiele für die Implementierung. Bitte treten Sie nicht zu viel. In den folgenden Veröffentlichungen werden wir versuchen, herauszufinden, wie ein funktionierender Microservice mit diesem Toolkit implementiert wird.
Wenn Sie Fragen zu diesem Toolkit haben, stellen Sie diese in den Kommentaren oder über die auf unserer Website angegebenen Kommunikationskanäle. Wir werden sie auf jeden Fall beantworten.
Links: www.pipservices.org