Служба Service Fabric и субъекты Service Fabric для представления пользователей

В моем приложении пользователи могут публиковать события на карте. Точка входа приложения — это служба веб-API без сохранения состояния. Для внутреннего представления пользователей я хочу иметь пользовательский сервис. Когда следует использовать Reliable Stateful Actors и когда Reliable Stateful Services для хранения данных профиля и опубликованных событий каждого пользователя?

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

Например:

Client/User --> WebApiService --> UserService/UserActor --> EventService

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

Client/User <-- WebApiService <-- EventService

Поскольку события имеют географическую привязку, я хочу разделить EventService на основе геокодов или чего-то подобного.

Какую модель программирования (актор и/или сервис) следует предпочесть для такого приложения и почему?


person CPA    schedule 24.01.2016    source источник


Ответы (1)


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

Для вашего сервиса событий да, вы, безусловно, можете разделить по географическим координатам. Один из способов, которым я делал это в прошлом, — преобразовывать геокоординаты в quadkeys, которые являются удобным способом представления двумерных пространственных данных в одномерном ключе. Однако имейте в виду, что вы можете получить локальные точки доступа, которые могут вызвать некоторую кластеризацию в ваших разделах (большинство ваших пользователей сосредоточено вокруг крупных городов? Если да, в этих разделах будет больше данных, чем в других).

person Vaclav Turecek    schedule 25.01.2016
comment
Какая причина использовать актеров в этом примере? Я читал о локальных точках доступа в вашей документации. Но для данного примера с геокоординатами. Как я могу избежать этих горячих точек? Я знаю, что не смогу изменить количество разделов позже, но можно ли позже настроить новые имена разделов? - person CPA; 26.01.2016
comment
Один из способов избежать горячих точек — использовать хороший алгоритм хеширования для генерации ключей. - person cdaq; 27.09.2016