Hi, ich baue einen Cloud-Service, der (im Moment) eine Web- und eine Worker-Rolle hat. Mein gewünschter Workflow wäre: Der Browser ruft einen WebApi-Controller in der Web-Rolle auf, der eine Nachricht an eine Warteschlange (oder Servicebus) sendet, die dann von der Worker-Rolle verarbeitet wird. So weit, ist es gut. Wenn nun die Worker-Rolle die Verarbeitung der Nachricht beendet, möchte ich eine Methode in der Web-Rolle aufrufen, die dann dem Browser signalisiert, dass die Verarbeitung abgeschlossen ist (via SignalR). Bitte entschuldigen Sie, wenn dies nicht der richtige Ort ist, um Fragen zu stellen, da dies mehr wie eine "Best Practice" -Frage ist, sondern eher ein echtes Problem. Ich habe bisher zwei Ansätze betrachtet:
Die Worker-Rolle aktualisiert eine Tabellenzeile (im Tabellenspeicher) mit dem Fortschritt und dem Abschluss der Aufgabe. Es gibt keine Signalisierung für die Webrolle. Der Browser liest den Tabellenspeicher direkt ab (über REST API) und weiß somit, wann die Aufgabe abgeschlossen ist. Das funktioniert gut (ich habe es bereits getestet), obwohl ich den Ansatz des konstanten Abfragens nicht mag und ich möchte eine "ereignisbasierte" Lösung haben. Sobald der Client die Information erhält, dass der Prozess abgeschlossen ist, muss er außerdem einen zusätzlichen Aufruf an eine Web-API-Methode ausführen, um den anderen Clients (über SignalR) mitzuteilen, dass die Operation abgeschlossen wurde.
Interrole-Kommunikation zusammen mit SignalR (siehe Codebeispiel unten) funktioniert auch (bereits getestet)
Codebeispiel:
%Vor%Meine Frage ist: Gibt es andere (bessere) Wege, in Richtung Arbeiterrolle zu kommunizieren - & gt; Webrolle? Das heißt, eine Methode für die Web-Rolle auslösen, wenn eine Worker-Rolle ihre Verarbeitung beendet hat? Die Methode in der Webrolle würde dann das Update über SignalR an alle Clients senden. Ich habe auch einen Blick auf Event Hubs geworfen, aber zu meinem Verständnis würden die Event-Konsumenten immer noch laufen die Arbeiterrolle.
Nach einigen zusätzlichen Versuchen und ein wenig Nachforschungen habe ich eine mögliche Lösung gefunden ... Ich habe diesen Code verwendet
%Vor%in der OnStart-Methode der Web-Rolle (NICHT die Worker-Rolle), so dass ich meine Methode innerhalb der Web-Rolle verweisen konnte (TestSignal () in diesem Fall) aber es stellte sich heraus, dass der IHubContext immer Null war, wenn von innen aufgerufen Dieser OnMessage Event-Handler, da er (sehr wahrscheinlich) zu einer anderen AppDomain gehört, wurde also nicht einmal der statische Hub von SignalR geteilt. Ich habe daher den gleichen ganzen Code in die Global.asax.cs verschoben, so dass er dieselbe AppDomain teilt und jetzt funktioniert. Ich denke, dass ich bei diesem Ansatz bleiben werde, da ich es viel mehr mag als die kontinuierliche Umfrage.
Ich denke, Sie haben bereits genug Wissen und Implementierungserfahrung, um dies zu erreichen. Mit SignalR ist brillanter Ansatz, ich habe von dir gelernt.
Ein anderer, etwas anderer Ansatz: Ich verwende konstantes Polling, indem ich Azure Scheduler in der Reihenfolge verwende um GET message an WebRole zu senden.
IMO, als eine Art Webapi-Server, ist Polling der geeignetste und zuverlässigste Ansatz, um zu verfolgen, welcher Web-Server entworfen wurde.
Etwas zu spät zur Frage :) aber was wir implementiert haben, ist eine Antwortwarteschlange und Sitzungs-IDs anzugeben, auf die die Web-Rolle wartet, nachdem die Nachricht an die Worker-Rolle gesendet wurde. Sie können es optimieren, um zu vermeiden, dass die Antwort blockiert wird, während die Web-Rolle auf die Antwort der Worker-Rolle wartet (in unserem Szenario wollten wir speziell warten)
WebRole
%Vor%Arbeiterrolle
%Vor%Sehen Sie sich auch Jessies Ansatz an , um direkt zur App zu gelangen über HttpClient.
%Vor%Tags und Links azure c# azure-web-roles azure-worker-roles