Görev hub'ları

Görev hub'ı, bekleyen tüm çalışmalar da dahil olmak üzere depolamadaki uygulamanın geçerli durumunun bir gösterimidir. Uygulama çalışırken görev hub'ı düzenleme, etkinlik ve varlık işlevlerinin ilerleme durumunu sürekli olarak depolar. Bu yaklaşım, uygulamanın geçici olarak durdurulduktan veya kesintiye uğradıktan sonra yeniden başlatılırsa işlemeye kaldığı yerden devam etmesini sağlar. Görev hub'ı, uygulamaların işlem çalışanlarını dinamik olarak ölçeklendirmesine de olanak tanır.

Bu makalede görev hub'larının depoladığı şeyler, görev hub'larını yapılandırma ve adlandırma, bunları farklı depolama arka uçlarıyla oluşturma ve yönetme ve görev hub'larının dahili olarak çalışma şekli açıklanmaktadır.

Dayanıklı Görev'de işlev uygulaması ve görev hub'ı mimarisini gösteren diyagramın ekran görüntüsü.

Kavramsal olarak, bir görev hub'ı aşağıdaki bilgileri depolar:

Tüm orkestrasyon ve varlık örneklerinin örnek durumları.
İşlenecek iletiler, örneğin:
- Çalıştırılmayı bekleyen etkinlikleri temsil eden tüm etkinlik iletileri .
- Örneklere teslim edilmeyi bekleyen tüm örnek iletileri.

Aktivite mesajları durumsuzdur ve herhangi bir yerde işlenebilir. Durum örneğine iletilmesi gereken mesajlar, örnek kimliğiyle tanımlanan belirli bir durum bilgisine sahip bir örneğe (orkestrasyon veya varlık) teslim edilmelidir.

Dahili olarak, her depolama sağlayıcısı örnek durumlarını ve iletilerini temsil etmek için farklı bir kuruluş kullanabilir. Örneğin, Azure Depolama sağlayıcısı iletileri Azure Depolama Kuyruklarında depolar, ancak MSSQL sağlayıcısı bunları ilişkisel tablolarda depolar. Bu farklılıklar uygulama tasarımı için önemli değildir, ancak bazıları performans özelliklerini etkileyebilir. Daha fazla bilgi için bkz . Depolamada temsil.

Dayanıklı Görev SDK'ları, görev hub'ları için arka uç olarak Dayanıklı Görev Zamanlayıcı'yı kullanır. Dayanıklı Görev Zamanlayıcı, depolamayı dahili olarak işleyen tam olarak yönetilen bir hizmettir.

Görev merkez adları

Görev hub'ları şu kurallara uyan bir adla tanımlanır:

Yalnızca alfasayısal karakterler içerir
Bir harfle başlar
En az 3 karakter uzunluğunda, en fazla 45 karakter uzunluğundadır

Aşağıdaki örnekte gösterildiği gibi görev hub'ı adını host.json dosyasında bildirin:

host.json (İşlevler 2.0)

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "hubName": "MyTaskHub"
    }
  }
}

host.json (İşlevler 1.x)

{
  "durableTask": {
    "hubName": "MyTaskHub"
  }
}

Görev hub'larını, aşağıdaki host.json örnek dosyada gösterildiği gibi uygulama ayarlarını kullanarak da ayarlayabilirsiniz:

host.json (İşlevler 2.0)

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "hubName": "%MyTaskHub%"
    }
  }
}

host.json (İşlevler 1.x)

{
  "durableTask": {
    "hubName": "%MyTaskHub%"
  }
}

Görev hub'ı adı, uygulama ayarının MyTaskHub değerine ayarlanır. Aşağıdaki local.settings.json dosya, MyTaskHub ayarının samplehubname olarak nasıl tanımlanacağını göstermektedir.

{
  "IsEncrypted": false,
  "Values": {
    "MyTaskHub" : "samplehubname"
  }
}

Uyarı

Dağıtım yuvalarını kullanırken, uygulama ayarlarını kullanarak görev hub'ı adını ayarlamak en iyi yöntemdir. Belirli bir yuvanın her zaman belirli bir görev hub'ı kullandığından emin olmak istiyorsanız "yuva-kilitli" uygulama ayarlarını kullanın.

host.json dosyasına ek olarak, görev hub'ı adları, orkestrasyon istemci bağlama meta verisinde de ayarlanabilir. Bu yapılandırma, ayrı bir işlev uygulamasında bulunan orkestrasyonlara veya varlıklara erişmeniz gerektiğinde kullanışlıdır. Aşağıdaki kod, uygulama ayarı olarak ayarlanmış bir görev hub'ı ile çalışmak için düzenleme istemci bağlamasını kullanan bir işlevin nasıl yazıldığını gösterir:

[FunctionName("HttpStart")]
public static async Task<HttpResponseMessage> Run(
    [HttpTrigger(AuthorizationLevel.Function, methods: "post", Route = "orchestrators/{functionName}")] HttpRequestMessage req,
    [DurableClient(TaskHub = "%MyTaskHub%")] IDurableOrchestrationClient starter,
    string functionName,
    ILogger log)
{
    // Function input comes from the request content.
    object eventData = await req.Content.ReadAsAsync<object>();
    string instanceId = await starter.StartNewAsync(functionName, eventData);

    log.LogInformation($"Started orchestration with ID = '{instanceId}'.");

    return starter.CreateCheckStatusResponse(req, instanceId);
}

Uyarı

Önceki örnek Dayanıklı İşlevler 2.x içindir. Dayanıklı İşlevler 1.x için DurableOrchestrationContext yerine IDurableOrchestrationContext kullanın. Sürümler arasındaki farklar hakkında daha fazla bilgi için Dayanıklı İşlevler sürümleri makalesine bakın.

Dosyadaki function.json görev hub'ı özelliği bir uygulama ayarı aracılığıyla ayarlanır:

{
    "name": "input",
    "taskHub": "%MyTaskHub%",
    "type": "durableClient",
    "direction": "in"
}

Uyarı

Bu örnek Dayanıklı İşlevler sürüm 2.x'i hedefler. Sürüm 1.x'te orchestrationClient yerine durableClient kullanın.

Dosyadaki function.json görev hub'ı özelliği Uygulama Ayarı aracılığıyla ayarlanır:

{
    "name": "input",
    "taskHub": "%MyTaskHub%",
    "type": "durableClient",
    "direction": "in"
}

Uyarı

Bu örnek Dayanıklı İşlevler sürüm 2.x'i hedefler. Sürüm 1.x'te orchestrationClient yerine durableClient kullanın.

Dosyadaki function.json görev hub'ı özelliği Uygulama Ayarı aracılığıyla ayarlanır:

{
    "name": "input",
    "taskHub": "%MyTaskHub%",
    "type": "durableClient",
    "direction": "in"
}

Uyarı

Bu örnek Dayanıklı İşlevler sürüm 2.x'i hedefler. Sürüm 1.x'te orchestrationClient yerine durableClient kullanın.

@FunctionName("HttpStart")
public HttpResponseMessage httpStart(
        @HttpTrigger(name = "req", route = "orchestrators/{functionName}") HttpRequestMessage<?> req,
        @DurableClientInput(name = "durableContext", taskHub = "%MyTaskHub%") DurableClientContext durableContext,
        @BindingName("functionName") String functionName,
        final ExecutionContext context) {

    DurableTaskClient client = durableContext.getClient();
    String instanceId = client.scheduleNewOrchestrationInstance(functionName);
    context.getLogger().info("Created new Java orchestration with instance ID = " + instanceId);
    return durableContext.createCheckStatusResponse(req, instanceId);
}

Uyarı

görev hub'ı adlarını istemci bağlama meta verilerinde ayarlamak yalnızca başka bir işlev uygulamasındaki düzenlemelere ve varlıklara erişmek için bir işlev uygulaması kullandığınızda gereklidir. İstemci işlevleri, düzenlemelerle ve varlıklarla aynı işlev uygulamasında tanımlanmışsa, bağlama meta verilerinde görev hub'ı adlarını belirtmekten kaçının. Varsayılan olarak, tüm istemci bağlamaları görev hub'ı meta verilerini host.json ayarlarından alır.

Belirtilmezse, aşağıdaki tabloda gösterildiği gibi varsayılan görev hub'ı adı kullanılır:

Dayanıklı uzantı sürümü	Varsayılan görev hub'ı adı
2.x	Azure'a dağıtıldığında, görev merkezi adı fonksiyon uygulaması adından türetilir. Azure dışında çalışırken, varsayılan görev hub'ı adı `TestHubName`'dir.
1.x	Tüm ortamlar için varsayılan görev hub'ı adıdır `DurableFunctionsHub`.

Uzantı sürümleri arasındaki farklar hakkında daha fazla bilgi için Dayanıklı İşlevler sürümleri makalesine bakın.

Ayrı görev hub'larıyla birden çok uygulama kullanma

Bir arka ucu paylaşan her uygulama, çakışmaları önlemek için kendi görev hub'ına bağlanmalıdır. Birden çok uygulama aynı görev hub'ını kullanıyorsa iletiler için rekabet eder ve bu da düzenlemelerin beklenmedik şekilde takılması gibi tanımsız davranışlara neden olabilir. Tek bir arka uç birden çok görev hub'ı içerebilir; her uygulamayı kendi hub'ı ile yapılandırın.

Bu gereksinim tüm depolama arka uçları için geçerlidir. BYO depolama sağlayıcıları (Azure Depolama, Netherite, MSSQL) için her işlev uygulamasını ayrı bir görev hub'ı adıyla yapılandırın. Bu gereksinim hazırlama yuvaları için de geçerlidir: her hazırlama yuvasını benzersiz bir görev hub'ı adıyla yapılandırın.

Önemli

Varsayılan olarak, uygulama adı görev hub'ı adı olarak kullanılır ve bu da yanlışlıkla paylaşımın gerçekleşmemesini sağlar. host.jsongörev hub'ı adlarını açıkça yapılandırıyorsanız adların benzersiz olduğundan emin olun. Tek istisna, olağanüstü durum kurtarma için aynı uygulamanın kopyalarınıbirden çok bölgeye dağıtmanızdır. Bu durumda, kopyalar için aynı görev hub'ını kullanın.

Aşağıdaki diyagramda, paylaşılan ve ayrılmış Azure Depolama hesaplarında işlev uygulaması başına bir görev hub'ı gösterilmektedir.

Paylaşılan ve ayrılmış Azure Depolama hesaplarında işlev uygulaması başına bir görev hub'ını gösteren diyagramın ekran görüntüsü.

Dayanıklı Görev Zamanlayıcı görev hub'ı yönetimi

Bu bölüm, Dayanıklı Görev Zamanlayıcı arka ucu kullanılırken görev hub'larının nasıl oluşturulacağını ve yönetileceğini kapsar. Uygulamanız bunları kullanmadan önce zamanlayıcı ve görev hub'ı kaynaklarını açıkça oluşturun.

Zamanlayıcı ve görev hub'ı oluşturma

Azure portalı, Azure CLI, Azure Resource Manager (ARM) veya Bicep kullanarak bir zamanlayıcı ve görev hub'ı oluşturun.

Azure portalında Dayanıklı Görev Zamanlayıcı'yı arayın ve sonuçlardan seçin.
Zamanlayıcı oluşturma bölmesini açmak için Oluştur'u seçin.
Temel bilgiler sekmesindeki kaynak grubu, zamanlayıcı adı, bölge ve SKU gibi alanları doldurun. Seçin, gözden geçir ve oluştur.
Doğrulama başarılı olduktan sonra Oluştur'u seçin. Dağıtım 15 dakika kadar sürer.
Zamanlayıcı oluşturulduktan sonra zamanlayıcı kaynağına gidin. Genel Bakış sayfasında yeni bir görev hub'ı oluşturun.

Dayanıklı Görev Zamanlayıcı CLI uzantısını yükleyin veya güncelleştirin.
```
az extension add --name durabletask
az extension update --name durabletask
```

Bir kaynak grubu oluşturun (gerekirse).

az group create --name YOUR_RESOURCE_GROUP --location LOCATION

Bir zamanlayıcı oluşturun.

az durabletask scheduler create \
  --name "YOUR_SCHEDULER" \
  --resource-group "YOUR_RESOURCE_GROUP" \
  --location "LOCATION" \
  --ip-allowlist "[0.0.0.0/0]" \
  --sku-name "dedicated" \
  --sku-capacity "1"

Zamanlayıcı içinde bir görev hub'ı oluşturun.

az durabletask taskhub create \
  --resource-group YOUR_RESOURCE_GROUP \
  --scheduler-name YOUR_SCHEDULER \
  --name YOUR_TASKHUB

ARM REST API'sini kullanarak bir zamanlayıcı ve görev hub'ı dağıtın.

Bir zamanlayıcı oluşturun.

PUT https://management.azure.com/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.DurableTask/schedulers/SCHEDULER_NAME?api-version=2025-04-01-preview

{
  "location": "LOCATION",
  "properties": {
    "ipAllowlist": ["0.0.0.0/0"],
    "sku": {
      "name": "Dedicated",
      "capacity": 1
    }
  }
}

Zamanlayıcı içinde bir görev hub'ı oluşturun.

PUT https://management.azure.com/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.DurableTask/schedulers/SCHEDULER_NAME/taskHubs/TASKHUB_NAME?api-version=2025-04-01-preview

{
  "properties": {}
}

Zamanlayıcıyı ve görev hub'ını bir Bicep şablonunda tanımlayın.

@description('The name of the Durable Task Scheduler.')
param schedulerName string

@description('The name of the task hub.')
param taskHubName string

@description('The location for all resources.')
param location string = resourceGroup().location

resource scheduler 'Microsoft.DurableTask/schedulers@2025-04-01-preview' = {
  name: schedulerName
  location: location
  properties: {
    ipAllowlist: [
      '0.0.0.0/0'
    ]
    sku: {
      name: 'Dedicated'
      capacity: 1
    }
  }
}

resource taskHub 'Microsoft.DurableTask/schedulers/taskHubs@2025-04-01-preview' = {
  parent: scheduler
  name: taskHubName
  properties: {}
}

Önemli

0.0.0.0/0 IP izin listesi herhangi bir IP adresinden erişime izin verir. Üretim dağıtımları için bunu yalnızca gerekli IP aralıklarıyla kısıtlayın.

Önceki örneklerde Ayrılmış SKU kullanılır. Dayanıklı Görev Zamanlayıcı bir Tüketim SKU'su da sunar. Dayanıklı Görev Zamanlayıcı kaynaklarını yönetme hakkında daha fazla bilgi için bkz. Dayanıklı Görev Zamanlayıcı ile geliştirme.

Kimlik tabanlı kimlik doğrulamayı yapılandırma

Dayanıklı Görev Zamanlayıcı yalnızca yönetilen kimlik kimlik doğrulamayı destekler. Depolama anahtarlarıyla bağlantı dizelerini desteklemez. Yönetilen bir kimliğe uygun rol tabanlı erişim denetimi (RBAC) rolünü atayın ve uygulamanızı bu kimliği kullanacak şekilde yapılandırın.

Aşağıdaki roller kullanılabilir:

Rol	Açıklama
Kalıcı Görev Verisi Katılımcısı	Tam veri erişimi. Diğer tüm rollerin üst kümesi.
Dayanıklı Görev Çalışanı	Orkestrasyonları, etkinlikleri ve varlıkları işlemek için planlayıcı ile etkileşime geçin.
Dayanıklı Görev Veri Okuyucusu	Orkestrasyon ve varlık verilerine salt okunur erişim.

Uyarı

Çoğu uygulama, Dayanıklı Görev Verileri Katkısı Rolü gerektirir.

Mümkün olduğunda kullanıcı tarafından atanan yönetilen kimlikleri kullanın çünkü bunlar uygulamanın yaşam döngüsüne bağlı değildir ve uygulama kaldırıldıktan sonra bunları yeniden kullanabilirsiniz.

Azure portalında zamanlayıcı veya görev hub'ı kaynağına gidin.
Soldaki menüden Erişim denetimi (IAM) öğesini seçin.
Ekle>Rol ataması ekle’yi seçin.
Dayanıklı Görev Verileri Katkıda Bulunanı'yı arayın ve seçin. sonrakiseçin.
Erişim ataması için Yönetilen kimlik'i seçin. 'ı seçin +üyelerini seçin.
Kullanıcı tarafından atanan yönetilen kimlik'i seçin, kimliği seçin ve Seç'i seçin.
Bitirmek için Gözden geçir ve ata'yı seçin.
İşlev uygulamanıza gidin ve Ayarlar>Kimliği'ne tıklayın. Kullanıcı tarafından atanan sekmesini seçin ve kimliği ekleyin.

Kullanıcı tarafından atanan bir yönetilen kimlik oluşturun.

az identity create -g YOUR_RESOURCE_GROUP -n YOUR_IDENTITY_NAME

Kimliğe, zamanlayıcı veya görev hub'ı kapsamında Dayanıklı Görev Verileri Katkıda Bulunanı rolünü atayın.

assignee=$(az identity show --name YOUR_IDENTITY_NAME --resource-group YOUR_RESOURCE_GROUP --query 'clientId' --output tsv)

scope="/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/YOUR_RESOURCE_GROUP/providers/Microsoft.DurableTask/schedulers/YOUR_SCHEDULER"

az role assignment create \
  --assignee "$assignee" \
  --role "Durable Task Data Contributor" \
  --scope "$scope"

Kimliği işlev uygulamanıza atayın.

resource_id=$(az resource show --resource-group YOUR_RESOURCE_GROUP --name YOUR_IDENTITY_NAME --resource-type Microsoft.ManagedIdentity/userAssignedIdentities --query id --output tsv)

az functionapp identity assign \
  --resource-group YOUR_RESOURCE_GROUP \
  --name YOUR_FUNCTION_APP \
  --identities "$resource_id"

ARM REST API'sini kullanarak yönetilen kimlik için bir rol ataması oluşturun.

PUT https://management.azure.com/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.DurableTask/schedulers/SCHEDULER_NAME/providers/Microsoft.Authorization/roleAssignments/ROLE_ASSIGNMENT_ID?api-version=2022-04-01

{
  "properties": {
    "roleDefinitionId": "/subscriptions/SUBSCRIPTION_ID/providers/Microsoft.Authorization/roleDefinitions/ROLE_DEFINITION_ID",
    "principalId": "MANAGED_IDENTITY_PRINCIPAL_ID",
    "principalType": "ServicePrincipal"
  }
}

Tip

Dayanıklı Görev Verileri Katkıda Bulunanı rol tanımı kimliğini bulmak için şunu çalıştırın:az role definition list --name "Durable Task Data Contributor" --query "[0].id" -o tsv

Bicep şablonunuza bir rol ataması ekleyin.

@description('The principal ID of the managed identity.')
param identityPrincipalId string

@description('The Durable Task Data Contributor role definition ID.')
var durableTaskDataContributorRoleId = subscriptionResourceId(
  'Microsoft.Authorization/roleDefinitions',
  'ROLE_DEFINITION_ID'
)

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(scheduler.id, identityPrincipalId, durableTaskDataContributorRoleId)
  scope: scheduler
  properties: {
    roleDefinitionId: durableTaskDataContributorRoleId
    principalId: identityPrincipalId
    principalType: 'ServicePrincipal'
  }
}

Kimliği atadıktan sonra aşağıdaki ortam değişkenlerini uygulamanıza ekleyin:

Variable	Değer
`TASKHUB_NAME`	Görev hub'ınızın adı.
`DURABLE_TASK_SCHEDULER_CONNECTION_STRING`	`Endpoint={scheduler endpoint};Authentication=ManagedIdentity;ClientID={client id}`

Uyarı

Sistem tarafından atanan bir yönetilen kimlik kullanıyorsanız, bağlantı dizesindeki ClientID segmentini çıkartarak: Endpoint={scheduler endpoint};Authentication=ManagedIdentity.

Tam kimlik yapılandırma ayrıntıları için Dayanıklı Görev Zamanlayıcı için yönetilen kimliği yapılandırma bölümüne bakın.

BYO depolama sağlayıcısı görev hub'ı yönetimi

Bu bölüm, görev hub'ı oluşturma ve silme ve görev hub'ı içeriğini inceleme konularını kapsar. Kendi seçtiğin depolama sağlayıcıları için geçerlidir: Azure Depolama, Netherite ve MSSQL.

Önemli

BYO depolama sağlayıcısı kullandığınızda, altta yatan depolama kaynaklarının güvenliğini sağlamaktan siz sorumlusunuz. Görev hub'ı depolamaya yazma erişimi, rastgele kod yürütmeyi tetikleme de dahil olmak üzere uygulama davranışını değiştirmek için kullanılabilir. Kimlik tabanlı bağlantıları kullanın, en az ayrıcalıklı RBAC uygulayın ve ağ erişimini kısıtlayın. Kapsamlı sağlamlaştırma denetim listesi için bkz: Task hub depolamanızın güvenliğini sağlama.

Görev hub'ları oluşturma ve silme

bir işlev uygulaması ilk kez başlatıldığında, depolamada gerekli tüm kaynakları içeren boş bir görev hub'ı otomatik olarak oluşturulur.

Azure Depolama sağlayıcısını kullanıyorsanız ek yapılandırma gerekmez. Aksi takdirde, depolama sağlayıcısının görev hub'ı için gerekli depolama kaynaklarını düzgün bir şekilde ayarlayabilmesi ve bu kaynaklara erişebilmesi için depolama sağlayıcılarını yapılandırma yönergelerini izleyin.

Uyarı

İşlev uygulamasını durdurduğunuzda veya sildiğinizde görev hub'ı otomatik olarak silinmez. Bu verileri kaldırmak için görev hub'ını, içeriğini veya içeren depolama hesabını el ile silin.

Tip

Bir geliştirme senaryosunda, sık sık temiz bir durumdan yeniden başlatmanız gerekebilir. Bunu hızlı bir şekilde yapmak için , yapılandırılan görev hub'ı adını değiştirmeniz gerekir. Bu değişiklik, uygulamayı yeniden başlattığınızda yeni, boş bir görev hub'ı oluşturulmasını zorlar. Bu durumda eski veriler silinmez.

Görev hub'ı içeriğini inceleme

Görev hub'ının içeriğini incelemenin birkaç yaygın yolu vardır:

bir işlev uygulaması içinde, istemci nesnesi örnek deposunu sorgulamak için yöntemler sağlar. Hangi sorgu türlerinin desteklendiği hakkında daha fazla bilgi edinmek için Örnek Yönetimi makalesine bakın.
Benzer şekilde , HTTP API'sinde düzenlemelerin ve varlıkların durumunu sorgulamak için REST istekleri sunulur. Diğer ayrıntılar için bkz. HTTP API Başvurusu .
Dayanıklı İşlevler İzleyici aracı görev hub'larını inceleyebilir ve görsel görüntüleme için çeşitli seçenekler sunar.

Bazı depolama sağlayıcıları için, doğrudan altındaki depolamaya giderek görev hub'ını da inceleyebilirsiniz.

Azure Depolama sağlayıcısını kullanırsanız, örnek durumları Instance Tablosu ve History Table içinde depolanır ve Azure Depolama Gezgini gibi araçları kullanarak inceleyebilirsiniz.
MSSQL depolama sağlayıcısını kullanıyorsanız, veritabanındaki görev hub'ını incelemek için SQL sorgularını ve araçlarını kullanın.

İş öğeleri

Görev hub'ında etkinlik iletileri ve örnek iletileri, uygulamanın işlemesi gereken çalışmayı temsil eder. Uygulama çalışırken, görev hub'ından sürekli olarak iş öğelerini getirir. Her iş öğesi bir veya daha fazla iletiyi işler. İki tür iş öğesi vardır:

Etkinlik iş öğeleri: Etkinlik iletisini işlemek için bir etkinlik işlevi çalıştırın.
Orkestratör iş öğeleri: Bir veya daha fazla örnek iletisini işlemek için bir orkestratör veya varlık işlevi çalıştırılır.

Çalışanlar, yapılandırılan çalışan başına eşzamanlılık sınırlarına bağlı olarak birden çok iş öğesini aynı anda işleyebilir.

Eşzamanlılık sınırlamaları hakkında daha fazla bilgi için bkz. Performans ve ölçeklendirme.

Bir çalışan bir iş öğesini tamamladıktan sonra, değişiklikleri görev merkezine geri kaydeder. Bu etkiler, yürütülen işlevin türüne göre değişir:

Tamamlanmış etkinlik işlevi, ana orchestrator örneğine yönelik sonuç içerikli bir mesaj oluşturur.
Tamamlanan bir düzenleyici işlevi düzenleme durumunu ve geçmişini güncelleştirir ve yeni iletiler oluşturabilir.
Tamamlanmış bir varlık işlevi varlık durumunu güncelleştirir ve yeni örnek iletileri de oluşturabilir.

Düzenlemelerde, her iş öğesi bu düzenlemenin yürütülmesinin bir bölümünü temsil eder. Bir bölüm, düzenleyicinin bir tur çalışarak mevcut sonuçları işlemesi ve ardından bir sonraki sonuç gelene kadar duraklamasıdır. Örneğin, bir bölüm düzenleme başladığında, etkinlik tamamlandığında ve bir sonuç döndürdüğünde veya bir dış olay geldiğinde başlar. İşlem, orkestratör tamamlandığında veya yeni iletileri beklemesi gereken bir noktaya ulaştığında sona erer.

Yürütme örneği

İki etkinliği paralel olarak başlatan ve her iki etkinliğin de tamamlanmasını bekleyen bir dağıtım-toplama orkestrasyonunu düşünün:

[FunctionName("Example")]
public static async Task Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    Task t1 = context.CallActivityAsync<int>("MyActivity", 1);
    Task t2 = context.CallActivityAsync<int>("MyActivity", 2);
    await Task.WhenAll(t1, t2);
}

module.exports = df.orchestrator(function*(context){
    const tasks = [];
    tasks.push(context.df.callActivity("MyActivity", 1));
    tasks.push(context.df.callActivity("MyActivity", 2));
    yield context.df.Task.all(tasks);
});

def orchestrator_function(context: df.DurableOrchestrationContext):
    tasks = []
    tasks.append(context.call_activity("MyActivity", 1))
    tasks.append(context.call_activity("MyActivity", 2))
    yield context.task_all(tasks)

param($Context)

$Tasks = @()

$Tasks += Invoke-DurableActivity -FunctionName 'MyActivity' -Input 1 -NoWait
$Tasks += Invoke-DurableActivity -FunctionName 'MyActivity' -Input 2 -NoWait

Wait-DurableTask -Task $Tasks

@FunctionName("Example")
public void exampleOrchestrator(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    Task<Void> t1 = ctx.callActivity("MyActivity", 1);
    Task<Void> t2 = ctx.callActivity("MyActivity", 2);
    ctx.allOf(List.of(t1, t2)).await();
}

using Microsoft.DurableTask;

public class Example : TaskOrchestrator<object?, object?>
{
    public override async Task<object?> RunAsync(TaskOrchestrationContext context, object? input)
    {
        Task t1 = context.CallActivityAsync("MyActivity", 1);
        Task t2 = context.CallActivityAsync("MyActivity", 2);
        await Task.WhenAll(t1, t2);
        return null;
    }
}

import { OrchestrationContext, TOrchestrator, whenAll } from "@microsoft/durabletask-js";

const example: TOrchestrator = async function* (ctx: OrchestrationContext): any {
    const t1 = ctx.callActivity(myActivity, 1);
    const t2 = ctx.callActivity(myActivity, 2);
    yield whenAll([t1, t2]);
};

from durabletask import task

def example_orchestrator(ctx: task.OrchestrationContext, _):
    t1 = ctx.call_activity("my_activity", input=1)
    t2 = ctx.call_activity("my_activity", input=2)
    yield task.when_all([t1, t2])

import com.microsoft.durabletask.TaskOrchestration;
import com.microsoft.durabletask.TaskOrchestrationContext;

public class Example implements TaskOrchestration {
    @Override
    public void run(TaskOrchestrationContext ctx) {
        Task<Void> t1 = ctx.callActivity("MyActivity", 1, Void.class);
        Task<Void> t2 = ctx.callActivity("MyActivity", 2, Void.class);
        ctx.allOf(List.of(t1, t2)).await();
    }
}

Bu düzenleme bir istemci tarafından başlatıldıktan sonra uygulama bunu bir iş öğeleri dizisi olarak işler. Tamamlanan her iş öğesi, commit edildiğinde görev hub'ın durumunu günceller. Adımlar şunlardır:

İstemci, instance-id "123" ile yeni bir düzenleme başlatmayı istemektedir. İstemci bu isteği tamamladıktan sonra, görev hub'ı orkestrasyon durumu için bir yer tutucu ve bir örnek iletisi içerir:

ExecutionStarted etiketi, bir düzenlemenin geçmişine katılan çeşitli ileti ve olay türlerini tanımlayan birçok history olay türünden biridir.
Çalışan, iletiyi işlemek için bir düzenleyici iş öğesi yürütür ExecutionStarted . Düzenleme kodunu yürütmeye başlayan orchestrator işlevini çağırır. Bu kod, iki etkinliği zamanlar ve ardından sonuçları beklerken yürütmeyi durdurur.

Çalışma zamanı durumu şimdi Running ve geçmiş bu ilk bölümü kaydeder: orkestratör başlatıldı, yürütme başlatıldı, iki görev zamanlandı ve orkestratör bölümü tamamladı.
Çalışan, iletilerden birini işlemek için bir etkinlik iş öğesi yürütür TaskScheduled . Etkinlik işlevini "2" girişiyle çağırır. Etkinlik işlevi tamamlandığında, sonucu içeren bir TaskCompleted ileti oluşturur.
Çalışan, iletiyi işlemek için bir düzenleyici iş öğesi yürütür TaskCompleted . Eğer orkestrasyon hala bellekte önbelleğe alınmışsa, yürütmeyi sürdürebilir. Aksi takdirde, işçi önce orkestrasyonun mevcut durumunu geri yüklemek için geçmişi yeniden oynatır. Ardından düzenlemeye devam ederek etkinliğin sonucunu sunar. Bu sonucu aldıktan sonra düzenleme diğer etkinliğin sonucunu bekler, bu nedenle yürütmeyi bir kez daha durdurur.

Geçmiş, ikinci bölümü kaydediyor: görev tamamlandı ve orkestratör yeniden duraklatıldı.
Çalışan, kalan iletiyi işlemek için bir TaskScheduled yürütür. Etkinlik işlevini "1" girişiyle çağırır.
Çalışan, iletiyi işlemek için başka bir orchestrator iş öğesi yürütür TaskCompleted . Bu ikinci sonucu aldıktan sonra düzenleme tamamlanır.

Çalışma zamanı durumu şu anda Completed, ve geçmişte üçüncü ve son bölüm kaydedilir: ikinci görev tamamlandı ve yürütme sona erdi.

Uyarı

Gösterilen zamanlama mümkün olan tek zamanlama değildir. Örneğin, ikinci etkinlik daha önce tamamlanırsa, her iki ileti de TaskCompleted tek bir iş öğesi tarafından işlenebilir ve bu da üç bölüm yerine yalnızca iki bölümle sonuçlanabilir.

Depolamada gösterim

Her depolama sağlayıcısı, depolamadaki görev hub'larını temsil etmek için farklı bir iç kuruluş kullanır. Bu kuruluşu anlamak, gerekli olmasa da sorun giderme sırasında veya performans, ölçeklenebilirlik veya maliyet hedeflerini karşılamaya çalışırken yardımcı olabilir.

Dayanıklı Görev SDK'ları arka uç olarak Dayanıklı Görev Zamanlayıcı'yı kullanır ve bu da görev hub'ı durumunu dahili olarak yönetir.

Dayanıklı Görev Zamanlayıcı sağlayıcısı

Dayanıklı Görev Zamanlayıcı, tüm görev hub'ı durumunu dahili olarak depolayan tam olarak yönetilen bir arka uç sağlayıcısıdır. Kendi cihazlarını getirme (BYO) depolama sağlayıcılarından farklı olarak, altta yatan depolama altyapısını ayarlamanız veya yönetmeniz gerekmez. Her zamanlayıcı kaynağı (Microsoft.DurableTask/schedulers) ayrılmış işlem ve bellek kaynaklarına sahiptir ve bir veya daha fazla görev hub'ı (Microsoft.DurableTask/schedulers/taskHubs) içerebilir.

Dayanıklı Görev Zamanlayıcı depolamayı dahili olarak yönettiğinden, temel alınan verileri doğrudan inceleyemezsiniz. Bunun yerine, düzenleme örneklerini izlemek ve sorgulamak için Dayanıklı Görev Zamanlayıcı panosunu kullanın.

BYO depolama sağlayıcısı seçenekleri ve bunların karşılaştırması hakkında daha fazla bilgi için bkz. Dayanıklı İşlevler depolama sağlayıcıları.

Azure depolama sağlayıcısı

Azure Depolama sağlayıcısı, aşağıdaki bileşenleri kullanarak depolamadaki görev hub'ını temsil eder:

İki Azure Tablo örnek durumlarını depolar.
Bir Azure Kuyruğu etkinlik iletilerini depolar.
Bir veya daha fazla Azure Kuyrukları örnek iletilerini depolar. Bu sözde denetim kuyruklarının her biri, örnek kimliğinin karması temelinde tüm örnek iletilerinin bir alt kümesine atanmış bir bölümü temsil eder.
Kira blobları veya büyük iletiler için kullanılan birkaç ek blob kapsayıcısı.

Örneğin, xyz adlı, PartitionCount = 4 içeren bir görev merkezi aşağıdaki kuyrukları ve tabloları içerir:

Dört denetim kuyruğuna sahip Azure Depolama sağlayıcısı görev hub'ı kuruluşunu gösteren diyagramın ekran görüntüsü.

Aşağıdaki bölümlerde bu bileşenler ve rolleri daha ayrıntılı olarak açıklanmaktadır.

Görev hub'larının Azure Depolama sağlayıcısı tarafından nasıl temsillendiği hakkında daha fazla bilgi için Azure Depolama sağlayıcısı belgelerine bakın.

Netherite depolama sağlayıcısı (Kaldırma süreci)

Netherite, tüm görev hub'ı durumunu belirtilen sayıda bölüme ayırır. Bu kaynaklar depolama alanında verileri depolar:

Bölüme göre gruplandırılmış tüm blobları içeren bir Azure Depolama blob kapsayıcısı.
Bölümlere ilişkin yayımlanan ölçümleri içeren bir Azure Tablosu.
İletileri bölmeler arasında iletmek için bir Azure Event Hubs ad alanı.

Örneğin, mytaskhub adında ve PartitionCount = 32 içeren bir görev hub'ı depolama alanında aşağıdaki gibi temsil edilir:

32 bölüm içeren görev hub'ı için Netherite depolama kuruluşunun gösterildiği diyagramın ekran görüntüsü.

Uyarı

Tüm görev merkezi durumu x-storage blob kapsayıcısında depolanır. DurableTaskPartitions Tablo ve Event Hubs ad alanı yedekli veriler içerir: içerikleri kaybolursa otomatik olarak kurtarılabilir. Bu nedenle, Azure Event Hubs ad alanını varsayılan süre sonu süresinden geçmiş iletileri korumak için yapılandırmanız gerekmez.

Netherite, bir bölümün geçerli durumunu göstermek için bir günlüğe ve denetim noktalarına dayalı bir olay kaynak oluşturma mekanizması kullanır. Hem blok blobları hem de sayfa blobları verileri depolar. Bu biçimi doğrudan depolama alanından okuyamazsınız, bu nedenle örnek deposunu sorgularken işlev uygulamasının çalışıyor olması gerekir.

Netherite depolama sağlayıcısının görev hub'ları hakkında daha fazla bilgi için bkz. Netherite depolama sağlayıcısı için Görev Hub'ı bilgileri.

MSSQL depolama sağlayıcısı

Tüm görev hub'ı verileri, şu tablolar kullanılarak tek bir ilişkisel veritabanında depolanır:

dt.Instances ve dt.History tabloları örnek durumlarını depolar.
Tablo örnek dt.NewEvents iletilerini depolar.
dt.NewTasks Tabloda etkinlik iletileri depolanmıştır.

Veritabanı tabloları içeren MSSQL depolama sağlayıcısı görev hub'ı kuruluşunu gösteren diyagramın ekran görüntüsü.

Birden çok görev hub'ının aynı veritabanında bağımsız olarak bir arada var olmasını sağlamak için, her tablo birincil anahtarının bir parçası olarak bir TaskHub sütun içerir. Diğer iki sağlayıcıdan farklı olarak MSSQL sağlayıcısının bölümleri yoktur.

MSSQL depolama sağlayıcısının görev hub'ları hakkında daha fazla bilgi için bkz. Microsoft SQL (MSSQL) depolama sağlayıcısı için Görev Hub'ı bilgileri.

Sonraki Adımlar

Orkestrasyon sürümlemesini nasıl yöneteceğinizi öğrenin

Sonraki Adımlar

Dayanıklı Görev SDK'larını kullanmaya başlama

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2026-06-03

Görev hub'ları

Görev merkez adları

host.json (İşlevler 2.0)

host.json (İşlevler 1.x)

host.json (İşlevler 2.0)

host.json (İşlevler 1.x)

Ayrı görev hub'larıyla birden çok uygulama kullanma

Dayanıklı Görev Zamanlayıcı görev hub'ı yönetimi

Zamanlayıcı ve görev hub'ı oluşturma

Kimlik tabanlı kimlik doğrulamayı yapılandırma

BYO depolama sağlayıcısı görev hub'ı yönetimi

Görev hub'ları oluşturma ve silme

Görev hub'ı içeriğini inceleme

İş öğeleri

Yürütme örneği

Depolamada gösterim

Dayanıklı Görev Zamanlayıcı sağlayıcısı

Azure depolama sağlayıcısı

Netherite depolama sağlayıcısı (Kaldırma süreci)

MSSQL depolama sağlayıcısı

Sonraki Adımlar

Sonraki Adımlar

Geri Bildirim

Ek kaynaklar