Как мне надежно создать экземпляр рабочего процесса на основе внешнего события?

немного нового в Windows Workflow, так что будьте спокойны :)

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

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

Одним из решений, которое я рассматриваю, является наличие интерфейса WCF на хостах WF и размещение их за неким балансировщиком нагрузки. Затем будет зависеть от любой части системы, которая запускает «событие», чтобы сделать вызов WCF.

Я не очень доволен этим, потому что, если оба \ все хосты WF не работают или недоступны, событие может быть «потеряно». Кроме того, я не смогу управлять загрузкой так, как мне хотелось бы. Я предполагаю ситуацию, когда за небольшой промежуток времени может быть много событий, но вполне приемлемо обрабатывать эти события через некоторое время.

Поэтому я считаю, что мне нужно как-то сохранить события и отделить создание события от обработки события.

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

Будет ли здесь полезен NServiceBus и надежный обмен сообщениями?

Любые идеи будут высоко оценены.

добавление

База данных будет кластеризована с общим хранилищем Fibre Channel. Сеть также будет избыточной. Чтобы экземпляры среды выполнения WF имели аварийное переключение, они должны указывать на общую службу персистентности, которая в данном случае является бэкэндом SQL. Это высокая доступность, а не полная доступность :)

Статья MSDN о надежности WF и высокой доступности

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

14.08.2008 14:56:30
3 ОТВЕТА

Я бы пошел с MSMQ / таблица событий. Опрос только грязный, если вы делаете это неправильно.

Нужно иметь в виду одну вещь: вы говорите, что хотите иметь несколько серверов WF для высокой доступности, но оба они используют один и тот же SQL-сервер ? Высокая доступность работает, только если вы удалите все отдельные точки отказа, а не только некоторые из них.

0
14.08.2008 15:56:19

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

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

1
17.09.2008 21:07:09

Вот как я это решил.

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

Для того чтобы узлы времени выполнения WF работали на разных компьютерах, шину сообщений \ очередь следует размещать на сервере Windows 2008 (MSMQ 4.0) или более поздней версии, поскольку более ранние версии MSMQ не поддерживают удаленное чтение транзакций. Также обратите внимание, что для выполнения удаленного транзакционного чтения на машине, выполняющей чтение, также должен быть установлен MSMQ 4.0 (т. Е. Windows Server 2008).

0
2.11.2008 16:55:44