Migrieren einer Azure Cloud Services-Anwendung zu Azure Service Fabric

Beispielcode

In diesem Artikel wird die Migration einer Anwendung von Azure Cloud Services zu Azure Service Fabric beschrieben. Er konzentriert sich auf architekturbezogene Entscheidungen und empfohlene Vorgehensweisen.

Für dieses Projekt haben wir mit einer Cloud Services-Anwendung namens „Surveys“ begonnen und diese zu Service Fabric portiert. Ziel war es, die Anwendung mit möglichst wenigen Änderungen zu migrieren. Weiter unten im Artikel wird veranschaulicht, wie Sie die Anwendung für Service Fabric optimieren.

Es ist hilfreich, wenn Sie sich vor dem Lesen dieses Artikels mit den Grundlagen von Service Fabric vertraut machen. Informationen hierzu finden Sie unter Übersicht über Azure Service Fabric.

Informationen zur Anwendung „Surveys“

Ein fiktives Unternehmen mit dem Namen Tailspin hat die App „Surveys“ entwickelt, mit der Kunden Umfragen erstellen können. Nachdem sich ein Kunde für die Anwendung registriert hat, können Benutzer Umfragen erstellen und veröffentlichen und die Ergebnisse zu Analysezwecken erfassen. Die Anwendung enthält eine öffentliche Website, auf der die Benutzer an einer Umfrage teilnehmen können. Weitere Informationen zum ursprünglichen Tailspin-Szenario finden Sie hier.

Jetzt will Tailspin die Surveys-Anwendung mithilfe von Service Fabric, das unter Azure ausgeführt wird, in eine Microservices-Architektur verschieben. Da die Anwendung bereits als Cloud Services-Anwendung bereitgestellt wurde, verfolgt Tailspin einen mehrstufigen Ansatz:

1. Portierung der Clouddienste zu Service Fabric bei gleichzeitiger Minimierung von Änderungen an der Anwendung.
2. Optimierung der Anwendung für Service Fabric durch Umstellung auf eine Microservices-Architektur.

In einem realen Projekt ist es wahrscheinlich, dass sich beide Phasen überlappen. Bei der Portierung zu Service Fabric würden Sie auch damit beginnen, die Anwendung in Microservices umzugestalten. Später können Sie die Architektur weiter verfeinern und umfassendere Dienste in kleinere Dienste unterteilen.

Der Anwendungscode steht auf GitHub zur Verfügung. Dieses Repository enthält sowohl die Cloud Services-Anwendung als auch die Service Fabric-Version.

Gründe für Service Fabric

Service Fabric eignet sich gut für dieses Projekt, da die meisten Funktionen, die in einem verteilten System benötigt werden, in Service Fabric integriert sind, z. B.:

• Clusterverwaltung: Service Fabric übernimmt automatisch Knotenfailover, Integritätsüberwachung und andere Funktionen der Clusterverwaltung.
• Horizontale Skalierung: Wenn Sie Knoten zu einem Service Fabric-Cluster hinzufügen, wird die Anwendung automatisch skaliert, da die Dienste auf die neuen Knoten verteilt werden.
• Dienstermittlung: Service Fabric stellt einen Ermittlungsdienst bereit, der den Endpunkt für einen benannten Dienst auflösen kann.
• Zustandslose und zustandsbehaftete Dienste: Zustandsbehaftete Dienste verwenden zuverlässige Sammlungen, die an die Stelle eines Caches oder einer Warteschlange treten und partitioniert werden können.
• Anwendungslebenszyklusverwaltung: Ein Upgrade der Dienste ist unabhängig und ohne Ausfallzeiten der Anwendungen möglich.
• Dienstorchestrierung für einen Cluster aus Computern.
• Höhere Dichte zur Optimierung des Ressourcenverbrauchs. Ein einzelner Knoten kann mehrere Dienste hosten.

Service Fabric wird von verschiedenen Microsoft-Diensten verwendet, darunter Azure SQL-Datenbank, Azure Cosmos DB, Azure Event Hubs und andere, was es zu einer bewährten Plattform für die Erstellung verteilter Cloudanwendungen macht.

Unterschiede zwischen Cloud Services und Service Fabric

In der folgenden Tabelle sind einige der wichtigsten Unterschiede zwischen Cloud Services- und Service Fabric-Anwendungen zusammengefasst. Eine ausführlichere Beschreibung finden Sie unter Lernen Sie die Unterschiede zwischen Cloud Services und Service Fabric kennen, bevor Sie Anwendungen migrieren.

* Zustandsbehaftete Dienste verwenden zuverlässige Sammlungen, um den Zustand replikatübergreifend zu speichern, damit alle Lesezugriffe lokal zu den Knoten im Cluster erfolgen. Schreibzugriffe werden aus Zuverlässigkeitsgründen knotenübergreifend repliziert. Zustandslose Dienste können einen externen Zustand aufweisen, indem sie eine Datenbank oder einen anderen externen Speicher verwenden.

** Workerrollen können die ASP.NET-Web-API mithilfe von OWIN auch selbst hosten.

Die Anwendung „Surveys“ unter Cloud Services

Das folgende Diagramm zeigt die Architektur der Surveys-Anwendung, die unter Cloud Services ausgeführt wird.

Die Anwendung besteht aus zwei Webrollen und einer Workerrolle.

• Die Webrolle Tailspin.Web hostet eine ASP.NET-Website, die Tailspin-Kunden zum Erstellen und Verwalten von Umfragen verwenden. Kunden können sich auch über diese Website für die Anwendung registrieren und ihre Abonnements verwalten. Schließlich können Tailspin-Administratoren damit die Liste der Mandanten anzeigen und die Mandantendaten verwalten.

• Die Webrolle Tailspin.Web.Survey.Public hostet eine ASP.NET-Website, auf der die Teilnehmer an den Umfragen teilnehmen können, die Tailspin-Kunden veröffentlichen.

• Die Workerrolle Tailspin.Workers.Survey führt die Hintergrundverarbeitung durch. Die Webrollen stellen Arbeitselemente in eine Warteschlange, und die Workerrolle verarbeitet die Arbeitselemente. Zwei Hintergrundaufgaben sind definiert: Exportieren von Umfrageantworten in die Azure SQL-Datenbank und Berechnen von Statistiken für Umfrageantworten.

Zusätzlich zu den Cloud Services verwendet die Surveys-Anwendung einige andere Azure-Dienste:

• Azure Storage, um Umfragen, Umfrageantworten und Mandanteninformationen zu speichern.

• Azure Cache for Redis, um einige der Daten, die in Azure Storage gespeichert sind, für einen schnelleren Lesezugriff zwischenzuspeichern.

• Azure Active Directory (Azure AD), um Kunden und Tailspin-Administratoren zu authentifizieren.

• Azure SQL-Datenbank, um Umfrageantworten für die Analyse zu speichern.

Wechsel zu Service Fabric

Wie bereits erwähnt, war das Ziel dieser Phase die Migration zu Service Fabric mit den minimal notwendigen Änderungen. Zu diesem Zweck haben wir zustandslose Dienste erstellt, die den einzelnen Clouddienstrollen in der ursprünglichen Anwendung entsprechen:

Diese Architektur ist absichtlich ähnlich wie die ursprüngliche Anwendung gehalten. Das Diagramm blendet jedoch einige wichtige Unterschiede aus. Im Rest dieses Artikels werden wir diese Unterschiede untersuchen.

Konvertieren von Clouddienstrollen in Dienste

Für die erste Migration wurden von Tailspin die Schritte befolgt, die im Abschnitt Anleitung zur Konvertierung von Web- und Workerrollen in zustandslose Service Fabric-Dienste aufgeführt sind.

Erstellen der Web-Front-End-Dienste

In Service Fabric wird ein Dienst innerhalb eines Prozesses ausgeführt, der von der Service Fabric-Laufzeit erstellt wurde. Für ein Web-Front-End bedeutet dies, dass der Dienst nicht innerhalb von IIS ausgeführt wird. Stattdessen muss der Dienst einen Webserver hosten. Dieser Ansatz wird Self-Hosting genannt, da der Code, der innerhalb des Prozesses aufgeführt wird, als Webserverhost fungiert.

Die ursprüngliche Surveys-Anwendung verwendet ASP.NET MVC. Da ASP.NET MVC in Service Fabric nicht selbst gehostet werden kann, hat Tailspin die folgenden Migrationsoptionen in Betracht gezogen:

• Portieren Sie die Webrollen zu ASP. NET Core, das selbstgehostet werden kann.
• Konvertieren Sie die Website in eine einseitige Anwendung (SPA), die eine Web-API aufruft, die mit der ASP.NET-Web-API implementiert wurde. Dies hätte eine komplette Neugestaltung des Web-Front-Ends erforderlich gemacht.
• Behalten Sie den vorhandenen ASP.NET MVC-Code bei, und stellen Sie IIS in einem Windows Server-Container für Service Fabric bereit. Dieser Ansatz würde nur eine geringe oder gar keine Codeänderung erfordern.

Dank der ersten Option (Portieren zu ASP.NET Core) konnte Tailspin die neuesten Features in ASP.NET Core nutzen. Für die Konvertierung hat Tailspin die Schritte befolgt, die unter Migrieren von ASP.NET MVC zu ASP.NET Core MVC beschrieben sind.

HTTP-Listener

In Cloud Services macht eine Web- oder Workerrolle einen HTTP-Endpunkt verfügbar, indem dieser in der Dienstdefinitionsdatei deklariert wird. Eine Webrolle muss über mindestens einen Endpunkt verfügen.

<!-- Cloud service endpoint -->
<Endpoints>
    <InputEndpoint name="HttpIn" protocol="http" port="80" />
</Endpoints>

Auf ähnliche Weise werden Service Fabric-Endpunkte in einem Dienstmanifest deklariert:

<!-- Service Fabric endpoint -->
<Endpoints>
    <Endpoint Protocol="http" Name="ServiceEndpoint" Type="Input" Port="8002" />
</Endpoints>

Im Gegensatz zu einer Clouddienstrolle können Service Fabric-Dienste zusammen innerhalb desselben Knotens platziert werden. Aus diesem Grund muss jeder Dienst an einem eindeutigen Port lauschen. Später in diesem Artikel werden wir besprechen, wie Clientanforderungen an Port 80 oder Port 443 zum richtigen Port für den Dienst weitergeleitet werden.

Ein Dienst muss für jeden Endpunkt explizit Listener erstellen. Der Grund dafür ist, dass Service Fabric sich nicht mit Kommunikationsstapeln auseinandersetzt. Weitere Informationen finden Sie unter Erstellen eines Webdienst-Front-Ends für Ihre Anwendung mithilfe von ASP.NET Core.

Verpackung und Konfiguration

Ein Clouddienst enthält die folgenden Konfigurations- und Paketdateien:

Es gibt eine CSDEF-Datei für die gesamte Anwendung. Sie können mehrere CSCFG-Dateien für verschiedene Umgebungen verwenden, z. B. „Lokal“, „Test“ oder „Produktion“. Wenn der Dienst ausgeführt wird, können Sie die CSCFG-Datei aktualisieren, aber nicht die CSDEF-Datei. Weitere Informationen finden Sie unter Was ist das Clouddienstmodell, und wie kann es gepackt werden?.

Service Fabric weist eine ähnliche Trennung von Dienstdefinition und Diensteinstellungen auf, aber die Struktur ist differenzierter. Um das Konfigurationsmodell von Service Fabric zu verstehen, ist es hilfreich zu erkennen, wie eine Service Fabric-Anwendung verpackt ist. Folgende Struktur wird verwendet:

Application package
  - Service packages
    - Code package
    - Configuration package
    - Data package (optional)

Das Anwendungspaket ist das, was Sie bereitstellen. Es enthält mindestens ein Dienstpaket. Ein Dienstpaket enthält Code-, Konfigurations- und Datenpakete. Das Codepaket enthält die Binärdateien für die Dienste, während das Konfigurationspaket die Konfigurationseinstellungen enthält. Dieses Modell gestattet es Ihnen, einzelne Dienste zu aktualisieren, ohne die gesamte Anwendung erneut bereitzustellen. Außerdem können Sie nur die Konfigurationseinstellungen aktualisieren, ohne den Code erneut bereitzustellen oder den Dienst erneut zu starten.

Eine Service Fabric-Anwendung enthält die folgenden Konfigurationsdateien:

Weitere Informationen finden Sie unter Modellieren einer Anwendung in Service Fabric.

Wenn Sie verschiedene Konfigurationseinstellungen für mehrere Umgebungen unterstützen möchten, können Sie den folgenden Ansatz verwenden, der unter Verwalten von Anwendungsparametern für mehrere Umgebungen beschrieben ist:

1. Definieren Sie die Einstellung in der Datei „Setting.xml“ für den Dienst.
2. Definieren Sie im Anwendungsmanifest eine Außerkraftsetzung für die Einstellung.
3. Stellen Sie umgebungsspezifische Einstellungen in Anwendungsparameterdateien.

Bereitstellen der Anwendung

Während Azure Cloud Services ein verwalteter Dienst ist, handelt es sich bei Service Fabric um eine Laufzeit. Sie können Service Fabric-Cluster in vielen Umgebungen erstellen, einschließlich Azure und lokal. Das folgende Diagramm zeigt eine empfohlene Bereitstellung für Azure:

Der Service Fabric-Cluster wird in einer VM-Skalierungsgruppe bereitgestellt. Skalierungsgruppen sind eine Azure-Computeressource, mit der Sie eine Gruppe von identischen virtuellen Computern bereitstellen und verwalten können.

Wie bereits erwähnt, empfehlen wir Ihnen, den Kestrel-Webserver aus Sicherheitsgründen hinter einem Reverseproxy anzuordnen. In diesem Diagramm ist Azure Application Gateway dargestellt. Dies ist ein Azure-Dienst, der über verschiedene Layer 7-Lastenausgleichsfunktionen verfügt. Er fungiert als Reverseproxydienst, beendet die Clientverbindung und leitet Anforderungen an Back-End-Endpunkte weiter. Möglicherweise verwenden Sie eine andere Reverseproxylösung wie nginx.

Layer 7-Routing

In der ursprünglichen Survey-Anwendung lauschte eine Webrolle an Port 80 und die andere Webrolle an Port 443.

Eine andere Möglichkeit besteht darin, das Layer 7-Routing zu verwenden. Bei diesem Ansatz werden unterschiedliche URL-Pfade zu unterschiedlichen Portnummern am Back-End weitergeleitet. Die öffentliche Website kann z. B. URL-Pfade verwenden, die mit /public/ beginnen.

Folgende Optionen zählen zum Layer 7-Routing:

• Die Verwendung von Application Gateway.
• Die Verwendung eines virtuellen Netzwerkgeräts wie nginx.
• Das Schreiben eines benutzerdefinierten Gateways als zustandsloser Dienst.

Betrachten Sie diesen Ansatz, wenn Sie über zwei oder mehr Dienste mit öffentlichen HTTP-Endpunkten verfügen, diese aber als einzelne Website mit einem einzigen Domänennamen angezeigt werden sollen.

Ein nicht zu empfehlender Ansatz besteht darin, für externe Clients das Senden von Anforderungen über den Reverseproxy von Service Fabric zuzulassen. Obwohl dies möglich ist, ist der Reverseproxy für die Kommunikation zwischen Diensten vorgesehen. Wenn Sie ihn für externe Clients öffnen, wird jeder im Cluster aktive Dienst sichtbar, der über einen HTTP-Endpunkt verfügt.

Knotentypen und Platzierungseinschränkungen

In der oben gezeigten Bereitstellung werden alle Dienste auf allen Knoten ausgeführt. Sie können jedoch auch Dienste gruppieren, sodass bestimmte Dienste nur auf gewissen Knoten innerhalb des Clusters ausgeführt werden. Gründe für die Verwendung dieses Ansatzes:

• Es werden einige Dienste auf verschiedenen Arten von virtuellen Computern ausgeführt. Einige Dienste sind möglicherweise rechenintensiv oder erfordern GPUs. Sie können eine Mischung aus verschiedenen Arten von virtuellen Computern in Ihrem Service Fabric-Cluster verwenden.
• Isolieren Sie die Front-End-Dienste aus Sicherheitsgründen von den Back-End-Diensten. Alle Front-End-Dienste werden auf einer Gruppe von Knoten ausgeführt, während die Back-End-Dienste auf anderen Knoten im selben Cluster ausgeführt werden.
• Es liegen unterschiedliche Skalierungsanforderungen vor. Einige Dienste müssen möglicherweise auf einer größeren Anzahl von Knoten als andere Dienste ausgeführt werden. Wenn Sie Front-End- und Back-End-Knoten definieren, kann jede Gruppe unabhängig skaliert werden.

Das folgende Diagramm zeigt einen Cluster mit getrennten Front-End- und Back-End-Diensten:

So implementieren Sie diesen Ansatz

1. Definieren Sie beim Erstellen des Clusters mindestens zwei Knotentypen.
2. Verwenden Sie für jeden Dienst Platzierungseinschränkungen, um den Dienst einem Knotentyp zuzuweisen.

Bei der Bereitstellung in Azure wird jeder Knotentyp in einer separaten VM-Skalierungsgruppe bereitgestellt. Der Service Fabric-Cluster umfasst alle Knotentypen. Weitere Informationen finden Sie unter Die Beziehung zwischen Service Fabric-Knotentypen und VM-Skalierungsgruppen.

Wenn ein Cluster über mehrere Knotentypen verfügt, wird ein Knotentyp als primärer Knotentyp bestimmt. Service Fabric-Laufzeitdienste wie der Clusterverwaltungsdienst werden auf dem primären Knotentyp ausgeführt. Stellen Sie mindestens fünf Knoten für den primären Knotentyp in einer Produktionsumgebung bereit. Der andere Knotentyp sollte mindestens zwei Knoten umfassen.

Konfigurieren und Verwalten des Clusters

Cluster müssen gesichert werden, um zu verhindern, dass sich nicht autorisierte Benutzer mit Ihrem Cluster verbinden. Es wird empfohlen, Azure AD für die Authentifizierung von Clients und X.509-Zertifikate für die Knoten-zu-Knoten-Sicherheit zu verwenden. Weitere Informationen finden Sie unter Szenarien für die Clustersicherheit in Service Fabric.

Informationen zum Konfigurieren eines öffentlichen HTTPS-Endpunkts finden Sie unter Angeben von Ressourcen in einem Dienstmanifest.

Sie können die Anwendung aufskalieren, indem Sie dem Cluster virtuelle Computer hinzufügen. VM-Skalierungsgruppen unterstützen die automatische Skalierung mithilfe automatischer Skalierungsregeln auf Grundlage von Leistungsindikatoren. Weitere Informationen finden Sie unter Horizontales Hoch- oder Herunterskalieren eines Service Fabric-Clusters mithilfe von Regeln für die automatische Skalierung.

Sammeln Sie die Protokolle von allen Knoten an einem zentralen Speicherort, während der Cluster aktiv ist. Weitere Informationen finden Sie unter Sammeln von Protokollen mit der Azure-Diagnose.

Umgestalten der Anwendung

Nachdem die Anwendung zu Service Fabric portiert wurde, ist der nächste Schritt die Umgestaltung in eine detailliertere Architektur. Ziel dieser Umgestaltung ist es, die Entwicklung, Erstellung und Bereitstellung der Anwendung zu vereinfachen. Durch die Aufgliederung der vorhandenen Web- und Workerrollen in eine detailliertere Architektur möchte Tailspin die enge Kopplung der Kommunikations- und Datenabhängigkeiten zwischen diesen Rollen beseitigen.

Außerdem erwartet sich Tailspin folgende Vorteile von der Migration der Anwendung „Surveys“ zu einer detaillierten Architektur:

• Jeder Dienst kann in unabhängigen Projekten mit einem Umfang verpackt werden, der problemlos von einem kleinen Team verwaltet werden kann.
• Jeder Dienst kann unabhängig versioniert und bereitgestellt werden.
• Jeder Dienst kann mit der optimalen Technologie für den jeweiligen Dienst implementiert werden. Ein Service Fabric-Cluster kann beispielsweise Dienste enthalten, die mit verschiedenen .NET Framework-Versionen, mit Java oder mit anderen Sprachen wie C# oder C++ erstellt wurden.
• Jeder Dienst kann unabhängig skaliert werden, um auf eine Zu- oder Abnahme der Last zu reagieren.

Der Quellcode für die umgestaltete Version der App ist auf GitHub verfügbar.

Überlegungen zum Entwurf

Das folgende Diagramm zeigt die Architektur der Anwendung „Surveys“ nach der Umgestaltung zu einer detaillierteren Architektur:

Tailspin.Web ist ein zustandsloser Dienst für eine selbstgehostete ASP.NET-MVC-Anwendung, mit der Tailspin-Kunden Umfragen erstellen und Umfrageergebnisse anzeigen. Dieser Dienst hat größtenteils den gleichen Code wie der Dienst Tailspin.Web aus der portierten Service Fabric-Anwendung. Wie weiter oben erwähnt, verwendet dieser Dienst ASP.NET Core und implementiert einen Weblistener, anstatt Kestrel als Web-Front-End zu verwenden.

Tailspin.Web.Survey.Public ist ein zustandsloser Dienst und hostet ebenfalls selbst eine ASP.NET-MVC-Website. Benutzer besuchen diese Website, um Umfragen aus einer Liste auszuwählen und zu beantworten. Dieser Dienst hat größtenteils den gleichen Code wie der Dienst Tailspin.Web.Survey.Public aus der portierten Service Fabric-Anwendung. Dieser Dienst verwendet ebenfalls ASP.NET Core und implementiert auch einen Weblistener, anstatt Kestrel als Web-Front-End zu verwenden.

Tailspin.SurveyResponseService ist ein zustandsbehafteter Dienst, der Umfrageantworten in Azure Blob Storage speichert. Darüber hinaus führt er Antworten in den Umfrageanalysedaten zusammen. Der Dienst wird als zustandsbehafteter Dienst implementiert, da er ReliableConcurrentQueue verwendet, um Umfrageantworten in Batches zu verarbeiten. Diese Funktion wurde ursprünglich im Dienst Tailspin.AnswerAnalysisService in der portierten Service Fabric-Anwendung implementiert.

Tailspin.SurveyManagementService ist ein zustandsloser Dienst zum Speichern und Abrufen von Umfragen und der Fragen von Umfragen. Der Dienst verwendet Azure Blob Storage. Diese Funktion wurde ebenfalls ursprünglich in den Datenzugriffskomponenten der Dienste Tailspin.Web und Tailspin.Web.Survey.Public in der portierten Service Fabric-Anwendung implementiert. Tailspin hat die ursprüngliche Funktion in diesem Dienst umgestaltet, um eine unabhängige Skalierung zu ermöglichen.

Tailspin.SurveyAnswerService ist ein zustandsloser Dienst zum Abrufen von Umfrageantworten und -analysen. Der Dienst verwendet ebenfalls Azure Blob Storage. Diese Funktion wurde ebenfalls ursprünglich in den Datenzugriffskomponenten des Diensts Tailspin.Web in der portierten Service Fabric-Anwendung implementiert. Tailspin hat die ursprüngliche Funktion in diesem Dienst umgestaltet, da das Unternehmen mit weniger Last rechnet und durch die Verwendung von weniger Instanzen Ressourcen sparen möchte.

Tailspin.SurveyAnalysisService ist ein zustandsloser Dienst, der Zusammenfassungsdaten für Umfrageantworten in einem Redis Cache speichert, um sie schnell abrufen zu können. Dieser Dienst wird von Tailspin.SurveyResponseService aufgerufen, wenn eine Umfrage beantwortet wird, und die neuen Umfrageantwortdaten werden in den Zusammenfassungsdaten zusammengeführt. Dieser Dienst enthält die Funktion, die ursprünglich im Dienst Tailspin.AnswerAnalysisService aus der portierten Service Fabric-Anwendung implementiert wurde.

Gegenüberstellung von Zustandslosen und zustandsbehafteten Diensten

Azure Service Fabric unterstützt folgende Programmiermodelle:

• Beim Modell der ausführbaren Gastanwendungsdatei kann jede beliebige ausführbare Datei als Dienst verpackt und in einem Service Fabric-Cluster bereitgestellt werden. Service Fabric orchestriert und verwaltet die Ausführung der ausführbaren Gastanwendungsdatei.
• Das Containermodell ermöglicht die Bereitstellung von Diensten in Containerimages. Service Fabric unterstützt die Erstellung und Verwaltung von Containern oberhalb von Linux-Kernelcontainern und Windows Server-Containern.
• Das Reliable Services-Programmiermodell ermöglicht die Erstellung zustandsloser oder zustandsbehafteter Dienste mit Integration in alle Service Fabric-Plattformfeatures. Zustandsbehaftete Dienste ermöglichen die Speicherung des replizierten Zustands im Service Fabric-Cluster. Bei zustandslosen Diensten ist dies nicht möglich.
• Das Reliable Actors-Programmiermodell ermöglicht die Erstellung von Diensten, die das Muster „Virtueller Akteur“ implementieren.

Mit Ausnahme des Diensts Tailspin.SurveyResponseService sind alle Dienste in der Anwendung „Surveys“ zustandslose Reliable Services. Dieser Dienst implementiert ReliableConcurrentQueue, um Umfrageantworten zu verarbeiten, wenn sie empfangen werden. Antworten in „ReliableConcurrentQueue“ werden in Azure Blob Storage gespeichert und zur Analyse an Tailspin.SurveyAnalysisService übergeben. Tailspin entscheidet sich für einen ReliableConcurrentQueue-basierten Ansatz, da für Antworten keine strenge FIFO-Sortierung (First In – First Out) erforderlich ist, wie sie beispielsweise von einer Warteschlange wie Azure Service Bus geboten wird. „ReliableConcurrentQueue“ bietet zudem einen hohen Durchsatz und eine geringe Wartezeit beim Hinzufügen zur Warteschlange und beim Entfernen aus der Warteschlange.

Vorgänge zum Speichern von Elementen, die aus „ReliableConcurrentQueue“ entfernt wurden, sollten im Idealfall idempotent sein. Wenn bei der Verarbeitung eines Elements aus der Warteschlange eine Ausnahme ausgelöst wird, kann das gleiche Element mehrmals verarbeitet werden. In der Anwendung „Surveys“ ist der Vorgang zum Zusammenführen von Umfrageantworten in Tailspin.SurveyAnalysisService nicht idempotent, da Tailspin beschlossen hat, dass es sich bei den Umfrageanalysedaten lediglich um eine aktuelle Momentaufnahme der Analysedaten handelt und diese nicht konsistent sein müssen. Da die in Azure Blob Storage gespeicherten Umfrageantworten letztlich konsistent sind, kann die Abschlussanalyse der Umfrage jederzeit auf der Grundlage dieser Daten neu berechnet werden.

Kommunikationsframework

Jeder Dienst in der Anwendung „Surveys“ kommuniziert über eine RESTful-Web-API. RESTful-APIs bieten folgende Vorteile:

• Benutzerfreundlichkeit: Jeder Dienst basiert auf ASP.NET Core-MVC und unterstützt somit nativ die Erstellung von Web-APIs.
• Sicherheit: SSL ist zwar nicht für jeden Dienst erforderlich, Tailspin kann dies für die einzelnen Dienste jedoch voraussetzen.
• Versionsverwaltung: Clients können für eine bestimmte Version einer Web-API geschrieben und getestet werden.

Dienste in der Anwendung „Surveys“ verwenden den von Service Fabric implementierten Reverseproxy. Der Reverseproxy ist ein Dienst, der auf den einzelnen Knoten im Service Fabric-Cluster ausgeführt wird. Er bietet Endpunktauflösung und automatische Wiederholung und behandelt andere Arten von Verbindungsfehlern. Zur Verwendung des Reverseproxys erfolgt jeder RESTful-API-Aufruf für einen bestimmten Dienst über einen vordefinierten Reverseproxyport. Wenn der Reverseproxyport also beispielsweise auf 19081 festgelegt wurde, kann ein Aufruf für Tailspin.SurveyAnswerService wie folgt durchgeführt werden:

static SurveyAnswerService()
{
    httpClient = new HttpClient
    {
        BaseAddress = new Uri("http://localhost:19081/Tailspin/SurveyAnswerService/")
    };
}

Geben Sie zum Aktivieren des Reverseproxys bei der Erstellung des Service Fabric-Clusters einen Reverseproxyport an. Weitere Informationen finden Sie unter Reverseproxy in Azure Service Fabric.

Überlegungen zur Leistung

Tailspin hat die ASP.NET Core-Dienste für Tailspin.Web und Tailspin.Web.Surveys.Public mithilfe von Visual Studio-Vorlagen erstellt. Diese Vorlagen beinhalten standardmäßig eine Protokollierung in der Konsole. Die Protokollierung in die Konsole kann während der Entwicklung und beim Debuggen genutzt werden, sollte aber entfernt werden, wenn die Anwendung in der Produktionsumgebung bereitgestellt wird.

So sollten beispielsweise die folgenden Zeilen in startup.cs für jeden der Web-Front-End-Dienste auskommentiert werden:

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    //loggerFactory.AddConsole(Configuration.GetSection("Logging"));
    //loggerFactory.AddDebug();

    app.UseMvc();
}

Wenn Tailspin die Anwendung „Surveys“ dann in der Produktionsumgebung bereitstellt, wird Visual Studio in den Modus Release versetzt.

Überlegungen zur Bereitstellung

Die umgestaltete Anwendung „Surveys“ besteht aus fünf zustandslosen Diensten und einem zustandsbehafteten Dienst. Die Clusterplanung ist also auf die Bestimmung der richtigen VM-Größe und der Anzahl von Knoten beschränkt. In der Datei applicationmanifest.xml, die den Cluster beschreibt, legt Tailspin das Attribut InstanceCount des Tags StatelessService für jeden der Dienste auf „-1“ fest. Durch den Wert „-1“ wird Service Fabric angewiesen, auf jedem Knoten im Cluster eine Instanz des Diensts zu erstellen.

Tailspin stellt den Cluster über das Azure-Portal bereit. Der Ressourcentyp „Service Fabric-Cluster“ stellt die gesamte erforderliche Infrastruktur bereit – einschließlich VM-Skalierungsgruppen und Lastenausgleich. Die empfohlenen VM-Größen werden während des Bereitstellungsprozesses für den Service Fabric-Cluster im Azure-Portal angezeigt. Da die virtuellen Computer in einer VM-Skalierungsgruppe bereitgestellt werden, können sie sowohl zentral als auch horizontal hochskaliert werden, wenn die Benutzerauslastung zunimmt.

Nächste Schritte

Der Code der Anwendung „Surveys“ steht auf GitHub zur Verfügung.

Wenn Sie noch nicht mit Azure Service Fabric gearbeitet haben, richten Sie zunächst Ihre Entwicklungsumgebung ein, und laden Sie anschließend das neueste Azure SDK und das Azure Service Fabric SDK herunter. Das SDK enthält den OneBox-Cluster-Manager, sodass Sie die Anwendung „Surveys“ lokal mit uneingeschränktem F5-Debugging bereitstellen und testen können.

Zugehörige Ressourcen

• Entwerfen einer Migrationsarchitektur
• Erstellen eines Migrationsplans mit Azure Migrate
• Modernisieren von Unternehmensanwendungen mit Azure Service Fabric