Я использую службы Service Fabric с отслеживанием состояния для хранения сведений о пользователях в системе. Моя стратегия разделения состоит в том, чтобы использовать нормализованный номер телефона в международном строковом формате для обращения к именованному экземпляру службы и хэш номера телефона для разрешения раздела этой службы. ПРИМЕР: Fabric:/myapp/users/1/718 (где международный номер телефона +1718xxxxxxx). Это позволяет мне определять геолокацию сервисов в зависимости от их страны (и далее на рынках США/Канады по коду города).
Мой вопрос носит теоретический, но и практический характер. Кому принадлежит логика разрешения службы? Простой подход заключается в том, чтобы просто потребовать, чтобы любой, кто зависит от этой службы, знал, как она разделена, но мне это кажется дырявой абстракцией. Кроме того, я хотел бы присвоить пользователю идентификатор, который оторван от концепции номера телефона.
- Мой первоначальный подход заключался в том, чтобы сделать идентификатор байтом [], который включал имя службы, идентификатор раздела и локальный идентификатор пользователя. Я отказался от этой идеи, так как размер идентификатора был очень большим и со временем увеличивался. (это проблематично, потому что все ключи в надежном словаре должны помещаться в память, и я бы не хотел убивать тонну памяти для идентификаторов). Кроме того, он по-прежнему несет с собой багаж всех, кто использует идентификатор, зная, как интерпретировать идентификатор и использовать его соответственно.
- Моей следующей идеей было предоставить клиентскую библиотеку всем, кто пользуется услугами. Это также имеет недостаток бинарной зависимости потребляющей службы. Если я хочу изменить стратегию в будущем, мне придется пройти через кучу обручей, чтобы обработать сбои, чтобы правильно разрешить сущность.
- Последняя альтернатива, о которой я могу думать, - это иметь прокси-сервер без сохранения состояния перед службой с отслеживанием состояния, которая обрабатывает разрешение для всех служб. Это наиболее привлекательно с точки зрения дизайна, но также требует управления, создания еще одного сервиса только для решения проблемы. Не против, а как дополнительное соображение. Если я пойду по этому пути, следует ли мне использовать эту службу как отдельное приложение Service Fabric или целесообразно хранить все как одно приложение.
Я также готов принять идею о том, что разделение пользователей таким образом — плохая идея. Однако использование телефона целесообразно по ряду причин.
