Как надежные субъекты используют платформу Service Fabric

В этой статье объясняется, как надежные субъекты работают на платформе Azure Service Fabric. Надежные субъекты выполняются в платформе, размещенной в реализации надежной службы с отслеживанием состояния, называемой службой субъектов. Служба субъектов содержит все компоненты, необходимые для управления жизненным циклом и отправкой сообщений для субъектов:

  • Среда выполнения субъекта управляет жизненным циклом, сборкой мусора и обеспечивает однопоточный доступ.
  • Сервис удаленного прослушивания службы актеров принимает вызовы удаленного доступа к актерам и отправляет их диспетчеру для маршрутизации к соответствующему экземпляру актера.
  • Поставщик состояний субъекта упаковывает поставщиков состояний (например, поставщика состояний Reliable Collections) и предоставляет адаптер для управления состоянием субъекта.

Эти компоненты вместе образуют платформу Reliable Actor.

Уровни служб

Так как сама служба субъектов является надежной службой, все модели приложений, жизненный цикл, упаковка, развертывание, обновление и масштабирование надежных служб применяются так же, как и к службам субъектов.

Многослойная архитектура сервисов акторов

На предыдущей схеме показана связь между платформами приложений Service Fabric и пользовательским кодом. Синие элементы представляют платформу приложений Reliable Services, оранжевый представляет платформу Reliable Actor, а зеленый — пользовательский код.

В Надежных сервисах ваша служба наследует класс StatefulService. Этот класс является производным от StatefulServiceBase (или StatelessService для бессостоянных служб). В Надежных акторах вы используете службу акторов. Актор-сервис — это другая реализация StatefulServiceBase класса, реализующего шаблон акторов, где выполняются акторы. Так как сама служба субъектов является просто реализацией StatefulServiceBase, вы можете написать собственную службу, наследуемую от ActorService и реализующую функции уровня обслуживания так же, как и при наследовании StatefulService, например:

  • Резервное копирование и восстановление службы.
  • Общая функциональность для всех участников, например, автоматический выключатель.
  • Удаленные вызовы процедур на службе акторов и на каждом отдельном актере.

Дополнительные сведения см. в разделе "Реализация функций уровня обслуживания" в актёрной службе.

Модель приложения

Службы субъектов являются надежными службами, поэтому модель приложения одинакова. Однако инструменты сборки каркаса акторов генерируют некоторые файлы модели приложения.

Манифест службы

Средства сборки платформы акторов автоматически создают содержимое файла ServiceManifest.xml акторного сервиса. Этот файл включает в себя:

  • Тип службы актера. Имя типа создается на основе имени проекта актера. На основе атрибута сохраняемости для актора флаг HasPersistedState устанавливается соответствующим образом.
  • Пакет кода.
  • Пакет конфигурации.
  • Ресурсы и конечные точки.

Манифест приложения

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

  • Число наборов реплик определяется атрибутом постоянства для актера. Каждый раз, когда атрибут сохраняемости для актора изменяется, количество наборов реплик в определении службы по умолчанию сбрасывается соответствующим образом.
  • Для схемы секционирования и диапазона задано значение Uniform Int64 с полным диапазоном ключей Int64.

Концепции разделения Service Fabric для актеров

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

Секционирование субъектов и распределение

Надежные службы можно создавать с различными схемами секционирования и диапазонами ключей разбиения. Служба акторов использует схему разделения Int64 с полным диапазоном ключей Int64 для сопоставления акторов с разделами.

Идентификатор актера

Каждый актор, созданный в службе, имеет уникальный идентификатор, ассоциированный с ним, представленный классом ActorId. ActorId — это непрозрачное значение идентификатора, которое можно использовать для равномерного распределения субъектов по секциям служб путем создания случайных идентификаторов:

ActorProxy.Create<IMyActor>(ActorId.CreateRandom());

ActorProxyBase.create<MyActor>(MyActor.class, ActorId.newId());

Каждый ActorId хэшируется в Int64. Поэтому служба субъектов должна использовать схему секционирования Int64 с полным диапазоном ключей Int64. Однако для пользовательских значений идентификаторов можно использовать ActorID, включая идентификаторы GUID/UUID, строки и Int64.

ActorProxy.Create<IMyActor>(new ActorId(Guid.NewGuid()));
ActorProxy.Create<IMyActor>(new ActorId("myActorId"));
ActorProxy.Create<IMyActor>(new ActorId(1234));

ActorProxyBase.create(MyActor.class, new ActorId(UUID.randomUUID()));
ActorProxyBase.create(MyActor.class, new ActorId("myActorId"));
ActorProxyBase.create(MyActor.class, new ActorId(1234));

При использовании идентификаторов GUID/UUID и строк значения хэшируются в int64. Однако, когда вы явно предоставляете Int64 в ActorId, Int64 будет сопоставляться напрямую с разделом без дополнительного хеширования. Этот метод можно использовать, чтобы контролировать, в какой раздел помещаются актеры.

Дальнейшие действия

  • Last updated on