Bewährte Methoden für den Azure Service Fabric-Anwendungsentwurf

  • Artikel

Dieser Artikel enthält bewährte Methoden für das Erstellen von Anwendungen und Diensten in Azure Service Fabric.

Kennenlernen von Service Fabric

Leitfaden für den Anwendungsentwurf

Machen Sie sich mit der allgemeinen Architektur von Service Fabric-Anwendungen und ihren Entwurfsüberlegungen vertraut.

Auswählen eines API-Gateways

Verwenden Sie einen API-Gatewaydienst, der mit Back-End-Diensten kommuniziert, die dann horizontal hochskaliert werden können. Die folgenden API-Gatewaydienste werden am häufigsten verwendet:

Zustandslose Dienste

Wir empfehlen, dass Sie immer damit beginnen, zustandslose Dienste mit Reliable Services zu erstellen und den Zustand in einer Azure-Datenbank, in Azure Cosmos DB oder Azure Storage zu speichern. Für die meisten Entwickler ist der externalisierte Zustand der vertrautere Ansatz. Dieser Ansatz ermöglicht auch die Nutzung von Abfragefunktionen im Speicher.

Szenarien für zustandsbehaftete Dienste

Ziehen Sie zustandsbehaftete Dienste in Betracht, wenn Sie ein Szenario mit geringer Latenzzeit haben und die Daten in der Nähe des Computes halten müssen. Einige Beispielszenarien sind digitale IoT-Zwillingsgeräte, Spielstatus, Sitzungsstatus, Zwischenspeicherung von Daten aus einer Datenbank und zeitintensive Workflows zur Verfolgung von Aufrufen anderer Dienste.

Festlegen des Zeitrahmens für die Datenaufbewahrung:

  • Zwischengespeicherte Daten: Sie verwenden Zwischenspeicherung, wenn die Latenz zu externen Speichern ein Problem darstellt. Verwenden Sie einen zustandsbehafteten Dienst als eigenen Datencache, oder verwenden Sie die Open-Source-Option „SoCreate service-fabric-distributed-cache“. In diesem Szenario müssen Sie sich keine Gedanken darüber machen, alle Daten im Cache zu verlieren.
  • Zeitgebundene Daten: In diesem Szenario müssen Sie Daten aus Latenzgründen eine Zeit lang nah an der Computeressource halten, aber diese Daten dürfen in einem Notfall verloren gehen. So müssen beispielsweise in vielen IoT-Lösungen die Daten nah an der Computeressource sein, etwa bei der Berechnung der Durchschnittstemperatur der letzten Tage. Wenn diese Daten aber verloren gehen, dann sind die aufgezeichneten spezifischen Datenpunkte nicht so wichtig. Darüber hinaus ist in diesem Szenario in der Regel die Sicherung der einzelnen Datenpunkte nicht von Bedeutung. Sie sichern nur berechnete Durchschnittswerte, die in regelmäßigen Abständen in einen externen Speicher geschrieben werden.
  • Langfristige Daten: Zuverlässige Sammlungen können Ihre Daten dauerhaft speichern. In diesem Fall müssen Sie sich jedoch auf eine Notfallwiederherstellung vorbereiten, einschließlich der Konfiguration von Richtlinien für regelmäßige Sicherungen für Ihre Cluster. Im Endeffekt konfigurieren Sie, was passiert, wenn Ihr Cluster in einem Notfall zerstört wird, wo Sie einen neuen Cluster erstellen müssen und wie Sie neue Anwendungsinstanzen bereitstellen und nach der letzten Sicherung wiederherstellen.

Sparen von Kosten und Verbessern der Verfügbarkeit:

  • Mit zustandsbehafteten Diensten können Sie die Kosten senken, da Ihnen keine Datenzugriffs- und Transaktionskosten aus dem Remotespeicher entstehen und Sie keinen weiteren Dienst wie etwa Azure Cache for Redis verwenden müssen.
  • Die Verwendung von zustandsbehafteten Diensten hauptsächlich für die Speicherung und nicht für Compute ist teuer und wird nicht empfohlen. Betrachten Sie zustandsbehaftete Dienste als Compute mit günstigem lokalem Speicher.
  • Durch das Entfernen von Abhängigkeiten von anderen Diensten können Sie die Dienstverfügbarkeit verbessern. Wenn Sie den Zustand mit Hochverfügbarkeit im Cluster verwalten, sind Sie vor anderen Dienstausfällen oder Latenzproblemen geschützt.

Arbeiten mit Reliable Services

Service Fabric Reliable Services ermöglichen Ihnen das einfache Erstellen von zustandslosen und zustandsbehafteten Diensten. Weitere Informationen finden Sie unter Einführung in Reliable Services.

  • Berücksichtigen Sie immer das Abbruchtoken in der RunAsync()-Methode für zustandslose und zustandsbehaftete Dienste und die ChangeRole()-Methode für zustandsbehaftete Dienste. Andernfalls weiß Service Fabric nicht, ob Ihr Dienst geschlossen werden kann. Beispielsweise kann die Nichtbeachtung des Abbruchtokens zu wesentlich längeren Upgradezeiten für Anwendungen führen.
  • Öffnen und schließen Sie Kommunikationslistener rechtzeitig, und berücksichtigen Sie die Abbruchtoken.
  • Kombinieren Sie niemals synchronen Code mit asynchronem Code. Verwenden Sie beispielsweise nicht .GetAwaiter().GetResult() in Ihren asynchronen Aufrufen. Arbeiten Sie in der gesamten Aufrufliste asynchron.

Arbeiten mit Reliable Actors

Service Fabric Reliable Actors ermöglicht Ihnen das einfache Erstellen von zustandsbehafteten virtuellen Akteuren. Weitere Informationen finden Sie unter Einführung in Reliable Actors.

  • Ziehen Sie unbedingt Veröffentlichen/Abonnieren-Messaging zwischen Ihren Akteuren für die Skalierung der Anwendung in Betracht. Tools, die diesen Dienst anbieten, sind z. B. die Open-Source-Lösung Service Fabric Pub/Sub von SoCreate und Azure Service Bus.
  • Stellen Sie den Akteurzustand so präzise wie möglich dar.
  • Verwalten Sie den Lebenszyklus des Akteurs. Löschen Sie Akteure, wenn Sie nicht vorhaben, sie noch einmal zu verwenden. Das Löschen von nicht benötigten Akteuren ist besonders wichtig, wenn Sie flüchtige Zustandsanbieter verwenden, da alle Zustände im Arbeitsspeicher gespeichert werden.
  • Aufgrund ihrer turnusbasierten Parallelität werden Akteure am besten als unabhängige Objekte verwendet. Erstellen Sie keine Graphen mit synchronen Methodenaufrufen mit mehreren Akteuren (von denen jeder höchstwahrscheinlich zu einem separaten Netzwerkaufruf wird), und erstellen Sie keine zirkulären Akteuranforderungen. Diese beeinflussen die Leistung und Skalierung erheblich.
  • Kombinieren Sie synchronen Code nicht mit asynchronem Code. Verwenden Sie immer asynchronen Code, um Leistungsprobleme zu vermeiden.
  • Verwenden Sie keine Aufrufe mit langer Ausführungszeit in Akteuren. Diese blockieren andere Aufrufe des gleichen Akteurs aufgrund der turnusbasierten Parallelität.
  • Wenn Sie mit anderen Diensten über Service Fabric-Remoting kommunizieren und eine ServiceProxyFactory erstellen, dann erstellen Sie die Factory auf der Eben des Actordiensts und nicht auf der des Akteurs.

Anwendungsdiagnose

Fügen Sie konsequent Anwendungsprotokollierung in Dienstaufrufen hinzu. Dies hilft bei der Diagnose von Szenarien, in denen Dienste sich gegenseitig aufrufen. Bei der Abrufreihenfolge „A ruft B auf – B ruft C auf – C ruft D auf“ könnte der Aufruf z. B. an jeder beliebigen Stelle zu einem Fehler führen. Wenn die Protokollierung nicht umfassend ist, können Fehler nur schwer diagnostiziert werden. Wenn die Dienste aufgrund des Aufrufaufkommens zu viel protokollieren, sollten Sie zumindest Fehler und Warnungen protokollieren.

Entwurfsleitfaden für Azure