Azure Service Fabric 應用程式設計最佳做法

本文提供在 Azure Service Fabric 上建立應用程式和服務的最佳做法指引。

熟悉 Service Fabric

熟悉 Service Fabric 應用程式的一般架構及其設計考量。

使用 API 閘道服務，與之後可擴增的後端服務通訊。最常使用的 API 閘道服務如下：

建議您一開始一律先使用Reliable Services，並在 Azure 資料庫、Azure Cosmos DB 或 Azure 儲存體中儲存狀態，以建立無狀態服務。將狀態具體化是大部分開發人員比較熟悉的方法。此方法也可讓您利用存放區上的查詢功能。

當您有低延遲且必須讓資料靠近計算的案例時，請考慮使用具狀態服務。一些範例案例包括 IoT 數位對應項裝置、遊戲狀態、工作階段狀態、快取資料庫中的資料，以及長時間執行工作流程來追蹤其他服務的呼叫。

決定資料保留時間範圍：

快取的資料。當外部存放區的延遲是個問題時，請使用快取。使用具狀態服務作為您自己的資料快取，或考慮使用開放原始碼 SoCreate Service Fabric 分散式快取。在此案例中，您不需要擔心是否會遺失快取中的所有資料。
有時間限制的資料。在此案例中，您必須讓資料靠近計算以因應一段時間的延遲，但您可以承受在災難中遺失資料。例如，在許多 IoT 解決方案中，資料必須在計算附近 (例如，計算過去幾天的平均溫度時)，但如果遺失此資料，記錄的特定資料點並不重要。此外，在此案例中，您通常不會在意如何備份個別的資料點。您只會備份定期寫入至外部儲存體的已計算平均值。
長期資料。可靠的集合可以永久儲存您的資料。但在此情況下，您需要為災害復原做好準備，包括設定叢集的定期備份原則。實際上，您應設定當叢集在災害中損毀時會發生什麼事，您將必須在何處建立新的叢集，以及如何部署新的應用程式執行個體並從最新的備份中復原。

節省成本並提升可用性：

您可以使用具狀態服務來降低成本，因為遠端存放區上不會產生資料存取和交易成本，也因為您不需要使用另一個服務 (例如 Azure Cache for Redis)。
將具狀態服務主要用於儲存而不是用於計算的成本很高，因此我們不建議這麼做。請將具狀態服務視為具有便宜本機儲存體的計算。
藉由移除其他服務的相依性，您可以改善服務可用性。使用叢集中的 HA 來管理狀態，可免於受到其他服務停機或延遲問題的影響。

Service Fabric Reliable Services 可讓您輕鬆地建立無狀態和具狀態服務。如需詳細資訊，請參閱 Reliable Services 簡介。

在無狀態和具狀態服務的 RunAsync() 方法中，以及具狀態服務的 ChangeRole() 方法中，一律接受取消權杖。如果您沒有這麼做，Service Fabric 不知道是否可以關閉您的服務。例如，如果您不接受取消權杖，應用程式的升級時間可能會比較長。
及時開啟和關閉通訊接聽程式，並接受取消權杖。
絕對不要將同步程式碼與非同步程式碼混合使用。例如，不要在您的非同步呼叫中使用 .GetAwaiter().GetResult()。一律透過呼叫堆疊使用非同步。

Service Fabric Reliable Actors 可讓您輕鬆地建立具狀態的虛擬執行者。如需詳細資訊，請參閱 Reliable Actors 簡介。

認真地考慮在您的執行者之間使用 pub/sub 傳訊，以縮放應用程式。提供此服務的工具包括開放原始碼 SoCreate Service Fabric Pub/Sub和 Azure 服務匯流排。
儘可能細分執行者狀態。
管理執行者的生命週期。如果您不打算再次使用執行者，請將其刪除。當您使用 volatile 狀態提供者時，刪除不必要的執行者特別重要，因為所有狀態都會儲存在記憶體中。
由於執行者採用回合式並行，因此最適合作為獨立物件使用。請勿建立多執行者的同步方法呼叫群組 (其中每一個呼叫都可能會變成個別的網路呼叫) 或建立迴圈執行者要求。這些會大幅影響效能和規模。
請勿將同步程式碼與非同步程式碼混合使用。一致使用非同步來防止效能問題。
請勿在執行者中進行長時間執行的呼叫。長時間執行的呼叫會封鎖對相同執行者的其他呼叫 (因為回合式並行的關係)。
如果您使用 Service Fabric 遠端處理來與其他服務通訊，而且您要建立 ServiceProxyFactory，請在執行者服務層級建立中心，而不是在執行者層級上建立。

請徹底了解如何在服務呼叫中新增應用程式記錄檔。這將協助您診斷服務彼此呼叫的案例。例如，當 A 呼叫 B 呼叫 C 呼叫 D 時，呼叫可能會在任何位置上失敗。如果您沒有足夠的記錄，則會難以診斷失敗。如果服務因為呼叫量而有太多記錄，請務必至少記錄錯誤和警告。