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

Posted 2023-02-23

【中文标题】服务结构是不是适合下载和压缩

【英文标题】：Is service fabric a good fit for download and compress服务结构是否适合下载和压缩

【发布时间】：2018-05-04 05:42:08

【问题描述】：

我有一个我认为可能适合 Service Fabric 的场景。我在现场工作。

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

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

Service Fabric 是否适合这种工作负载？

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

下载完所有文件后，我会启动一个不同的过程来将文件添加到 zip 存档中。 如果您能告诉我一种将文件添加到 zip 存档作为服务的一部分的方法，那么您将获得奖励

【问题讨论】：

你考虑过使用 Azure Functions 吗？它们按需扩展，您只需按所需方式付费，无需设置和管理 Service Fabric 集群。我们正在谈论的文件有多大？恕我直言，使用 Service Fabric 对您的方案来说听起来有点矫枉过正。拥有 100 个实例并不能告诉我们太多，您的集群的大小是多少？

感谢您的回复。我在本地工作，因此无法使用 Azure Functions。文件范围从 100KB 到大约 800KB。至于服务的数量和集群的大小 - 我想在 30 分钟内完成工作，所以无论集群的实例数量/大小都可以使用。

【参考方案1】：

Service Fabric 是否适合这种工作负载？

如果仅用于下载和压缩文件，我认为设置一个集群并对其进行管理以维持一个非常简单的应用程序将是多余的。我认为您可以找到许多替代方案，您不必设置环境来保持应用程序运行并处理来自队列的消息。

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

实例数量多并不代表下载速度会更快，还要考虑网络限制，否则只会导致服务器CPU和内存空闲，网络可能是瓶颈。

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

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

这些信息并不完全是您计划做的，但可能会根据您拥有的规模以及如何处理来自队列的大量消息提供指导（IoT Hub 消息传递与服务总线非常相似）。

对于其他问题，我建议在单独的主题上创建它们。

【参考方案2】：

同意 Diego 的观点，为此使用服务结构将是一种矫枉过正，而且它不会是资源的最佳利用，而且这似乎更像是一个磁盘广泛的问题，您需要大量存储空间来下载这些文件而不是将其压缩为zip。一个想法可以是使用天蓝色函数，因为在您的情况下，计算对我来说似乎很少。在 azure 文件共享中下载文件，然后上传到您想要的任何存储（例如 BLOB）。这样您就不会使用太多资源，并且可以根据需要扩展功能和 azure 文件共享。