Именно для этой цели я использовал WCF с привязками net.tcp, с интерфейсом обратного вызова, чтобы программа главного управления знала, что работа была выполнена (да, она называлась «MCP», процессы, которые инициировали задания, были называется "Sark", а сеть упоминается как "Game Grid", см. рисунок).
«Sark» был реализован как консольное приложение и служба Windows (для простоты разработки и «погружения наших пальцев» в новую рабочую машину), тогда как MCP представлял собой долго работающий графический интерфейс. Если бы я внедрил его заново, я бы, вероятно, сделал бы Master Control также и службой Windows, но ИТ-отделу было бы полезно посмотреть, какие задания запланированы, и приостановить работу MCP при выполнении задания резервного копирования или другой задачи обслуживания. было обусловлено. Сегодня я все еще делаю MCP сервисом и просто предоставляю графический интерфейс для него.
Задания были записаны как сборки DLL .Net с интерфейсом для вызова задачи. «Sark» скопирует последнюю версию двоичных файлов на файловый ресурс, создаст новый домен приложений, загрузит и запустит задание в этом домене приложений, а затем закроет его, когда это будет сделано. Это позволило обновить задания без перезапуска MCP или Sarks.
Кроме того, каждый экземпляр «Sark» также использовал MSMQ с кратковременными сообщениями (время ожидания 10 секунд), чтобы сообщать о нагрузке на каждом рабочем компьютере. Затем MCP будет использовать взвешенный случайный выбор, чтобы выбрать, на какую рабочую машину отправлять задание. То есть: если машина сообщила, что она простаивала на 80%, то она получила бы 80 «голосов», чтобы выполнить следующую запланированную задачу, что означало, что она была более вероятной, чем машина, которая простаивала только на 10%. Это был достаточно эффективный способ равномерного распределения нагрузки, избегая горячих точек.
Я выбрал net.tcp в качестве привязки WCF к отправке заданий и получению результатов, потому что «запустить и забыть» не очень хорошо работает на практике. Происходит сбой: будут исключения из-за нехватки памяти, проблемы со временем выполнения на сервере (главная из них была, когда задача должна была работать с таблицами FoxPro, а драйвер ODBC FoxPro от Microsoft не входил в 64- битовая версия - проблема, когда у нас было сочетание 32-битных и 64-битных рабочих машин), или из-за сотен непредвиденных непредвиденных обстоятельств, например, когда рабочий находился на IP-адресе, который был защищен брандмауэром той машиной, с которой он хотел поговорить к. Немедленный ответ на обратный вызов дал MCP возможность переназначить задание другому работнику на другом компьютере.
MSMQ, тем не менее, идеально подходил для сообщения о работоспособности рабочих машин, поскольку MCP не должен был работать, чтобы рабочие сообщали о своей нагрузке, а короткий тайм-аут в сообщениях означал, что MCP не будет ' Не могу получить информацию, которая была слишком устаревшей.