2017-03-23

Dezember 2015

Band 30, Nummer 13

Microsoft Azure – Azure Service Fabric und die Microservices-Architektur

Von Cesar de la Torre, Kunal Deep Singh, Vaclav Turecek | Dezember 2015

„Microservices“ ist derzeit eines der beliebtesten Schlagworte. Während bei vielen Präsentationen und Konferenzdiskussionsrunden vielfach die Rede davon ist, bleiben viele Entwickler verwirrt zurück. Eine der uns häufig gestellten Fragen lautet: „Ist dies nicht bloß ein weiterer SOA- (Serviceorientierte Architektur) oder DDD-Ansatz (Domain-Driven Design)?“

Sicherlich sind viele der beim Microservices-Ansatz verwendeten Techniken von den Erfahrungen von Entwicklern mit SOA und DDD abgeleitet. Sie können sich Microservices als „ geglückte SOA“ vorstellen – mit Prinzipien und Mustern wie autonomen Diensten, Mustern mit gebundenen Kontexten und Ereignissteuerung, die alle ihre Wurzeln in SOA und DDD haben.

In diesem Artikel beschäftigen wir uns mit der Theorie und Implementierung von Microservices. Wir beginnen mit einer kurzen Einführung in Microservices und wenden uns dann der praktischen Seite zu, indem wir zeigen, wie Sie Microservices mit Azure Service Fabric entwickeln und bereitstellen können. Abschließend veranschaulichen wir, warum diese Plattform sich besonders für das Entwickeln von Microservices eignet.

Wie der Name schon sagt, ist die Microservices-Architektur ein Ansatz zum Entwickeln einer Serveranwendung in Form einer Gruppe kleiner Dienste. Dabei wird jeder Dienst in seinem eigenen Prozess ausgeführt, und die Dienste kommunizieren miteinander über Protokolle wie HTTP und WebSockets. Jeder Microservice implementiert spezifische umfassende Domänen- und Geschäftsfunktionen innerhalb eines gebundenen Kontexts pro Dienst und muss über automatisierte Mechanismen autonom entwickelt und unabhängig bereitgestellt werden. Schließlich muss jeder Dienst ein eigenes zugehöriges Domänendatenmodell und eigene Domänenlogik aufweisen und kann pro Microservice verschiedene Datenspeichertechnologien (SQL, NoSQL) und Programmiersprachen nutzen.

Beispiele von Microservices sind u. a. Protokollgateways, Benutzerprofile, Einkaufswagen, Inventarverarbeitung, Einkaufssubsystem, Zahlungsverarbeitung, Warteschlangen und Caches.

Gründe für Microservices Der Hauptgrund ist Agilität. Langfristig ermöglichen Microservices eine überlegene Verwaltbarkeit großer, komplexer und überaus skalierbarer Systeme, indem Anwendungen basierend auf vielen unabhängig bereitstellbaren Diensten entworfen werden, die eine differenzierte Versionsplanung ermöglichen.

Ein weiterer Vorteil ist, dass Microservices unabhängig horizontal hochskaliert werden können. Anstatt mit riesigen monolithischen Anwendungsblöcken zu arbeiten, die zugleich horizontal hochskaliert werden müssen, können Sie stattdessen bestimmte Microservices horizontal hochskalieren. Auf diese Weise können bloß die Funktionsbereiche skaliert werden, die mehr Verarbeitungsleistung oder Netzwerkbandbreite zum Erfüllen der Nachfrage brauchen, sodass dies bei anderen Anwendungsbereichen, die dies nicht benötigen, nicht erforderlich ist.

Das Entwerfen differenzierter Microservices-Anwendungen ermöglicht fortlaufende Integration und Entwicklungsmethoden und beschleunigt die Bereitstellung neuer Funktionen in der Anwendung. Durch das differenzierte Zerlegen von Anwendungen können Sie zudem Microservices isoliert ausführen und testen sowie Microservices unabhängig weiterentwickeln, wobei strenge Verträge zwischen ihnen eingehalten werden müssen. Solange Sie nicht gegen die Vorgaben der Verträge der Schnittstellen verstoßen, können Sie die Implementierung eines Microservice ändern und neue Funktionalität hinzufügen, ohne die anderen Microservices zu stören, die von diesem abhängen.

Wie Abbildung 1 zeigt, geht es beim Microservices-Ansatz hauptsächlich um Effizienz für agile Änderungen und schnelle Iterationen, da Sie bestimmte, kleine Teile großer, komplexer und skalierbarer Anwendungen ändern können.

Abbildung 1: Der Microservices-Ansatz im Vergleich zum herkömmlichen Ansatz für Serveranwendungen

Datensouveränität pro Microservice

Ein wichtiger Grundsatz bei diesem Ansatz ist, dass jeder Microservice seine eigene(n) Domänendaten und -Logik im Rahmen eines autonomen Lebenszyklus besitzen muss – bei unabhängiger Bereitstellung pro Microservice. Dies ist keine Unterschied dazu, wie eine vollständige Anwendung ihre Logik und Daten besitzt.

Dieser Ansatz bedeutet, dass das konzeptionelle Modell der Domäne sich bei Subsystemen bzw. Microservices unterscheidet. Nehmen Sie z. B. Unternehmensanwendungen, bei denen CRM-Anwendungen (Customer Relationship Management), transaktionsgesteuerte Einkaufssubsysteme und Kundendienstsubsystemen eindeutige Kundenentitätsattribute und Daten in Anspruch nehmen und einen anderen gebundenen Kontext nutzen.

Dieses Prinzip ist ähnlich wie beim DDD, wo jeder gebundene Kontext (ein mit einem Subsystem/Dienst vergleichbares Muster) über ein eigenes Domänenmodell (Daten und Logik) verfügen muss. Jeder gebundene Kontext in DDD kann mit einem anderen Microservice korreliert werden.

Im Gegensatz dazu steht der herkömmliche (bzw. monolithische) Ansatz in vielen Anwendungen, der ein einzelne, zentrale Datenbank (häufig eine normalisierte SQL-Datenbank) für die gesamte Anwendung und alle ihre internen Subsysteme vorsieht (siehe Abbildung 2). Dieser Ansatz sieht anfänglich einfacher aus und scheint die Wiederverwendung von Entitäten in verschiedenen Subsystemen zu ermöglichen, damit alles konsistent ist. Doch in Wirklichkeit haben Sie es mit riesigen Tabellen zu tun, die Anforderungen vieler verschiedener Subsysteme erfüllen und Attribute und Spalten enthalten, die in den meisten Fällen nicht wirklich nötig sind. Das ist wie der Versuch, dieselbe Karte für eine kurze Wanderung, einen Tagesausflug mit dem Auto und das Erlernen von Topografie zu nutzen.

Abbildung 2: Vergleich der Datensouveränität: Microservices und monolithischer Ansatz

Zustandsfreie oder zustandsbehaftete Microservices?

Wie bereits erwähnt, muss jeder Microservice sein eigenes Domänenmodell haben. Bei zustandslosen Microservices sind die Datenbanken extern und arbeiten mit relationalen Varianten wie SQL Server oder NoSQL-Varianten wie MongoDB oder Azure Document DB. In einem weiteren Schritt können die Dienst selbst zustandsbehaftet sein, was bedeutet, dass die Daten im selben Microservice enthalten sind. Diese Daten können nicht bloß auf demselben Server, sondern im Prozess desselben Microservice, im Arbeitsspeicher oder beständig auf einer Festplatte bei Replikation auf andere Knoten enthalten sein.

Der zustandlose Ansatz eignet sich perfekt und ist einfacher zu implementieren als zustandsbehaftete Microservices, da er mit herkömmlichen und vertrauten Mustern vergleichbar ist. Doch zustandlose Microservices weisen Latenz zwischen dem Prozess und Datenquellen auf und verfügen außerdem über mehr bewegliche Teile, wenn die Leistung mittels zusätzlicher Cachekapazität und Warteschlangen verbessert wird. Die Folge sind möglicherweise komplexe Architekturen mit zu vielen Ebenen.

Zustandsbehaftete Microservices eignen sich hingegen besonders in anspruchsvolleren Szenarien, da es keine Latenz zwischen Domänenlogik und -daten gibt. Umfassende Datenverarbeitungsaufgaben, Back-Ends von Spielen, Database-as-a-Service-Lösungen und andere Szenarien mit niedriger Latenz profitieren allesamt von zustandsbehafteten Diensten, die einen lokalen Zustand für einen schnelleren Zugriff ermöglichen.

Der Nachteil: Zustandsbehaftete Dienste zeichnen sich hinsichtlich der horizontalen Skalierung durch mehr Komplexität aus. Für Funktionalität, die üblicherweise innerhalb der Grenzen der externen Datenbank implementiert würde, müssen bestimmte Aspekte berücksichtigt werden, wie z. B. die Datenreplikation in zustandsbehaftete Microservices-Replikate, Datenpartitionierung usw. Doch dies ist genau einer der Bereiche, in denen Service Fabric am nützlichsten ist, indem die Entwicklung und der Lebenszyklus zustandsbehafteter Microservices vereinfacht wird.

Vorteile von Azure Service Fabric

Bei allen Vorteilen, die dieser Microservices-Ansatz zu bieten hat, gibt es auch einen Nachteil. Bereitstellungen für die verteilte Verarbeitung mit komplexen Microservices können schwierig zu verwalten sein, wenn Sie es selbst versuchen. Service Fabric bietet die Instrumente, die Sie brauchen, um Microservices effektiv und effizient zu erstellen, bereitzustellen, auszuführen und zu verwalten.

Was ist Service Fabric? Eine Plattform für verteilte Systeme, die zum Erstellen überaus skalierbarer, zuverlässiger und einfach zu verwaltender Anwendungen für die Cloud dient. Mithilfe von Service Fabric können die signifikanten Herausforderungen bei der Entwicklung und Verwaltung von Cloudanwendungen bewältigt werden. Dank Service Fabric können Entwickler und Administratoren das Lösen komplexer Infrastrukturprobleme vermeiden und sich stattdessen auf die Implementierung unternehmenswichtiger, anspruchsvoller Workloads konzentrieren, die skalierbar, zuverlässig und verwaltbar sind. Service Fabric stellt die nächste Generation der Middlewareplattform von Microsoft für das Entwickeln und Verwalten geschäftswichtiger Clouddienste für Großunternehmen dar.

Service Fabric ist eine universelle Bereitstellungsumgebung. Sie können beliebige ausführbare Dateien basierend auf verschiedenen Sprachen (Microsoft .NET Framework, Node.js, Java, C++) oder sogar Datenbanklaufzeiten wie MongoDB bereitstellen.

Deshalb muss klargestellt werden, dass Azure Service Fabric nicht auf Microservices-orientierte Anwendungen begrenzt ist. Sie können damit auch herkömmliche Anwendungen (Web-Apps oder Dienste) hosten und bereitstellen, um sich zahlreiche Vorteile hinsichtlich Skalierbarkeit, Lastenausgleich und Bereitstellungstempo zu sichern. Dennoch ist Azure Service Fabric eine von Grund auf neu entwickelte Plattform, die insbesondere auf Systeme mit Hyperskalierung und Microservices ausgelegt ist (siehe Abbildung 3).

Abbildung 3: Microsoft Azure Service Fabric

Es folgen einige der Vorteile von Azure Service Fabric:

Kann in Azure, lokal oder in beliebigen Clouds ausgeführt werden. Ein sehr wichtiges Merkmal von Service Fabric ist die Möglichkeit der Ausführung in Azure, aber auch lokal auf Ihren eigenen Bare-Metal-Servern oder virtuellen Computern (VMs) und sogar in anderen von Drittanbietern gehosteten Clouds. Es gibt keine Bindung an eine bestimmte Cloud. Sie können einen Service Fabric-Cluster sogar in Amazon Web Services (AWS) ausführen.
Unterstützung für Windows und Linux. Derzeit (letztes Quartal 2015) bietet Service Fabric Unterstützung für Windows, aber auch für Linux und Container (Windows- und Docker-Images).
Umfassend geprüft. Service Fabric wird bereits seit mehreren Jahren von Microsoft für den Betrieb vieler seiner Cloudprodukte eingesetzt.

Service Fabric entsprang der Notwendigkeit, innerhalb von Microsoft umfangreiche Dienste zu entwickeln. Das Verwenden von Produkten wie SQL Server und deren Gestaltung als in der Cloud verfügbare Dienste (Azure SQL-Datenbank) mit Agilität, Zuverlässigkeit, Skalierbarkeit und Wirtschaftlichkeit erforderte eine verteilte Technologie, mit der alle diese Anforderungen effektiv erfüllt werden konnten. Während die Kerntechnologie für eine Lösung für diese komplexen Szenarien entwickelt wurde, ergab sich, dass SQL Server nicht das einzige Produkt war, das einen solchen Sprung machte. Für Produkte wie Skype for Business mussten auf dem Weg zu einer auf Microservices basierenden Anwendung ähnliche Probleme gelöst werden. Service Fabric ist die Anwendungsplattform, die sich aus diesen Herausforderungen entwickelt hat und die in vielen umfassenden Diensten bei Microsoft mit unterschiedlichen Architekturen und Anforderungen nach Maß ausgeführt wird. Intune, DocumentDB und das Back-End für Cortana und Skype for Business sind allesamt in Service Fabric ausgeführte Dienste.

Dank seiner Erfahrung bei der Unterstützung unternehmenswichtiger Systeme konnte Microsoft eine Plattform entwerfen, die die verfügbaren Infrastrukturressourcen und Anforderungen skalierbarer Anwendungen eindrücklich versteht. Diese Plattform ermöglicht ein sich automatisch selbst aktualisierendes und korrigierendes Verhalten, das für die Bereitstellung hoch verfügbarer und beständiger Dienste mit Hyperskalierung wesentlich ist. Microsoft stellt diese in der harten Praxis erprobte Technologie jedermann zur Verfügung.

Azure Service Fabric-Programmiermodelle

Service Fabric bietet zwei allgemeine Frameworks für das Entwickeln von Diensten: die Reliable Services-APIs und die Reliable Actors-APIs. Wenngleich beide auf demselben Service Fabric-Kern basieren, machen sie hinsichtlich Parallelität, Partitionierung und Kommunikation unterschiedliche Kompromisse zwischen Einfachheit und Flexibilität (siehe Abbildung 4). Es bietet sich an, sich mit der Funktionsweise der beiden Modelle vertraut zu machen, damit Sie das Framework wählen können, das für Ihren Dienst am besten geeignet ist. In vielen Anwendungsszenarien können Sie mit einem kombinierten Ansatz arbeiten und Reliable Actors für bestimmte Microservices und Reliable Services zum Aggregieren von Daten nutzen, die von verschiedenen Actors generiert wurden. Daher kann ein Reliable Service in vielen gängigen Szenarien Actor-Dienste orchestrieren.

Abbildung 4: Vergleichen der Service Fabric-Programmiermodelle

Reliable Actor-APIs	Reliable Services-APIs
Ihr Szenario umfasst viele kleine unabhängige Einheiten/Objekte mit Zustand und Logik (aktive Internet of Things-Objekte oder Back-End-Szenarien für Spiele sind gut geeignete Beispiele).	Sie müssen Logik und Abfragen für mehrere Entitätstypen und Komponenten verwalten.
Sie arbeiten mit einer riesigen Menge von Single-Thread-Objekten und sind weiter in der Lage, für Skalierbarkeit und Konsistenz zu sorgen.	Sie arbeiten mit Reliable Collections (wie .NET Dictionary und Queue) zum Speichern und Verwalten von Zustand/Entitäten.
Sie möchten die Parallelität und Granularität vom Framework verwalten lassen.	Sie möchten Granularität und Parallelität Ihres Zustands steuern.
Sie möchten, dass Service Fabric die Verwaltung der Kommunikationsimplementierung für Sie übernimmt.	Sie möchten die Kommunikationsprotokolle bestimmen, verwalten und implementieren (Web-API, WebSockets, Windows Communication Foundation usw.).
Sie möchten, dass Service Fabric das Verwalten des Partitionierungsschemas von zustandsbehafteten Actor-Diensten transparent für Sie übernimmt.	Sie möchten das Partitionierungsschema Ihres zustandsbehafteten Diensts steuern.

Erstellen zustandloser Microservices mit Azure Service Fabric

Ein Microservice in Azure Service Fabric kann nahezu jeder Serverprozess sein, den Sie in .NET Framework, Node.js, Java oder C++ erstellen möchten. Derzeit stehen nur die .NET- und C++-Bibliotheken der Service Fabric-API zur Verfügung. Deshalb müssen Sie für Low-Level-Implementierungen Microservices in .NET Framework oder C++ implementieren.

Wie bereits erwähnt, liegt bei einem zustandlosen Microservice ein Prozess (z. B. ein Front-End- oder Geschäftslogikdienst) vor, ohne dass innerhalb des Diensts ein Zustand dauerhaft gespeichert wird. Oder der vorhandene Zustand geht verloren, wenn der Prozess abgeschlossen ist, und erfordert keine Synchronisierung, Replikation, Beständigkeit oder Hochverfügbarkeit. Dieser Microservice kann einen dazugehörigen externen Zustand haben, der aber in einem externen Speicher wie Azure SQL-Datenbank, Azure Storage, Azure DocumentDB oder einem Speichermodul eines Drittanbieters (relational oder NoSQL) beständig gespeichert wird. Daher kann ein vorhandener Dienst wie ein ASP.NET-Web-API-Dienst, der in Azure Cloud Services ausgeführt wird, eine Workerrolle oder Azure-Web-App mühelos in zustandslose Service Fabric-Dienste migriert werden.

Zum Einrichten Ihrer Entwicklungsumgebung benötigen Sie das Service Fabric SDK, das Ihnen das Ausführen eines lokalen Entwicklungsclusters ermöglicht, der kein Emulator ist, sondern denselben Code wie in Azure ausführt. Außerdem werden durch die Integration der Visual Studio 2015-Tools die Entwicklung und das Debugging erleichtert.

Doch vor dem Bereitstellen und Debuggen von Diensten auf Ihrem lokalen Computer müssen Sie den Cluster aus Knoten erstellen. Dazu führen Sie das Windows PowerShell-Skript „DevClusterSetup.ps1“ aus, was in der Dokumentation im Artikel „Vorbereiten Ihrer Entwicklungsumgebung“ im Abschnitt „Installieren und Starten eines lokalen Clusters“ unter bit.ly/1Mfi0LB erklärt wird. Auf dieser Seite finden Sie eine vollständige exemplarische Vorgehensweise für den Einrichtungsprozess.

Basisklasse eines zustandslosen Diensts Zustandslose Service Fabric-Dienstklassen müssen von der „Microsoft.ServiceFabric.Services.StatelessService“-Klasse abgeleitet sein. Diese Klasse bietet API-Methoden und Kontext in Bezug auf den Service Fabric-Cluster und die Ausführungsumgebung und ist mit dem Lebenszyklus Ihres Diensts verknüpft.

Unabhängig davon, ob Ihr Dienst zustandsbehaftet oder zustandlos ist, bietet Reliable Services einen einfachen Lebenszyklus, mit dem Sie Ihren Code rasch verbinden und die ersten Schritte unternehmen können. Um Ihren Service Fabric-Dienst in Betrieb zu nehmen, müssen Sie lediglich eine oder zwei Methoden implementieren, meist „RunAsync“ und „CreateServiceReplicaListeners“, auf die wir näher eingehen, wenn wir uns detailliert mit den Kommunikationsprotokollen beschäftigen.

Sehen Sie sich „RunAsync“ in Abbildung 5 an. Hier kann Ihr Dienst Aufgaben im Hintergrund erledigen. Das bereitgestellte „cancellationToken“ ist ein Signal, wann die Arbeit beendet werden soll.

Abbildung 5: Basisstruktur eines zustandslosen Diensts in Azure Service Fabric

using Microsoft.ServiceFabric.Services;
namespace MyApp.MyStatelessService
{ 
  public class MyStatelessService : StatelessService
  {
    //... Service implementation
    protected override async Task RunAsync(CancellationToken cancellationToken)
    {   
      int iterations = 0;
      while (!cancellationToken.IsCancellationRequested)
      {
        ServiceEventSource.Current.ServiceMessage(this, "Working-{0}",
          iterations++);
        // Place to write your own background logic.
        // Example: Logic doing any polling task.
        // Logic here would be similar to what you usually implement in
        // Azure Worker Roles, Azure WebJobs or a traditional Windows Service.
         await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);
      }
      } 
    }
}

Kommunikationsprotokolle in Azure Service Fabric Reliable Services Azure Service Fabric Reliable Services bietet ein austauschbares Kommunikationsmodell. Sie können die Transportmethode Ihrer Wahl nutzen, wie z. B. HTTP mit ASP.NET-Web-API, WebSockets, Windows Communication Foundation, benutzerdefinierte TCP-Protokolle usw.

Sie können Ihren eigenen Code für Ihr gewähltes Kommunikationsprotokoll in Ihrem Dienst implementieren oder einen anderen mit Service Fabric bereitgestellten Kommunikationsstapel verwenden, wie z. B. ServiceCommunicationListener/ServiceProxy, den von Reliable Services Framework in Service Fabric standardmäßig bereitgestellten Kommunikationsstapel. Es gibt außerdem getrennte NuGet-Pakete mit zusätzlichen Kommunikationsstapeln, die Sie mit Service Fabric verbinden können.

Verwenden der ASP.NET-Web-API in Service Fabric-Microservices Wie schon erwähnt, überlässt Service Fabric Ihnen die Entscheidung, wie Ihre Dienste kommunizieren sollen. Doch eine der gängigsten Möglichkeiten ist das Erstellen von HTTP-Diensten in .NET Framework mithilfe der ASP.NET-Web-API.

Die Web-API in Service Fabric entspricht der ASP.NET-Web-API, die Sie kennen und mögen. Sie verwenden Controller und „HttpRoutes“ und können REST-Dienste auf dieselbe Weise erstellen, indem Sie „MapHttpRoute“ oder Attribute für die Methoden verwenden, die Sie „HttpRoutes“ zuordnen möchten. Der Unterschied bei Verwenden von Service Fabric besteht darin, wie Sie eine Web-API-Anwendung hosten. Als Erstens muss berücksichtigt werden, dass Sie IIS in Azure Service Fabric nicht verwenden können, da nur einfache Prozesse genutzt werden, die im gesamten Cluster repliziert werden. Deshalb müssen Sie den HTTP-Listener in Ihrem Code selbst hosten. Für Web-API-Dienste haben Sie hierfür zwei Möglichkeiten:

Verwenden Sie die ASP.NET 5-Web-API (Codename „Project K“), um den HTTP-Listener selbst in Ihrem Service Fabric-Microservices-Prozess zu hosten.
Verwenden Sie OWIN/Katana und die ASP.NET 4.x-Web-API, um den HTTP-Listener selbst in Ihrem Service Fabric-Microservices-Prozess zu hosten.

Die Ausführung von ASP.NET 5 auf Azure Service Fabric ist, wie bereits erwähnt, die beste Lösung für das Erstellen von Microservices, da Service Fabric Ihnen das Bereitstellen einer beliebigen Anzahl von Diensten in jedem Knoten bzw. virtuellen Computer erlaubt. Dadurch wird eine hohe Dichte von Microservices pro Cluster möglich. Darüber hinaus kann die hohe Dichte noch optimiert werden, wenn Service Fabric künftig Unterstützung für .NET Core 5 und CoreCLR bietet (unter ASP.NET 5). Dies wird die bestmögliche Lösung zum Erzielen einer überaus hohen Dichte von Microservices, da .NET Core 5 im Vergleich zum vollständigen .NET 4.x Framework ein schlankes Framework mit sehr kleinem Arbeitsspeicherbedarf ist.

Verwenden von Web-Apps und Service Fabric-Microservices des Typs „MVC“ ASP.NET MVC ist ein sehr beliebtes Framework für herkömmliche Websites, doch das „alte“ MVC-Framework (bis MVC 5) kann nicht mit Service Fabric verwendet werden. Der Grund ist, dass Sie in Service Fabric den HTTP-Listener selbst in Ihrem Prozess hosten müssen und dass OWIN/Katana in ASP.NET 4.x MVC nicht unterstützt wird (Unterstützung bietet nur die ASP.NET 4.x-Web-API.) Daher haben Sie die folgenden Optionen zum Implementieren einer Webanwendung vom Typ „MVC“ in Service Fabric-Diensten:

Verwenden Sie MVC 6 in ASP.NET 5, um den HTTP-Listener selbst in Ihrem Service Fabric-Microservices-Prozess zu hosten. MVC wird unterstützt, da die Web-API und MVC in ASP.NET 5 zusammengeführt wurden und sich nun im selben Framework mit denselben Controllern ohne Abhängigkeit von IIS befinden. Mit der RTM-Version von ASP.NET 5 wird dies zur ersten Wahl.
Verwenden Sie die ASP.NET 4.x-Web-API mit OWIN/Katana, um den HTTP-Listener selbst in Ihrem Service Fabric-Microservices-Prozess zu hosten. Simulieren Sie MVC-Controller mithilfe von Web-API-Controllern, und verwenden Sie die HTML-/JavaScript-Ausgabe anstelle des herkömmlichen Web-API-Inhalts (JSON/XML). Auf der Dokumentationsseite unter bit.ly/1UMdKIf wird die Implementierung dieser Technik veranschaulicht.

Implementieren des eigenständigen Hostings mit der ASP.NET 4.x-Web-API und OWIN/Katana

Bei diesem Ansatz ändert sich die Web-API-Anwendung, mit der Sie bislang gearbeitet haben, nicht. Sie unterscheidet sich nicht von Web-API-Anwendungen, die Sie ggf. in der Vergangenheit geschrieben haben, und Sie sollten in der Lage sein, einen Großteil Ihres Anwendungscodes einfach zu übertragen. Das Hosten der Anwendung ist jedoch ggf. ein wenig anders, als Sie es bisher beim Hosten in IIS gewohnt waren.

„CreateServiceReplicaListeners“-Methode in der Dienstklasse An dieser Stelle bestimmt der Dienst die Kommunikationsstapel, die verwendet werden sollen. Der Kommunikationsstapel, wie z. B. die Web-API, definiert die lauschenden Endpunkte des Diensts und auch wie die Meldungen, die angezeigt werden, mit dem Rest des Dienstcodes interagieren.

Wenn ich nun wieder zur zuvor in Abbildung 4 erwähnten Dienstklasse zurückkehre, muss ich bloß eine neue Methode mit dem Namen „CreateServiceReplicaListeners“ hinzufügen, die mindestens einen Kommunikationsstapel angibt, den ich verwenden möchte. In diesem Falle ist dies die von der Web-API verwendete „OwinCommunicationListener“-Methode (siehe Abbildung 6).

Abbildung 6: Hinzufügen der „CreateServiceReplicaListeners“-Methode zur zustandslosen Dienstklasse

using Microsoft.ServiceFabric.Services;
namespace MyApp.MyStatelessService
{ 
  public class MyStatelessService : StatelessService
  {
    //... Service implementation.
    protected override async Task RunAsync(CancellationToken cancellationToken)
    {            
      // Place to write your own background logic here.
      // ...         
    }
    protected override IEnumerable<ServiceReplicaListener>
      CreateServiceReplicaListeners()
      {
        return new List<ServiceReplicaListener>()
        {
          new ServiceReplicaListener(parameters =>
            new OwinCommunicationListener(
            "api", new Startup()))
        };
      } 
    }
}

Wichtig ist der Hinweis, dass Sie Ihrem Dienst mehrere Kommunikationslistener hinzufügen können.

Die „OwinCommunicationListener“-Klasse ist ein Codebaustein, den Sie in allen Ihren Microservices wiederverwenden können. Auf ähnliche Weise können Sie eine Verbindung mit anderen Protokollen (WCF, WebSockets usw.) herstellen.

Wenn Sie einen Web-API-Microservice erstellen, arbeiten Sie weiterhin mit Controllern mit typischem Code, der sich in nichts davon unterscheidet, woran Sie bei der Implementierung von Web-API-Diensten gewöhnt sind, wie z. B. folgender Code:

// Typical Web API Service class implementation
public class CustomerController : ApiController
{ 
  //// Example - GET /customers/MSFT
  [HttpGet]
  [Route("customers/{customerKey}", Name = "GetCustomer")]
  public async Task<IHttpActionResult> GetCustomer(string customerKey)
  {
    // ... Stateless method implementation.       
  }
}

Da dieser Artikel lediglich eine umfassende Übersicht über Azure Service Fabric und Microservices bietet, durchlaufen wir nicht die weiteren Schritte zum Implementieren von OWIN in Ihren Service Fabric-Microservice. Auf GitHub gibt es unter (bit.ly/1OW5Bmj) ein einfaches Beispiel, das Sie herunterladen und analysieren können: „HelloWorld“-Beispiel für Web-API und Service Fabric (ASP.NET 4.x).

Implementieren des eigenständigen Hostings mit der ASP.NET 5.x-Web-API

Die Ausführung von ASP.NET 5 auf Azure Service Fabric ist die beste Lösung für das Erstellen von Microservices, da Service Fabric Ihnen das Bereitstellen einer beliebigen Anzahl von Diensten in jedem Knoten bzw. virtuellen Computer erlaubt. Dadurch wird eine hohe Dichte von Microservices pro Cluster möglich. ASP.NET 5 bietet außerdem sehr nützliche Features wie z. B. die folgenden:

Flexibles Hosting: Sie können nun Ihre ASP.NET 5-Anwendung unter IIS oder in Ihrem eigenen Prozess hosten. Das Hosting in Ihrem eigenen Prozess ist in Azure Service Fabric wesentlich.
Web-API, MVC und Webseiten: Diese Komponenten werden zusammengeführt. Die Anzahl der Konzepte wird auf diese Weise vereinfacht.
Vollständige parallele Unterstützung: ASP.NET 5-Anwendungen können nun auf einem Computer installiert werden, ohne dass sich dies auf andere Anwendungen auf dem Computer auswirkt, auf denen ggf. eine andere Version von .NET Framework verwendet wird. Dies ist für die IT-Verwaltung besonders nützlich.
Plattformübergreifende Unterstützung: ASP.NET 5 kann unter den unterstützten Betriebssystemen Windows, Mac und Linux ausgeführt werden.
Bereit für die Cloud: Funktionen wie etwa Diagnose, Sitzungszustand, Cache und Konfiguration funktionieren ohne Änderungen lokal und in der Cloud (z. B. in Azure).

Vorausblickend kann die Möglichkeit hoher Dichte noch optimiert werden, wenn Service Fabric schlussendlich Unterstützung für .NET Core 5 und CoreCLR bietet.

Wenngleich sich die Unterstützung von .NET Core und CoreCLR für Service Fabric noch in der Entwicklung befindet, sind die sich dadurch bietenden Vorteile offensichtlich. Die Ausführung von ASP.NET 5 auf .NET Core 5 ermöglicht ein schlankes .NET-Framework und eine CoreCLR-Laufzeit mit einem in Vergleich zu .NET 4.x sehr kleinen Arbeitsspeicherbedarf. Diese Kombination ermöglicht eine unglaubliche Dichte von Microservices, was im Bereich „Microservice B“ in Abbildung 7 erkennbar ist.

Abbildung 7: Vergleichen der Ausführung von ASP.NET 5 in CLR und CoreCLR im Service Fabric-Kontext

Wenngleich die Unterstützung von .NET Core 5 und CoreCLR bislang noch nicht gegeben ist, können sich Unternehmen darauf vorbereiten, indem Sie ASP.NET 5-Dienste auf .NET 4.x in Service Fabric entwickeln. Dadurch wird eine künftige Migration zu CoreCLR erleichtert.

Betreiben und Bereitstellen von Microservices mit Hyperskalierung

Die von Service Fabric ermöglichte Betriebs- und Bereitstellungsverwaltung sind weitere Gründe, warum sich diese Lösung besonders gut für das Erstellen und Ausführen von Microservices mit Hyperskalierung in Produktionsumgebungen eignet. Sie können sich auf die Entwicklung von Microservices konzentrieren und das Bereitstellen aller komplexen Konfigurationen Service Fabric überlassen.

Die hohe Dichte von Microservices ist ein großer Vorteil, wenn Sie an der Senkung der Infrastrukturkosten interessiert sind. Ein Service Fabric-Cluster besteht aus einem Pool zahlreicher VMs und Server (und in der Zukunft Container), die im Cluster als Knoten bezeichnet werden. Service Fabric stellt auf jedem Knoten automatisch mehrere Dienste bereit. Deshalb können Sie abhängig von der Leistung der einzelnen Server bzw. VMs im gesamten Cluster über eine überaus hohe Dichte von Microservices verfügen.

In Azure Service Fabric haben Sie die Möglichkeit, Hunderte von Dienstinstanzen auf den einzelnen Computern oder VMs auszuführen. Dadurch lassen sich Ihre Gesamtbetriebskosten umfassend reduzieren, da Sie für dieselbe Menge von Diensten weniger Hardware benötigen. Daher ist hohe Dichte ein wesentliches Unterscheidungsmerkmal beim Vergleich von Azure Service Fabric mit Azure Cloud Services, bei denen Sie auf eine VM pro Dienst beschränkt sind. Wenn Sie Microservices als Webrolle oder Workerrolle bereitgestellt haben, wurden wahrscheinlich zu viele Rollen einem einzelnen Microservice zugeteilt, wodurch Bereitstellung und Verwaltung verlangsamt wurden. In Abbildung 8 wird eine VM pro Instanz des Diensts in Form einer Azure-Webrolle oder -Workerrolle gezeigt (die Farbe gibt den Diensttyp an, während jede Form oder Box eine andere VM oder Dienstinstanz darstellt). Dieser Ansatz ist nicht hilfreich, wenn Sie eine hohe Dichte von Microservices wünschen, es sei denn, Sie nutzen kleine VMs. Es gibt jedoch eine Obergrenze, weshalb Sie in keiner der Bereitstellungen im Vergleich zu Azure Service Fabric denselben Grad an hoher Dichte erreichen.

Abbildung 8: Vergleich der Dichte von Diensten: Azure Cloud Services und Service Fabric

Im Gegensatz dazu können Sie in Service Fabric auf jedem Knoten eine beliebige Anzahl von Microservices bereitstellen, sodass die Dichte der Dienste wesentlich effizienter ist und Kosten gesenkt werden. Sie können über Dutzende, Hunderte oder sogar Tausende von VMs bzw. Servern pro Cluster verfügen, auf denen sich Dutzende oder Hunderte von Instanzen und Replikaten von Microservices pro Knoten bzw. VM befinden. Da jeder Microservice einfach nur ein Prozess ist, erfolgt die Bereitstellung und Skalierung wesentlich schneller als das Erstellen einer neuen VM pro Dienst, was bei Azure Cloud Services der Fall ist.

Erstellen eines Clusters in der Azure-Cloud Vor der Bereitstellung von Microservices müssen Sie den Cluster mit den Knoten in Azure oder auf lokalen Servern erstellen. Beim Erstellen des Clusters in der Azure-Cloud können Sie wie für Ihre Produktions- oder Stagingumgebung direkt im Azure Portal arbeiten oder den Azure-Ressourcen-Manager (ARM) verwenden. Abbildung 9 zeigt einen Service Fabric-Cluster, den wir in unserem Azure-Abonnement mithilfe des Azure-Portals erstellt haben. Intern basiert der Clustererstellungsprozess auf dem ARM und Azure-Ressourcengruppen. In diesem Fall haben wir einen Cluster mit fünf Knoten bzw. VMs erstellt, die außerdem in einer Azure- Ressourcengruppe platziert wurden.

Abbildung 9: Service Fabric-Cluster im Azure-Portal

Bereitstellen von Anwendungen/Diensten im Cluster Nach der Inbetriebnahme des Clusters und seiner Knoten/VMs können Sie Dienste bereitstellen. In Produktionsclustern verwenden Sie zumeist ein Windows PowerShell-Skript für das Bereitstellen Ihrer Apps und Dienste im Cluster in Azure, wenngleich bei Staging- und Testumgebungen auch eine direkte Bereitstellung aus Visual Studio möglich ist.

Bei einer Bereitstellung in einem lokalen Cluster auf Ihrem Entwicklungs-PC mithilfe von Visual Studio 2015 erfolgt in der Regel eine direkte Bereitstellung aus der IDE, indem mit der rechten Maustaste auf das Service Fabric-Anwendungsprojekt geklickt und dann „Bereitstellen“ ausgewählt wird. Sie können auch über Windows PowerShell eine Bereitstellung in Ihrem Entwicklungscluster auf Ihrem Laptop vornehmen, da in Entwicklungsclustern und auf der Azure-Cloud basierenden Clustern derselbe Service Fabric-Code ausgeführt wird.

Die Sicherstellung von Betrieb und Verwaltung von Bereitstellungen ist langfristig für die ordnungsgemäße Ausführung von Diensten erforderlich. Deshalb wurden in Service Fabric Features für die Verwaltung des Anwendungslebenszyklus integriert, die den auf Microservices basierenden Ansatz berücksichtigen. Zu den in Service Fabric verfügbaren Betriebs- und Verwaltungsfunktionen gehören schnelle Bereitstellungen, das Upgrade von Anwendungen ohne Ausfallzeit, Überwachung der Integrität der Dienste und die Hoch- und Herunterskalierung des Clusters. Upgrades ohne Ausfallzeiten sind möglich, da die Upgradetechnologie in Service Fabric eine integrierte Kombination paralleler Upgrades und automatischer Integritätsprüfungen bietet, mit deren Hilfe die Änderungen im Upgrade erkannt und rückgängig gemacht werden, wenn sie die Anwendung destabilisieren. Die Verwaltung von Service Fabric-Clustern und -Anwendungen kann über Windows PowerShell-Befehle erfolgen. Dadurch steht Ihnen die Leistungsfähigkeit der Befehlszeilenschnittstelle (CLI) und Skripts zur Verfügung, während zur einfacheren Nutzung auch grafische Tools wie Visual Studio unterstützt werden.

Parallele Upgrades erfolgen in Phasen. In jeder Phase wird das Upgrade auf eine Teilmenge der Knoten im Cluster angewendet, die als Upgradedomäne bezeichnet wird. Die Folge ist, dass die Anwendung während des gesamten Upgrades verfügbar bleibt. Ihnen wird auch eine strenge Versionsverwaltung und parallele Unterstützung mehrerer Versionen (z. B. V1 und V2) derselben Microservices geboten. Je nach Anforderung des Clients nimmt Service Fabric eine entsprechende Umleitung vor. In der Dokumentation unter bit.ly/1kSupz8 finden Sie weitere Einzelheiten.

Beim Debuggen von Diensten in Ihrem lokalen Entwicklungscluster auf Ihrem PC erleichtert Ihnen Visual Studio die Arbeit, selbst wenn die Prozesse des Diensts bereits laufen, ehe Sie mit dem Debuggen beginnen. Die IDE stellt automatisch eine Verbindung mit allen zu Ihrem Projekt gehörigen Microservices her, wodurch der Einstieg und das Verwenden der herkömmlichen Haltepunkte im Code Ihrer Service Fabric-Microservices vereinfacht wird. Setzen Sie einfach die Haltepunkte in Ihrem Code, und drücken Sie F5. Sie müssen nicht herausfinden, an welchen Prozess Sie Visual Studio anfügen müssen.

Service Fabric Explorer Der in Abbildung 10 gezeigte Service Fabric Explorer ist ein vom Cluster bereitgestelltes webbasiertes Tool zum Visualisieren des Zustands bereitgestellter Anwendungen, Untersuchen des Inhalts einzelner Knoten und Ausführen verschiedener Verwaltungsaktionen. Dieser Explorer wird über denselben HTTP-Gatewaydienst zur Verfügung gestellt, der die Service Fabric-REST-APIs unterstützt und kann unter „http://<Endpunkt_Ihres_Clusters>:19007/Explorer“ erreicht werden. Bei einem lokalen Cluster lautet die URL „http://localhost:19007/Explorer“.

Abbildung 10: Der Service Fabric Explorer

Weitere Details zum Service Fabric Explorer finden Sie in der Dokumentation im Artikel „Visualisieren des Clusters mit Service Fabric Explorer“ (bit.ly/1MUNyad).

Die Service Fabric-Plattform ermöglicht eine Vielzahl von Features, dank derer Sie sich auf die Anwendungsentwicklung konzentrieren können, ohne sich um die Erfüllung komplexer Integritätsanforderungen und aktualisierbarer Systeme kümmern müssen. Beispiele:

Horizontales Skalieren zustandsloser Dienste Das Service Fabric-Orchestrierungsmodul dient zum automatischen Skalieren Ihrer Web-App auf mehreren Computern, sobald einem Cluster neue Knoten hinzugefügt werden. Beim Erstellen von Instanzen eines zustandslosen Diensts können Sie die Anzahl der Instanzen angeben, die Sie erstellen möchten. Service Fabric platziert diese Anzahl von Instanzen entsprechend auf Knoten im Cluster und stellt sicher, dass auf einem Knoten nicht mehr als eine Instanz erstellt wird. Sie können Service Fabric auch anweisen, stets eine Instanz auf jedem Knoten zu erstellen, indem für die Anzahl der Instanzen „-1“ angegeben wird. Dies gewährleistet, dass wenn Sie Knoten zum horizontalen Hochskalieren Ihres Clusters hinzufügen, eine Instanz Ihres zustandslosen Diensts auf den neuen Knoten erstellt wird.

Automatischer Ressourcenausgleich Service Fabric bietet einen automatischen Ausgleich von Dienstressourcen (bzw. eine Dienstorchestrierung), indem die insgesamt verfügbaren Ressourcen im Cluster (wie die Computekapazität der VMs) erkannt wird. Die Microservices werden abhängig von definierten Richtlinien und Einschränkungen automatisch verschoben, um die Platzierung von Diensten auf den VMs zu optimieren (siehe Abbildung 11). Hierbei liegt der Fokus auf einer Kosten- und Leistungsoptimierung.

Abbildung 11: Dienstverteilung im Cluster auf die Knoten und automatischer Ressourcenausgleich

Integrierte Failover- und Replikationsfunktionen Computer in Datencentern oder öffentlichen Clouds sind anfällig für den unerwarteten Ausfall von Hardware. Zum Schutz vor solchen Szenarien bietet Service Fabric integrierte Failover- und Replikationsfunktionen, was bedeutet, dass trotz Hardwareproblemen die Verfügbarkeit von Diensten nicht beeinträchtigt wird. Dies ist möglich, da Service Fabric mehrere Instanzen jedes Diensts auf mehreren Computern und in mehreren Fehlerdomänen ausführen und verwalten kann.

Einschränkungen bei der Platzierung Sie können den Cluster beispielsweise anweisen, die Front-End-Microservices nicht auf denselben VMs/Knoten wie die Microservices der mittleren Ebene zu platzieren und das Zusammenstellen verschiedener Typen auf denselben Knoten zu vermeiden. Dies kann erfolgen, um bekannte Konflikte zu minimieren oder um für bestimmte Microservices einen priorisierten Zugriff auf Ressourcen sicherzustellen.

Lastenausgleich von Anforderungen Der Lastenausgleich von Anforderungen ist nicht mit dem automatischen Ressourcenausgleich zu verwechseln und wird nicht von Service Fabric, sondern von Azure Load Balancers oder einer anderen für Service Fabric externen Plattform übernommen.

Integrität Ermöglicht das Überwachen und Untersuchen Ihrer Systeme. Spielt auch bei Upgrades von Anwendungen eine Rolle, um Sicherheitsüberprüfungen zu bieten, damit Upgrades rückgängig gemacht werden können, falls das Upgrade destabilisierende Auswirkungen hat. In der Dokumentation finden Sie unter „Einführung in die Service Fabric-Integritätsüberwachung“ (bit.ly/1jSvmHB) weitere Informationen.

Zustandsbehaftete Microservices in Azure Service Fabric

Die Unterstützung zustandsbehafteter Dienste ist eine sehr nützliche und wichtige Eigenschaft von Azure Service Fabric. Sie ist außerdem komplex und so weitreichend, dass eine Erörterung zustandsbehafteter Dienste den Rahmen dieses Artikels sprengen würde. Dennoch wollen wir kurz darauf eingehen. In einer künftigen Ausgabe werden wir uns in einem Folgeartikel mit diesem Bereich von Service Fabric beschäftigen.

Bei einem zustandsbehafteten Dienst in Service Fabric werden Computefunktionen und Daten zusammengestellt, wobei der Zustand vom Dienst selbst (sowohl im Arbeitsspeicher als auch beständig auf einem lokalen Datenträger) gespeichert wird. Die Zuverlässigkeit des Zustands wird über eine lokale beständige Speicherung und die Replikation der Daten auf andere Knoten/VMs erreicht. Grundlegend sind jeder Datenpartition mehrere Replikatdienste zugeordnet. Jedes Replikat kann auf einem anderen Knoten bzw. virtuellen Computer bereitgestellt werden, um Hochverfügbarkeit zu bieten, sollte das primäre Replikat ausfallen. Dies ist vergleichbar damit, wie Azure SQL-Datenbank mit Datenbankreplikaten arbeitet, da diese Lösung auf Azure Service Fabric basiert.

Bei komplexen und skalierbaren Anwendungen vereinfachen zustandsbehaftete Dienste im Vergleich mit einer herkömmlichen aus drei Ebenen bestehenden Architektur, die mit externem Cache und externen Warteschlangen arbeiten muss, die Architektur und verringern die Anzahl der Komponenten. Bei Verwenden zustandsbehafteter Dienste gelten die Vorteile eines herkömmlichen externen Caches nun inhärent für den zustandsbehafteten Dienst. Darüber hinaus sind externe Warteschlangen nicht nötig, da wir interne Warteschlangen in die Service Fabric-Microservices implementieren können.

Bei Verwenden zustandsbehafteter Dienste werden automatisch sekundäre Hotbackup-Knoten erstellt, die Vorgänge an der Stelle fortsetzen können, an der ein primärer Knoten aufgrund eines Hardwarefehlers ausgefallen ist. Dienste müssen häufig skaliert werden, um die Anforderungen eines wachsenden Benutzerstamms zu erfüllen, was das Hinzufügen von Hardware zur ausgeführten Umgebung erfordert. Service Fabric verwendet Features wie die Partitionierung, sodass Dienste so erstellt werden können, dass sie ohne Benutzereingriffe automatisch auf neue Hardware verteilt werden.

Zustandsbehaftete Azure Reliable Services bieten vielfältige Funktionen, wozu die Unterstützung der Datenpartitionierung und -replikation, Auswahl einer übergeordneten Instanz, Benennung von Replikatinstanzen und die Ermittlung von Dienstadressen über den Gatewaydienst gehören. Geboten werden außerdem die Verwaltung der Parallelität und Granularität von Zustandsänderungen mittels Transaktionen, die Fähigkeit zum Aufrechterhalten einer einheitlichen Zustandsreplikation sowie die Verwendung zuverlässiger, verteilter Schlüssel-/Wertsammlungen (Reliable Dictionary und Reliable Queue). Die gute Nachricht ist, dass sich Service Fabric für Sie um die Komplexität und Details dieser Themen kümmert, sodass Sie sich auf das Programmieren von Anwendungen konzentrieren können.

Reliable Actors Services in Azure Service Fabric

Azure Service Fabric Reliable Actors ist ein auf Actors basierendes Programmiermodell in Service Fabric, das ein asynchrones Single-Thread-Actor-Modell bietet. Ein Actor stellt eine Einheit aus Zustand und Berechnung dar und ist auf gewisse Weise mit dem Open-Source-Softwareprojet „Orleans“ vergleichbar, das von Microsoft Research entwickelt wurde. Der wichtige Punkt ist, dass die Service Fabric Reliable Actors-API auf der von Service Fabric bereitgestellten zugrunde liegenden Infrastruktur basiert.

Die Implementierung von Actor-Instances für IoT-Geräte (Internet of Things, Internet der Dinge) ist ein gutes Beispiel für die Nutzung von Actor-Diensten. Ein„ Vehicle-Actor“-Typ in Form einer C#-Klasse kapselt die IoT-Fahrzeugdomänenlogik sowie deren aktive Zustände wie z. B. GPS-Koordinaten und andere Daten. Dann verfügen wir potenziell über Millionen von Actor-Objekten oder -Instanzen dieser erwähnten Klasse, die auf viele Knoten im Cluster verteilt sind.

Actors sind allerdings nicht auf aktive IoT-Objekte begrenzt, sondern eignen sich für beliebige Bereiche, aber „aktive IoT-Objekte“ stellen ein nützliches didaktisches Szenario dar.

Actors sind auf den gesamten Cluster verteilt, um hohe Skalierbarkeit und Verfügbarkeit zu erzielen, und werden in allen VMs des Clusters als arbeitsspeicherinterne Objekte behandelt. Außerdem werden Actors auf lokalen Datenträgern beständig gespeichert und im gesamten Cluster repliziert.

Sie sind isolierte Single-Thread-Objekte, die sowohl Zustand als auch Verhalten kapseln. Jeder Actor ist eine Instanz eines Actor-Typs ähnlich dem hier gezeigten .NET-Code:

// Actor definition (State+Behaviour) to run in the back end.
// Object instances of this Actor class will be running transparently
// in the service back end.
public class VehicleActor : Actor<Vehicle>, IVehicleActor
{
  public void UpdateGpsPosition(GpsCoordinates coord)
  { 
    // Update coordinates and trigger any data processing
    // through the State property on the base class Actor<TState>.
    this.State.Position= coord;
  }
}

Als Nächstes zeigt der folgende Code ein Beispiel von Clientcode zum Verwenden des Actors mithilfe eines Proxyobjekts:

// Client .NET code
ActorId actorId = ActorId.NewId();
string applicationName = "fabric:/IoTVehiclesActorApp";
IVehicleActor vehicleActorProxy =
  ActorProxy.Create<IVehicleActor>(actorId, applicationName);
vehicleActorProxy.UpdateGpsPosition(new GpsCoordinates(40.748440, -73.984559));

Intern kümmert sich das Service Fabric Reliable Actors-Framework um die gesamte Kommunikationsinfrastruktur.

Auch wenn Sie über Millionen von „VehicleActor“-Objekten verfügen, die in Ihrem Cluster auf vielen verschiedenen Knoten/VMs ausgeführt werden, übernimmt Service Fabric die erforderlichen Konfigurationen einschließlich der Partitionen und Replikate, auf die Ihre Millionen von Actors gleichmäßig verteilt werden.

Die Actors-Client-API ermöglicht die Kommunikation zwischen einer Actor-Instanz und einem Actor-Client. Zum Kommunizieren mit einem Actor erstellt ein Client ein Actor-Proxyobjekt, das die Actor-Schnittstelle implementiert. Der Client interagiert mit dem Actor durch Aufrufen von Methoden für das Proxyobjekt.

In für Actors geeigneten Szenarien wird die Implementierung von Microservices dadurch stark vereinfacht. Dies gilt insbesondere im Vergleich mit zustandsbehafteten Reliable Services, bei denen Sie zwar mehr Steuerungsmöglichkeiten haben, aber viele Einstellungsaufgaben in Bezug auf die Partitionierung von Daten, die Adressierung von Partitionen, Replikate usw. ausführen müssen. Wenn Sie keine differenzierte Steuerung benötigen, können Sie sich den zusätzlichen Aufwand durch den Einsatz von Reliable Actors sparen.

Zusammenfassung

Microservices-Architekturen erfordern eine Festlegung auf dezentrale Ansätze, disziplinierte Architektur- und Designprozesse, neue Technologien wie Azure Service Fabric und eine Änderung der Teamdynamik in Richtung kleiner Entwicklungsteams und agiler Prinzipien, die für den jeweiligen Microservice befolgt werden.

Cesar de la Torreist ein leitender Programm-Manager bei Microsoft und lebt in Redmond im US-Bundesstaat Washington. Seine Schwerpunkte sind die Microsoft Azure- und .NET-Entwicklung mittels Ansätzen wie Microservices-Architekturen und Domain-Driven Design, sowie die Entwicklung mobiler Apps, die die Dienste nutzen.

Kunal Deep Singhist ein leitender Programm-Manager im Microsoft Azure Service Fabric-Team. Vor Azure hat er an mehreren Versionen von Windows Phone, Silverlight und als Entwickler von Spielen für die Xbox gearbeitet. Er lebt in Seattle im US-Bundesstaat Washington.

Vaclav Turecekist ein leitender Programm-Manager bei Microsoft. Er arbeitet unermüdlich mit einer sehr talentierten Gruppe daran, Azure Service Fabric zur besten Plattform-as-a-Service-Lösung der nächsten Generation zu machen.

Unser Dank gilt dem folgenden technischen Experten bei Microsoft für die Durchsicht von und Mitwirkung an diesem Artikel: Mark Fussell
Mark Fussell ist ein leidenschaftlicher Entwickler von Cloudanwendungen, der bereits seit vielen Jahren bei Microsoft an der Entwicklung von Produkten arbeitet, u. a. an Datenzugriffs- und Kommunikations- sowie anderen serverseitigen Technologien. Er ist erfreut, dass Service Fabric von Microsoft jedermann zur Verfügung gestellt wird, um Anwendungen mittels eines Microservices-Ansatzes zu entwickeln.

Freigeben über