SignalR Актеры или службы без гражданства

Question

Я изучаю миграцию приложения на сервисную ткань, работающую на Azure. Это приложение чата в реальном времени, использующее SignalR. Я хотел бы иметь экземпляр службы, выполняющей сам хостинг концентратора SignalR (через OWIN) для каждой «группы сродства», в которой пользователи общаются. Поэтому я могу избежать масштабирования SignalR с объединительной платой. Я бы хотел, чтобы эти функции были развернуты вверх и вниз, так как группы пользователей вошли и покинули мое приложение. Я бы ожидал, что я смогу разместить десятки этих сервисов на виртуальную машину с типичной нагрузкой сотен пользователей на группу.

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

Как я могу создать это в Service Fabric на Azure, чтобы а) каждый из сервисов/актеров доступный с помощью клиента SignalR из Интернета? и б) у меня работает только столько сервисов, сколько необходимо, чтобы обслуживать m активных групп из n всего групп? Требование к этому приложению очень кратковременное и острое, поэтому я надеюсь воспользоваться тем фактом, что услуги - это просто процессы и могут быть предоставлены в течение нескольких секунд против моего текущего сценария, когда мне приходится раскручивать все облачные сервисы и ждать десятки минут, чтобы справиться с шипами (на которые указывают, что это слишком поздно)

Answer 1

Вы бы сделать несколько вещей:

• есть «сервис менеджер службы», что перехваченный первоначальные запросы присоединиться и создал новую службу Тканевые услуги «на лету», если они еще не существуют ИЛИ если они уже существуют, разрешают текущее местоположение службы, а затем возвращают этот адрес клиенту

  • В качестве альтернативы, они могли бы просто передать имя внутренней службы (если вы хорошо разбираетесь в этой информации), и клиент может выполнить разрешение, а затем соединение. В какой-то степени это будет зависеть от того, как много информации вы хотите выставить клиенту, можете ли вы или хотите изменить его «знать о» Service Fabric и т.д.

• Затем клиент будет подключаться к фактическая базовая услуга напрямую

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

• Возможно, вам было бы лучше моделировать чат-сервис как надежную услугу, а не как актер, поскольку стек надежных служб обеспечивает большую гибкость в отношении протоколов/стеков.