Service Fabric — это отдельный экземпляр службы с отслеживанием состояния на раздел.

Я пытаюсь переварить архитектурные шаблоны Service Fabric и их лучшие практики.

вариант использования:

Я определяю службу с отслеживанием состояния с 26 разделами, и в каждом разделе я храню слова с одинаковыми первыми буквами.

  • 1) Означает ли это, что у меня на самом деле есть 26 экземпляров службы с отслеживанием состояния?
  • 2) Находясь за пределами службы с отслеживанием состояния, т. е. в вызывающем объекте, я создаю URI для своего клиента структуры служб, указывая идентификатор раздела, с которым я хочу, чтобы клиент работал. Означает ли это, что когда я нахожусь в контексте службы с отслеживанием состояния (т. е. экземпляр службы, созданный и вызываемый службой с отслеживанием состояния), я не могу ссылаться на другие разделы?

  • 3) Верно ли сказать, что служба с отслеживанием состояния — это единица работы, которой нужно знать, с каким разделом работать, и которая не может принимать решения самостоятельно? Здесь я имею в виду множество примеров, когда внутри метода RunAsync службы с отслеживанием состояния есть вызовы базового надежного хранилища, например, код, взятый из этого поста:

    protected override async Task RunAsync(CancellationToken cancelServicePartitionReplica)
{
var myDictionary = await   this.StateManager.GetOrAddAsync<IReliableDictionary<string, int>> ("myDictionary");

var partition = base.ServicePartition.PartitionInfo.Id;
byte append = partition.ToByteArray()[0];

while (!cancelServicePartitionReplica.IsCancellationRequested)
{

// Create a transaction to perform operations on data within this partition's replica.
using (var tx = this.StateManager.CreateTransaction())
{
    var result = await myDictionary.TryGetValueAsync(tx, "A");

    await myDictionary.AddOrUpdateAsync(tx, "A", 0, (k, v) => v + append);
    ServiceEventSource.Current.ServiceMessage(this,
        $"Append {append}: {(result.HasValue ? result.Value : -1)}");
    await tx.CommitAsync();
}

// Pause for 1 second before continue processing.
    await Task.Delay(TimeSpan.FromSeconds(3),  cancelServicePartitionReplica);
    }
}

Итак, вероятно, мое утверждение 3) неверно. Служба с отслеживанием состояния может вызывать свое внутреннее хранилище без того, чтобы кто-то (клиент службы) вызывал ее извне и предоставлял информацию для точного раздела. Но тогда как приведенный выше код решает, в какой раздел поместить свои данные? И, самое главное, как позже запросить эти данные через клиент службы, который должен предоставить точный идентификатор раздела?


azure-service-fabric
person akrsmv    schedule 12.06.2016    source источник
comment
а) Не эксперт, но я думаю, что разделение (в данном случае) связано с тем, как данные распределяются (через IReliableStateManager) между экземплярами (технически называемыми репликами) в одном разделе. У вас может быть две реплики на раздел, чтобы реплика A_1 (на узле 1) и реплика A_2 (на узле 2) могли обмениваться данными друг с другом. Но A_1 не смог поделиться данными с B_1 b) Я думаю, у вас может быть слишком много вопросов в вашем вопросе :)   -  person Philip Pittle    schedule 12.06.2016

Ответы (1)


arrow_upward
5
arrow_downward

Экземпляры службы с отслеживанием состояния на самом деле являются репликами. Вы настраиваете количество реплик для каждого раздела (для производительности, масштабирования, высокой доступности и аварийного восстановления). Записывает только одна реплика (основная). Все реплики (вторичные и первичные) могут использоваться для чтения. Реплика содержит осколок вашего набора данных. Данные в разделе 1 не используются совместно с разделом 2.

Клиенты, вызывающие службы с отслеживанием состояния, должны сами решить, с каким разделом они хотят взаимодействовать. Службы могут читать/записывать только в своем собственном разделе (напрямую).

Подробнее здесь.

person LoekD    schedule 12.06.2016