Durable Functions 是什麼?What are Durable Functions?

Durable FunctionsAzure Functions 的擴充功能,可讓您在無伺服器計算環境中撰寫具狀態函式。Durable Functions is an extension of Azure Functions that lets you write stateful functions in a serverless compute environment. 此擴充功能可讓您使用 Azure Functions 程式設計模型,藉由撰寫協調器函式**來定義具狀態的工作流程,以及撰寫實體函式**來定義具狀態的實體。The extension lets you define stateful workflows by writing orchestrator functions and stateful entities by writing entity functions using the Azure Functions programming model. 擴充功能其實會為您管理狀態、檢查點和重新啟動,讓您將焦點放在商務邏輯。Behind the scenes, the extension manages state, checkpoints, and restarts for you, allowing you to focus on your business logic.

支援的語言Supported languages

Durable Functions 目前支援下列語言:Durable Functions currently supports the following languages:

  • C#預先編譯的類別庫C# 指令碼C#: both precompiled class libraries and C# script.
  • JavaScript:只有 2.x 版的 Azure Functions 執行階段才支援。JavaScript: supported only for version 2.x of the Azure Functions runtime. 需要 1.7.0 版的 Durable Functions 擴充功能,或更新版本。Requires version 1.7.0 of the Durable Functions extension, or a later version.
  • Python:需要 1.8.5 版的 Durable Functions 擴充功能,或更新版本。Python: requires version 1.8.5 of the Durable Functions extension, or a later version. Durable Functions 的支援目前處於公開預覽狀態。Support for Durable Functions is currently in public preview.
  • F#:預先編譯的類別庫和 F# 指令碼。F#: precompiled class libraries and F# script. 只有 1.x 版的 Azure Functions 執行階段才支援 F# 指令碼。F# script is only supported for version 1.x of the Azure Functions runtime.
  • PowerShell:Durable Functions 的支援目前處於公開預覽狀態。PowerShell: support for Durable Functions is currently in public preview. 只有 3.x 版的 Azure Functions 執行階段和 PowerShell 7 才支援。Supported only for version 3.x of the Azure Functions runtime and PowerShell 7. 需要 2.2.2 版的 Durable Functions 擴充功能,或更新版本。Requires version 2.2.2 of the Durable Functions extension, or a later version. 目前僅支援以下模式:函式鏈結展開傳送/傳入非同步 HTTP APIOnly the following patterns are currently supported: Function chaining, Fan-out/fan-in, Async HTTP APIs.

Durable Functions 的目標是支援所有的 Azure Functions 語言Durable Functions has a goal of supporting all Azure Functions languages. 請參閱 Durable Functions 問題清單,以取得最新工作狀態來支援其他語言。See the Durable Functions issues list for the latest status of work to support additional languages.

如同 Azure Functions,有一些範本可協助您使用 Visual Studio 2019Visual Studio CodeAzure 入口網站開發 Durable Functions。Like Azure Functions, there are templates to help you develop Durable Functions using Visual Studio 2019, Visual Studio Code, and the Azure portal.

應用程式模式Application patterns

Durable Functions 主要用來簡化無伺服器應用程式中複雜的具狀態協調需求。The primary use case for Durable Functions is simplifying complex, stateful coordination requirements in serverless applications. 下列各節會說明可受惠於 Durable Functions 的典型應用程式模式:The following sections describe typical application patterns that can benefit from Durable Functions:

模式 #1:函式鏈結Pattern #1: Function chaining

在函式鏈結模式中,有一連串的函式會依特定順序執行。In the function chaining pattern, a sequence of functions executes in a specific order. 在此模式中,一個函式的輸出會套用至另一個函式的輸入。In this pattern, the output of one function is applied to the input of another function.

模式鏈結模式的圖表

您可以使用 Durable Functions 簡潔地實作如下列範例所示的函式鏈結模式。You can use Durable Functions to implement the function chaining pattern concisely as shown in the following example.

在此範例中,F1F2F3F4 值是相同函式應用程式中其他函式的名稱。In this example, the values F1, F2, F3, and F4 are the names of other functions in the same function app. 您可以使用一般命令式編碼建構來實作控制流程。You can implement control flow by using normal imperative coding constructs. 程式碼會由上而下地執行。Code executes from the top down. 程式碼可包含現有語言的控制流程語意,例如條件和迴圈。The code can involve existing language control flow semantics, like conditionals and loops. 您可以在 try/catch/finally 區塊中包含錯誤處理邏輯。You can include error handling logic in try/catch/finally blocks.

[FunctionName("Chaining")]
public static async Task<object> Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    try
    {
        var x = await context.CallActivityAsync<object>("F1", null);
        var y = await context.CallActivityAsync<object>("F2", x);
        var z = await context.CallActivityAsync<object>("F3", y);
        return  await context.CallActivityAsync<object>("F4", z);
    }
    catch (Exception)
    {
        // Error handling or compensation goes here.
    }
}

您可以使用 context 參數依名稱叫用其他函式、傳遞參數,以及傳回函式輸出。You can use the context parameter to invoke other functions by name, pass parameters, and return function output. 每當程式碼呼叫 await 時,Durable Functions 架構便會對目前函式執行個體的進度設定檢查點。Each time the code calls await, the Durable Functions framework checkpoints the progress of the current function instance. 如果處理序或虛擬機器在執行途中回收,函式執行個體便會從先前的 await 呼叫繼續執行。If the process or virtual machine recycles midway through the execution, the function instance resumes from the preceding await call. 如需詳細資訊,請參閱下一節,模式 #2:展開傳送/收合傳送。For more information, see the next section, Pattern #2: Fan out/fan in.

模式 #2:展開傳送/收合傳送Pattern #2: Fan out/fan in

在展開傳送/收合傳送模式中,您會以平行方式執行多個函式,然後等候所有函式完成。In the fan out/fan in pattern, you execute multiple functions in parallel and then wait for all functions to finish. 某些彙總工作通常會在函式傳回結果時執行。Often, some aggregation work is done on the results that are returned from the functions.

展開傳送/收合傳送模式的圖表

在標準函式中,您可藉由讓函式傳送多則訊息給佇列來進行展開傳送。With normal functions, you can fan out by having the function send multiple messages to a queue. 反過來的收合傳送則困難得多。Fanning back in is much more challenging. 若要收合傳送,您可撰寫程式碼來追蹤佇列所觸發的函式何時結束,然後儲存函式輸出。To fan in, in a normal function, you write code to track when the queue-triggered functions end, and then store function outputs.

Durable Functions 擴充功能會以較簡單的程式碼處理此模式:The Durable Functions extension handles this pattern with relatively simple code:

[FunctionName("FanOutFanIn")]
public static async Task Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    var parallelTasks = new List<Task<int>>();

    // Get a list of N work items to process in parallel.
    object[] workBatch = await context.CallActivityAsync<object[]>("F1", null);
    for (int i = 0; i < workBatch.Length; i++)
    {
        Task<int> task = context.CallActivityAsync<int>("F2", workBatch[i]);
        parallelTasks.Add(task);
    }

    await Task.WhenAll(parallelTasks);

    // Aggregate all N outputs and send the result to F3.
    int sum = parallelTasks.Sum(t => t.Result);
    await context.CallActivityAsync("F3", sum);
}

展開傳送工作會散發至 F2 函式的多個執行個體。The fan-out work is distributed to multiple instances of the F2 function. 此工作是使用動態的工作清單進行追蹤。The work is tracked by using a dynamic list of tasks. 系統會呼叫 Task.WhenAll 以等候所有已呼叫的函式完成。Task.WhenAll is called to wait for all the called functions to finish. 然後,F2 函式的輸出會從動態工作清單彙總起來並傳遞給 F3 函式。Then, the F2 function outputs are aggregated from the dynamic task list and passed to the F3 function.

Task.WhenAllawait 呼叫發生的自動檢查點作業,可確保可能的中途當機或重新開機不需要重新啟動已完成的工作。The automatic checkpointing that happens at the await call on Task.WhenAll ensures that a potential midway crash or reboot doesn't require restarting an already completed task.

注意

在少數的情況下,在活動函式完成後,但將其完成儲存到協調流程歷程記錄前的空窗期中可能會發生損毀。In rare circumstances, it's possible that a crash could happen in the window after an activity function completes but before its completion is saved into the orchestration history. 如果發生這種情況,則會在程序復原之後從頭重新執行活動函式。If this happens, the activity function would re-run from the beginning after the process recovers.

模式 #3:非同步的 HTTP APIPattern #3: Async HTTP APIs

非同步 HTTP API 模式會處理與外部用戶端協調長時間執行作業狀態的問題。The async HTTP API pattern addresses the problem of coordinating the state of long-running operations with external clients. 實作為此模式的常見方式是讓 HTTP 端點觸發長時間執行的動作。A common way to implement this pattern is by having an HTTP endpoint trigger the long-running action. 然後,將用戶端重新導向至用戶端輪詢的狀態端點,以了解作業完成的時間。Then, redirect the client to a status endpoint that the client polls to learn when the operation is finished.

HTTP API 模式的圖表

Durable Functions 會提供此模式的內建支援,進而簡化或甚至移除您需要撰寫的程式碼,以與長時間執行的函式執行作業互動。Durable Functions provides built-in support for this pattern, simplifying or even removing the code you need to write to interact with long-running function executions. 例如,Durable Functions 快速入門範例 (C#JavaScript) 會顯示一個簡單的 REST 命令,您可將此命令用來啟動新的協調器函式執行個體。For example, the Durable Functions quickstart samples (C# and JavaScript) show a simple REST command that you can use to start new orchestrator function instances. 在執行個體啟動後,擴充功能就會公開 Webhook HTTP API 來查詢協調器函式的狀態。After an instance starts, the extension exposes webhook HTTP APIs that query the orchestrator function status.

下列範例顯示 REST 命令,這些命令可啟動協調器及查詢其狀態。The following example shows REST commands that start an orchestrator and query its status. 為了清楚起見,此範例省略了一些通訊協定詳細資料。For clarity, some protocol details are omitted from the example.

> curl -X POST https://myfunc.azurewebsites.net/api/orchestrators/DoWork -H "Content-Length: 0" -i
HTTP/1.1 202 Accepted
Content-Type: application/json
Location: https://myfunc.azurewebsites.net/runtime/webhooks/durabletask/instances/b79baf67f717453ca9e86c5da21e03ec

{"id":"b79baf67f717453ca9e86c5da21e03ec", ...}

> curl https://myfunc.azurewebsites.net/runtime/webhooks/durabletask/instances/b79baf67f717453ca9e86c5da21e03ec -i
HTTP/1.1 202 Accepted
Content-Type: application/json
Location: https://myfunc.azurewebsites.net/runtime/webhooks/durabletask/instances/b79baf67f717453ca9e86c5da21e03ec

{"runtimeStatus":"Running","lastUpdatedTime":"2019-03-16T21:20:47Z", ...}

> curl https://myfunc.azurewebsites.net/runtime/webhooks/durabletask/instances/b79baf67f717453ca9e86c5da21e03ec -i
HTTP/1.1 200 OK
Content-Length: 175
Content-Type: application/json

{"runtimeStatus":"Completed","lastUpdatedTime":"2019-03-16T21:20:57Z", ...}

Durable Functions 執行階段會為您管理狀態,因此您不必實作自己的狀態追蹤機制。Because the Durable Functions runtime manages state for you, you don't need to implement your own status-tracking mechanism.

Durable Functions 擴充功能會公開內建 HTTP API,該 API 可管理長時間執行的協調流程。The Durable Functions extension exposes built-in HTTP APIs that manage long-running orchestrations. 您也可以使用自己的函式觸發程式 (例如 HTTP、佇列或 Azure 事件中樞) 和協調流程用戶端繫結,自行執行此模式。You can alternatively implement this pattern yourself by using your own function triggers (such as HTTP, a queue, or Azure Event Hubs) and the orchestration client binding. 例如,您可以使用佇列訊息來觸發終止。For example, you might use a queue message to trigger termination. 或者,您可以使用由 Azure Active Directory 驗證原則保護的 HTTP 觸發程序,而不是使用內建 HTTP API (其使用產生的金鑰進行驗證)。Or, you might use an HTTP trigger that's protected by an Azure Active Directory authentication policy instead of the built-in HTTP APIs that use a generated key for authentication.

如需詳細資訊,請參閱 HTTP 功能一文,其中說明如何使用 Durable Functions 擴充功能,透過 HTTP 公開非同步、長時間執行的程序。For more information, see the HTTP features article, which explains how you can expose asynchronous, long-running processes over HTTP using the Durable Functions extension.

模式 #4:監視Pattern #4: Monitor

監視模式是指工作流程中有彈性的週期性程序。The monitor pattern refers to a flexible, recurring process in a workflow. 範例會輪詢直到符合特定條件為止。An example is polling until specific conditions are met. 您可以一般計時器觸發程序來解決基本案例,例如定期清除作業,但其間隔是靜態的,且管理執行個體存留期會變得很複雜。You can use a regular timer trigger to address a basic scenario, such as a periodic cleanup job, but its interval is static and managing instance lifetimes becomes complex. 您可以使用 Durable Functions 來建立有彈性的週期間隔、管理工作存留期,以及從單一協調流程建立多個監視程序。You can use Durable Functions to create flexible recurrence intervals, manage task lifetimes, and create multiple monitor processes from a single orchestration.

監視模式的範例是反轉先前的非同步 HTTP API 案例。An example of the monitor pattern is to reverse the earlier async HTTP API scenario. 長期執行的監視器會取用外部端點,而後等待狀態變更,而不會公開端點,以供外部用戶端監視長時間執行的作業。Instead of exposing an endpoint for an external client to monitor a long-running operation, the long-running monitor consumes an external endpoint, and then waits for a state change.

監視模式的圖表

在幾行程式碼中,您可以使用 Durable Functions 建立可觀察任意端點的多個監視器。In a few lines of code, you can use Durable Functions to create multiple monitors that observe arbitrary endpoints. 監視器可以在符合條件時結束執行,或其他函式可使用長期協調流程用戶端終止監視器。The monitors can end execution when a condition is met, or another function can use the durable orchestration client to terminate the monitors. 您可以根據特定條件 (例如,指數輪詢) 來變更監視器的 wait 間隔時間。You can change a monitor's wait interval based on a specific condition (for example, exponential backoff.)

下列程式碼會實作基本的監視器:The following code implements a basic monitor:

[FunctionName("MonitorJobStatus")]
public static async Task Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    int jobId = context.GetInput<int>();
    int pollingInterval = GetPollingInterval();
    DateTime expiryTime = GetExpiryTime();

    while (context.CurrentUtcDateTime < expiryTime)
    {
        var jobStatus = await context.CallActivityAsync<string>("GetJobStatus", jobId);
        if (jobStatus == "Completed")
        {
            // Perform an action when a condition is met.
            await context.CallActivityAsync("SendAlert", machineId);
            break;
        }

        // Orchestration sleeps until this time.
        var nextCheck = context.CurrentUtcDateTime.AddSeconds(pollingInterval);
        await context.CreateTimer(nextCheck, CancellationToken.None);
    }

    // Perform more work here, or let the orchestration end.
}

收到要求時,系統會針對該作業識別碼建立新的協調流程執行個體。When a request is received, a new orchestration instance is created for that job ID. 執行個體會輪詢狀態,直到符合條件且迴圈結束為止。The instance polls a status until a condition is met and the loop is exited. 長期計時器可控制輪詢間隔。A durable timer controls the polling interval. 接著可執行更多工作,否則協調流程可能會結束。Then, more work can be performed, or the orchestration can end. nextCheck 超過 expiryTime 時,監視器就會結束。When nextCheck exceeds expiryTime, the monitor ends.

模式 #5:人為互動Pattern #5: Human interaction

許多自動化程序都會牽涉到某種類型的人為互動。Many automated processes involve some kind of human interaction. 自動化程序卻需人為涉入很弔詭,因為人們無法像雲端服務一樣隨時有空能夠回應。Involving humans in an automated process is tricky because people aren't as highly available and as responsive as cloud services. 自動化程序可使用逾時和補償邏輯來允許此互動。An automated process might allow for this interaction by using timeouts and compensation logic.

核准程序是需要人為互動的商務程序範例。An approval process is an example of a business process that involves human interaction. 超過特定金額的費用報告就可能需要管理員核准。Approval from a manager might be required for an expense report that exceeds a certain dollar amount. 如果經理未在 72 小時內核准費用報告 (可能是經理休假了),系統就會啟動向上呈報程序,以尋求其他人的核准 (或許是經理的經理)。If the manager doesn't approve the expense report within 72 hours (maybe the manager went on vacation), an escalation process kicks in to get the approval from someone else (perhaps the manager's manager).

人類互動模式的圖表

您可以使用協調器函式,在此範例中執行模式。You can implement the pattern in this example by using an orchestrator function. 協調器會使用長期計時器來要求核准。The orchestrator uses a durable timer to request approval. 如果發生逾時,協調器就會向上呈報。The orchestrator escalates if timeout occurs. 協調器會等待外部事件,例如人為互動所產生的通知。The orchestrator waits for an external event, such as a notification that's generated by a human interaction.

這些範例會建立核准程序,以示範人類互動模式:These examples create an approval process to demonstrate the human interaction pattern:

[FunctionName("ApprovalWorkflow")]
public static async Task Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    await context.CallActivityAsync("RequestApproval", null);
    using (var timeoutCts = new CancellationTokenSource())
    {
        DateTime dueTime = context.CurrentUtcDateTime.AddHours(72);
        Task durableTimeout = context.CreateTimer(dueTime, timeoutCts.Token);

        Task<bool> approvalEvent = context.WaitForExternalEvent<bool>("ApprovalEvent");
        if (approvalEvent == await Task.WhenAny(approvalEvent, durableTimeout))
        {
            timeoutCts.Cancel();
            await context.CallActivityAsync("ProcessApproval", approvalEvent.Result);
        }
        else
        {
            await context.CallActivityAsync("Escalate", null);
        }
    }
}

若要建立長期計時器,請呼叫 context.CreateTimerTo create the durable timer, call context.CreateTimer. 通知則由 context.WaitForExternalEvent 接收。The notification is received by context.WaitForExternalEvent. 接著會呼叫 Task.WhenAny,以決定是要向上呈報 (先發生逾時) 還是處理核准 (逾時前收到核准)。Then, Task.WhenAny is called to decide whether to escalate (timeout happens first) or process the approval (the approval is received before timeout).

外部用戶端可以使用內建的 HTTP API,將事件通知傳遞至等候中的協調器函式:An external client can deliver the event notification to a waiting orchestrator function by using the built-in HTTP APIs:

curl -d "true" http://localhost:7071/runtime/webhooks/durabletask/instances/{instanceId}/raiseEvent/ApprovalEvent -H "Content-Type: application/json"

此外也可從相同函式應用程式中的另一個函式使用長期協調流程用戶端來引發事件:An event can also be raised using the durable orchestration client from another function in the same function app:

[FunctionName("RaiseEventToOrchestration")]
public static async Task Run(
    [HttpTrigger] string instanceId,
    [DurableClient] IDurableOrchestrationClient client)
{
    bool isApproved = true;
    await client.RaiseEventAsync(instanceId, "ApprovalEvent", isApproved);
}

模式 #6:彙總工具 (具狀態實體)Pattern #6: Aggregator (stateful entities)

第六個模式是關於將一段時間的事件資料彙總成單一可定址的「實體」**。The sixth pattern is about aggregating event data over a period of time into a single, addressable entity. 在此模式中,所彙總的資料可能來自多個來源、可分批傳遞,或可散佈於長期的時間。In this pattern, the data being aggregated may come from multiple sources, may be delivered in batches, or may be scattered over long-periods of time. 彙總工具可能需要在事件資料送達時對其採取動作,而外部用戶端可能需要查詢所彙總的資料。The aggregator might need to take action on event data as it arrives, and external clients may need to query the aggregated data.

彙總工具圖表

嘗試使用一般無狀態函式來實作此模式的弔詭之處在於,並行控制會變成一大挑戰。The tricky thing about trying to implement this pattern with normal, stateless functions is that concurrency control becomes a huge challenge. 您不只需要擔心多個執行緒同時修改相同的資料,也需要擔心如何確保彙總工具一次只在單一 VM 上執行。Not only do you need to worry about multiple threads modifying the same data at the same time, you also need to worry about ensuring that the aggregator only runs on a single VM at a time.

您可以使用耐久性實體,輕鬆地將此模式實作為單一函式。You can use Durable entities to easily implement this pattern as a single function.

[FunctionName("Counter")]
public static void Counter([EntityTrigger] IDurableEntityContext ctx)
{
    int currentValue = ctx.GetState<int>();
    switch (ctx.OperationName.ToLowerInvariant())
    {
        case "add":
            int amount = ctx.GetInput<int>();
            ctx.SetState(currentValue + amount);
            break;
        case "reset":
            ctx.SetState(0);
            break;
        case "get":
            ctx.Return(currentValue);
            break;
    }
}

耐久性實體也可以模型化為 .NET 中的類別。Durable entities can also be modeled as classes in .NET. 如果作業清單固定且變得很大,此模型會很實用。This model can be useful if the list of operations is fixed and becomes large. 下列範例等同於使用 .NET 類別和方法來實作 Counter 實體。The following example is an equivalent implementation of the Counter entity using .NET classes and methods.

public class Counter
{
    [JsonProperty("value")]
    public int CurrentValue { get; set; }

    public void Add(int amount) => this.CurrentValue += amount;

    public void Reset() => this.CurrentValue = 0;

    public int Get() => this.CurrentValue;

    [FunctionName(nameof(Counter))]
    public static Task Run([EntityTrigger] IDurableEntityContext ctx)
        => ctx.DispatchAsync<Counter>();
}

用戶端可以使用實體用戶端繫結,將實體函式的「作業」** 排入佇列 (也稱為「訊號處理」)。Clients can enqueue operations for (also known as "signaling") an entity function using the entity client binding.

[FunctionName("EventHubTriggerCSharp")]
public static async Task Run(
    [EventHubTrigger("device-sensor-events")] EventData eventData,
    [DurableClient] IDurableOrchestrationClient entityClient)
{
    var metricType = (string)eventData.Properties["metric"];
    var delta = BitConverter.ToInt32(eventData.Body, eventData.Body.Offset);

    // The "Counter/{metricType}" entity is created on-demand.
    var entityId = new EntityId("Counter", metricType);
    await entityClient.SignalEntityAsync(entityId, "add", delta);
}

注意

動態產生的 Proxy 也適用於在 .NET 中以型別安全方式進行實體訊號處理。Dynamically generated proxies are also available in .NET for signaling entities in a type-safe way. 除了訊號處理外,用戶端也可以在協調流程用戶端繫結上使用型別安全方法來查詢實體函式的狀態。And in addition to signaling, clients can also query for the state of an entity function using type-safe methods on the orchestration client binding.

實體函式可在 C# 和 JavaScript 的 Durable Functions 2.0 和更新版本中取得。Entity functions are available in Durable Functions 2.0 and above for C# and JavaScript.

技術The technology

Durable Functions 擴充功能其實是以長期工作架構為基礎所建置的,長期工作架構是 GitHub 上以程式碼用來建置工作流程的開放原始碼程式庫。Behind the scenes, the Durable Functions extension is built on top of the Durable Task Framework, an open-source library on GitHub that's used to build workflows in code. 如同 Azure Functions 是 Azure WebJobs 的無伺服器演化,Durable Functions 也是長期工作架構的無伺服器演化。Like Azure Functions is the serverless evolution of Azure WebJobs, Durable Functions is the serverless evolution of the Durable Task Framework. Microsoft 和其他組織會廣泛地使用長期工作架構,將任務關鍵程序自動化。Microsoft and other organizations use the Durable Task Framework extensively to automate mission-critical processes. 它天生就適合無伺服器的 Azure Functions 環境。It's a natural fit for the serverless Azure Functions environment.

程式碼條件約束Code constraints

為了提供可靠且長時間執行的執行保證,協調器函式具有一組必須遵循的編碼規則。In order to provide reliable and long-running execution guarantees, orchestrator functions have a set of coding rules that must be followed. 如需詳細資訊,請參閱協調器函式程式碼條件約束一文。For more information, see the Orchestrator function code constraints article.

計費Billing

Durable Functions 的收費方式與 Azure Functions 相同。Durable Functions are billed the same as Azure Functions. 如需詳細資訊,請參閱 Azure Functions 價格For more information, see Azure Functions pricing. 在 Azure Functions 取用方案中執行協調器函式時,有一些要注意的計費行為。When executing orchestrator functions in the Azure Functions Consumption plan, there are some billing behaviors to be aware of. 如需這些行為的詳細資訊,請參閱 Durable Functions 計費一文。For more information on these behaviors, see the Durable Functions billing article.

立即參與Jump right in

完成下列其中一個特定語言快速入門教學課程,即可在 10 分鐘內開始使用 Durable Functions:You can get started with Durable Functions in under 10 minutes by completing one of these language-specific quickstart tutorials:

在這些快速入門中,您會在本機建立及測試 "hello world" 耐久函式。In these quickstarts, you locally create and test a "hello world" durable function. 接著會將函式程式碼發佈至 Azure。You then publish the function code to Azure. 您建立的函式會協調對其他函式的呼叫並鏈結在一起。The function you create orchestrates and chains together calls to other functions.

深入了解Learn more

下列影片特別說明 Durable Functions 的優點:The following video highlights the benefits of Durable Functions:

如需 Durable Functions 和基礎技術的更深入討論,請參閱下列影片 (著重於 .NET,但這些概念也適用於其他支援的語言):For a more in-depth discussion of Durable Functions and the underlying technology, see the following video (it's focused on .NET, but the concepts also apply to other supported languages):

因為 Durable Functions 是 Azure Functions 的進階擴充功能,因此並非所有應用程式都適用。Because Durable Functions is an advanced extension for Azure Functions, it isn't appropriate for all applications. 如需與其他 Azure 協調流程技術的比較,請參閱比較 Azure Functions 和 Azure Logic AppsFor a comparison with other Azure orchestration technologies, see Compare Azure Functions and Azure Logic Apps.

後續步驟Next steps