Microservices entwickeln mit Service Fabric

Schnelle und agile Software-Entwicklung steht immer mehr im Mittelpunkt einer erfolgreichen Firmenstrategie. Hierbei kann eine Microservice-Architektur die Arbeit von Entwicklern an vielen Stellen erleichtern. Der Grundgedanke ist dabei, eine komplexe Anwendung in kleine, lose miteinander verbundene Komponenten (Services) aufzuteilen. Hierbei sollten die einzelnen Komponenten vollkommen unabhängig voneinander sein. So können diese Komponenten unabhängig voneinander entwickelt und deployed werden.

Vorteile einer solchen Architektur sind außerdem:

– Gute Skalierbarkeit
– Hohe Verfügbarkeit
– Hohe Zuverlässigkeit

Neben den Vorteilen einer Microservice-Architektur, wie z. B. schnellere Entwicklung, gute Skalierbarkeit und einfachem Deployment, gibt es aber auch einige Nachteile, die vor allem die Entwicklung erschweren:

  1. Die Entwicklung verteilter Systeme ist schwierig.
  2. Verteilte Systeme sind schwer zu testen.
  3. Verteiltes Logging
  4. Verwaltung der Microservices
  5. Überwachung von Microservices

Diese Nachteile lassen sich durch den Einsatz eines geeigneten Frameworks aber sehr gut kompensieren. Gängige Microservice-Frameworks sind z. B. das Java-Framework Akka, das mit Akka.NET auch als .NET-Version existiert. Leider sind die beiden Versionen nicht kompatibel zueinander. Außerdem existieren auch eigene Programmiersprachen, wie Erlang, die auf das Erstellen von verteilten, skalierbaren Echtzeit-Systemen optimiert sind.

Auch Microsoft hat die Notwendigkeit erkannt, ein Framework und eine Laufzeitumgebung für Microservices zur Verfügung zu stellen: Azure Service Fabric.

Microsoft benutzt diese Technologie seit einigen Jahren schon selbst intern für eigene Dienste in seiner Cloud-Umgebung. Service Fabric kann sowohl als vorkonfigurierte Cloudlösung innerhalb der Azure-Cloud betrieben werden als auch on-premise oder in jeder anderen Cloud-Umgebung auf Windows- oder Linux-Basis. Die Entwicklung erfolgt in .NET oder Java, kann aber auch unter NodeJS erfolgen.

Die Entwicklung einer Applikation mit Azure Service Fabric ist vollkommen in die Entwicklungsumgebung Microsoft Visual Studio integriert. Hierbei wird nicht nur ein Service-Fabric-Cluster simuliert, sondern ein lokaler Service-Fabric-Cluster erstellt. Das bietet den Vorteil, dass eventuelle Inkompatibilitäten durch eine Emulation entfallen. Der Software-Entwickler erstellt seine Services in der gewohnten Umgebung und ist sogar in der Lage, diese verteilten Services in derselben Entwicklungsumgebung zu erstellen, zu debuggen und zu testen. Dies erleichtert den Entwicklungsprozess von verteilten Anwendungen enorm.

Insgesamt unterstützt das Framework die folgenden Punkte:

– Service-Discovery
– Local Data Storage
– Logging
– Monitoring, Skalierung und Failover
– Deployment und Upgrade (Update on the Fly)
– Versionierung

 

Service-Fabric-Architektur

Ein Service-Fabric-Cluster setzt sich aus einer beliebigen Anzahl von physikalischen oder virtuellen Servern zusammen, auf denen die Service Fabric Runtime installiert wurde. In einer produktiven Umgebung entspricht normalerweise ein Knoten einem Server. Zum Entwickeln oder Testen können aber auch mehrere Knoten auf einem Server laufen.

 

 

Wird eine Service-Fabric-Applikation auf den Cluster deployed, übernimmt der Cluster selbständig die Installation und Verteilung auf die vorhandenen Knoten. Sollte während der Laufzeit ein Server beziehungsweise ein Knoten ausfallen, wird dies automatisch erkannt und Anfragen an den sekundären Service weitergeleitet. Alle Services werden automatisch auf die vorhandenen Knoten verteilt, um eine möglichst gute Lastverteilung zu erreichen.

 

 

Programmiermodelle

Es gibt verschiedene Möglichkeiten, Services für die Service Fabric zu erstellen. Service Fabric unterscheidet zwischen 3 Programmiermodellen:

– Guest Executables
– Reliable Services
– Reliable Actors

Guest Executables

Bei den Guest Executables handelt es sich im Prinzip um beliebige Executables/Assemblies. Dadurch ist es möglich, unabhängig von der Programmiersprache Services für eine Service-Fabric-Applikation zu entwickeln. Eine spezielle Service-Fabric-Library wird hierbei nicht benutzt. Im Prinzip können beliebige Programme verwendet werden, die sich auf dem jeweiligen Betriebssytem ausführen lassen. Nachteil dieser Vorgehensweise ist, dass der so zur Verfügung gestellte Service nichts von der Service-Fabric-Umgebung kennt und daher auch nicht alle Funktionalitäten nutzen kann.

Reliable Services

Im Gegensatz zu Guest Executables können Reliable Services direkt auf die Service Fabric API zugreifen. Da diese Services wissen, dass sie innerhalb eines Service-Fabric-Clusters ausgeführt werden, können sie auf Ressourcen und Informationen innerhalb des Clusters zugreifen. So ist es z. B. problemlos möglich, Daten hochverfügbar innerhalb des Clusters zu speichern.

Bei Reliable Services unterscheidet man zwischen Stateless Services und Stateful Services:

Stateless Services

Stateless Services können verwendet werden, wenn der Zustand eines Service nicht gespeichert werden muss. Zustandslose Dienste werden daher oft als Front-End-Services verwendet, die die öffentliche API für eine Web-Anwendung darstellen. Intern können diese dann mit anderen Services kommunizieren. Sie stellen die einfachste Form eines Service-Fabric-Services dar.

Stateful Services

Im Gegensatz zu Stateless Services können Stateful Services ihren Zustand konsistent und sicher speichern. Für die Speicherung von Daten werden Reliable Collections verwendet. Unterschieden werden zwischen:

– Reliable Dictionary: ein asynchrones, transaktionsbasiertes, repliziertes Wörterbuch
– Reliable Queue: eine asynchrone, transaktionsbasierte, replizierte Warteschlange

Durch die Reliable Collections ist es möglich, auf die Verwendung einer zentralen Datenbank komplett zu verzichten. Jeder Service speichert seine Daten lokal in einer Reliable Collection. Service Fabric sorgt dann dafür, dass diese Daten zu den anderen Knoten repliziert werden und bei einem Ausfall eines Knotens die Daten weiter zur Verfügung stehen. Durch den Verzicht auf eine zentrale Datenbank können die Services wesentlich besser skaliert werden.

Reliable Actors

Ein weiteres Programmiermodel stellen die Reliable Actors innerhalb der Service Fabric dar. Diese basiert auf dem Actor Model. Hierbei kommunizieren Aktoren als nebenläufige Einheiten ausschließlich über Nachrichtenaustausch miteinander. Ein Aktor hat folgende Eigenschaften:

  1. Ein Aktor kann Nachrichten empfangen.
  2. Ein Aktor kann Nachrichten senden.
  3. Ein Aktor kann neue Aktoren erzeugen.
  4. Ein Aktor kann sein Verhalten ändern.

Aktoren sind hierbei innerhalb einer Service-Fabric-Applikation virtuell, d. h. Aktoren müssen weder explizit erzeugt noch gelöscht werden, da sie logisch immer existieren. Wird ein Aktor nicht mehr benutzt, wird dieser automatisch von Service Fabric deaktiviert. Ein Aktor basiert auf einem Stateful Service. Daher wird der Zustand eines Aktors in einer Reliable Collection gespeichert. Service Fabric kümmert sich also um folgende Dinge:

– Instanziierung eines Aktors
– Speicherung der Eigenschaften eines Aktors
– Lebensdauer eines Aktors; (nicht benutzte Aktoren werden automatisch aus dem Speicher entfernt.)

 

Fazit

Microsoft stellt mit Service Fabric eine mächtige Entwicklungsumgebung für Microservices zur Verfügung. Wird ein Service-Fabric-Cluster innerhalb der Microsoft Azure betrieben, dient Service Fabric sogar als „Platform as a Service“ (PaaS). Die Verwaltung der einzelnen Knoten übernimmt Azure selbst, neue Knoten können sehr einfach zu einem bestehenden Cluster hinzugefügt werden. Dies ermöglicht einen minimalen administrativen Aufwand für das Betreiben eines Clusters.

Die Entwicklung von Service Fabric geht rasant weiter. So lassen sich in der neuesten Version auch Docker-Container innerhalb eines Service-Fabric-Clusters betreiben. Es bleibt spannend, wie sich diese Technologie weiterentwickelt.

 

Autor: Rüdiger Gutfleisch, Software Architekt und Innovation Developer

Kontakt: Ruediger.Gutfleisch@dot4.de

Schreibe einen Kommentar

Your email address will not be published. Required fields are marked *