Повторное использование приложения "жир-клиент" в качестве распределенного рабочего потока

118
14

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


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


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


Спасибо заранее.

спросил(а) 2021-01-19T16:26:56+03:00 6 месяцев назад
1
Решение
63

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


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


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


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

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


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


Надеюсь, это указывает на то, что вы в правильном направлении!

ответил(а) 2021-01-19T16:26:56+03:00 6 месяцев назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема