Azure Service Fabric內部服務通信

Question

我目前有一個Service Fabric應用程序，它由多個服務組成。 我想要實現的是一個排隊機制， 因此一個服務可以將消息發布到隊列，另一個服務可以從同一隊列接收消息 。

以下不起作用（對於Listener服務，沒有任何東西可以出列）：

PublisherService ：

protected override async Task RunAsync(CancellationToken cancellationToken)
{
    var myQueue = await StateManager.GetOrAddAsync<IReliableQueue<string>>("fooQueue");
    while (true)
    {
        cancellationToken.ThrowIfCancellationRequested();
        using (var tx = this.StateManager.CreateTransaction())
        {
            // Put some message in the queue
            await myQueue.EnqueueAsync(tx, "Foobar");

            await tx.CommitAsync();
        }

        await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);
    }
}

ListenerService ：

protected override async Task RunAsync(CancellationToken cancellationToken)
{
    var myQueue = await StateManager.GetOrAddAsync<IReliableQueue<string>>("fooQueue");
    while (true)
    {
        cancellationToken.ThrowIfCancellationRequested();
        using (var tx = this.StateManager.CreateTransaction())
        {
            var result = await myQueue.TryDequeueAsync(tx);

            if (result.HasValue)
            {
                ServiceEventSource.Current.ServiceMessage(this.Context, "New message receieved: {0}", result.Value.ToString());
            }

            await tx.CommitAsync();
        }

        await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);
    }
}

看起來隊列的范圍僅限於單個服務 。 這似乎不是文檔中指定的限制。

所以我的問題是：

• 這實際上是一些無證的限制嗎？
• 或者上面的代碼有什么問題嗎？
• 我怎樣才能實現上面的場景（一個服務將消息添加到隊列，另一個服務從同一隊列中檢索消息）？

顯然我可以使用Azure Service Bus，但我不能出於以下幾個原因：

• 在我的實際場景中，我將有幾個隊列（變量號），因此需要按需創建服務總線隊列（這不是一個快速的操作）
• 向另一個Azure服務添加依賴項（因此增加了整個系統的失敗概率）
• 成本更高
• 更復雜的部署
• 等等

Answer 1

ReliableQueues對於服務是本地的，因為它的意圖是存儲該特定服務的狀態。 該狀態被復制到其他實例。 它就像.Net中的普通System.Collections.Generic.Queue<T> 。

對於低成本解決方案，您可以使用Azure存儲隊列 。 是的，它添加了一個依賴項，但它具有高可用性。 這是一個權衡，只有你可以決定接受與否。

另一方面，開箱即用：

創建具有多個ReliableQueues的有狀態服務，並使用stand remoting通信公開其他服務可以調用的方法，如：

class QueuingService
{
    void AddToQueue<T>(string queuename, T input) { .. }
    void DeQueue(string queuename) { .. }
}

這當然會產生依賴性，但它具有Service Fabric提供的所有安全機制，並且不會花費太多。 但話說回來，你自己正在構建一個糟糕的人員服務總線/天藍色存儲隊列。

關於文檔，不是沒有用很多詞來說可靠的隊列與1個服務相關聯，但它取決於你如何解釋這個

Service Fabric通過Reliable Collections為.NET開發人員提供了一種狀態編程模型。 具體而言，Service Fabric提供可靠的字典和可靠的隊列類。 當您使用這些類時， 您的狀態（我的解釋：服務狀態）被分區（用於可伸縮性），復制（用於可用性），並在分區內進行事務處理（用於ACID語義）。

Answer 2

查看為此目的創建的優先級隊列服務 。

Answer 3

如果您為所有調用代碼添加了故障處理重試模式，則在調用之間不需要隊列，請參閱https://docs.microsoft.com/en-us/azure/service-fabric/service-織物可靠的服務通信

該鏈接的相關部分如下：

異常處理程序負責確定發生異常時要采取的操作。 例外分為可重試和非可重試。 不可重試的異常只是重新回放給調用者。 可重試的異常進一步分為瞬態和非瞬態。 瞬態異常是可以在不重新解析服務端點地址的情況下簡單地重試的異常。 這些將包括瞬態網絡問題或服務錯誤響應，而不是指示服務端點地址不存在的響應。 非瞬態異常是需要重新解析服務端點地址的異常。 這些包括指示無法訪問服務端點的異常，指示服務已移至其他節點。