服务结构是否适合下载和压缩

时间:2018-05-04 05:42:08

标签: azure azure-service-fabric

我认为可能适合Service Fabric。我在外地工作。

我从队列中读取消息。 每条消息都包含需要下载的文件的详细信息。 文件已下载并添加到zip存档中。

有40,000条消息,因此有40,000个下载和文件。 我将这些添加到40个zip存档中,因此每个存档有1000个文件。

Service Fabric是否适合此工作负载?

我计划创建一个服务,将消息从队列中取出,下载文件并将其保存在某处。 然后,我将该服务扩展为100个实例。

一旦下载了所有文件,我就会尝试将文件添加到zip存档中。 如果您可以告诉我一种方法将文件添加到zip存档作为服务的一部分

,那么可以获得奖励

2 个答案:

答案 0 :(得分:1)

  

Service Fabric是否适合此工作负载?

如果用途只是用于下载和压缩文件,我认为设置集群并管理它以维持一个非常简单的应用程序将是不合适的。我认为您可以找到许多替代方案,您不必设置环境以保持应用程序正常运行并处理队列中的消息。

  

然后我将该服务扩展为100个实例。

实例数并不意味着下载速度会更快,您还必须考虑网络限制,否则您将最终得到具有空闲CPU和内存的服务器,其中网络可能是瓶颈。

  

我计划创建一个服务,将消息从队列中取出,下载文件并将其保存在某处。

如果您想坚持使用服务结构和队列方法,我会建议我之前给出的答案: Simulate 10,000 Azure IoT Hub Device connections from Azure Service Fabric cluster

这些信息并不完全符合您的计划,但可能会根据您的规模以及如何处理来自队列的大量消息来指示(IoT Hub消息与服务总线非常相似)。

对于其他问题,我建议在另一个主题上创建它们。

答案 1 :(得分:0)

同意迭戈,使用服务结构这将是一个过度杀伤,它不会是资源的最佳利用,而且这似乎更像是一个磁盘广泛的问题,你需要大量的存储来下载这些文件而不是压缩拉链。一个想法可以是使用azure函数,因为在你的情况下,计算对我来说似乎很小。在azure文件共享中下载文件,然后上传到您想要的任何存储空间(例如BLOB)。这样您就不会使用大量资源,您可以根据需要扩展功能和azure文件共享。