服務結構有狀態服務-擴展而不分區？

Question

我計划通過三個步驟將現有的雲整體式Restful Web API服務遷移到Service Fabric。 內存緩存（正在處理）已在我的雲服務中大量使用。

步驟1）將雲服務遷移到具有1個副本和單個分區的SF狀態服務。 緩存代碼保持原樣。 不使用可靠收集。

步驟2） SF整體狀態服務的水平擴展到5個副本和單個分區。 緩存代碼已修改為使用可靠收集。

步驟3）將SF整體服務分解為微服務（無狀態/有狀態）

以上方法更清潔嗎？ 有什么建議嗎？ 有什么缺點嗎？

有關步驟2）SF狀態服務的水平擴展的更多信息

• 我不打算使用SF分區策略，因為我無法想到應用程序中的統一數據分布。
• 通過添加更多副本並且不使用SF狀態服務進行分區，我只是使我的服務更加可靠（可用性）。 我的理解正確嗎？
• 我將修改緩存代碼以使用“可靠集合-字典”。 相同狀態數據將在所有副本中可用。
• 我了解GET可以在任何副本上執行，但是需要在主副本上執行更新/寫入嗎？
• 如何在不分區的情況下擴展SF狀態服務？

• 包括secondory在內的所有副本都可以偵聽我的客戶請求並響應嗎？ GET將能夠執行，PUT＆POST調用如何工作？

• 我是否應該在此步驟中使用外部緩存存儲（Redis）而不是可靠的收集？ 使用無狀態服務？

Answer 1

本文檔很好地概述了用於擴展Service Fabric中特定工作負載的選項，以及一些有關何時使用它們的示例。

選項2（動態或預先創建更多服務實例）聽起來像可以很好地映射到您的工作負載。 您決定使用自定義狀態服務作為緩存還是使用外部存儲取決於以下幾件事：

• 主計算機中是否有足夠的空間來存儲緩存的數據
• 您的服務是否可以通過簡單的緩存擺脫困境，還是需要其他緩存服務提供的更高級功能？
• 您的服務是否需要提高與Web層相同的一組節點中的緩存的性能，或者是否可以承受延遲方面的對遠程服務的調用
• 您是否可以負擔得起緩存服務的費用，或者是否要使用已經通過虛擬機付費的內存，計算和本地存儲來賺錢。
• 是否真的要構建並運行自己的緩存

要回答您的其他一些問題：

• 是的，添加更多副本將增加可用性/可靠性，而不是規模。 實際上，這可能會對性能（寫入）產生負面影響，因為必須將更改寫入更多副本。
• 不能保證所有副本中的狀態數據都是相同的，只是其中大部分是相同的。 某些中學甚至可以領先，這就是為什么不鼓勵從中學讀書的原因。
• 因此，對於您的下一個問題，建議始終對主數據庫執行所有讀寫操作，以便您看到一致的仲裁提交數據。