asp.net core - 長時間運行的進程輪詢其他有界上下文事件發件箱

Question

我正在構建一個遵循 DDD 模式的應用程序，每個 AR 都將其事件發件箱保存到永久存儲中。 該商店由對事件感興趣的其他部分進行輪詢。

整個應用程序是面向用戶的，所以基本的基礎設施是 asp.net web api。

現在，我想避免讓我的域工件分布在不同的流程/基礎設施選項中。 例如，偵聽事件存儲並根據接收到的事件執行邏輯的 Azure 函數。

將 web api 和事件消費者放在同一個容器中似乎很方便。 原因是域工件與 api 和事件消費者基礎設施一起部署。

我讀到IHostedService可能是它的一種選擇，因為它可以作為長時間運行的后台進程運行。

問題是， IHostedService適用於這種對事件發件箱做出反應的特定場景？ 還是我遺漏了一些重要的缺點和更好的基礎設施選擇？

Answer 1

一般來說，我認為使用托管服務來運行后台工作者沒有任何問題。

我對“來自其他有界上下文的輪詢”部分持懷疑態度。 我至少會擔心這是否會破壞我的上下文的封裝（類似於從上下文持久性中讀取“外部”組件）。 但在您的情況下，情況可能並非如此。

無論如何，如果您只想保證您的事件可靠地傳輸，我寧願確保每個實現特定有界上下文的組件（例如微服務或單體組件）將這些事件推送到感興趣的消費者能夠獲取它們的地方。

因此，如果是關於傳出事件的可靠傳輸，我會建議使用事務發件箱模式，也許結合發布-訂閱方法。

當您使用 .net 堆棧時，您可能會對NServiceBus的發件箱功能感興趣。

Answer 2

這是一個關於實現 IHostedService 的鏈接。）。

事實上， IHostedService 是通過兩種方法為您的場景長時間運行進程的好方法。 請務必注意，您部署 ASP.NET Core WebHost 或 .NET Host 的方式可能會影響最終解決方案。 例如，如果您在 IIS 或常規 Azure 應用服務上部署 WebHost，您的主機可能會因應用池回收而關閉。 但是，如果您將主機作為容器部署到 Kubernetes 之類的編排器中，則可以控制主機的有保證的活動實例數量。 此外，您可以考慮雲中專為這些場景設計的其他方法，例如 Azure Functions。 最后，如果您需要該服務一直運行並部署在 Windows Server 上，您可以使用 Windows 服務。

但即使對於部署到應用程序池中的 WebHost，也存在重新填充或刷新應用程序的內存緩存等場景仍然適用。

IHostedService 接口提供了一種在 ASP.NET Core Web 應用程序（在 .NET Core 2.0 和更高版本中）或在任何進程/主機（從 .NET Core 2.1 和 IHost 開始）中啟動后台任務的便捷方法。 它的主要好處是您有機會在主機本身關閉時通過優雅的取消來清理后台任務的代碼。