Я перепроектирую наш текущий ETL для приема файлов, где контейнеры spring -batch будут развернуты в Kubernetes.
Каждый тип файла обрабатывается другим заданием, которое будет запускаться по запросу через http через приложение диспетчера прослушивает SQS, где s3 pu sh сообщает о событии создания нового объекта. Поэтому, когда необходимо обработать N файлов одного типа, диспетчер должен сделать N HTTP-запросов к одному и тому же заданию.
Учитывая, что один экземпляр может обрабатывать только один файл за раз и с некоторым допуском перед масштабированием (т.е. если задание A должно обрабатывать два файла в течение всего дня, и они оба поступают одновременно, их можно обрабатывать последовательно без необходимости масштабирования), как я могу масштабировать экземпляры задания на основе этого сценария?
Я мог бы запросить таблицу выполнения заданий, чтобы узнать, сколько заданий одного и того же типа выполняется, и применить лог c для увеличения числа экземпляров, но это не выглядит элегантным решением.
В настоящее время все задания находятся в одном приложении (даже в диспетчере), и мы масштабируемся на основе количества сообщений SQS, но в новой архитектуре для этого потребуется очередь для каждого задания (т.е. для каждого типа файла), в то время как я хотел бы централизовать logi c для запуска задания по запросу в отдельном диспетчерском приложении ция.