Рекомендации по отключенным сообщениям с WCF через брандмауэры - PullRequest
Новая
       4

Рекомендации по отключенным сообщениям с WCF через брандмауэры

0 голосов
/ 19 декабря 2010

All

Я ищу совет по следующему сценарию:

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

Сообщения связаны с тем, что важна последовательность их поступления. Они имеют метку времени с отметкой времени клиента.

Я думаю, что я заставлю клиентов использовать WCF basicHttpBinding (некоторые основаны на .NET CF, который имеет только базовый) для отправки сообщений на сервер приложений (это потому, что мы можем гарантировать, что порт 80/443 будет открыт для исходящих соединений). Сервер принимает их и записывает в очередь. Эта очередь может быть масштабирована при необходимости на нескольких машинах.

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

Что я бы предпочел, так это центральную очередь (например, таблицу базы данных), которую отслеживают все серверы приложений.

Имея это в виду, я хотел бы создать пользовательскую привязку WCF, аналогичную netMsmqBinding, но вместо этого использовать таблицу DB, но я не уверен, могу ли я просто создать пользовательский транспорт или a Мне нужна полная привязка, и позволит ли эта привязка клиенту отправлять через HTTP. Я просмотрел интернет, но немного озадачен тем, с чего начать.

Я не мог бы возиться с пользовательской привязкой WCF, но, похоже, это хороший способ внедрить масштабируемость, если мне нужно разделить серверы.

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

1 Ответ

0 голосов
/ 20 декабря 2010

Я бы начал с MSMQ, потому что именно для этой цели.Используйте одну транзакционную очередь на кластерном компьютере и разрешите серверам приложений принимать сообщения для обработки из этой очереди.Обработка каждого сообщения должна быть частью распределенной транзакции (MSDTC).

Этот сценарий обеспечит:

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

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

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

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

  • MSMQ также доступен в .NET CF, поэтому вы можете отправлять сообщения напрямую в очередь без промежуточных ненадежныхуровень веб-службы.

  • Должна быть возможность настроить MSMQ по HTTP (но я никогда не использовал его, поэтому не уверен, как он взаимодействует с предыдущими упомянутыми функциями).

Предлагаемое вами решение будет довольно сложным.Вы закончите в создании MessageBox BizTalk.Но если вы действительно хотите это сделать, проверьте сообщение Омара о построении таблицы очереди базы данных.

...