目前，我们将资源密集型处理作为具有 Web 角色的云服务来运行。该服务包仅包含经常更改的.NET 程序集。它还依赖于 C++ DCOM 服务器，该服务器的代码和数据总量约为 1 GB。该 DCOM 服务器被打包到存档中并放入 blob 存储中。当角色实例启动其OnStart()时下载存档，将其解压到本地文件系统并注册 DCOM 服务器，然后 .NET 代码使用 DCOM 服务器。
它可以工作，但扩展速度非常慢 - 将扩展操作发送到 Azure 管理服务和角色之间大约需要两到五分钟 OnStart()运行(然后运行 OnStart() 大约需要一分钟)。我听说 HyperV 容器对于横向扩展来说几乎是神奇的 - 它们几乎可以立即扩展。我还听说 Azure Service Fabric 使用容器来托管服务实例。因此，我认为 Azure Service Fabric 可用于解决扩展缓慢的问题。
问题是 - 可以对 OnStart() 中长时间运行的代码执行什么操作。让每个服务实例运行该代码会打败容器 - 它们会快速扩展，然后陷入该初始化代码。
Azure Service Fabric 是否可以执行双阶段初始化之类的操作，相当于 OnStart()在部署服务时首先在单个实例中运行，然后快速“克隆”完全初始化的实例以按需扩展服务？对于所描述的场景，它能做得更好吗？
最佳答案
在 Service Fabric 中，理想情况下，依赖项将作为应用程序包(可选容器化)的一部分进行携带，这意味着它们将在尝试启动实际服务之前复制到盒子中 - 而且应用程序镜像已经是在 Service Fabric 群集内上传，这意味着它通常在本地或至少从同一组计算机内复制(而不是从网络或存储帐户所在的任何位置)。
关于web-services - 如何合理地将需要长时间初始化的 Azure 云服务转换为 Azure Service Fabric 服务？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37729747/