Businstanzen Lebenszyklus und Best Practices [geschlossen]

Question

Geschlossen.Diese Frage ist meinungsbasiert.Derzeit werden keine Antworten akzeptiert.

---

Möchten Sie diese Frage verbessern? Aktualisieren Sie die Frage, damit sie mit Fakten und Zitaten beantwortet werden kann diesen Beitrag bearbeiten.

Geschlossen vor 5 Jahren.

Bei der Bewertung von Warteschlangenmechanismen im Allgemeinen und Rebus im Besonderen bin ich auf die folgenden Fragen zum Lebenszyklus von Businstanzen gekommen:

1. Wenn Sie von mehreren WCF-Diensten, die auf einem Windows-Dienst gehostet werden, Zugriff auf die Bus-Instanz (unidirektionaler Client-Modus) benötigen, ist die einzige Instanziierungsoption der Singleton-Modus?

2. Es gibt eine Möglichkeit, einen Bus anzuhalten (das Versenden von Nachrichten an die Nachrichtenhandler zu stoppen?) und ihn dann erneut zu starten. Oder die einzige Möglichkeit besteht darin, ihn zu entsorgen und einen neuen zu erstellen.

   • Ein Anwendungsfall hierfür ist, wenn Sie eine Verbindung zu Systemen herstellen, die Durchsatzbeschränkungen oder Beschränkungen für Transaktionen pro Stunde haben.

3. Können Sagen mehrere Arbeiter haben, wenn ja und unter der Annahme, dass die Ereignisse in der richtigen Reihenfolge gesendet wurden (Initiator zuerst), gibt es eine Möglichkeit zu gewährleisten, dass der Initiator zuerst behandelt wird, der für die Erstellung der Saga zuständig ist, bevor die folgenden Ereignisse behandelt werden mit mehreren Arbeitern?

4. Wenn im selben Host mehrere Businstanzen verwendet werden und wir innerhalb eines Nachrichtenhandlers send auf einer anderen Businstanz basierend auf derselben Konfiguration aufrufen.Die Korrelations-ID wird nicht übertragen und Dinge wie Antworten funktionieren nicht richtig, oder?

Ich bevorzuge konkrete Antworten darauf, wie Rebus dies unterstützen könnte oder nicht, mit Codeverweisen/Beispielen.

Answer 1

1:Es ist ganz einfach:Die Businstanz (d. h.Die Implementierung von IBus Das wird in den Behälter gegeben und Ihnen ausgehändigt, wenn Sie das tun Configure.With(...) Konfigurationszauber) soll eine Singleton-Instanz sein, die Sie für die gesamte Lebensdauer Ihrer Anwendung behalten.

Sie können zwar problemlos mehrere Instanzen erstellen, dies wäre jedoch nur für das Hosten mehrerer Rebus-Endpunkte im selben Prozess nützlich.

IOW ist der Bus vollständig wiedereintrittsfähig und kann sicher von Threads in Ihrer Webanwendung gemeinsam genutzt werden.

2:Nicht ohne weiteres, nein – zumindest nicht in einer Weise, die von der öffentlichen API unterstützt wird.Du dürfen mach das aber: ((RebusBus)bus).SetNumberOfWorkers(0) (d. h.wirf das IBus Instanz zu RebusBus und ändern Sie die Anzahl der Worker-Threads), wodurch blockiert wird, bis die Anzahl der Worker auf die gewünschte Anzahl angepasst wurde.

Auf diese Weise können Sie tatsächlich das erreichen, was Sie anstreben.Es handelt sich lediglich (noch) nicht um ein offizielles Feature von Rebus, aber es könnte in der Zukunft dazu kommen.Ich kann jedoch garantieren, dass die Möglichkeit, die Anzahl der Worker zur Laufzeit anzupassen, nicht verschwinden wird.

3:Ja, Sagen werden durch ein optimistisches Parallelitätsschema geschützt, unabhängig davon, welche Persistenzschicht Sie wählen.Wenn Sie sich nicht sicher sind, welche Art von Nachricht zuerst in Ihrer Saga eintrifft, sollten Sie Ihre Saga diesbezüglich tolerant gestalten – d. h.einfach umsetzen IAmInitiatedBy<> für jeden potenziell initiierenden Nachrichtentyp und sorgen Sie dafür, dass die Saga damit richtig umgeht.

(ziemlich) tolerant gegenüber Nachrichten außerhalb der Reihenfolge zu sein, ist ein gutes allgemeines Robustheitsprinzip, das Ihnen auch dann gute Dienste leistet, wenn Nachrichten erneut zugestellt werden, nachdem sie eine Weile in einer Fehlerwarteschlange verblieben sind.

4:Rebus greift den aktuellen Nachrichtenkontext auf, auch wenn Sie mehrere Businstanzen verwenden, da es eine verwendet „Umgebungskontext“ (d. h.A MessageContext Instanz, die im Arbeitsthread gemountet ist), um zu erkennen, dass Sie eine Nachricht aus einem Handler heraus senden, was wiederum dazu führt, dass die Korrelations-ID der verarbeiteten Nachricht in alle ausgehenden Nachrichten kopiert wird.

Daher bus.Reply wird auch funktionieren.

Aber wie ich in (1) festgestellt habe, ist die Businstanz vollständig wiedereintrittsfähig und es besteht keine Notwendigkeit, mehrere Instanzen zu haben, es sei denn, es handelt sich tatsächlich um logisch unterschiedliche Endpunkte.

Ich hoffe, das beantwortet deine Fragen :)