Локально кэшированный stateManager ... есть ли риск в Service Fabric? - PullRequest
Новая
       36

Локально кэшированный stateManager ... есть ли риск в Service Fabric?

0 голосов
/ 14 февраля 2019

То, что кажется обычной практикой, может быть неправильно в Service Fabric.Я подозреваю, что приведенный ниже код, в котором stateManager сохраняется как локальный кеш, может вызвать потенциальную проблему, когда создается экземпляр класса Startup в операторе возврата метода CreateServiceReplicaListeners () в службе состояний SomeService.

Ситуация, которая может случиться, - когда государственный менеджер каким-то образом воссоздан.Мне нужно больше объяснений относительно того, является ли приведенная ниже практика правильной или нет.Если нет, то что может быть лучшей практикой вместо этого? 

internal class SomeService : StatefulService
{
    protected  override IEnumerable<ServiceReplicaListener> CreateServiceReplicaListeners()
    {
        return new[]{
            new ServiceReplicaListener(
                        initParams =>
                            new OwinCommunicationListener("SomeService", new Startup(this.StateManager), initParams))
                };
        }
    }
}

public class Startup : IOwinAppBuilder
{
    private readonly IReliableStateManager stateManager;

    public Startup(IReliableStateManager stateManager)
    {
        this.stateManager = stateManager;
    }

    public void Configuration(IAppBuilder appBuilder)
    {
        // other initialization codes..
        ...
        ...

        UnityConfig.RegisterComponents(config, this.stateManager);

        appBuilder.UseWebApi(config);
    }
}

1 Ответ

0 голосов
/ 15 февраля 2019

Всякий раз, когда Служба с отслеживанием состояния меняет роли, она запускает IStatefulServiceReplica.ChangeRoleAsync(ReplicaRole newRole, CancellationToken cancellationToken).

ChangeRoleAsync(..) гарантирует, что новая роль используетдля правильной связи выполните следующие действия:

  • Позвоните CloseCommunicationListenersAsync(CancellationToken cancellationToken), чтобы закрыть все открытые слушатели
  • Позвоните OpenCommunicationListenersAsync(newRole, cancellationToken) для Основной или ActiveSecondary роли
  • Метод OpenCommunicationListenersAsync() вызовет CreateServiceReplicaListeners() для получения слушателей и вызова CreateCommunicationListener(serviceContext)для каждого возвращенного слушателя открыть соответствующие конечные точки.

Смена ролей очень часто происходит во время обновлений и балансировки нагрузки, поэтому это очень распространенное событие.

В итоге,

Каждый раз, когда происходит смена роли, будет вызываться CreateServiceReplicaListeners(), ChangeRole не отключает службу, поэтому она может иметь побочные эффекты,например, если вы регистрируете зависимости в контейнере DI, вы можете столкнуться с дублирующимися регистрациями.

...