Dayanıklı İşlevler görev hub'ları (Azure İşlevleri)

Makale
05/05/2023

Dayanıklı İşlevler'dekibir görev hub'ı, bekleyen tüm çalışmalar da dahil olmak üzere uygulamanın depolamadaki geçerli durumunun bir gösterimidir. İşlev uygulaması çalışırken düzenleme, etkinlik ve varlık işlevlerinin ilerleme durumu sürekli olarak görev hub'ında depolanır. Bu, uygulamanın herhangi bir nedenle geçici olarak durdurulduktan veya kesintiye uğradıktan sonra yeniden başlatılması gerekiyorsa işlemeye kaldığı yerden devam etmesini sağlar. Ayrıca işlev uygulamasının işlem çalışanlarını dinamik olarak ölçeklendirmesine olanak tanır.

İşlev uygulaması kavramını ve görev hub'ı kavramını gösteren diyagram.

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

Tüm düzenleme ve varlık örneklerinin örnek durumları .
İşlenecek iletiler,
- çalıştırılmayı bekleyen etkinlikleri temsil eden tüm etkinlik iletileri .
- örneklere teslim edilmeyi bekleyen tüm örnek iletileri .

Etkinlik ile örnek iletileri arasındaki fark, etkinlik iletilerinin durum bilgisi olmayan olması ve bu nedenle her yerde işlenebildiği, örnek iletilerinin ise örnek kimliğiyle tanımlanan belirli bir durum bilgisi olan örneğe (düzenleme veya varlık) teslim edilmesi gerektiğidir.

Dahili olarak, her depolama sağlayıcısı örnek durumlarını ve iletilerini temsil etmek için farklı bir kuruluş kullanabilir. Örneğin, iletiler Azure Depolama sağlayıcısı tarafından Azure Depolama Kuyruklarında, ANCAK MSSQL sağlayıcısı tarafından ilişkisel tablolarda depolanır. Bu farklılıklar, uygulamanın tasarımı açısından önemli değildir, ancak bazıları performans özelliklerini etkileyebilir. Bunları aşağıdaki Depolamada temsil bölümünde ele alıyoruz.

İş öğeleri

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

Etkinlik iş öğeleri: Etkinlik iletisini işlemek için bir etkinlik işlevi çalıştırın.
Orchestrator iş öğesi: Bir veya daha fazla örnek iletisini işlemek için bir düzenleyici veya varlık işlevi çalıştırın.

Ç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.

Bir çalışan bir iş öğesini tamamladıktan sonra, etkileri görev hub'ına geri işler. Bu etkiler, yürütülen işlevin türüne göre farklılık gösterir:

Tamamlanmış etkinlik işlevi, üst düzenleyici örneğine yönelik sonucu içeren bir örnek iletisi oluşturur.
Tamamlanmış 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ütmesinin bir bölümünü temsil eder. Düzenleyicinin işlemesi gereken yeni iletiler olduğunda bir bölüm başlar. Böyle bir ileti düzenlemenin başlaması gerektiğini gösterebilir; veya bir etkinliğin, varlık çağrısının, süreölçerin veya alt toplamın tamamlandığını gösterebilir; veya bir dış olayı temsil edebilir. İleti, düzenleyicinin sonucu işlemesine ve sonraki bölüme devam etmesine olanak tanıyan bir iş öğesini tetikler. Düzenleyici tamamlandığında veya yeni iletileri beklemesi gereken bir noktaya ulaştığında bu bölüm sona erer.

Yürütme örneği

İki etkinliği paralel olarak başlatan ve ikisinin de tamamlanmasını bekleyen bir fan-out-in düzenlemesi 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();
}

Bu düzenleme bir istemci tarafından başlatıldıktan sonra işlev uygulaması tarafından bir iş öğeleri dizisi olarak işlenir. Tamamlanan her iş öğesi işlendiğinde görev hub'ı durumunu güncelleştirir. Bu 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'ı düzenleme durumu için bir yer tutucu ve bir örnek iletisi içerir:

Etiket ExecutionStarted , bir düzenlemenin geçmişine katılan çeşitli ileti ve olay türlerini tanımlayan birçok geçmiş 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 etkinlik zamanlar ve sonuçları beklerken yürütmeyi durdurur. Çalışan bu iş öğesini işledikten sonra görev hub'ı

Çalışma zamanı durumu artık Running, iki yeni TaskScheduled ileti eklendi ve geçmiş artık beş olayı OrchestratorStartediçerir: , ExecutionStartedTaskScheduled, , TaskScheduled, OrchestratorCompleted. Bu olaylar, bu düzenlemenin yürütülmesinin ilk bölümünü temsil eder.
Çalışan, iletilerden birini işlemek için bir etkinlik iş öğesi yürütür TaskScheduled . "2" girişiyle etkinlik işlevini çağırır. Etkinlik işlevi tamamlandığında sonucu içeren bir TaskCompleted ileti oluşturur. Çalışan bu iş öğesini işledikten sonra görev hub'ı
Çalışan, iletiyi işlemek için bir düzenleyici iş öğesi yürütür TaskCompleted . Düzenleme hala bellekte önbelleğe alınmışsa yürütmeyi sürdürebilir. Aksi takdirde, çalışan önce düzenlemenin geçerli durumunu kurtarmak için geçmişi yeniden yürüter. 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. Çalışan bu iş öğesini işledikten sonra görev hub'ı

Düzenleme geçmişi artık üç olay OrchestratorStarteddaha içerir: , TaskCompletedOrchestratorCompleted. Bu olaylar, bu düzenlemenin yürütülmesinin ikinci bölümünü temsil eder.
Çalışan, kalan TaskScheduled iletiyi işlemek için bir etkinlik iş öğesi yürütür. "1" girişiyle etkinlik işlevini çağırır. Çalışan bu iş öğesini işledikten sonra görev hub'ı
Çalışan, iletiyi işlemek için başka bir düzenleyici iş öğesini yürütür TaskCompleted . Bu ikinci sonucu aldıktan sonra düzenleme tamamlanır. Çalışan bu iş öğesini işledikten sonra görev hub'ı

Çalışma zamanı durumu şimdi Completedve düzenleme geçmişi artık dört olay OrchestratorStarteddaha içeriyor: , TaskCompleted, ExecutionCompleted. OrchestratorCompleted Bu olaylar, bu düzenlemenin yürütülmesinin üçüncü ve son bölümünü temsil eder.

Bu düzenlemenin yürütmesinin son geçmişi 12 olayı OrchestratorStarted, , ExecutionStarted, TaskScheduled, TaskScheduled, OrchestratorCompleted, , OrchestratorStarted, TaskCompleted, OrchestratorCompleted, ExecutionCompletedOrchestratorStartedTaskCompleted, OrchestratorCompletediçerir.

Not

Gösterilen zamanlama tek zamanlama değildir: çok az sayıda farklı olası zamanlama vardır. Örneğin, ikinci etkinlik daha önce tamamlanırsa, her iki örnek iletisi de TaskCompleted tek bir iş öğesi tarafından işlenebilir. Bu durumda yürütme geçmişi biraz daha kısadır çünkü yalnızca iki bölüm vardır ve şu 10 olayı içerir: OrchestratorStarted, , ExecutionStarted, TaskScheduled, TaskScheduled, OrchestratorCompleted, OrchestratorStarted, TaskCompleted, TaskCompleted, , ExecutionCompleted. OrchestratorCompleted

Görev hub'ı yönetimi

Şimdi görev hub'larının nasıl oluşturulduğuna veya silindiğine, birden çok işlev uygulaması çalıştırılırken görev hub'larının nasıl doğru kullanılacağına ve görev hub'larının içeriğinin nasıl denetlenebileceğine daha yakından bakalım.

Oluşturma ve silme

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

Varsayılan 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 gereken depolama kaynaklarını düzgün bir şekilde sağlayıp erişebildiğinden emin olmak için depolama sağlayıcılarını yapılandırma yönergelerini izleyin.

Not

İşlev uygulamasını durdurduğunuzda veya sildiğinizde görev hub'ı otomatik olarak silinmez. Bu verileri artık saklamak istemiyorsanız görev hub'ını, içeriğini veya içeren depolama hesabını el ile silmeniz gerekir.

İpucu

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ştirebilirsiniz. Bu, uygulamayı yeniden başlattığınızda yeni, boş bir görev hub'ı oluşturmaya zorlar. Bu durumda eski verilerin silinmediğini unutmayın.

Birden çok işlev uygulaması

Birden çok işlev uygulaması bir depolama hesabını paylaşıyorsa, her işlev uygulamasının ayrı bir görev hub'ı adıyla yapılandırılması gerekir. Bu gereksinim hazırlama yuvaları için de geçerlidir: her hazırlama yuvası benzersiz bir görev hub'ı adıyla yapılandırılmalıdır. Tek bir depolama hesabı birden çok görev hub'ı içerebilir. Bu kısıtlama genellikle diğer depolama sağlayıcıları için de geçerlidir.

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ış depolama hesaplarını gösteren diyagram.

Not

Görev hub'ı paylaşım kuralının istisnası, uygulamanızı bölgesel olağanüstü durum kurtarma için yapılandırıyor olmanızdır. Daha fazla bilgi için olağanüstü durum kurtarma ve coğrafi dağıtım makalesine bakın.

İçerik 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 temel alınan depolamaya giderek görev hub'ını incelemek de mümkündür:

Azure Depolama sağlayıcısı kullanılıyorsa örnek durumları Örnek Tablosu'nda ve Geçmiş Tablosu'nda depolanır ve Azure Depolama Gezgini gibi araçlar kullanılarak incelenebilir.
MSSQL depolama sağlayıcısı kullanılıyorsa SQL sorguları ve araçları, veritabanı içindeki görev hub'ı içeriğini incelemek için kullanılabilir.

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. Bir işlev uygulamasında sorun giderirken veya performans, ölçeklenebilirlik veya maliyet hedeflerini sağlamaya çalışırken bu kuruluşu anlamak gerekli olmasa da yararlı olabilir. Bu nedenle, her depolama sağlayıcısı için verilerin depolamada nasıl düzenlendiğinden kısaca açıklayacağız. Çeşitli 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:

Örnek durumlarını iki Azure Tablosu depolar.
Etkinlik iletilerini bir Azure Kuyruğu depolar.
Bir veya daha fazla Azure Kuyruğu ö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ı ve/veya büyük iletiler için kullanılan birkaç ek blob kapsayıcısı.

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

4 denetim kuyruğu için Azure Depolama sağlayıcısı depolama düzenlemesini gösteren diyagram.

Ardından, bu bileşenleri ve oynadıkları rolü daha ayrıntılı bir şekilde açıklayacağız.

Görev hub'larının Azure Depolama sağlayıcısı tarafından nasıl temsil edildiklerine ilişkin daha fazla bilgi için Bkz. Azure Depolama sağlayıcısı belgeleri.

Netherite depolama sağlayıcısı

Netherite, tüm görev hub'ı durumunu belirtilen sayıda bölüme böler. Depolama alanında aşağıdaki kaynaklar kullanılır:

Bölüme göre gruplandırılmış tüm blobları içeren bir Azure Depolama blob kapsayıcısı.
Bölümler hakkında yayımlanan ölçümleri içeren bir Azure Tablosu.
Bölümler arasında ileti teslim etmek için bir Azure Event Hubs ad alanı.

Örneğin, ile PartitionCount = 32 adlı mytaskhub bir görev hub'ı depolama alanında aşağıdaki gibi temsil edilir:

32 bölüm için Netherite depolama kuruluşunu gösteren diyagram.

Not

Görev hub'ı durumunun tümü blob kapsayıcısının x-storage içinde depolanır. DurableTaskPartitions Tablo ve EventHubs ad alanı yedekli veriler içerir: içerikleri kaybolursa otomatik olarak kurtarılabilir. Bu nedenle, Azure Event Hubs ad alanını iletileri varsayılan süre sonu süresinden sonra tutmak için yapılandırmak 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ı kullanılır. Bu biçimi doğrudan depolama alanından okumak mümkün olmadığından işlev uygulamasının örnek deposunu sorgularken ç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, birkaç tablo 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.

MSSQL depolama kuruluşunu gösteren diyagram.

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üm kavramı 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.

Görev hub'ı adları

Görev hub'ları, şu kurallara uyması gereken 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

Görev hub'ı adı, aşağıdaki örnekte gösterildiği gibi host.json dosyasında bildirilir:

host.json (İşlevler 2.0)

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

host.json (İşlevler 1.x)

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

Görev hub'ları, aşağıdaki host.json örnek dosyada gösterildiği gibi uygulama ayarları kullanılarak da yapılandırılabilir:

host.json (İşlevler 1.0)

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

host.json (İşlevler 2.0)

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

Görev hub'ı adı, uygulama ayarının MyTaskHub değerine ayarlanır. Aşağıda local.settings.json ayarın MyTaskHub olarak samplehubnamenasıl tanımlanacağı gösterilmektedir:

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

Not

Dağıtım yuvalarını kullanırken, uygulama ayarlarını kullanarak görev hub'ı adını yapılandırmak en iyi yöntemdir. Belirli bir yuvanın her zaman belirli bir görev hub'ı kullandığına emin olmak istiyorsanız , "yuva yapışkan" uygulama ayarlarını kullanın.

Host.json'a ek olarak, görev hub'ı adları da orchestration istemci bağlama meta verilerinde yapılandırılabilir. Bu, ayrı bir işlev uygulamasında bulunan düzenlemelere veya varlıklara erişmeniz gerekiyorsa kullanışlıdır. Aşağıdaki kod, Uygulama Ayarı olarak yapılandırılmış 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);
}

Not

Önceki örnek Dayanıklı İşlevler 2.x içindir. Dayanıklı İşlevler 1.x için yerine IDurableOrchestrationContextkullanmanız DurableOrchestrationContext gerekir. 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 Uygulama Ayarı aracılığıyla ayarlanır:

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

Not

Bu örnek, Dayanıklı İşlevler sürüm 2.x'i hedefler. Sürüm 1.x'te yerine durableClientkullanınorchestrationClient.

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

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

Not

Bu örnek, Dayanıklı İşlevler sürüm 2.x'i hedefler. Sürüm 1.x'te yerine durableClientkullanınorchestrationClient.

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

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

Not

Bu örnek, Dayanıklı İşlevler sürüm 2.x'i hedefler. Sürüm 1.x'te yerine durableClientkullanınorchestrationClient.

@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);
}

Not

görev hub'ı adlarını istemci bağlama meta verilerinde yapılandırmak 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üzenleme ve varlıklarla aynı işlev uygulamasında tanımlanıyorsa, bağlama meta verilerinde görev hub'ı adlarını belirtmekten kaçınmanız gerekir. Varsayılan olarak, tüm istemci bağlamaları görev hub'ı meta verilerini host.json ayarlarından alır.

Görev hub'ı adları bir harfle başlamalı ve yalnızca harf ve sayılardan oluşmalıdı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'da dağıtıldığında, görev hub'ı adı işlev uygulamasının adından türetilir. Azure dışında çalışırken varsayılan görev hub'ı adı şeklindedir `TestHubName`.
1.x	Tüm ortamlar için varsayılan görev hub'ı adı şeklindedir `DurableFunctionsHub`.

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

Not

Paylaşılan depolama hesabında birden çok görev hub'ı olduğunda bir görev hub'ını diğerinden ayıran addır. Paylaşılan depolama hesabını paylaşan birden çok işlev uygulamanız varsa, host.json dosyalarındaki her görev hub'ı için açıkça farklı adlar yapılandırmanız gerekir. Aksi takdirde, birden çok işlev uygulaması iletiler için birbirleriyle rekabet eder ve bu da düzenlemelerin veya Running durumunda beklenmedik bir şekilde "takılması" da dahil olmak üzere tanımsız davranışlara Pending neden olabilir.

Sonraki adımlar

Düzenleme sürümü oluşturma işleminin nasıl işlendiğini öğrenin

Share via

Dayanıklı İşlevler görev hub'ları (Azure İşlevleri)

İş öğeleri

Yürütme örneği

Görev hub'ı yönetimi

Oluşturma ve silme

Birden çok işlev uygulaması

İçerik inceleme

Depolamada gösterim

Azure Depolama sağlayıcısı

Netherite depolama sağlayıcısı

MSSQL depolama sağlayıcısı

Görev hub'ı adları

host.json (İşlevler 2.0)

host.json (İşlevler 1.x)

host.json (İşlevler 1.0)

host.json (İşlevler 2.0)

Sonraki adımlar

Ek kaynaklar