Derzeit führen wir eine ressourcenintensive Verarbeitung als Cloud-Service mit einer Web-Rolle aus. Das Servicepaket enthält nur häufig wechselnde .NET-Assemblys. Es gibt auch eine Abhängigkeit zu einem C++ - DCOM-Server, die etwa einen Gigabyte Code und Daten insgesamt aufweist. Dieser DCOM-Server wird in ein Archiv gepackt und in den BLOB-Speicher gestellt. Wenn eine Rolleninstanz gestartet wird, lädt ihr OnStart() das Archiv herunter, entpackt es in das lokale Dateisystem und registriert den DCOM-Server. Der .NET-Code verbraucht dann den DCOM-Server.Wie würde ich einen Azure Cloud-Dienst mit langer Initialisierung sinnvoll in einen Azure Service Fabric-Dienst konvertieren?
Es funktioniert, aber die Skalierung ist ziemlich langsam - es dauert etwa zwei bis fünf Minuten zwischen einem Scale-Out-Vorgang an Azure Management Service gesendet wird und OnStart() ausgeführt wird (und dann dauert es noch eine Minute, OnStart() auszuführen). Ich habe gehört, dass HyperV-Container fast magisch sind, um zu skalieren - sie skalieren fast sofort. Ich habe auch gehört, dass Azure Service Fabric Container zum Hosten von Dienstinstanzen verwendet. Also nehme ich an, dass Azure Service Fabric verwendet werden könnte, um unsere Probleme mit langsamer Skalierung zu lösen.
Die Frage ist - was kann zu diesem langen laufenden Code in OnStart() getan werden. Wenn jede Serviceinstanz diesen Code ausführt, werden Container besiegt - sie würden schnell skalieren und dann mit diesem Initialisierungscode stecken bleiben.
Mit Azure Service Fabric wird eine zweiphasige Initialisierung durchgeführt, bei der zuerst eine Instanz von OnStart() ausgeführt wird, während der Dienst bereitgestellt wird. Anschließend wird eine vollständig initialisierte Instanz schnell "geklont", um den Dienst zu skalieren Nachfrage? Kann es für das beschriebene Szenario etwas besser machen?