В облачной среде, предоставляя клиентским компаниям услуги REST API для хранения и обновления информации о своих клиентах (номера телефонов и т. д.), Я ищу способ для недавно присоединившейся компании-клиента передать файл (или набор файлов), содержащий все их клиенты. Файл (ы) может содержать миллионы записей о клиентах.
Предположим, идея состоит в том, что файл (ы) может быть загружен в определенную папку, и после обнаружения запускается процесс импорта. Предположим также, что в облаке существует служба, которая может создать покупателя из запроса, содержащего детали. Предположим, размер каждого файла ограничен примерно 1 ГБ.
Я слышал, что можно использовать Yarn или Kubernetes, но я действительно не понимаю, как их можно использовать или в чем преимущество их использования.
Этот процесс импорта может быть выполнен на чистой Java следующим образом: код отслеживания папки в Java может легко обнаружить новый файл в папке и вызвать процесс, который считывает записи файла / ов и из каждой записи в файле, создать объект запроса и вызвать службу, которая может создать клиента.
Так в чем же преимущество использования Yarn или Kubernetes по сравнению с чистой Java при выполнении такой задачи? И есть ли другие альтернативные технологии, которые можно использовать для этой задачи?




В облачной среде вы хотите, чтобы ваш Java-сервис был «высокодоступным», а при работе с «миллионами клиентских записей» на каждого клиента - даже «безопасным». Здесь на помощь приходят Kubernetes и Yarn.
Если вы используете одну виртуальную машину, а процесс Java сохраняет конфиденциальные данные клиента в незашифрованном виде в локальной файловой системе - что происходит, когда:
Вы понимаете, существует бесконечное количество сценариев отказа и компрометации.
Kubernetes и Yarn по-разному поддерживают архитектурные шаблоны, которые позволяют запускать несколько процессов загрузки и импорта Java через коллекцию виртуальных машин, чтобы можно было разумно обрабатывать различные случаи сбоя и разумный механизм хранения для чувствительных аспектов этого. масштабируемый процесс с данными в реальном времени.
Итак, из этого я понял, что эти технологии делают для вас в области моей проблемы, что если произойдет сбой во время процесса импорта (виртуальная машина / процесс), он воскресит сбойную виртуальную машину / процесс и, самое большее, повторно попытаться импортировать файл. И он будет устанавливать / вызывать то, что необходимо для каждого нового файла, даже если эти файлы удаляются параллельно.
Но для определенного огромного файла импорта существует процесс, который его запускает ... Предположим, что где-то в коде процесса существует метод, который может обрабатывать отдельную запись потокобезопасным способом. даже если процесс вызывает этот метод асинхронно для каждой записи, он все равно выполняется в одном процессе. Есть ли способ в этих технологиях разделить работу на несколько машин? Например, кажется, что файл можно сначала разделить на файлы меньшего размера, а затем каждый файл потенциально будет назначен другому компьютеру ... но есть ли что-то в этих технологиях, поддерживающее это?
Они не выполняют никакой бизнес-логики (например, повторно импортируют файл). Если процесс выйдет из строя, он будет перезапущен. Если машина выходит из строя, рабочие процессы перезапускаются на других машинах. Если процесс был привязан к абстракции хранилища, когда машина вышла из строя, он будет восстановлен на другой машине. Если процесс можно разделить на идентичные части работы, все они будут завершены / повторены, пока не завершатся. Он не дает ответов на все вопросы, но предлагает набор инструментов, которые работают в кластере для создания отказоустойчивых систем с несколькими машинами.
Рецензенты не прочитали вопрос. Это не не по теме. Запросов на рекомендацию нет. Это просьба объяснить роль определенного класса технологий в области решения конкретной проблемы.