Клиент-серверные архитектуры на основе сообщений через Интернет

Question

Проблема

Я уже некоторое время думаю о тонкостях архитектур на основе сообщений, когда одним из каналов передачи сообщений является Интернет.

Я согласен с концепцией организации очередей сообщений на клиентах, которые при обработке приводят к вызовам веб-служб через Интернет, которые затем помещают в очередь те же сообщения на сервере для обработки в соответствии с бизнес-правилами. В настоящее время я не знаю механизма отправки сообщений назад клиенту, чтобы сообщить ему, что что-то произошло.

Пример

Рассмотрим в этом примере приложение управления настольным хранилищем, которое хочет получать сообщения с сервера, а не опрашивать, чтобы узнать, есть ли они.

* 1013 Е.Г. *

1. Пользователь создает срочный заказ на веб-сайте с жестким соглашением об уровне обслуживания для выбора в течение нескольких минут, потому что кто-то уже находится в процессе сбора товара.
2. OrderCreated сообщение опубликовано на сервере.
3. Волшебство происходит при отправке сообщения OrderCreated клиентскому программному обеспечению, работающему на ПК на складе.
4. Клиентское программное обеспечение отображает новый порядок на экране (и, возможно, кэширует на диск в случае перезапуска и т. Д.).
5. Складская команда подбирает предметы для выполнения заказа.

Это пункт 3 выше, что я ищу технологии, чтобы заполнить пробел.

Некоторые возможные решения

1. Регулярный и частый опрос сервера (менее минуты) для определения наличия сообщений и загрузки их в локальную очередь для обработки.
2. Используйте что-то вроде двусторонней связи в WCF, хотя для этого требуется, чтобы каналы / сокеты / порты и т. Д. Постоянно оставались открытыми между клиентами и сервером, поэтому это не будет элегантно масштабироваться.
3. На самом деле откройте порты и настройте переадресацию портов, брандмауэры и т. Д. На локальных сайтах, чтобы MSMQ (или другие технологии, такие как WCF, что может означать размещение IIS или аналогичные устройства на клиентском оборудовании) передавали сообщения клиентам. Конечно, затраты на развертывание и поддержку здесь астрономические.

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

Большое спасибо заранее.

Answer 1

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

Из этих двух я всегда предпочитал двустороннюю связь,Он достаточно хорошо масштабируется до определенной точки - возможны десятки тысяч соединений с сокетами / WCF, если сервер использует асинхронные API (и, в частности, не использует схему «один поток на соединение»)мерзость).

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

Я не использовал MSMQ для этого типа связи, но использовал IBM WebSphere (аналогичная технология).Очередь сообщений имеет свой собственный набор проблем для автоматизации, таких как обработка очередей недоставленных сообщений и т. Д. Это полезно, если вы ожидаете, что сервер не работает в течение определенного периода времени (или если у вас ненадежное «промежуточное ПО» между клиентом и сервером), но в целом я предпочел двунаправленную связь по сокетам или WCF.

Answer 2

Взгляните на WebSockets - его еще нет, но он должен стать преемником Comet / методов длинного опроса.Он предназначен для реализации в веб-браузерах, но нет причин, по которым вы не можете использовать его в клиентах другого типа.

Answer 3

В настоящее время я работаю над чем-то очень похожим, когда сообщения должны своевременно доставляться через Интернет клиентскому программному обеспечению за маршрутизатором / модемом DSL и, возможно, привязываться к динамическому IP-адресу. Частые опросы - это выбранное нами решение, обеспечивающее баланс между производительностью и простотой.

Answer 4

Я бы использовал службу WCF с использованием TCP и обратных вызовов.

Что заставляет вас говорить, что оно не масштабируется?

Answer 5

Здесь - фрагмент кода, который я ранее использовал (3 или 4 года назад) для создания программы обмена мгновенными сообщениями.Он создает TcpListener, который может принимать сообщения от сервера, и NetworkStream и TcpClient для отправки сообщений на сервер.Это может быть не полный ответ, но он может помочь направить вас.

Answer 6

Возможно, что-то сгенерировать после JMS (или даже просто собрать адаптер JMS для вашего существующего .net-сервера и затем использовать JMS напрямую)?Например, вы можете сделать так, чтобы клиент поддерживал постоянное соединение сокетов с вашим сервером уведомлений (если вы собираетесь опрашивать сервер несколько раз в минуту, то почему бы просто не оставить сокет открытым?).Когда сокет установлен, подключающийся клиент может подписаться / зарегистрироваться на любые события, которые он заинтересован в получении (например, «Я хочу только события, связанные с продуктами в Складе A»).Затем, когда сообщение OrderCreated публикуется на сервере, сервер может просмотреть свой список клиентов, чтобы увидеть, кто зарегистрирован для этого сообщения, и немедленно опубликовать уведомление для клиента через соответствующее сокетное соединение.