Service Fabric 應用程式升級：進階主題

在應用程式升級期間新增或移除服務類型

如果將新的服務類型新增至已發行的應用程式作為升級的一部分，則會將新的服務類型新增至已部署的應用程式。 此升級不會影響已包含應用程式的任何服務實例，但必須建立新增服務類型的實例，新服務類型才會生效（參見 New-ServiceFabricService）。

同樣地，服務類型也可以從應用程式移除，作為升級的一部分。 不過，在繼續進行升級之前，必須先移除 to-be移除服務類型的所有服務實例（請參閱 Remove-ServiceFabricService）。

避免在無狀態服務的計畫性停機期間發生連線中斷

對於無狀態執行個體的計畫性停機，例如應用程式/叢集升級或節點停用，執行個體停機後，公開端點會遭到移除，因此連線可能中斷，並導致連線遭到強制關閉。

若要避免這種情況，請在服務組態中新增執行個體關閉延遲持續時間，以設定 RequestDrain 功能，讓叢集內現有的要求得以在公開端點上排空。 其作法是，在關閉執行個體之前、延遲開始前，先移除無狀態執行個體所宣告的端點。 這項延遲可讓現有要求在執行個體實際停機前，順利完成排空。 客戶端會在啟動延遲時透過回呼函式收到端點變更通知，以便重新解析端點，並避免將新的請求發送至即將關閉的實例。 這些請求可能來自使用 反向代理 的客戶端，或是使用帶有通知模型（ServiceNotificationFilterDescription）的服務端點解析 API，以更新端點。

服務組態

有數種方式可以在服務端設定延遲。

  • 建立新的服務時， 請指定 -InstanceCloseDelayDuration：

    New-ServiceFabricService -Stateless [-ServiceName] <Uri> -InstanceCloseDelayDuration <TimeSpan>

  • 在應用程式指令清單的 defaults 區段中定義服務時，請指派 InstanceCloseDelayDurationSeconds 屬性：

          <StatelessService ServiceTypeName="Web1Type" InstanceCount="[Web1_InstanceCount]" InstanceCloseDelayDurationSeconds="15">
          <SingletonPartition />
      </StatelessService>

  • 更新現有的服務時，請指定 -InstanceCloseDelayDuration：

    Update-ServiceFabricService [-Stateless] [-ServiceName] <Uri> [-InstanceCloseDelayDuration <TimeSpan>]`

  • 透過 ARM 範本建立或更新現有服務時，請指定 InstanceCloseDelayDuration 值（最低支援的 API 版本：2020-03-01）：

    {
  "apiVersion": "2020-03-01",
  "type": "Microsoft.ServiceFabric/clusters/applications/services",
  "name": "[concat(parameters('clusterName'), '/', parameters('applicationName'), '/', parameters('serviceName'))]",
  "location": "[variables('clusterLocation')]",
  "dependsOn": [
    "[concat('Microsoft.ServiceFabric/clusters/', parameters('clusterName'), '/applications/', parameters('applicationName'))]"
  ],
  "properties": {
    "provisioningState": "Default",
    "serviceKind": "Stateless",
    "serviceTypeName": "[parameters('serviceTypeName')]",
    "instanceCount": "-1",
    "partitionDescription": {
      "partitionScheme": "Singleton"
    },
    "serviceLoadMetrics": [],
    "servicePlacementPolicies": [],
    "defaultMoveCost": "",
    "instanceCloseDelayDuration": "00:00:30.0"
  }
}

客戶端設定

若要在端點變更時接收通知，客戶端應該註冊回調函數，請參閱 範例 ServiceNotificationFilterDescription。 變更通知表示端點已經變更，客戶端應該重新解析端點，不要使用那些不再公告的端點，因為它們很快就會當機。

選用升級覆寫

除了設定每個服務的預設延遲持續時間之外，您也可以使用相同的選項 (InstanceCloseDelayDurationSec) 來覆蓋應用程式/叢集升級時的延遲。

Start-ServiceFabricApplicationUpgrade [-ApplicationName] <Uri> [-ApplicationTypeVersion] <String> [-InstanceCloseDelayDurationSec <UInt32>]

Start-ServiceFabricClusterUpgrade [-CodePackageVersion] <String> [-ClusterManifestVersion] <String> [-InstanceCloseDelayDurationSec <UInt32>]

覆寫延遲時間僅適用於被呼叫的升級實例，並不會改變個別的服務延遲設定。 例如，您可以用這個方式指定 0 的延遲，以略過任何預先設定的升級延遲。

備註

  • 排空要求的設定，無法防止 Azure 負載平衡器將新的要求傳送至正在排空的端點。
  • 以抱怨為基礎的解決方法機制，不會讓要求順利排空，因為它會在發生失敗後觸發服務解析。 如先前所述，應改為採用 ServiceNotificationFilterDescription 來訂閱端點變更的通知。
  • 若升級屬於無影響升級，也就是升級期間不會讓複本停機，系統就不會採用這些設定。
  • 您可以在服務描述中設定的 InstanceCloseDelayDuration 最大值，或升級描述中的 InstanceCloseDelayDurationSec 不能大於叢集設定 FailoverManager.MaxInstanceCloseDelayDurationInSeconds，預設值為 1800 秒。 若要更新最大值，應更新叢集層級組態。 此設定僅適用於運行時間 9.0 版或更新版本。

備註

當叢集程式代碼版本 7.1.XXX 或更新版本時，可以使用上述 Update-ServiceFabricService Cmdlet 或 ARM 範本，在現有服務中設定此功能。

手動升級模式

備註

建議對所有 Service Fabric 升級使用 受監視 的升級模式。 只有在升級失敗或暫停時，才應考慮使用 UnmonitoredManual 升級模式。

在 受監視 模式中，Service Fabric 會套用健康情況原則，以確保應用程式在升級進行時狀況良好。 如果違反健康情況原則，則會根據指定的 FailureAction 暫停升級，或自動將升級復原。

在 UnmonitoredManual 模式中，應用程式管理員完全控制升級的進展。 套用自定義健康情況評估原則或執行非傳統升級以完全略過健康情況監視時，此模式很有用（例如應用程式已在數據遺失中）。 在此模式下執行的升級，在完成每個 UD 後都會自行暫停，而且您必須明確使用 Resume-ServiceFabricApplicationUpgrade 來繼續。 當使用者暫停升級並準備好繼續升級時，其升級狀態會顯示 RollforwardPending （請參閱 UpgradeState）。

最後， UnmonitoredAuto 模式對於在服務開發或測試期間執行快速升級反覆專案很有用，因為不需要使用者輸入，也不會評估任何應用程式健康情況原則。

使用差異套件升級

除了布建完整的應用程式套件之外，也可以布建只包含更新程式代碼/組態/資料套件的 diff 套件，以及完整的應用程式指令清單和完整的服務指令清單來執行升級。 只有將應用程式初始安裝到叢集時，才需要完整的應用程式套件。 後續升級可以使用完整應用程式套件，也可以使用差異套件。

如果差異套件中的應用程式資訊清單或服務資訊清單參考的內容，在應用程式套件中找不到，系統就會自動以目前已佈建的版本替換。

使用差異套件的案例包括：

  • 當您擁有一個大型應用程式包，此包參考多個服務清單檔案和/或多個程式包、組態包或資料包時。
  • 當您有部署系統直接從應用程式建置程式產生組建配置時。 在此情況下，即使程式代碼尚未變更，新建的元件仍會取得不同的總和檢查碼。 使用完整的應用程式套件會要求您在所有程式碼套件上更新版本。 使用差異套件時，您只需提供已變更的檔案，以及版本已變更的資訊清單檔案。

使用 Visual Studio 升級應用程式時，會自動發佈差異套件。 若要手動建立差異套件，必須更新應用程式指令清單和服務指令清單，但只有變更的套件應該包含在最終的應用程式套件中。

例如，讓我們從下列應用程式開始（提供的版本號碼以方便瞭解）：

app1           1.0.0
  service1     1.0.0
    code       1.0.0
    config     1.0.0
  service2     1.0.0
    code       1.0.0
    config     1.0.0

假設您只想使用差異套件更新 service1 的程式碼套件。 更新的應用程式有下列版本變更：

app1           2.0.0      <-- new version
  service1     2.0.0      <-- new version
    code       2.0.0      <-- new version
    config     1.0.0
  service2     1.0.0
    code       1.0.0
    config     1.0.0

在此情況下，您會將應用程式指令清單更新為 2.0.0，而 service1 的服務指令清單會反映程式代碼套件更新。 應用程式封裝的資料夾會有下列結構：

app1/
  service1/
    code/

換句話說，通常會建立完整的應用程式套件，然後移除版本未變更的任何程式代碼/設定/數據封裝資料夾。

獨立升級應用程式參數而不受版本影響

有時候，不需要變更指令清單版本，即可變更 Service Fabric 應用程式的參數。 這可以使用 -ApplicationParameter 旗標搭配 Start-ServiceFabricApplicationUpgrade 的 Azure Service Fabric PowerShell cmdlet 來方便地完成。 假設 Service Fabric 應用程式具有下列屬性：

PS C:\> Get-ServiceFabricApplication -ApplicationName fabric:/Application1

ApplicationName        : fabric:/Application1
ApplicationTypeName    : Application1Type
ApplicationTypeVersion : 1.0.0
ApplicationStatus      : Ready
HealthState            : Ok
ApplicationParameters  : { "ImportantParameter" = "1"; "NewParameter" = "testBefore" }

現在，使用 Start-ServiceFabricApplicationUpgrade Cmdlet 升級應用程式。 此範例會顯示受監視的升級，但也可以使用未受監視的升級。 若要查看此 Cmdlet 所接受之旗標的完整描述，請參閱 Azure Service Fabric PowerShell 模組參考

PS C:\> $appParams = @{ "ImportantParameter" = "2"; "NewParameter" = "testAfter"}

PS C:\> Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/Application1 -ApplicationTypeVers
ion 1.0.0 -ApplicationParameter $appParams -Monitored

升級之後，請確認應用程式具有更新的參數和相同的版本：

PS C:\> Get-ServiceFabricApplication -ApplicationName fabric:/Application1

ApplicationName        : fabric:/Application1
ApplicationTypeName    : Application1Type
ApplicationTypeVersion : 1.0.0
ApplicationStatus      : Ready
HealthState            : Ok
ApplicationParameters  : { "ImportantParameter" = "2"; "NewParameter" = "testAfter" }

復原應用程式升級

雖然升級可以以三種模式之一向前執行（Monitored、UnmonitoredAuto 或 UnmonitoredManual），但只能以 UnmonitoredAuto 或 UnmonitoredManual 模式回滾。 在 UnmonitoredAuto 模式中復原的運作方式與向前復原的方式相同，但 UpgradeReplicaSetCheckTimeout 的預設值不同，請參閱 應用程式升級參數。 在 UnmonitoredManual 模式下復原的方式，與向前升級相同：復原在完成每個 UD 後都會自行暫停，而且您必須明確使用 Resume-ServiceFabricApplicationUpgrade，才能繼續復原。

當採用監視模式、且 FailureAction 設為 Rollback 的升級違反健康情況原則時，系統可以自動觸發復原 (請參閱應用程式升級參數)，或者您也可以明確使用 Start-ServiceFabricApplicationRollback 觸發復原。

在復原期間，您仍可隨時使用 Update-ServiceFabricApplicationUpgrade 變更 UpgradeReplicaSetCheckTimeout 的值和模式。

後續步驟

使用 Visual Studio 升級應用程式 會逐步引導您使用 Visual Studio 進行應用程式升級。

使用 PowerShell 升級應用程式 會逐步引導您使用 PowerShell 升級應用程式。

使用 升級參數控制應用程序升級的方式。

瞭解如何使用 資料串行化，讓您的應用程式升級相容。

藉由參考針對應用程式升級進行 疑難解答中的步驟，修正應用程式升級的常見問題。

  • 上次更新時間：