Вопрос проектирования сервисного уровня - PullRequest
Новая
       34

Вопрос проектирования сервисного уровня

0 голосов
/ 13 мая 2011

Я ищу решение .NET для следующего сценария. Ожидайте любые известные рамки, решения или некоторые идеи дизайна для разработки этого компонента.

У нас есть служба WCF, которая выполняет обратные вызовы для клиентов, подключенных для обновления их пользовательского интерфейса. Простой пример: когда, скажем, 10 пользователей подключены к этой службе, а 1 пользователь обновляет запись в сетке и сохраняет ее, служба выполняет обратный вызов для обновления пользовательского интерфейса в других 9 клиентах. Этот сервис делает много разных вещей, и поэтому прямые связи с клиентами замедляют это, и мы видим некоторые проблемы по мере роста числа клиентов. Итак, мы думаем добавить еще один уровень, с которым клиент и служба общаются для прослушивания и трансляции своих сообщений / событий.

Я ищу решение, где, например, шина сообщений, брокер сообщений или инфраструктура или идея модели pub-sub, где клиент и служба отделены. Это также может быть использовано в распределенной среде. Интересно, предлагает ли WCF какое-либо средство для этого, или некоторые известные решения или конструктивные идеи могут помочь, а также удивительные решения, такие как ESB, являются излишним для таких сценариев, или у нас есть что-то вроде ESB, но легкий вес от MS, или MSMQ просто решит этот сценарий.

Большое спасибо, Mani

1 Ответ

0 голосов
/ 14 мая 2011

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

  1. Количество клиентов.Существует множество уровней и решений от 10 до 500 000 000 (одновременных) клиентов.Также важно знать количество одновременных клиентов и нужно ли сигнализировать клиентам, которые не подключены, когда они вернутся в сеть.

  2. Технология.Если необходимо поддерживать несколько клиентских платформ, выбор будет очень разным.

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

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

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

  6. Долговечность.Если вам нужно восстановить систему путем загрузки резервной копии, что вы ожидаете от системы обмена сообщениями?

  7. Производительность.Как быстро это должно быть?Здесь много последствий.Разница между доставкой сообщения за день и доставкой сообщения в течение 10 секунд огромна.

Пока эти факторы (а я их исключил) неизвестны, почти невозможно дать подходящее решение.

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

...