Kann mich jemand auf etwas hinweisen, das erklärt, wann ich eine Azure Service Fabric-Anwendung im Vergleich zu einer Azure App Service-Anwendung erstellen sollte? Ich habe eine Anwendung, die ich erstellen möchte, kann aber nicht bestimmen, ob ich sie mithilfe des Azure Service Fabric oder des Azure App Service erstellen soll.Azure-App-Service und Azure Service Fabric
Microsoft hat den document mit einem Vergleich für Azure App Service, virtuelle Maschinen, Service Fabric und Cloud Services erstellt.
Leider gibt es keine offizielle Anleitung, wann was zu verwenden ist. Sie sind zwei getrennte Plattformen, die unterschiedlichen Entwicklungsparadigmen folgen.
Der App-Service bietet Ihnen Funktionen, die Service Fabric nicht standardmäßig bereitstellt. Dinge wie automatische Skalierung, Authentifizierung, Ratenbegrenzung, Integration mit SaaS-Anwendungen, etc. Einige oder alle diese Dinge können nach und nach zu Service Fabric kommen, aber ich würde sagen, dass sie in der Minute auf unterschiedliche Zielgruppen ausgerichtet sind - a Ein weniger erfahrenes Team könnte es einfacher finden, mit dem App Service zu arbeiten.
Service Fabric hingegen erleichtert das Zusammensetzen von Teilen. Wenn Sie beispielsweise im "herkömmlichen" Ansatz über eine API verfügen, die mit einem Datenspeicher und einem Cache kommuniziert, um eine Beschädigung des Datenspeichers zu vermeiden, müssen Sie mit den verschiedenen Fehlertoleranzszenarien umgehen. Mit Service Fabric kann Ihr Cache innerhalb des API-Prozesses in einer zuverlässigen Sammlung gespeichert werden und Sie müssen nicht mit einer externen Cache-Komponente arbeiten. Die Daten befinden sich gemeinsam mit dem Service (schneller abrufen/bearbeiten!) Und sind zuverlässig, da sie auf alle Knoten verteilt sind, auf denen der Service bereitgestellt wird. Ähnliches mit Warteschlangen. Wenn Sie an ein Workflow-System denken, wo es eine API, einen Job-Service und eine Warteschlange gibt, die zwischen ihnen sitzt und ihnen erlaubt zu kommunizieren, müssen Sie 3 verschiedene Komponenten und die Kommunikation zwischen ihnen verwalten. Mit Service Fabric kommt die Warteschlange in die Anwendung. Und das ist nur die Hälfte :) Sie erhalten auch die Möglichkeit, das Aktormodell für verteilte Berechnungen ohne die üblichen Nebenläufigkeitskopfschmerzen zu verwenden. Schließlich haben Sie mit Service Fabric den Vorteil, eine vollständigere Entwicklungsumgebung in Ihrer lokalen Box zu haben - Sie müssen sich nicht mit dem Erstellen von Warteschlangen usw. auf einem Azure-Dev-Konto oder Ähnlichem beschäftigen.
Auch beachten Sie, dass Sie beide Paradigmen nicht stoppen können - stellen Sie sich zwei Apps vor, von denen mindestens eine eine Service Fabric-App ist, die APIs und eine Logik-App offen legt.
Ihre Entscheidung sollte darauf basieren, was Sie versuchen zu erstellen, in wie viel Zeit, wann Sie veröffentlichen möchten (Service Fabric ist derzeit nur in der privaten Vorschau, so wird es eine Weile dauern, bis sie GA erhalten) und welche Art von Team Sie haben. Ich kann mir vorstellen, dass es mit dem App Service leicht ist, den Boden zu betreten, selbst wenn Sie kein enorm erfahrenes Team haben, aber Service Fabric gibt Ihnen mehr Power, Flexibilität und Kontrolle.
Danke Charisk, das hilft definitiv. Ich denke, das Hybridmodell ist attraktiv. Ich möchte die Einfachheit und die zusätzlichen Funktionen eines App-Service für meine Web- und API-Apps nutzen, aber ich möchte das Back-End des Systems mithilfe von Service Fabric aufbauen. Ich werde herausfinden, wie man das mehr macht. Hoffentlich gibt es einen Weg, das Beste aus beiden Welten zu machen. :) – StewartArmbrecht
App-Service ist ein Managed Service, SF ist mehr Sie verwalten Ihre eigenen und Sie können auch in Ihren eigenen Räumlichkeiten laufen. SF hat bessere Unterstützung für Nicht-MS-Stack-Entwickler, z. B. native Apps usw.
Wie das Dokument besagt "Service Fabric ist eine gute Wahl, wenn Sie eine neue App erstellen oder eine vorhandene App neu schreiben, um eine Microservice-Architektur zu verwenden . "
Wenn Sie ein paar Apps hosten, sollten Sie nicht auf SF schauen, auf der anderen Seite, wenn Sie mehr als 10 Dienste bereitstellen, als es eine bessere Lösung wird.
Hinweis: SF verfügt über einen Datenspeichermechanismus, der zu den Diensten gehört.Es ist gut bei 3 Dinge 1) Massive Cluster von Daten 2) Einfache Daten, oft in Micros Services DBs werden zu einer schweren Belastung, da jeder Dienst seine eigenen Daten haben sollte und Dinge wie SQL sind etwas übertrieben, wenn Sie nur 1-3 haben Tabellen. 3) Statusspeicher für das Actor-Programmiermodell.
Ich denke, SF und Web-Anwendungen werden die Benutzerbasis "Cloud Service" in der Zukunft schneiden.
Ich glaube nicht, dass es da draußen einen definitiven Leitfaden gibt - es hängt davon ab, was Sie zu bauen versuchen und welche Art von Team Sie haben. Vielleicht können Sie einige dieser Informationen teilen? – charisk
Es ist eine benutzerdefinierte Enterprise-Projekt-Management-Anwendung, die in ein Content-Management-System und mehr erweitern könnte. Es kann leicht mit Standard API und Web Apps erstellt werden, aber ich bin mir nicht sicher, was ich aufgeben würde. Ich mag die Skalierbarkeit des Service Fabric, sowohl hinsichtlich der Leistung als auch der Entwicklung. Ich weiß jedoch nicht, was ich aufgeben würde, wenn ich diesen Ansatz gegenüber dem App-Service-Ansatz verwende. Was ich mir erhofft hatte, war etwas, das die Vor- und Nachteile jedes Ansatzes aufzeigen sollte. Wie entscheidest du zwischen den beiden? – StewartArmbrecht
In diesem Artikel finden Sie nützliche Informationen zum Vergleichen von Azure App Service, virtuellen Maschinen, Service Fabric und Cloud Services - https://docs.microsoft.com/en-us/azure/app-service-web/choose-web-site- cloud-service-vm – mvark