2015-11-27 2 views
2

Простой пример: у меня есть служба, насчитывающая 1 000 000 пользователей, и у каждого пользователя есть информация о профиле. Я хочу управлять операциями CRUD с данными этого профиля с помощью участников.Грамотность актера в Azure Service Fabric vs Project Orleans

В проекте Орлеана, я понимаю, что у меня будет одно зерна для каждого пользователя, так 1,000,000 виртуальных зерен одного и того же типа актера (который будет создан только если используются), и каждое зерно будет управлять информацией профиля один пользователь, сохраненный в его состоянии. По мере роста моих пользователей, так же как и количество зерен.

В Сервисная ткань, если я интерпретирую документацию правильно, она будет работать несколько иначе. У меня был бы тип состояния с состоянием, который управлял операциями CRUD с всеми пользователями, а для масштабируемости я бы разбил актера, предоставляя каждому разделу ответственность за подмножество пользовательских данных. Учитывая partition options, я не вижу очевидного способа реализовать его таким же мелкомасштабным способом, как Project Orleans.

Мне очень нравится подход в Проекте Орлеан. Актер просто обрабатывает данные для одного пользователя, а масштабируемость очевидна (больше пользователей равно больше зерен). Модель памяти также проста: один актер гидратируется по требованию с небольшим количеством состояний.

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

Так что мой вопрос: правильно ли я понимаю, что актеры в Service Fabric просто более грубые, чем Project Orleans?

Update

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

ответ

5

ActorType фактически размещен в Сервисе. Эта служба разделена. Каждый раздел будет содержать несколько экземпляров вашего ActorType (в соответствии с указанными диапазонами и количеством разделов).

Используя API вы можете заполучить экземпляр актера (вы не должны явно создать):

var actor = ActorProxy.Create<IActorType>(new ActorId("some id"), "fabric:/application"); 

В Орлеане, ваши зерна разбросаны по Шило без пакетирования их в перегородках.Поэтому Орлеан может переместить один экземпляр на другой Силос, если захочет. В Service Fabric все это делается на уровне раздела. Таким образом, все экземпляры в разделе перемещаются вместе.

+1

Спасибо Мичиэлю, это прояснило для меня все. –

2

Я не знаю много о Проекте Орлеан, но я думаю, что вы, возможно, путали понятие актера и типа актера в Service Fabric.

Актер - это экземпляр типа актера - отношение аналогично классам и объектам в объектно-ориентированных языках.

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

+0

Спасибо за ответ, я понимаю, что разница, но на самом деле ваш ответ просто щелкнул для меня. Я собираюсь запустить некоторые тесты и обновить свой вопрос. –

+1

Привет, Charisk, после нескольких тестов, а также с ответом Михеля, я могу лучше оценить то, что говорил ваш последний абзац. Он также ответил на мой вопрос, но я отметил Мичиэля как ответ, потому что это было немного яснее для меня. Благодаря! –

+0

Делает смысл :) радостные вещи яснее – charisk

Смежные вопросы