Пересмотр приложения толстого клиента как распределенного рабочего процесса - PullRequest
0 голосов
/ 11 декабря 2010

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

Проблема, с которой мы сейчас сталкиваемся, заключается в том, что, поскольку наши клиенты предоставляют нам большие наборы документов, мы тратим больше, чем ожидалось, на машины, поддержку ИТ и т. Д. Итак, мы начали задумываться о перестройке платформы чтобы сделать его масштабируемым. Особенностью нашего решения является то, что каждый документ может обрабатываться независимо друг от друга. Также у нас есть 10 шагов рабочего процесса, два из которых занимают около 90% времени обработки.

Одна из идей, над которой мы размышляем, заключается в добавлении поля шага рабочего процесса в схему документа, чтобы отслеживать, какой шаг рабочего процесса был выполнен для документа. Затем мы можем выбросить весь кластер машин для работы с одним набором документов. Один компьютер не будет нести ответственность за последовательную обработку документа на всех этапах рабочего процесса, но запрашивает у БД следующую пару шагов документ / рабочий процесс и выполняет эту обработку. Это звучит как разумный подход? Есть предложения?

Заранее спасибо.

1 Ответ

1 голос
/ 11 декабря 2010

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

Предполагая, что у вас есть ряд независимых шагов - т.е. рабочий продукт шага A является входом для шага B, а продукт шага B является входом для шага C и т. Д. Я бы рассматривал очереди сообщений как потенциальное решение.

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

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

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

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

Надеюсь, это направит вас в правильном направлении!

...