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

Question

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

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

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

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

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

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

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

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

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

Добавление

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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