Подходит ли сервисная ткань для скачивания и сжатия?

Question

У меня есть сценарий, который, я думаю, может подойти для Service Fabric. Я работаю на месте.

Я читаю сообщения из очереди. Каждое сообщение содержит информацию о файле, который необходимо загрузить. Файлы загружаются и добавляются в zip-архив.

Есть 40 000 сообщений, то есть 40000 загрузок и файлов. Я добавлю их в 40 zip-архивов, так что это 1000 файлов на архив.

Подойдет ли Service Fabric для этой рабочей нагрузки?

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

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

Answer 1

Согласитесь с Диего, использование сервисной структуры для этого было бы излишним, и это не будет лучшим использованием ресурсов, более того, это, похоже, более масштабная проблема с диском, где вам потребуется много места для загрузки этих файлов. и чем сжимать его в молнии. Идея может заключаться в использовании лазурных функций, так как в вашем случае вычисления кажутся мне минимальными. Загрузите файл в общую папку Azure и затем загрузите его в любое хранилище (например, BLOB). Таким образом, вы не будете использовать большую часть ресурсов и сможете масштабировать функцию и общий доступ к файлам Azure в соответствии со своими потребностями.

Answer 2

Подойдет ли Service Fabric для этой рабочей нагрузки?

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

Я бы тогда масштабировал эту службу, чтобы иметь 100 экземпляров.

Количество экземпляров не означает, что загрузка будет быстрее, вы также должны учитывать ограничение сети, в противном случае вы просто получите серверы с незанятым ЦП и памятью, где сеть может стать узким местом.

Я планирую создать службу, которая удалит сообщение из очереди, загрузит файл и сохранит его где-нибудь.

Если вы хотите придерживаться сервисной структуры и подхода очереди, я бы предложил этот ответ, который я дал некоторое время назад: Моделирование 10 000 подключений устройств-концентраторов IoT Azure из кластера Azure Service Fabric

Информация не совсем то, что вы планируете делать, но может дать указания, основанные на вашей шкале и способах обработки большого количества сообщений из очереди (обмен сообщениями в IoT-концентраторе очень похож на служебную шину).

По остальным вопросам я бы предложил создать их по отдельной теме.