👩🏻‍⚕️ 👨🏿‍🤝‍👨🏼 🤲🏻 Erstellen Sie eine skalierbare und ausfallsichere Architektur mit dynamischen Mikrodiensten 🤱 💴 🔐

Hallo wieder. Wie Sie wissen, startet OTUS im März einen völlig neuen Kurs zu Architektur- und Designmustern . Vor Beginn des Kurses wurde viel Material für Sie zum Erstellen einer skalierbaren und ausfallsicheren Architektur mithilfe dynamischer Mikrodienste übersetzt. Viel Spaß beim Lesen!

Anmerkung

Einer der wichtigsten Trends in der Industriearchitektur ist die Verwendung von Mikrodiensten zum Nachteil monolithischer Architekturen, die an Popularität verlieren. Dank der Cloud-Architektur ist die Bereitstellung von Microservice-Systemen produktiver, flexibler und kostengünstiger. Wie dem auch sei, viele Unternehmen haben bereits begonnen, von einem Architekturtyp zu einem anderen zu wechseln, aber dies steckt noch in den Kinderschuhen. In diesem Artikel lösen wir Probleme, die sich aus der Notwendigkeit ergeben, ein skalierbares und fehlertolerantes System auf der Basis von Mikrodiensten zu entwickeln. In unseren Experimenten betrachten wir zwei Arten von Mikrodiensten, einfache und fortgeschrittene, und zeigen, dass die vorgeschlagene Lösung aufgrund ihres dynamischen Verhaltens innovativ ist.

1. Einleitung

In den letzten Jahrzehnten war die Geschichte der Programmiersprachen und der Paradigmen der Informatik durch eine verstärkte Aufmerksamkeit für die Verteilung und Modularisierung gekennzeichnet, um die Wiederverwendung und Zuverlässigkeit von Code zu verbessern.

Die Quantität und Qualität der Software musste erhöht werden [1]. Einer der Schlüsselfaktoren bei der Klärung der verschiedenen Meinungsverschiedenheiten im Zusammenhang mit innovativem Design ist die Angemessenheit der Verwendung verschiedener Tools für das Design und die Entwicklung fortschrittlicherer Softwaresysteme [2]. Ein großer Erfolg in diesem Prozess wurde kürzlich durch Systeme demonstriert, die auf Mikrodiensten basieren [3], einem Architekturparadigma, das sich auf verschiedene Anwendungen konzentriert (z. B. für Menschen mit Behinderungen) [3]. Unter der Schirmherrschaft von Microservices wächst das Interesse an Architektur und Design. Qualitätsattribute (z. B. Skalierbarkeit, Leistung und Fehlertoleranz) oder Modellauswahl, z. B. "Contractual De Service" [5] oder API Gateway,nicht mehr gegen das YAGNI-Prinzip verstoßen („Sie werden es nicht brauchen“ - „unter BDUF-Fehlern leiden“ („Big Design Up Front“ - „Großes Design zuerst“). Die wichtigste Forschungsfrage, die dieser Artikel beantworten soll, ist, wie wir ein System entwickeln können, das auf Mikrodiensten basiert und die gleiche Einfachheit wie ein monolithisches System aufweist. Und wie können wir ausgehend vom vorherigen Thema eine Umgebung erstellen, die eine dynamische Verteilung der Rechenleistung zwischen Clients ermöglicht? Unsere Forschungshypothese schlägt vor, eine Client-Server-Systemarchitektur zu verwenden, die verteiltes Computing und Microservices kombiniert, um diese Probleme zu lösen.Die wichtigste Forschungsfrage, die dieser Artikel beantworten soll, ist, wie wir ein System entwickeln können, das auf Mikrodiensten basiert und die gleiche Einfachheit wie ein monolithisches System aufweist. Und wie können wir ausgehend vom vorherigen Thema eine Umgebung erstellen, die eine dynamische Verteilung der Rechenleistung zwischen Clients ermöglicht? Unsere Forschungshypothese schlägt vor, eine Client-Server-Systemarchitektur zu verwenden, die verteiltes Computing und Microservices kombiniert, um diese Probleme zu lösen.Die wichtigste Forschungsfrage, die dieser Artikel beantworten soll, ist, wie wir ein System entwickeln können, das auf Mikrodiensten basiert und die gleiche Einfachheit wie ein monolithisches System aufweist. Und wie können wir ausgehend vom vorherigen Thema eine Umgebung erstellen, die eine dynamische Verteilung der Rechenleistung zwischen Clients ermöglicht? Unsere Forschungshypothese schlägt vor, eine Client-Server-Systemarchitektur zu verwenden, die verteiltes Computing und Microservices kombiniert, um diese Probleme zu lösen.Was sorgt für eine dynamische Verteilung der Rechenleistung zwischen Clients? Unsere Forschungshypothese schlägt vor, eine Client-Server-Systemarchitektur zu verwenden, die verteiltes Computing und Microservices kombiniert, um diese Probleme zu lösen.Was sorgt für eine dynamische Verteilung der Rechenleistung zwischen Clients? Unsere Forschungshypothese schlägt vor, eine Client-Server-Systemarchitektur zu verwenden, die verteiltes Computing und Microservices kombiniert, um diese Probleme zu lösen.

Die Struktur des Dokuments ist wie folgt: Abschnitt 2 bietet einen kurzen Überblick über die aktuelle Literatur, in der die Bedeutung von Mikrodiensten erläutert wird, einschließlich zweier bekannter Dienste, die von Azure angeboten werden, und Abschnitt 3 behandelt die vorgeschlagene Architektur. In Abschnitt 4 wird die Bewertung dieses Systems erörtert, bevor im letzten Abschnitt Schlussfolgerungen gezogen werden.

2. Literaturübersicht über Microservices

Dank der Cloud-Architektur ist der Einsatz von Microservice-Systemen produktiver, flexibler und kostengünstiger [6]. Zimmermann merkt jedoch an, dass Microservices ein sensibles Thema sind, das hauptsächlich in Wissenschaft [7] und Industrie untersucht wird. Der Begriff „Microservices“ wurde erstmals im Mai 2011 auf einem Seminar von Softwarearchitekten in Italien erörtert, um zu beschreiben, was die Teilnehmer als einen gemeinsamen Architekturstil betrachteten, der kürzlich von vielen von ihnen untersucht wurde. Ein Jahr später bestätigte dieselbe Gruppe, dass der Begriff „Microservices“ der am besten geeignete Name ist. Tatsächlich wurden Microservices als Antwort auf Probleme in monolithischen Anwendungen oder serviceorientierten Architekturen entwickelt, die die Skalierbarkeit, Komplexität und Abhängigkeiten der zu entwickelnden Anwendung erschweren.zusammen mit der Verwendung von leichten Kommunikationsmechanismen [8-9]. Da es sich bei dem Monolithen um eine Softwareanwendung handelt, deren Module nicht unabhängig voneinander ausgeführt werden können, sollten wir eine auf Mikrodiensten basierende Lösung in Betracht ziehen, da sie als einzige in der Lage ist, voneinander unabhängige Anweisungen auszuführen [10-11]. Große Monolithen sind im Laufe der Zeit problematisch zu warten und aufgrund ihrer Komplexität schwer zu bewerten. Der Hauptnachteil besteht jedoch darin, dass sie die Skalierbarkeit des Produkts einschränken. Ein weiteres Problem besteht darin, dass sie keine Fehlertoleranz bieten und nicht zulassen, dass eine einzelne Komponente des Systems funktioniert, wenn eine andere Komponente nicht funktioniert, was in mikroserviceorientierten Architekturen möglich ist.Da es sich bei dem Monolithen um eine Softwareanwendung handelt, deren Module nicht unabhängig voneinander ausgeführt werden können, sollten wir eine auf Mikrodiensten basierende Lösung in Betracht ziehen, da sie als einzige in der Lage ist, voneinander unabhängige Anweisungen auszuführen [10-11]. Große Monolithen sind im Laufe der Zeit problematisch zu warten und aufgrund ihrer Komplexität schwer zu bewerten. Der Hauptnachteil besteht jedoch darin, dass sie die Skalierbarkeit des Produkts einschränken. Ein weiteres Problem besteht darin, dass sie keine Fehlertoleranz bieten und nicht zulassen, dass eine einzelne Komponente des Systems funktioniert, wenn eine andere Komponente nicht funktioniert, was in mikroserviceorientierten Architekturen möglich ist.Da es sich bei dem Monolithen um eine Softwareanwendung handelt, deren Module nicht unabhängig voneinander ausgeführt werden können, sollten wir eine auf Mikrodiensten basierende Lösung in Betracht ziehen, da sie als einzige in der Lage ist, voneinander unabhängige Anweisungen auszuführen [10-11]. Große Monolithen sind im Laufe der Zeit problematisch zu warten und aufgrund ihrer Komplexität schwer zu bewerten. Der Hauptnachteil besteht jedoch darin, dass sie die Skalierbarkeit des Produkts einschränken. Ein weiteres Problem besteht darin, dass sie keine Fehlertoleranz bieten und nicht zulassen, dass eine einzelne Komponente des Systems funktioniert, wenn eine andere Komponente nicht funktioniert, was in mikroserviceorientierten Architekturen möglich ist.Befehle unabhängig voneinander ausführen können [10-11]. Große Monolithen sind im Laufe der Zeit problematisch zu warten und aufgrund ihrer Komplexität schwer zu bewerten. Der Hauptnachteil besteht jedoch darin, dass sie die Skalierbarkeit des Produkts einschränken. Ein weiteres Problem besteht darin, dass sie keine Fehlertoleranz bieten und nicht zulassen, dass eine einzelne Komponente des Systems funktioniert, wenn eine andere Komponente nicht funktioniert, was in mikroserviceorientierten Architekturen möglich ist.Befehle unabhängig voneinander ausführen können [10-11]. Große Monolithen sind im Laufe der Zeit problematisch zu warten und aufgrund ihrer Komplexität schwer zu bewerten. Der Hauptnachteil besteht jedoch darin, dass sie die Skalierbarkeit des Produkts einschränken. Ein weiteres Problem besteht darin, dass sie keine Fehlertoleranz bieten und nicht zulassen, dass eine einzelne Komponente des Systems funktioniert, wenn eine andere Komponente nicht funktioniert, was in mikroserviceorientierten Architekturen möglich ist.und sie lassen nicht zu, dass eine einzelne Komponente des Systems funktioniert, wenn eine andere Komponente nicht funktioniert, was in mikroserviceorientierten Architekturen möglich ist.und sie lassen nicht zu, dass eine einzelne Komponente des Systems funktioniert, wenn eine andere Komponente nicht funktioniert, was in mikroserviceorientierten Architekturen möglich ist.

In SOA (Service Oriented Architecture) werden die Hauptdienste mithilfe von zwei Methoden koordiniert: Orchestrierung (wobei es einen zentralen Mikrodienst gibt, der Anforderungen an andere Dienste sendet und den gesamten Prozess durch Senden und Empfangen von Antworten steuert) und Choreografie (ohne Zentralisierung). aber jeder Dienst weiß im Voraus, was er tun soll) [1]. Wie bei monolithischen Architekturen und SOA-Architekturen bleibt das schwierigste Problem die Aufteilung des Systems in Dienste [12]. In keinem Fall sollten Sie das Problem der Bereitstellung vertraulicher Informationen durch die unkontrollierte Verteilung von Diensten vernachlässigen [13].

Unsere Architektur kombiniert verteiltes Computing mit Microservices, um eine Umgebung zu schaffen, die eine dynamische Verteilung des Computing zwischen Clients ermöglicht. Unter verteiltem Computing verstehen wir die Verfügbarkeit der Verarbeitung und Speicherung großer Datenmengen in der Cloud, was ein Schlüsselelement in der modernen Industrie sowohl innerhalb als auch außerhalb des IT-Bereichs ist. Verteilte Speichersysteme erfüllen die Anforderungen verteilter und rechnerisch fortschrittlicher Anwendungen mit breiter Anwendbarkeit, Skalierbarkeit und hoher Leistung. Eine bekannte Lösung ist MapReduce [14], das Berechnungen durch Sortieren verteilter Server koordiniert und gleichzeitig verschiedene Aufgaben, die gesamte Kommunikation und die Datenübertragung zwischen Teilen des Systems verwaltet.Bereitstellung von Redundanz und Fehlertoleranz.

Azure Batch ist ein weiteres Programmiermodell, mit dem Computeranwendungen ohne manuelle Konfiguration oder Infrastrukturverwaltung mit leistungsstärkeren Clustern von Hochleistungsrechnern (HPC - High Performance Computing) effizient im parallelen oder umfangreichen Modus ausgeführt werden können [15]. Um diese Ideen zu veranschaulichen, möchten wir Sie an SaaS (Software as a Service) oder Clientanwendungen erinnern, die eine breite Ausführung erfordern [16]. Tatsächlich zeigen verschiedene IT-Unternehmen ein verstärktes Interesse an SaaS, sind daran interessiert, ihre Betriebskosten zu senken und infolgedessen die Flexibilität ihres Geschäfts zu erhöhen [17]. Ein weiterer Dienst, der von großen Cloud-Dienstanbietern angeboten wird, sind Azure-Funktionen.Dies ermöglicht den Start bei Bedarf, ohne dass eine explizite Bereitstellung oder Verwaltung der Infrastruktur erforderlich ist [18].

Es erhöht auch das Interesse von Anwendungen, kleine Codeteile oder „Funktionen“ in der Cloud einfach zu starten. Das wachsende Interesse am Internet der Dinge (Internet of Things, IoT) macht Azure Functions [19] zu einer hervorragenden Lösung für die Datenverarbeitung, Systemintegration und die Erstellung einfacher APIs und Microservices.

3. Methodik

Das strukturell vorgeschlagene System kann in drei verschiedene Bereiche unterteilt werden: (1) der Client - der die vom Server zugewiesenen Aufgaben ausführt; (2) Server - eine Schnittstelle zu einem Client, dem Gehirn monolithischer Anwendungen; (3) ein Client-Server-Kommunikationsverwaltungsbereich, der alle Details zusammenfasst, die mit der Übertragung der Ausführung vom Server zum Client verbunden sind. Alle über das Netzwerk zwischen Client und Server übertragenen Informationen werden mit dem DES-Algorithmus (Data Encryption Standard) verschlüsselt, und der Schlüssel wird mit dem Diffie-Hellman-Protokoll [20] geändert, das unter bestimmten Bedingungen anfällig ist. dennoch in einer Vielzahl von Internet-Sicherheitslösungen implementiert.

3.1. Systemarchitektur

Unser System basiert stark auf der Architektur dynamischer Microservice-Systeme. Die Architektur basiert auf dem Client-Server, bei dem der Server einer größeren Anzahl von Clients entspricht. Sowohl der Server als auch der Client führen Web-Microservices durch, das Kommunikationsprotokoll ist HTTP, das Datenformat ist JSON. Diese Architektur ist nützlich, um Ressourcen zwischen Clients zu verteilen und dynamisch neu zu verteilen. Ein solches Architekturmodell wird verwendet, um große, komplexe und horizontal skalierbare Anwendungen zu erstellen, die aus kleinen, unabhängigen und separaten Prozessen bestehen, die mithilfe der API miteinander interagieren [21].

In Abb. Abbildung 1 zeigt, wie ein Server Funktionspakete für seine Clients verteilt. Abhängig von der Anzahl der Clients gibt es möglicherweise Anweisungen, die keinem Client zugewiesen werden, oder denselben Befehlssatz, der mehreren Clients zugewiesen ist.

Feige. 1. Verteilung von Dienstleistungen an Kunden.

Die Anwendungsarchitektur wurde mit dem ASP.NET MVC-Framework von Microsoft erstellt. Im zentralen Teil sehen wir Server-Microservices auf dem Server selbst, und links und rechts warten viele Clients darauf, Aufgaben vom Server aus zu starten. Die Servicekomponente der Orchestrierung bietet einerseits die Kommunikation zwischen dem Server und den Clients, sendet Aufgaben an Clients und überwacht andererseits den Status dieser Anforderungen.

Diese Architektur ermöglicht es einem Mikrodienst, einen anderen Mikrodienst aufzurufen (somit erhalten wir einen erweiterten (erweiterten) Mikrodienst) oder sich gegenseitig aufzurufen, was zu einer zirkulären Abhängigkeit führen kann, die auf Benutzerebene verhindert werden sollte. Das Client-Server-Kommunikationsprotokoll wird in den folgenden Schritten ausgeführt:

Der Client stellt eine Verbindung zum Server her und initiiert ein Schlüsselaustauschprotokoll. Er wird sie auch dem Server und dem Port zur Verfügung stellen, denen sie entsprechen werden.
Der Server benachrichtigt den Client über die nächste auszuführende Aufgabe (die Aufgabe ist ein Paar (Microservice, Eingabedaten)).
Der Client empfängt den Auftrag und benachrichtigt den Server, dass die Übertragung und der Download entweder erfolgreich oder erfolglos abgeschlossen wurden.
Sobald die Verbindung zwischen den beiden Objekten hergestellt ist, sendet der Server die mit DES verschlüsselten Daten im JSON-Format zur Verarbeitung an den Client.
( , ) JSON, DES.
, .
— .

Ein Sonderfall dieser Interaktion ist ein Szenario, in dem ein Client eine Aufgabe ausführt, für deren Ergebnis das Ergebnis eines anderen Clients erforderlich ist. Für diesen Fall wurden zwei bestehende Möglichkeiten bewertet: Orchestrierung und Choreografie.

Im Fall der Choreografie haben wir mehrere Hindernisse festgestellt: (a) Eine Liste der für die Ausführung einer externen Aufgabe verfügbaren Clients musste vom Server an den Client gesendet werden, und die Beibehaltung dieser Liste aktualisierter Werte würde häufig zu einer erhöhten Belastung des Informationsaustauschnetzwerks führen. (b) Die Kommunikation zwischen den beiden Clients war anfällig für Angriffe. Zwei Situationen wurden durch Orchestrierung gelöst. Tatsächlich liegt die gesamte Managementpflege beim Server, und Clients sind nur einfache Objekte, mit denen einfach gearbeitet werden kann.

Für die erweiterte Microservices-Option sind die Phasen der Client-Client-Interaktion wie folgt:

. , . , DES.
, , . , , , , . , ( . .).
, ( ), , .
.
Der Client entschlüsselt das Ergebnis mit einem Einmalkennwort und setzt die Ausführung fort.

3.2. Anwendung

Um diese Architektur zu testen und zu bewerten, haben wir mehrere Mikrodienste implementiert, die wir für das, was wir gleichzeitig überprüfen wollten, aufgerufen haben.

Feige. 2. Die Schnittstelle.

Im ersten Experiment haben wir 3 Mikrodienste wie folgt verwendet: (1) einen Mikrodienst, der eine mathematische Operation an zwei Zahlen ausführt (unter Verwendung von LibraryMath), (2) einen Mikrodienst, der uns sagt, ob die Zahl positiv ist (MasterOfNumbers) und (3) einen erweiterten Mikrodienst, Dieser ruft den ersten Mikrodienst auf, wenn er zwei Nummern empfängt, und das Ergebnis wird an den zweiten Mikrodienst gesendet, um Informationen über diese Nummer (UniverseOfSuperMath) zu extrahieren.

Abbildung 2 zeigt, wie wir mit den vorgestellten Mikrodiensten mathematische Berechnungen erhalten. Auf der Schnittstellenebene wird nur das Ergebnis einer mathematischen Operation angezeigt. Der Rest der Informationen kann als Ergebnis des Empfangs eines AJAX-Anrufs durch Drücken der gleichen Taste durch den Server angezeigt werden (beide Ergebnisse sind positiv).

Als nächstes betrachten wir die Hauptfunktionalität der Anwendung, die sich darauf konzentriert, was passiert, wenn ein, zwei oder mehr verbundene Clients vorhanden sind. In Abbildung 3 sehen wir, wie wir in unseren Experimenten mehr Clients auf dem lokalen Computer gestartet haben, wobei für jeden von ihnen unterschiedliche Ports verwendet wurden.

Feige. 3. Die Schnittstelle.

Wir haben 6 Felder: ClientToken - ein eindeutiges Token, das jedem Client zugeordnet ist (wenn der Aufruf lokal ist und den Wert localhost hat); Datum - der Zeitpunkt, zu dem die Anfrage gestellt wurde; IP & Port = IP-Adresse des Clients und des Ports, über den die Kommunikation erfolgt; Funktion - Name der aufgerufenen Funktion; Erfolg - Ein boolesches Flag, das den Erfolg des Aufrufs anzeigt. Beispielsweise stellen wir fest, dass beim ersten Aufruf (h: 8:38:21 der Client nicht mit dem Server verbunden ist, der Vorgang vom Server ausgeführt wird). Beim zweiten Aufruf beobachten wir das dynamische Verhalten des Systems, dessen eine Aufgabe von einem der Clients und die anderen beiden vom Server ausgeführt werden. Insbesondere wird UniverserOfSuperMath aufgerufen (lokal - der Client ist für diese Aufgabe nicht verfügbar), das wiederum zwei andere Mikrodienste aufruft, einen lokalen und einen über einen Client, der zur Verwendung einer bestimmten Anweisung usw. delegiert wurde.d.

Fehlertoleranz
Eine weitere Funktionalität, die ich beim Erstellen dieser Architektur berücksichtigt habe, betraf die Fehlertoleranz des Systems. Basierend auf dem vorherigen Szenario können wir beobachten, was passiert, wenn ein oder mehrere Clients das System verlassen.

In Abbildung 3 rechts zeigt der Anruf um 8:46 Uhr dieses Szenario. Clients an den Ports 8390 und 8827 haben ein lokales oder Netzwerkproblem oder schließen einfach die Verbindung zum Server, und der Server erhält nicht rechtzeitig eine Benachrichtigung, um sie aus der Liste zu entfernen. Der Server versucht, Clients zu kontaktieren und Befehle auszuführen. Wenn sie jedoch nicht rechtzeitig antworten, übernimmt der Server ihre Aufgaben und gibt das angeforderte Ergebnis zurück. Zur Bestätigung werden Kunden nach einer Weile erneut angefordert. Wenn sie weiterhin nicht antworten, werden sie aus der Liste der verfügbaren Kunden entfernt. Der nächste Aufruf (8:47) fordert nicht mehr nutzlos Clients an, die nicht mehr verfügbar sind, und Aufgaben, die von verfügbaren Clients übersprungen werden, werden vom Server ausgeführt.

Vor- und Nachteile der vorgeschlagenen Lösung

Die Vorteile dieser Architektur liegen auf der Hand: Niedrige Hosting-Kosten, in einem verteilten Netzwerk angebotene Microservices sind dynamisch und automatisch skalierbar (wenn Kunden mit zunehmender Rechenleistung auch Rechenleistung anbieten, steigt die Rechenleistung des Systems).

Die Einschränkungen sollten gleichermaßen hervorgehoben werden: Wenn die Rechenleistungskurve nicht mit der Kundenleistungskurve übereinstimmt. Wir haben auch eine Einschränkung für die Möglichkeit, diese Anwendung auf jedem Betriebssystem auszuführen. Zu diesem Zweck haben wir uns entschlossen, eine kostengünstige Lösung von .NET nach Java zu konvertieren. Diese Lösung weist jedoch einige Nachteile gegenüber der ursprünglichen Lösung auf (Java bietet eine geringere Datenverarbeitungsgeschwindigkeit und eine weniger dynamische Paketübertragung als in .NET). Wir verwenden diese Lösung derzeit, da der von Microsoft für die Arbeit auf mehreren Plattformen angebotene .Net Core noch keine ausgereifte Lösung ist und nicht alle Funktionen der Standard-.NET-Plattform bietet.

3.3. Client-Server-Komponenten

3.3.1. Kunde

In dieser Architektur ist der Client eine Windows Presentation Foundation (WPF) -Desktopanwendung, die speziell für die Kommunikation mit dem Server und die Ausführung verschiedener von ihm empfangener Aufgaben entwickelt wurde. Da es sich bei der Anwendung um eine ausführbare Datei handelt, für die keine Installation erforderlich ist, muss das Betriebssystem mit dem .NET Framework arbeiten. Im Wesentlichen interagiert ein Web-Microservice mit einem anderen Web-Microservice.

Zunächst startet der Client den Taskplaner in einem parallelen Thread, der jede Minute versucht, den Server über seine Anwesenheit zu informieren. Eine Aufgabe kann zwei Zustände annehmen: (1) entweder muss eine Aufgabe ausgeführt werden (die Initialisierung des Codepakets wurde bereits abgeschlossen) - in diesem Fall benachrichtigt sie nur den Server über ihre Anwesenheit; (2) oder erfordert eine Initialisierung mit dem Server.

Die Initialisierung mit dem Server umfasst zunächst eine willkürliche Auswahl von Code und Port, mit dem der Server gestartet wird. Diese werden wiederum mithilfe des Diffie-Hellman-Schlüsselaustauschprotokolls (IKE) an ihn gesendet. Sobald die Verbindung zwischen den beiden Objekten hergestellt ist, benachrichtigt der Server den Client mit einem Paket von Anweisungen zur Installation. Die Hauptaufgabe des Clients besteht darin, ein Anweisungspaket vom Server zu empfangen, es in den Speicher zu laden, die vom Server empfangenen Informationen zu verarbeiten und dann das Ergebnis zurückzugeben, das durch Ausführen dieses Anweisungspakets erhalten wurde. Der erste vom Client ausgeführte Schritt besteht darin, den Server zu kontaktieren, um ein Anweisungspaket zu erhalten. Dieses Anweisungspaket wird als ZIP-Archiv geliefert.

Löschen Sie vor dem Extrahieren dieses Pakets das vorherige Verzeichnis mit Anweisungen aus dem Ordner "process" (falls vorhanden), extrahieren Sie den neuen Inhalt in diesen Ordner und laden Sie ihn in den Speicher. Das Laden des Speichers beginnt einmal, unabhängig davon, wie viele Anrufe der Client erhält. Dies ist möglich, da drei Eigenschaften in der Sitzung unverändert bleiben: Assembly, methodInfo und type. Assembly speichert einen Link zur geladenen DLL, die Eigenschaft methodInfo enthält die von der DLL aufgerufene Methode und type beschreibt den Typ der DLL. Die Datei install.zip ist ein Paket von Anweisungen, die von einem Server empfangen werden und DLLs, XML, Images, Konfigurationsdateien usw. sowie den gesamten kompilierten Code enthalten, der in einem zukünftigen Prozess ausgeführt wird.

Dieser Schritt markiert den Beginn der Kommunikation zwischen Client und Server, um eine bestimmte Aufgabe auszuführen. Sobald der Client erfolgreich für die Ausführung einer bestimmten Aufgabe initialisiert wurde, sendet der Server nur das Datenpaket in verschlüsselter Form, das verarbeitet werden muss, und wartet auch auf eine Antwort in verschlüsselter Form.

Durch Ausführen des vom Server empfangenen Codes wird das System "gesperrt", der Client kann eine Verbindung zu den Datenbanken herstellen, andere APIs aufrufen, insbesondere andere Clients aufrufen, die dieselben oder andere Anweisungen ausführen. Die Verbindung wird im Orchestrierungssystem hergestellt, wo der Server nach dem nächsten verfügbaren Client sucht, das Ergebnis anfordert und seine Antwort vom Server zurück zum Client umgeleitet wird. Diese Microservice-Orchestrierung wird als "ExtendedService" bezeichnet. Der einzige Unterschied auf Client-Ebene besteht darin, dass die Verschlüsselung optimiert ist.

Das technische Problem bestand darin, den Client mit einem weiteren Paket von auszuführenden Anweisungen neu zu initialisieren. Da das Laden des Speichers in einem speziellen Kontext (Webserver) statisch ist, war dies nur durch einen Neustart des gesamten Prozesses zur Verarbeitung der in den Speicher geladenen DLLs möglich. Zu diesem Zweck haben wir Ereignisse in Windows erstellt, die von einer Webanwendung ausgeführt werden, die in einer Desktopanwendung ausgeführt wird. Dies ist notwendig, da es sich um zwei verschiedene Kontexte in zwei verschiedenen Ausführungsthreads handelt.

3.3.2. Server

Der eingebettete Mikroservice verfügt über eine ILibraryMath-Schnittstelle, die die SimpleMath-Methode bereitstellt, und die Schnittstelle wird von der LibraryMath-Klasse implementiert. Die LibraryMath-Klasse erweitert die universelle abstrakte Klasse MicroCore, die zwei entsprechende Parameter für die Eingabe und Ausgabe enthält. Beim Erweitern dieser abstrakten Klasse sollte die ProcessTask-Methode implementiert werden, bei der der gesamte auszuführende Code geschrieben ist, und die Run-Funktion wird in der erweiterten abstrakten Klasse aufgerufen, um diesen Code in der SimpleMath-Methode auszuführen. Auf diese Weise ist es möglich, Schnittstellen und Methoden zu definieren, die nicht auf einen bestimmten Namen beschränkt sind. Wenn Sie den Code jedoch durch eine abstrakte Klasse leiten, erhalten Sie die volle Kontrolle über den Code, den wir auf verschiedene Clients verteilen können. Innerhalb dieser Klasse können wir leicht mehr Funktionen und importierte Bibliotheken haben,wenn sie in einem Paket zusammengefasst sind.

Der nächste Schritt besteht darin, diese Schnittstelle in SimpleInjector zu schreiben, eine Bibliothek, die die Bereitstellung eines Abhängigkeitsinjektionsmusters mit lose gekoppelten Komponenten erleichtert. Zusätzlich zum Aufzeichnen von verschachtelten Klassen im Simple Injector-Container müssen wir die Klasse im Microservice-Speichercontainer registrieren, der von der Anwendung skaliert wird, um die Abhängigkeit zwischen Anwendungsebenen zu lösen (Einführung von Vorlagenabhängigkeiten). Nach diesem Schritt können wir die von der Schnittstelle bereitgestellte Funktion für den erstellten Zweck verwenden.

Service1 implementiert IService1 und erweitert die abstrakte MicroCore-Klasse und registriert sich dann bei MicroContainer.RegisterMicro in diesem Container. Erwähnenswert ist das Vorhandensein von APIs in localohst / DynamicMicros / {Service}, über die Clients mit dem Server kommunizieren. Wichtige Aktionen, die über diese APIs verfügbar sind: Der Client stellt eine Verbindung her, der Client benachrichtigt den Server über seine Aktivität, die Microservices werden erweitert usw. Als nächstes stellen wir die Klassen MicroCore und MicroContainer vor, die zusammen die Grundlage unserer Anwendung bilden.

Die MicroCore-Klasse ist eine abstrakte, universelle Klasse und für den Aufruf von Code aus der virtuellen ProcessTask-Methode verantwortlich. Dies erfolgt durch Aufrufen der Run-Methode, die wiederum die öffentliche TaskManager-Methode aufruft. Beachten Sie, dass der Microservice wiederum diese Methode aufruft. Wenn ein ZIP-Paket zum Laden in den Speicher und zur Ausführung an den Client gesendet wird, wird es mit all seinen Abhängigkeiten gesendet, einschließlich dieser Klasse, die zum Verwalten des Microservices des Clients verwendet wird. Die Ausführungssteuerung umfasst das Deserialisieren / Serialisieren des zu sendenden Datenpakets, das Aufrufen des Codes selbst, das Aufrufen anderer APIs usw. Die

Rückkehr zur Serverseite und das Steuern der Ausführung des Codes besteht aus den folgenden Schritten:

Wenn es sich um einen ExtendedService-Aufruf handelt, wird der Server zur Beantwortung aufgerufen.
Wenn ein Kunde für die Anfrage verfügbar ist, wird er an ihn gesendet, um das Ergebnis zu verarbeiten. Im negativen Fall verarbeitet der Server selbst die Daten.
Wir bitten einen Kunden um Datenverarbeitung.
Wenn der Client Probleme hat, bitten wir Sie erneut um Bestätigung der Verfügbarkeit, senden jedoch eine Serverantwort (um Ausfallzeiten und lange Wartezeiten zu vermeiden).
Wir registrieren aktuelle Aktivitäten.

Die MicroContainer-Klasse ist der Verwaltungsbereich für das gesamte eingebettete Mikrosystem. Hier stellen die Clients, die die Anwendung (den Server) verbinden, eine Verbindung her, und es gibt Funktionsaufrufe, die die abstrakte MicroCore-Klasse für "erweiterte Dienste" erweitern. Dies ist eine statische Klasse, in der die Liste der auf Microservices ausgeführten Aufgaben, die Liste der verbundenen Clients und die Liste der Clientaufgaben, die diese Aufgaben ausführen, im Wörterbuch gespeichert sind.

Beim Start wird die Klasse für die Integration in den Microservice mit RegisterMicro registriert. Dies geschieht nur einmal während der Initialisierung. Die AddNewClient-Methode ermöglicht die Registrierung eines neuen Clients, den Schlüsselaustausch, die Registrierung der IP-Adresse des Servers und des Ports, an dem er arbeiten wird. Das vom neuen Client empfangene Token wird überprüft, bevor es in die Liste der Clients eingefügt wird, um seine Eindeutigkeit zu bestätigen. Sobald die Verbindung zum Client hergestellt ist, ruft der Server die InstallService-Methode auf, die die Daten packt, sendet und nach der Antwort des Clients dem Wörterbuch für diese Aufgabe hinzugefügt wird. Die Servicezeit, die jedem Kunden zugewiesen wird, hängt von der verwendeten Strategie ab. Wenn Sie den abstrakten MicroCore-Mikroservice starten, der sowohl auf dem Server als auch auf dem Client (mit ExtendedService) aufgerufen wird,Mit der Funktion GetNextClient werden verfügbare Clients für die angeforderte Aufgabe angefordert. Dieser Vorgang wird sehr häufig ausgeführt, und seine Komplexität wirkt sich direkt auf die Antwortzeit der Anwendung aus. Deshalb war unser Ansatz, einen Kunden zufällig auszuwählen. Dies geschieht schnell und sorgt aus unseren Experimenten für eine gleichmäßige Verteilung der Anrufe.

Eine weitere Option war die Implementierung einer Round-Robin-Liste - eine Lösung mit dem Nachteil, dass die Aktualisierung der Round-Robin-Liste im Falle eines großen Client-E / A-Streams mehr Zeit und Komplexität erfordert, was wir zu vermeiden versuchten. Die RecordClientError-Methode wird aufgerufen, wenn der Client nicht auf die empfangene Anforderung antwortet. Nach Beantwortung dieser Frage wird entschieden, diesen Client zu speichern oder zu löschen. Clients werden durch den vom Client während der Initialisierung gesendeten Token-Code eindeutig identifiziert, und jeder Mikrodienst wird durch einen Namespace und einen Klassennamen identifiziert. Alle Ressourcen (Clients, Code) werden über diese einheitliche Einheit verwaltet, die die erforderlichen Vorgänge unterstützt.

In Bezug auf die Systemsicherheit wurden Maßnahmen ergriffen, um Angriffe, Abfangen und Datenschutz zu verhindern. Alle zwischen dem Server und den Clients gesendeten Nachrichten werden mit dem symmetrischen DES-Schlüsselalgorithmus und dem Diffie-Hellman-Schlüsselaustausch zwischen dem Client und dem Server verschlüsselt, der während der Clientinitialisierung erfolgt. Verfügbare Clients und laufende Programme werden im Serverspeicher gespeichert. Wir haben uns für diese Lösung entschieden, weil sie unserer Meinung nach die beste Option war, da sie einen schnellen Zugriff auf Daten bietet, Informationen sehr häufig geändert werden können und der Speicherbereich sehr schwer anzugreifen ist.

3.4. Dynamisches Verhalten eines Microservice-Systems

Erstens können sich alle Computer, auf denen die Clients arbeiten, in demselben oder in verschiedenen Netzwerken befinden. Zwei Elemente haben Vorrang: (a) Zeitaufwand für die Datenübertragung; und (b) den vom System für die Datenverwaltung hinzugefügten Overhead (z. B. Kundensuche, Verschlüsselung, Entschlüsselung, Fehlerbehandlung usw.). Wir waren hauptsächlich am Verhalten unseres Systems in lokalen (LAN) und globalen (WAN) Netzwerken interessiert (Abb. 4).

Feige. 4. Aufzeichnung des Systems, das in einem lokalen Netzwerk (erste Protokollspalte) und global (zweite Protokollspalte) arbeitet.

Die Spalte Aufgabenname enthält alle vom Clientaufruf für jede Aufgabe vorgenommenen Registrierungen, und die Spalten Protokolle geben die Stunden und die Dauer in ms für jede Aufgabenverarbeitung an (links im lokalen Netzwerk und rechts im globalen Netzwerk). Beachten Sie, dass Aufgaben die längste Antwortzeit auf den ersten Anruf haben und danach abnimmt. Natürlich, da alle Speicher-Downloads, Speicheradressen usw. normalerweise beim ersten Aufruf erfolgen. Die ersten drei Aufgaben sind einfache mathematische Operationen, die normalerweise innerhalb von Millisekunden ausgeführt werden - die Zeit, die auch für unser System benötigt wird.

Für ein lokales Netzwerk haben wir durchschnittlich 20 bis 30 Millisekunden pro Aufgabe, die aus der Verschlüsselung, Protokollierung und Übertragung über das Netzwerk stammen (auch wenn es lokal ist). Dieses Modell der LAN-Kommunikation wird auch in der Cloud verwendet, wo sich Computer am selben Ort (Rechenzentrum) befinden und die Kommunikation zwischen ihnen über Glasfaser erfolgt. Die Netzwerkverzögerung ist minimal. Die Ergebnisse sind in Abb. 2 dargestellt. 4 in der linken Spalte der Protokolle.

Um unsere WAN-Anwendung zu testen, haben wir den Router so konfiguriert, dass ein Anruf von Port 80 an Folgendes weitergeleitet wird:http://192.168.1.160/(Netzwerkadresse) und IIS (Internet Information Services) haben die Anwendung gestartet und waren von überall außerhalb des lokalen Netzwerks zugänglich. Um die Anwendung auf Client-Ebene auszuführen, war das Recht erforderlich, die Ports 8000: 9000 (beliebige Ports) zu verwenden. Clients werden an beliebigen Punkten angeordnet, die Verbindung zur öffentlichen IP wurde über die API festgestellt : https://api.ipify.org/. Die Ergebnisse sind in Abb. 2 dargestellt. 4 in der Protokollspalte rechts.

In den in Abb. In 4 sind die Werte in der rechten Spalte des Journals 16-17% höher als die Werte in der linken Spalte des Journals für die ersten drei Aufgaben (ohne Kommunikation mit anderen Mikrodiensten) und ± 10% für Mikrodienste, die Dokumente aus dem Internet heruntergeladen oder mit der Datenbank interagiert haben spezifischer Server.

4. Bewertung

In dieser Studie haben wir das Verhalten des Systems sowohl im lokalen Netzwerk (5 Computer über ein drahtloses Netzwerk verbinden) als auch im globalen Netzwerk (unter Verwendung des Namespace mihaidm.ddns.net ) überwacht und unser System mit einem monolithischen System verglichen. Diese Vorgänge werden auf demselben System ausgeführt Computer (siehe Tabelle 1).

Tabelle 1. Systembewertung für Netzwerke.

	Berechnung (ms)	in Datenbank schreiben (ms)	PDF-Generierung (ms)
localhost	1	4.458	15.449
lan	25	4.408	16.415
wan	54	4.826	29.309

Die Tests wurden nacheinander auf einem Gerät mit 5 verbundenen Clients für Netzwerktests durchgeführt. Jede Aufgabe wurde 100 Mal ausgeführt, wobei die Gesamtzahl der Millisekunden in allen Aufrufen ausgewertet wurde.

Es war ein Produkt aus zwei Zahlen als numerische Berechnung. Ein Microservice interagiert nicht mit anderen Microservices, die über das Netzwerk übertragene Informationsmenge ist gering und die Komplexität wird minimiert, um die für Server-, Client- und Netzwerkverwaltungsaufgaben aufgewendete Zeit genau zu untersuchen. Wenn die Berechnung vom Server (localhost) durchgeführt wird, wird zunächst geprüft, ob ein Client verfügbar ist. Da der Client nicht verbunden ist, verarbeitet der Server das Ergebnis. Im folgenden Fall zeigt das Vorhandensein von Clients im lokalen Netzwerk den Abschluss der Aufgabe unter Bedingungen eines sehr schnellen Netzwerkbetriebs und von der Verarbeitungsseite aus Verschlüsselung / Entschlüsselung, wobei die Antwort des Clients gefunden wird. Für 100 Ausführungen betrug die durchschnittliche Zeit, die zum Abschließen des Vorgangs erforderlich war, 25 ms, was angesichts des Verhältnisses von Flexibilität zu Geschwindigkeit ein vielversprechender Wert ist. Im Falle von WAN ist die Zeit doppelt so langals im lokalen Netzwerk (54 ms) ist dies auf den Verschlüsselungsprozess zurückzuführen, Transportkosten, aber für die eigentliche Ausführung dauert eine halbe Millisekunde.

Eine weitere Aufgabe, die wir untersucht haben, ist das Schreiben in die Datenbank. Insbesondere wird das Wort, das in die Datenbank geschrieben wird, als Parameter verwendet. Wir sind daran interessiert, wie schnell der Kunde eine Datenbank außerhalb des lokalen Bereichs kontaktieren wird (für diese Studie befand sich die Datenbank unter www.my.gearhost.com ). Beachten Sie, dass die Laufzeitwerte in LAN und localhost nahe beieinander liegen. Im globalen Netzwerk ist der Unterschied spürbar, da die Verarbeitung, Verwaltung von Daten und Clients nicht so lange dauert wie der Bereich der Clients, die eine Verbindung zur Datenbank herstellen, um den Wert einzufügen.

Die letzte Aufgabe in dieser Studie war die Erstellung einer PDF-Datei. Unser Fokus lag auf der Schätzung der Übertragungszeit der Daten im System. Dazu laden wir die PDF-Datei von www.pdf-archive.com/2018/05/14/diploma/diploma.pdf herunter , die in den Speicher geladen wird. Das System schreibt den Namen an eine bestimmte Position und gibt das Ergebnis (in Form von Bytevektoren) an den Server zurück. Bei einem lokalen Host und einem lokalen Netzwerk entspricht eine Differenz von ca. 1000 ms der Zeit, die zum lokalen Verschlüsseln und Übertragen von PDF-Dateien erforderlich ist. Für das WAN ist der resultierende Wert höher, da die Übertragungskosten des Bytevektors sehr hoch sind.

5. Schlussfolgerungen und zukünftige Arbeit

Die allgemeine und abstrakte Natur der Systemarchitektur, die in dieser Arbeit auf der Serverseite vorgestellt wurde, erschwerte das Design, da derselbe Code sowohl vom Server als auch vom Client ausgeführt wird. Wir können argumentieren, dass die aktuelle Architektur kompakt, einfach, leicht zu verstehen und zu erweitern ist. Der Client kann die vom Server zugewiesenen Aufgaben ausführen, der Server ist ein Monolith und die Client-Schnittstelle.

Die vorgeschlagene Architektur macht es sehr einfach, neue Mikrodienste zu erstellen, die dann automatisch in das eingebettete System integriert werden. Innovative Elemente dieser Architektur: Sie kann sehr einfach skaliert werden, jeder neue Client erhält eine Aufgabe vom Server gemäß der verfolgten Strategie (die teuersten Aufgaben, die häufigste, eine Kombination der beiden zuvor aufgeführten oder nur eine willkürliche Strategie). Tatsächlich haben wir einen Monolithen mit der Flexibilität eines Microservice-Systems. Der Server verarbeitet die dynamische Verteilung von Aufgaben zwischen Clients und bietet eine dynamische Skalierung basierend auf einer Reihe von Parametern (Anzahl der Aufrufe der Aufgabe, Ausführungszeit oder eine Kombination davon).

Eine der zukünftigen Richtungen berücksichtigt, dass dieses System erfolgreich in eine Website oder ein API-System mit einem ausgeprägten anwendbaren Charakter integriert werden kann. Die vorgeschlagene Architektur kann aufgrund der Verfügbarkeit für mehrere Plattformen (z. B. für Mobiltelefone) jederzeit verbessert und erweitert werden.

Eine andere Richtung in der Zukunft, die wir in Betracht ziehen, wird heute als äußerst attraktiv angesehen - ist, dass der Benutzer gegen eine Gebühr (zum Beispiel das BITCOIN-System) Rechenleistung bereitstellt. Unsere Anwendung wurde entwickelt, um Microservices auf bestimmten Computern auszuführen.

Quelllink

Diese Studie wurde mit Unterstützung des Programms POC-A1-A1.2.3-G-2015 im Rahmen des PrivateSky-Projekts (P_40_371 / 13/01/01/2016) und des README-Projekts „Interaktive und innovative Anwendung zur Bewertung der Lesbarkeit rumänischer Texte und zur Verbesserung der Benutzerqualität“ veröffentlicht Schreibstile “, Vertrags-Nr. 114 / 09.15.2017, MySMIS 2014 Code 119286.

Verweise

[1] Dragoni, N., Giallorenzo, S., Lluch-Lafuente, AL, Mazzara, M., Montesi, F., Mustafin, R. (2017a) "Microservices: Gestern, heute und morgen." Mazzara M., Meyer B. (Hrsg.), Present and Ulterior Software Engineering. Springer
[2] M. Mazzara, K. Khanda, R. Mustafin, V. Rivera, L. Safina und A. Silitti (2018) "Microservices Science and Engineering". In: P. Ciancarini, S. Litvinov, A. Messina, A., Sillitti, G. Succi (Hrsg.) Tagungsband der 5. Internationalen Konferenz für Software-Engineering für Verteidigungsanwendungen, SEDA 2016, Springer, 10-20.
[3] Dragoni, N., Lanese, I., Larsen, ST, Mazzara, M., Mustafin, R. und Safina, L. (2017b) „Microservices: So erstellen Sie Ihre Anwendungsskala“. In: Petrenko A., Voronkov A. (Hrsg.) Perspektiven der Systeminformatik. PSI 2017. Lecture Notes in Computer Science, 10742. Springer, Cham.
[4] Melis, A., Mirri, S., Prandi, C., Prandini, M., Salomoni, P. und Callegati, F. (2016) „Ein Anwendungsfall für die Microservice-Architektur für Menschen mit Behinderungen“. Auf der 2. Internationalen EAI-Konferenz zu intelligenten Objekten und Technologien für das soziale Wohl, DOI: 10.1007 / 978-3-319-61949-1_5.
[5] Zimmermann, O. (2017) „Grundsätze von Microservices: Agiler Ansatz für die Entwicklung und Bereitstellung von Diensten, Informatik - Forschung und Entwicklung“, 32 (3-4): 301-310.
[6] Xia, C., Zhang, Y., Wang, L., Coleman, S. und Liu, Y. (2018) „Mikroservice-basiertes Cloud-Robotersystem für den intelligenten Raum“. In: Robotics and Autonomous Systems 110, DOI: 10.1016 / j.robot.2018.10.001.
[7] Bogner, J., Fritzsch, J., Wagner, S. und Zimmermann, A. (2019) „Microservices in Industry: Einblicke in Technologien, Eigenschaften und Softwarequalität“. Auf der IEEE International Conference on Software Architecture Workshops (ICSAW) 2019 in: Hamburg, Deutschland.
[8] Akentev, E., Tchitchigin, A., Safina, L. und Mzzara, M. (2017), „Verifizierter Typprüfer für die Programmiersprache Jolie“, https: // arXiv.org/pdf/1703.05186.pdf.
[9] Černý, T., Donahoo, MJ und Trnka, M. (2018) „Kontextuelles Verständnis der Microservice-Architektur: aktuelle und zukünftige Richtungen“. ACM SIGAPP Applied Computing Review 17 (4): 29-45, DOI: 10.1145 / 3183628.3183631.
[10] Larucces, X., Santamaria, I., Colomo-Palacios, R. und Ebert, C. (2018) "Microservices". In: IEEE Software, 35/3: 96-100.
[11] Kalske, M. (2017) „Transformation der monolithischen Architektur in Richtung Mikroservice-Architektur“. M.Sc. Diplomarbeit, Univ. von Helsinki.
[12] Lenarduzzi, V. und Taibi, D. (2016) „MVP Explained: Eine systematische Kartierungsstudie zu den Definitionen eines minimal lebensfähigen Produkts“. Auf der 42. Euromicro-Konferenz für Software Engineering und Advanced Applications (SEAA), 112-119.
[13] Taibi, D., Lenarduzzi, V., Janes, A., Liukkunen, K. und Ahmad, MO (2017) „Vergleich der Anforderungszerlegung innerhalb des Scrum, Scrum mit Kanban-, XP- und Bananenentwicklungsprozessen“. In: Baumeister H., Lichter H., Riebisch M. (Hrsg.) Agile Prozesse in Software Engineering und Extreme Programming. Lecture Notes in Business Information Processing, 283. Springer, Cham.
[14] Gómez, A., Benelallam, A. und Tisi, M. (2015) „Dezentrale Modellpersistenz für verteiltes Rechnen“. Beim 3. BigMDE-Workshop in L'Aquila, Italien.
[15] Kandave, KR (2018) „Hochleistungsrechnen auf Azure“. Nanette Ray (Hrsg.), AzureCAT, Microsoft Corporation.
[16] Sreenivas, V., SriHarsha, S. und Narasimham, C. (2012) „Ein Cloud-Modell zur Implementierung von SaaS“. In: Advanced Materials Research 341-342, Trans Tech Publications, Schweiz, 499-503.
[17] Badidi, E. (2013) „Ein Rahmen für die Auswahl und Bereitstellung von Software als Service“. In: Internationales Journal für Computernetzwerke und Kommunikation (IJCNC), 5 (3): 189-200.
[18] Lynn, T., Rosati, P., Lejeune, A. und Emeakaroha, V. (2017) „Ein vorläufiger Überblick über Enterprise Serverless Cloud Computing-Plattformen (Functionas-a-Service)“. Auf der 9. Internationalen IEEE-Konferenz 2017 zu Cloud Computing-Technologie und -Wissenschaft, 162-169.
[19] Adzic, G. und Chatley, R. (2017) „Serverless Computing: Wirtschaftliche und architektonische Auswirkungen.“ Bei: ESEC / FSE'17, 4.-8. September 2017, Paderborn, Deutschland, ACM.
[20] Diffie, W. und Hellman, M. (1976) "Neue Richtungen in der Kryptographie". In: IEEE Transactions on, Information Theory, 22 (6): 644–654.
[21] Kratzke, N. (2015) „Über Microservices, Container und ihre unterschätzten Auswirkungen auf die Netzwerkleistung“. Bei der CLOUD Comput. 2015, 180 arxiv.org/abs/1710.04049 .

Erfahren Sie mehr über den Kurs

Erstellen Sie eine skalierbare und ausfallsichere Architektur mit dynamischen Mikrodiensten