Modellieren von Anwendungen in Service Fabric
Dieser Artikel bietet eine Übersicht über das Azure Service Fabric-Anwendungsmodell und erläutert, wie eine Anwendung und ein Dienst über Manifestdateien definiert werden.
Informationen zum Anwendungsmodell
Eine Anwendung ist eine Sammlung von einzelnen Diensten, die eine bzw. mehrere bestimmte Funktionen ausführen. Ein Dienst führt eine vollständige und eigenständige Funktion aus und kann unabhängig von anderen Diensten gestartet und ausgeführt werden. Ein Dienst besteht aus Code, Konfiguration und Daten. Für jeden Dienst besteht der Code aus den ausführbaren Binärdateien, die Konfiguration umfasst Diensteinstellungen, die zur Laufzeit geladen werden können, und die Daten bestehen aus beliebigen statischen Daten, die vom Dienst verarbeitet werden. Jede Komponente in diesem hierarchischen Anwendungsmodell kann unabhängig mit einer Versionsangabe versehen und aktualisiert werden.
Ein Anwendungstyp ist eine Kategorisierung einer Anwendung und besteht aus einem Bündel von Diensttypen. Ein Diensttyp ist eine Kategorisierung eines Diensts. Bei der Kategorisierung können die Einstellungen und Konfigurationen variieren, die Kernfunktionen bleiben jedoch gleich. Die Instanzen eines Diensts sind die verschiedenen Dienstkonfigurationsvarianten desselben Diensttyps.
Klassen (oder „Typen“) von Anwendungen und Diensten werden über XML-Dateien (Anwendungsmanifeste und Dienstmanifeste) beschrieben. Die Manifeste beschreiben Anwendungen und Dienste und sind die Vorlagen, anhand derer Anwendungen aus dem Imagespeicher des Clusters instanziiert werden können. Manifeste werden unter Anwendungs- und Dienstmanifeste ausführlich behandelt. Die Schemadefinition für die Dateien „ServiceManifest.xml“ und „ApplicationManifest.xml“ wird mit dem Service Fabric SDK und den Service Fabric-Tools unter C:\Programme\Microsoft SDKs\Service Fabric\schemas\ServiceFabricServiceModel.xsd installiert. Eine Dokumentation des XML-Schemas finden Sie unter ServiceFabricServiceModel.xsd – Schemadokumentation.
Der Code für verschiedene Anwendungsinstanzen wird jeweils als separater Prozess ausgeführt, auch wenn der gleiche Service Fabric-Knoten als Host fungiert. Darüber hinaus kann der Lebenszyklus jeder Anwendungsinstanz unabhängig verwaltet (z.B. Durchführen eines Upgrades). Die folgende schematische Darstellung zeigt die Gliederung von Anwendungstypen in Diensttypen, die wiederum aus Code, Konfiguration und Datenpaketen bestehen. Obwohl jeder Diensttyp normalerweise einige oder alle dieser Pakettypen enthält, werden nur die Code-/Konfigurations-/Datenpakete für ServiceType4
angezeigt, um das Diagramm zu vereinfachen.
Im Cluster können eine oder mehrere Instanzen eines Diensttyps aktiv sein. Zustandsbehaftete Dienstinstanzen oder Replikate erzielen beispielsweise eine hohe Zuverlässigkeit durch die Replikation des Zustands zwischen Replikaten, die sich im Cluster in verschiedenen Knoten befinden. Die Replikation gewährleistet im Wesentlichen die Redundanz für den Dienst, sodass dieser auch bei Ausfall eines Knotens in einem Cluster verfügbar ist. Bei einem partitionierten Dienst unterteilt sich der Zustand (und die Zugriffsmuster auf diesen Zustand) noch weiter auf verschiedene Knoten im Cluster.
Die folgende schematische Darstellung zeigt die Beziehung zwischen Anwendungen und Dienstinstanzen, Partitionen und Replikaten.
Tipp
Sie können das Layout von Anwendungen in einem Cluster mit dem Service Fabric Explorer-Tool anzeigen, das hier verfügbar ist: http://<IhreClusterAdresse>:19080/Explorer. Weitere Informationen finden Sie unter Visualisieren Ihres Clusters mit Service Fabric Explorer.
Nächste Schritte
- Machen Sie sich mit der Skalierbarkeit von Anwendungen vertraut.
- Erfahren Sie mehr über den Status, die Partitionierung und die Verfügbarkeit von Diensten.
- Lesen Sie, wie Anwendungen und Dienste in Anwendungs- und Dienstmanifesten definiert werden.
- Anwendungshostingmodelle beschreiben die Beziehung zwischen Replikaten (oder Instanzen) eines bereitgestellten Diensts und dem Diensthostprozess.
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für