nservicebus sagas - 試圖了解目的和利益

Question

我已多次閱讀網站上的文檔。 我一遍又一遍地閱讀相同的文章，我無法理解他們想要用傳奇來實現的目標。 此外，互聯網上幾乎沒有與此主題相關的資源。

但我完全陷入了試圖理解定義所謂的傳奇的目的和好處。 我理解處理程序（IHandleMessages） - 這些是攔截器。 但我無法理解佐賀的用途。 文檔中的語言假設我應該知道一些特別的東西來掌握這個想法，但我不這樣做。

有人可以用簡單的語言向我解釋，希望以現實生活中的例子說明我必須或應該定義Saga的情況，這樣做有什么好處？ 我創建了一個具有多個端點和Saga定義的應用程序，如示例中所示，它可以工作（我猜）但我不明白這些傳奇是如何定義的......在許多示例中，他們在Saga類中使用RequestTimeout（）方法。 為什么，為什么有人想故意造成超時？ 我不想在這里放任何代碼片段，因為它無關，我需要理解為什么我會想要使用“Sagas”無論那意味着什么？

謝謝。

Answer 1

NServiceBus Saga是Enterprise Integration Patterns 一書中描述的Process Manager的變體。

要了解何時使用Saga，必須要有它。 假設您只使用常規消息處理程序來實現新的用戶注冊過程。 在某個時間點，您發現只有40％的全新注冊人確認其電子郵件地址並成為活躍的用戶帳戶。 您有兩件事需要解決。

1. 提醒新注冊人在注冊后24小時內發送提醒確認其電子郵件。
2. 在48小時內從數據存儲中刪除注冊人信息（例如電子郵件）以符合GDPR 。

現在，如何使用常規消息處理程序執行此操作？ 處理程序將通過生成帶有確認鏈接的電子郵件來接收初始請求（第一條消息，m1）以啟動注冊。 一旦處理程序完成，它就完成了。 但是你的過程還沒有完成。 這是一個長期運行的邏輯過程，必須在完成之前的48小時內完成。 它不再僅僅是單個消息處理，而是此時的工作流程。 具有多個檢查點的工作流程。 類似於狀態機。 要從一種狀態轉移到另一種狀態，必須滿足某種條件。 在NServiceBus的情況下，那些將是消息。 任何用戶操作都不會觸發24小時后發送提醒的消息（讓我們稱之為m2）。 這是一個“系統”消息。 應該自動啟動的定時消息。 如果未激活驗證鏈接，則指示系統刪除注冊人信息的消息也是如此。 可以觀察到主題：需要在將來安排消息以重新保持工作流程，並從上次離開的狀態繼續。

這就是超時。 這些是從最后一次在某個時間點 - 幾分鍾，幾小時，幾天，幾個月，幾年的時間點 - 重新保持/繼續傳奇/工作流程的請求。

這就是這種工作流程看起來像一個傳奇（過於簡化並且不考慮所有邊緣情況）。

class RegistrationWorkflow : 
  Saga<WorkflowState>,
  IAmStartedByMessages<RegisterUser>,
  IHandleMessages<ActivationReceived>,
  IHandleTimeouts<NoResponseFor24Hours>,
  IHandleTimeouts<NoResponseFor48Hours>
{
  protected override void ConfigureHowToFindSaga(SagaPropertyMapper<WorkflowState> mapper)
  {
    // omitted for simplicity, see message correlation
    // https://docs.particular.net/nservicebus/sagas/message-correlation
  }

  public async Task Handle(RegisterUser message, IMessageHandlerContext context)
  {
    Data.RegistrationId = message.RegistrationEmail;

    await RequestTimeout<NoResponseFor24Hours>(context, TimeSpan.FromHours(24));
  }

  public async Task Handle(ActivationReceived message, IMessageHandlerContext context)
  {
    Data.ConfirmationReceived = true;

    // email was confirmed and account was activated
    await context.Send(new PromoteCandidateToUser 
    { 
      CandidateEmail = Data.RegistrationEmail 
    });

    MarkAsComplete()
  }

  public async Task Timeout(NoResponseFor24Hours timeout, IMessageHandlerContext context)
  {
    if (Data.ConfirmationReceived)
    {
      return;
    }

    await context.Send(new SendReminderEmailToActivateAccount { Email = Data.RegistrationEmail });        

    await RequestTimeout(context, TimeSpan.FromHours(24), new NoResponseFor48Hours());
  }

  public async Task Timeout(NoResponseFor48Hours timeout, IMessageHandlerContext context)
  {
    if (Data.ConfirmationReceived)
    {
      return;
    }

    context.Send(new CleanupRegistrationInformationForGDPRCompliancy 
    { 
      RegistrationEmail = Data.RegistrationEmail 
    });

    MarkAsComplete();
  }
}

由於這是一個狀態機，因此狀態在Saga調用之間保持不變。 調用將由saga可以處理的消息（ RegisterUser和ActivationReceived ）或由到期的超時（ NoResponseFor24Hours和NoResponseFor48Hours ）引起。 對於這個特定的傳奇，州由以下POCO定義：

class WorkflowState : ContainSagaData
{
  public string RegistrationEmail { get; set; }
  public bool ConfirmationReceived { get; set; }
}

超時只不過是普通的IMessage延遲了。 這個樣本中使用的超時時間是

class NoResponseFor24Hours : IMessage {}
class NoResponseFor48Hours : IMessage {}

希望這明確的想法傳奇故事一般，什么超時 ，以及它們是如何使用的。 我沒有進入Message Correlation ， Saga Concurrency和其他一些細節，因為這些可以在你提到的文檔站點找到。 這將我們帶到下一點。

我已經多次閱讀他們網站上的文檔。 這絕對是可怕的。 我一遍又一遍地閱讀相同的文章，我無法理解他們想要實現的目標。

該網站有一個您絕對應該提供的反饋機制。

此外，互聯網上幾乎沒有與此主題相關的資源。

希望看到您在此主題上發布博客（或一系列帖子）。 通過這樣做，你將有積極的貢獻。

完整免責聲明 ：我在NServiceBus上工作