WF4 Affinity в Windows Azure и других средах NLB

Question

Я использую Windows Azure и WF4, и мой сервис рабочего процесса размещен в веб-роли (с N экземплярами). Моя работа сейчас выяснить, как чтобы сделать сходство, таким образом, чтобы я мог отправлять сообщения в правильный экземпляр рабочего процесса. Чтобы объяснить этот сценарий, мой рабочий процесс (в приложении) начинается с действия получения «StartWorkflow», создает 3 «человека» и, параллельно для каждого, ожидает подтверждения этих 3 человек (действие получения «ConfirmCreation»).

Затем я начал искать способ создания сходства в других средах NLB (в основном искал информацию о том, как это работает в Windows Server AppFabric), но я не нашел точного ответа. Так как же это сделать в других средах NLB?

Моя следующая задача - выяснить, как я могу внедрить систему для обработки этой привязки в Windows Azure и сколько будет стоить это решение (по цене, времени и объему работы), чтобы увидеть, насколько оно жизнеспособно или лучше работать только с одним экземпляром веб-роли, пока мы ожидаем хоста WF4 для Azure AppFabric. Единственный способ, который я нашел, - это сохранить экземпляр рабочего процесса. Есть ли другие способы сделать это?

Моя третья, но не последняя, ​​задача - выяснить, как WF4 обрабатывает несколько сообщений, полученных одновременно. В моем сценарии это означает, как это будет происходить, если 3 человека подтвердят одновременно и сообщения с подтверждением будут получены одновременно. Поскольку наиболее логичным решением этой проблемы, похоже, является использование очереди, я начал искать информацию об очередях на WF4 и нашел людей, говорящих о MSQM. Но какова собственная система обработки сообщений WF4? Этот обработчик действительно очередь или это другая система? Как обрабатывается этот параллелизм?

Answer 1

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

Что касается сохранения настойчивости для Windows Azure, то вам нужно будет либо взломать стандартные сценарии постоянства SQL, чтобы они работали на SQLAzure или напишите свою собственную InstanceStore реализацию, которая находится поверх хранилища Azure.Мы выполнили последнее для рабочего процесса, который выполняется в Azure, но я не могу поделиться кодом.По шкале от 1 до 10 за усилия я бы оценил ее как 8 *. 1006 *

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

Вот несколько других предложений:

• Убедитесь, что вы используете опцию PersistBeforeSend в ваших действиях SendReply
• Настройте следующие параметры службы рабочего процесса
  • <workflowIdle timeToUnload="00:00:00" />
  • <sqlWorkflowInstanceStore ... instanceLockedExceptionAction="AggressiveRetry" />

Answer 2

Использование готового хранилища экземпляров SQL с SQL Azure в настоящее время представляет собой небольшую проблему с пакетом SDK Azure 1.3, поскольку каждое развертывание, даже если вы изменили 0 кодов, приводит к развертыванию новой службы, что означает, что уже постоянные рабочие процессы не могут продолжаться. Это ошибка, которая будет решена, но пока PITA.

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

Отправка сообщений через MSMQ с помощью WCF NetMsmqBinding работает просто отлично. Внутренне WF использует совершенно другой механизм, называемый закладками, который позволяет остановить и возобновить рабочий процесс. Каждое действие «Получить», а также другие, такие как «Задержка», создают закладку и ожидают возобновления. Вы можете только возобновить существующие закладки. Даже возобновление закладки не является прямым действием, а помещается во внутреннюю очередь, а не в MSMQ, планировщиком рабочего процесса и выполняется через SynchronizationContext. Вы не получаете никакого контроля над планировщиком, но вы можете заменить SynchronizationContext при использовании WorkflowApplication и таким образом получить некоторый контроль над тем, как и где выполняются действия.