Общие сведения о надежных субъектах Service Fabric

Надежные субъекты — это платформа приложений Service Fabric на основе шаблона виртуального субъекта . API Надежных субъектов предоставляет однопоточную модель программирования, основанную на гарантиях масштабируемости и надежности, предоставляемых Service Fabric.

Что такое акторы?

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

Когда следует использовать надежные субъекты

Reliable Actors в Service Fabric — это реализация паттерна проектирования акторов. Как и в случае с любым шаблоном проектирования программного обеспечения, решение о том, использовать ли конкретный шаблон, принимается на основе того, соответствует ли задача проектирования программного обеспечения этому шаблону.

Хотя шаблон проектирования акторов может быть хорошим подходом к ряду проблем и сценариев распределенных систем, следует учитывать ограничения шаблона и фреймворка, который его реализует. В качестве общих рекомендаций рассмотрите шаблон субъекта для моделирования проблемы или сценария, если:

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

Акторы в Service Fabric

В Service Fabric субъекты реализуются в платформе надежных субъектов: платформа приложений на основе шаблонов субъектов, созданная на основе Service Fabric Reliable Services. Каждая служба надежных субъектов, написанная на самом деле, является секционированной, надежной службой с отслеживанием состояния.

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

Срок жизни актора

Субъекты Service Fabric являются виртуальными, то есть их время существования не привязано к их представлению в памяти. В результате они не должны быть явно созданы или уничтожены. Среда выполнения Reliable Actors автоматически активирует актор при первом получении запроса на идентификатор этого актора. Если актор не используется в течение определенного времени, среда выполнения Reliable Actors запускает сборщик мусора для удаления объекта из памяти. Он также будет поддерживать знания о существовании актера, если его нужно будет активировать снова позже. Дополнительные сведения см. в разделе Жизненный цикл актора и сборка мусора.

Эта абстракция времени существования виртуального субъекта содержит некоторые предостережения в результате модели виртуального субъекта, и на самом деле реализация Надежных субъектов иногда отклоняется от этой модели.

• Актер автоматически активируется (что вызывает создание объекта актера) при первой отправке сообщения на его идентификатор. Через некоторое время объект актора подвергается сборке мусора. В будущем использование идентификатора субъекта снова приводит к построению нового объекта субъекта. Состояние субъекта истекает время существования объекта при хранении в диспетчере состояний.
• Вызов любого метода актора для его идентификатора активирует этого актора. По этой причине типы субъектов имеют свой конструктор, вызываемый неявно средой выполнения. Поэтому клиентский код не может передавать параметры конструктору типа субъекта, хотя параметры могут передаваться конструктору субъекта самой службой. В результате акторы могут быть созданы в частично инициализированном состоянии к моменту вызова других методов, если актор требует параметры инициализации от клиента. Нет единой точки входа для активации актера от клиента.
• Хотя надежные субъекты неявно создают объекты субъектов; у вас есть возможность явно удалить субъект и его состояние.

Распределение и переключение при отказе

Чтобы обеспечить масштабируемость и надежность, Service Fabric распределяет субъекты по всему кластеру и автоматически переносит их из неработоспособных узлов в работоспособные. Это абстракция над разделённой надежной службой с сохранением состояния. Распределение, масштабируемость, надежность и автоматическая отработка отказа предоставляются в силу того, что субъекты работают внутри надежной службы с отслеживанием состояния, называемой службой субъектов.

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

Например, служба субъектов с девятью секциями, развернутыми на трех узлах с использованием размещения секций субъекта по умолчанию, будет распределена таким образом:

Платформа Субъектов управляет схемой секционирования и параметрами диапазона ключей. Это упрощает некоторые варианты, но также имеет некоторые аспекты:

• Надежный сервис позволяет выбрать схему разделения, диапазон ключей (при использовании схемы разделения по диапазону) и количество разделов. Надежные акторы ограничены схемой разбиения диапазонов (однородной схемой Int64) и требуют использования полного диапазона ключей Int64.
• По умолчанию субъекты случайным образом помещаются в секции, что приводит к равномерному распределению.
• Так как субъекты размещаются случайным образом, следует ожидать, что операции субъекта всегда требуют сетевого взаимодействия, включая сериализацию и десериализацию данных вызова метода, взимая задержку и издержки.
• В сложных сценариях можно управлять размещением секций субъекта с помощью идентификаторов субъектов Int64, которые сопоставляются с определенными секциями. Однако это может привести к несбалансированному распределению субъектов между секциями.

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

Коммуникация актёров

Взаимодействие акторов определяется в интерфейсе, который поддерживает актер, реализующий интерфейс, и клиент, получающий прокси к актеру через тот же интерфейс. Так как этот интерфейс используется для асинхронного вызова методов субъекта, каждый метод интерфейса должен возвращать задачи.

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

Заместитель актёра

Клиентский API Reliable Actors обеспечивает взаимодействие между экземпляром актора и клиентом актора. Для взаимодействия с субъектом клиент создает прокси-объект субъекта, реализующий интерфейс субъекта. Клиент взаимодействует с субъектом, вызывая методы в прокси-объекте. Прокси актёра можно использовать для общения между клиентом и актёром, а также для общения между актёрами.

// Create a randomly distributed actor ID
ActorId actorId = ActorId.CreateRandom();

// This only creates a proxy object, it does not activate an actor or invoke any methods yet.
IMyActor myActor = ActorProxy.Create<IMyActor>(actorId, new Uri("fabric:/MyApp/MyActorService"));

// This will invoke a method on the actor. If an actor with the given ID does not exist, it will be activated by this method call.
await myActor.DoWorkAsync();

// Create actor ID with some name
ActorId actorId = new ActorId("Actor1");

// This only creates a proxy object, it does not activate an actor or invoke any methods yet.
MyActor myActor = ActorProxyBase.create(actorId, new URI("fabric:/MyApp/MyActorService"), MyActor.class);

// This will invoke a method on the actor. If an actor with the given ID does not exist, it will be activated by this method call.
myActor.DoWorkAsync().get();

Обратите внимание, что два фрагмента информации, используемые для создания прокси-объекта субъекта, являются идентификатором субъекта и именем приложения. Идентификатор актера однозначно определяет актера, а имя приложения идентифицирует приложение Service Fabric, в котором развернут актер.

Класс ActorProxy(C#) / ActorProxyBase(Java) на стороне клиента выполняет необходимое разрешение для поиска субъекта по идентификатору и открытия канала связи с ним. Он также пытается вновь найти актера в случаях сбоев связи и восстановления после отказа. В результате доставка сообщений имеет следующие характеристики:

• Доставка сообщений — это лучшие усилия.
• Субъекты могут получать повторяющиеся сообщения от одного клиента.

Конкурентность

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

• Один экземпляр субъекта не может обрабатывать несколько запросов одновременно. Экземпляр актора может привести к узкому месту по пропускной способности, если ожидается обработка одновременных запросов.
• Субъекты могут взаимоблокировать друг друга, если между двумя субъектами существует циклический запрос, в то время как внешний запрос выполняется к одному из субъектов одновременно. Среда выполнения актора автоматически установит тайм-аут на вызовы актора и вызовет исключение, чтобы прервать возможные ситуации взаимоблокировки.

Пошаговый доступ

Поворот состоит из полного выполнения метода субъекта в ответ на запрос от других субъектов или клиентов, или полное выполнение обратного вызова таймера или напоминания . Несмотря на то, что эти методы и обратные вызовы асинхронны, среда выполнения Actors не пересекает их. Текущий ход должен быть полностью завершен перед началом нового хода. Другими словами, метод актора или обратный вызов таймера/напоминания, который в настоящее время выполняется, должен быть полностью завершен до того, как будет разрешен новый вызов метода или обратного вызова. Метод или обратный вызов считается завершенным, если выполнение возвращается из метода или обратного вызова, а задача, возвращенная методом или обратным вызовом, завершена. Стоит подчеркнуть, что пошаговая параллельность учитывается даже в разных методах, таймерах и обратных вызовах.

Среда выполнения Actors обеспечивает пошаговую параллелизацию, получая блокировку для актера в начале шага и освобождая её в конце шага. Таким образом, пошаговая параллельность применяется на уровне каждого актора, а не между акторами. Методы акторов и обратные вызовы таймера или напоминания могут выполняться одновременно от имени разных акторов.

В следующем примере показаны приведенные выше понятия. Рассмотрим тип субъекта, реализующий два асинхронных метода (например, Method1 и Method2), таймер и напоминание. На приведенной ниже схеме показан пример временной шкалы для выполнения этих методов и обратных вызовов от имени двух субъектов (ActorId1 и ActorId2), принадлежащих этому типу субъекта.

Эта схема следует следующим соглашениям:

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

Некоторые важные моменты, которые следует учитывать:

• Хотя метод1 выполняется от имени ActorId2 в ответ на запрос клиента xyz789, другой запрос клиента (abc123) поступает, который также требует, чтобы Метод1 был выполнен субъектомId2. Однако второе выполнение метода 1 не начинается до завершения предыдущего выполнения. Аналогичным образом, напоминание, зарегистрированное субъектомId2 , запускается в то время как Метод1 выполняется в ответ на запрос клиента xyz789. Обратный вызов напоминания выполняется только после завершения обоих выполнений метода 1 . Всё это связано с принудительным применением пошаговой параллельности для ActorId2.
• Аналогичным образом, последовательное выполнение также обеспечивается для ActorId1, как это демонстрируется выполнением Method1, Method2 и обратного вызова таймера от имени ActorId1, происходящих последовательно.
• Выполнение Метод1 от имени ActorId1 перекрывается его выполнением от имени ActorId2. Это связано с тем, что параллелизм на основе смены применяется только внутри актора, а не между акторами.
• В некоторых случаях выполнения методов или обратных вызовов возвращаемый объект Task(C#) / CompletableFuture(Java) завершается после возврата из метода. В некоторых других операция асинхронной операции уже завершена с момента возврата метода или обратного вызова. В обоих случаях блокировка для каждого актера освобождается только после того, как метод/обратный вызов возвращается и асинхронная операция завершается.

Повторный вход

Среда выполнения Actors по умолчанию разрешает повторный вход. Это означает, что если метод актора A вызывает метод у актора B, который, в свою очередь, вызывает другой метод у актора A, этот метод может быть выполнен. Это связано с тем, что он является частью одного и того же контекста логической цепочки вызовов. Все вызовы для таймера и напоминания начинаются с нового логического контекста вызова. Дополнительные сведения см. в разделе реентерабельности надёжных акторов.

Область гарантий параллелизма

Среда выполнения Actors предоставляет эти гарантии параллелизма в ситуациях, когда она управляет вызовом этих методов. Например, он предоставляет эти гарантии для вызовов методов, выполненных в ответ на запрос клиента, а также для обратных вызовов таймера и напоминаний. Однако если код субъекта напрямую вызывает эти методы вне механизмов, предоставляемых средой выполнения Actors, среда выполнения не может обеспечить какие-либо гарантии параллелизма. Например, если метод вызывается в контексте какой-то задачи, которая не связана с задачей, возвращаемой методами субъекта, среда выполнения не может обеспечить гарантии параллелизма. Если метод вызывается из потока, который субъект создает самостоятельно, среда выполнения также не может обеспечить гарантии параллелизма. Таким образом, для выполнения фоновых операций акторы должны использовать таймеры акторов и напоминания акторов, которые поддерживают поочередный параллелизм.

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

Начало работы с созданием первой службы Надежных акторов:

• Начало работы с надежными акторами в .NET
• Начало работы с надежными акторами на Java