Spring Batch правильный способ сломать существующий большой ItemReader

Question

В настоящее время я смотрю на рефакторинг существующего задания Spring Batch.

Однако считыватель слишком манипулирует слишком большим количеством данных.

В настоящее время выполняется одно чтение

• Переход к внешнему сервису для получения списка объектов
• Использование этого списка для перехода к другому сервису для заполнения карты
• Затем используйте эту карту, чтобы дважды запросить другой сервис
• Используйте результат для создания объекта, используемого для записи в CSV

Правильно ли я считаю, что это мешает весенним партиям эффективно распределять работу по частям?

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

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

Answer 1

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

Подробнее о шаблоне запроса на движение вы можете прочитать в документации здесь: https://docs.spring.io/spring-batch/trunk/reference/html/patterns.html#drivingQueryBasedItemReaders