Hangfire mit mehreren Projekten in .net-Lösung

8

Ich möchte Hangfire in meine asp.net web api und asp.net MVC Website Projekte implementieren.

So habe ich meine Lösung strukturiert:

  

Lösung - Meine Lösung
  1: Modell - (Projekt enthält Entity Framework Objekte und Klassen)
  2: Dienste (Wo ich meine gesamte Geschäftslogik, Änderungen usw. implementiere). Hier werde ich wahrscheinlich HangFire verwenden.

     

3: Web API (mein Asp.net API Projekt)
  4: Web UI (mvc 5 Admin-Schnittstelle Website)

Sowohl das Projekt 3 als auch das Projekt 4 verwenden das Projekt 2:Services , um Arbeiten auszuführen und Dienste aufzurufen, die Geschäftslogik ausführen. Hier werden die meisten Aufgaben ausgegliedert.

Wie würde ich Hangfire implementieren, damit die jeweiligen Iis-Sites beide die gleiche "Instanz" von Hangfire nutzen können? aber es wird natürlich auf den zugehörigen App-Pools laufen?

oder kann es nicht so funktionieren und ich muss es an einem Ort laufen lassen?

Was sind meine Optionen und was ist der empfohlene Ansatz?

    
Zapnologica 22.12.2015, 12:39
quelle

1 Antwort

2

Der größte Nachteil für mich war, dass HangFire nach einem Arbeitspool-Shutdown (d. h. Leerlauf-Timeout) nicht fortfahren wird, was ohnehin mein Kernproblem ist, und empfiehlt, die Serverkonfiguration so zu ändern, dass Arbeitspläne niemals heruntergefahren werden. Wenn Ihre App rund um die Uhr in Betrieb ist, sollte das kein Problem für Sie sein, auch wenn Ihr Arbeits-Pool aus verschiedenen Gründen noch recycelt werden könnte, aber für eine App, die bei Ihnen und bei Ihnen Höhen und Tiefen erlebt Vielleicht möchten Sie einen Out-of-Process-HangFire-Server in Betracht ziehen.

Der Ansatz, den ich mache, ist der spätere. Ich entwickle einen Proof-of-Concept, der einen Windows-Dienst (gebaut mit Topshelf - sehr empfehlenswert hierfür) enthält, auf dem sich der HangFire befindet Server (und Dashboard), eine gemeinsam genutzte Kernbibliothek und ein Client (der meine WebAPI in der Produktion sein wird, aber eine WPF-App für den PoC ist). Der Client reiht einen Job mithilfe einer Klasseninstanz aus der gemeinsam genutzten Bibliothek in die Warteschlange ein, auf die der HangFire-Server ebenfalls zugreifen kann.

Ich nehme von Ihrer Beschreibung an, dass die WebAPI-Controller-Aktionen entsprechende Methoden in der Klasse von der Service-Schicht aufrufen? Wenn dies der Fall ist, würde ich mich für eine ähnliche Lösung entscheiden, da der HangFire Windows-Dienst bei Bedarf Zugriff auf Ihre Dienste und Modelle hat.

Wenn Ihre App stark frequentiert wird und die Wiederverwendung des Arbeitsspeichers Sie nicht stört, würde ich den HangFire-Server direkt in Ihrer WebAPI hosten.

    
Geoff Bennett 08.01.2016 04:56
quelle

Tags und Links