Durable Functions 的不停機部署

發行項
06/01/2023

Durable Functions 的可靠執行模型需要具決定性的協調流程，這會產生部署更新時要考慮的額外挑戰。當部署包含變更活動函式簽章或協調器邏輯時，則正式發行前小眾測試版協調流程執行個體會失敗。此情況特別適用於長時間執行的協調流程執行個體，這可能代表工作時數或天數。

若要防止這些失敗發生，您有兩個選項：

延遲部署，直到所有正在執行的協調流程執行個體都完成為止。
請確定任何正在執行的協調流程執行個體都使用您函式的現有版本。

下圖比較三個主要策略，以達到 Durable Functions 的不停機部署：

策略	使用時機	優點	缺點
版本控制	不常發生重大變更的應用程式。	易於實作。	增加記憶體中的函數應用程式大小與函式數目。程式碼重複。
位置的狀態檢查	沒有長時間執行之協調流程持續 24 小時以上或經常重疊協調流程的系統。	簡單的程式碼基底。不需要額外的函數應用程式管理。	需要額外的儲存體帳戶或工作中樞管理。需要沒有任何協調流程正在執行的一段時間。
應用程式路由	有一段時間沒有任何協調流程正在執行的系統，例如具有持續 24 小時以上的協調流程或經常重疊協調流程的時間週期。	使用持續執行的協調流程來處理具有重大變更的新版本系統。	需要智慧型應用程式路由器。可能會超過訂閱所允許的函數應用程式數目上限。預設值為 100。

此文件的其餘部分會更詳細地描述這些策略。

注意

這些不停機部署策略的描述假設您使用預設的 Azure 儲存體提供者進行 Durable Functions。若您正在使用預設 Azure 儲存體提供者以外的儲存體提供者，則指引可能不適用。如需各種儲存體提供者選項及相互比較方式的詳細資訊，請參閱 Durable Functions 儲存體提供者文件。

版本控制

定義新版的函式，並將舊版保留在函數應用程式中。如您在圖表中所見，函式的版本會成為其名稱的一部分。因為會保留舊版的函式，所以正式發行前小眾測試版協調流程執行個體可以繼續參考這些函式。同時，新協調流程執行個體的要求會呼叫最新版本，您的協調流程用戶端函式可以從應用程式設定參考。

Versioning strategy

在此策略中，必須複製每個函式，且必須更新其對其他函式的參考。您可以藉由撰寫指令碼來簡化該策略。以下是具有移轉指令碼的範例專案。

注意

此策略會使用部署位置，以避免在部署期間停機。如需如何建立及使用新部署位置的詳細資訊，請參閱 Azure Functions 部署位置。

位置的狀態檢查

當函數應用程式目前版本在生產位置中執行時，請將新版的函數應用程式部署至預備位置。在交換生產與預備位置之前，請先檢查是否有任何正在執行的協調流程執行個體。完成所有協調流程執行個體之後，您就可以執行交換。當您沒有任何協調流程執行個體處於正式發行前小眾測試階段時，此策略非常實用。當協調流程並非長時間執行，且協調流程執行不常重疊時，這是最佳方法。

函數應用程式設定

使用下列程序來設定此案例。

將部署位置新增至預備與生產的函數應用程式。
針對每個位置，將 AzureWebJobsStorage 應用程式設定設定為共用儲存體帳戶的連接字串。 Azure Functions 執行階段會使用此儲存體帳戶連接字串來安全地儲存函式的存取金鑰。
針對每個位置，建立新的應用程式設定，例如 DurableManagementStorage。將其值設定為不同儲存體帳戶的連接字串。 Durable Functions 延伸模組會使用這些儲存體帳戶進行可靠執行。針對每個位置使用個別的儲存體帳戶。請勿將此設定標記為部署位置設定。
在函數應用程式的 host.json 檔案的 durableTask 區段中，將 connectionStringName (Durable 2.x) 或 azureStorageConnectionStringName (Durable 1.x) 指定為您在步驟 3 中所建立的應用程式設定名稱。

下圖顯示部署位置與儲存體帳戶的已描述設定。在此潛在的前置部署案例中，函數應用程式的第 2 版是在生產位置中執行，而第 1 版會保留在預備位置中。

Deployment slots and storage accounts

host.json 範例

下列 JSON 片段是 host.json 檔案中連接字串設定的範例。

Functions 2.0

{
  "version": 2.0,
  "extensions": {
    "durableTask": {
      "hubName": "MyTaskHub",
      "storageProvider": {
        "connectionStringName": "DurableManagementStorage"
      }
    }
  }
}

Functions 1.x

{
  "durableTask": {
    "azureStorageConnectionStringName": "DurableManagementStorage"
  }
}

CI/CD 管線設定

只有當函數應用程式沒有擱置中或正在執行的協調流程執行個體時，才能設定部署 CI/CD 管線。當您使用 Azure Pipelines 時，可以建立檢查這些條件的函式，如下列範例所示：

[FunctionName("StatusCheck")]
public static async Task<IActionResult> StatusCheck(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestMessage req,
    [DurableClient] IDurableOrchestrationClient client,
    ILogger log)
{
    var runtimeStatus = new List<OrchestrationRuntimeStatus>();

    runtimeStatus.Add(OrchestrationRuntimeStatus.Pending);
    runtimeStatus.Add(OrchestrationRuntimeStatus.Running);

    var result = await client.ListInstancesAsync(new OrchestrationStatusQueryCondition() { RuntimeStatus = runtimeStatus }, CancellationToken.None);
    return (ActionResult)new OkObjectResult(new { HasRunning = result.DurableOrchestrationState.Any() });
}

接下來，將預備閘道設定為等候，直到沒有協調流程正在執行為止。如需詳細資訊，請參閱使用閘道發行部署控制

Deployment gate

開始部署之前，Azure Pipelines 會先檢查您的函數應用程式是否有正在執行的協調流程執行個體。

Deployment gate (running)

現在，您函數應用程式的新版本應該已部署至預備位置。

Staging slot

最後，交換位置。

未標記為部署位置設定的應用程式設定也會交換，因此第 2 版應用程式會保留其儲存體帳戶 A 的參考。因為協調流程狀態會在儲存體帳戶中追蹤，所以第 2 版應用程式上執行的任何協調流程都會繼續在新位置中執行，而不會中斷。

Deployment slot

若要針對這兩個位置使用相同的儲存體帳戶，您可以變更工作中樞的名稱。在此情況下，您必須管理位置的狀態與應用程式的 HubName 設定。若要深入了解，請參閱 Durable Functions 中的工作中樞。

應用程式路由

此策略最複雜。然而，其可用於沒有時間執行協調流程的函數應用程式。

針對此策略，您必須在 Durable Functions 前面建立「應用程式路由器」。此路由器可以透過 Durable Functions 來實作。該路由器必須負責：

部署函式應用程式。
管理 Durable Functions 的版本。
將協調流程要求路由至函數應用程式。

第一次收到協調流程要求時，路由器會執行下列工作：

在 Azure 中建立新的函數應用程式。
將函數應用程式的程式碼部署至 Azure 中的新函數應用程式。
將協調流程要求轉送至新的應用程式。

路由器會管理部署至 Azure 中函數應用程式之應用程式程式碼版本的狀態。

Application routing (first time)

路由器會根據與要求一起傳送的版本，將部署與協調流程要求導向適當的函數應用程式。其會忽略修補檔版本。

當您部署新版的應用程式而沒有重大變更時，可以增加修補檔版本。路由器會部署至現有的函數應用程式，並傳送舊版與新版程式碼的要求，其中會將這些程式碼路由至相同的函數應用程式。

Application routing (no breaking change)

當您部署新版的應用程式且具有重大變更時，可以增加主要或次要版本。然後，應用程式路由器會在 Azure 中建立新的函數應用程式、部署至該函數應用程式，並將新版應用程式的要求路由至該函數應用程式。下圖中，在 1.0.1 版的應用程式上執行協調流程會持續執行，但 1.1.0 版的要求會路由至新的函數應用程式。

Application routing (breaking change)

路由器會監視 1.0.1 版上的協調流程狀態，並在所有協調流程完成後移除應用程式。

追蹤存放區設定

每個函數應用程式都應該使用個別的排程佇列，其可能位於個別的儲存體帳戶中。若您想要查詢應用程式所有版本的協調流程執行個體，可以跨函數應用程式共用執行個體與記錄資料表。您可以在 host.json 設定檔案中設定 trackingStoreConnectionStringName 與 trackingStoreNamePrefix 設定來共用資料表，以便全都使用相同的值。

如需詳細資訊，請參閱管理 Azure 中 Durable Functions 的執行個體。

Tracking store settings

下一步

Durable Functions版本設定

共用方式為