如何明智地将具有长时间初始化的 Azure 云服务转换为 Azure Service Fabric 服务？答案

【问题标题】：How would I sensibly convert an Azure Cloud Service with long initialization into an Azure Service Fabric service?如何明智地将具有长时间初始化的 Azure 云服务转换为 Azure Service Fabric 服务？
【发布时间】：2016-06-09 15:06:07
【问题描述】：

目前，我们将资源密集型处理作为具有 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() 的内容首先在部署服务时在单个实例中运行，然后快速“克隆”一个完全初始化的实例以扩展服务一经请求？对于所描述的场景，它可以做得更好吗？

【问题讨论】：

标签： web-services azure service azure-cloud-services azure-service-fabric

【解决方案1】：

在 Service Fabric 中，理想情况下，依赖项将作为应用程序包的一部分（可选容器化）携带，这意味着它们将在尝试启动实际服务之前被复制到盒子中——此外，应用程序映像已经是在 Service Fabric 群集中上传，这意味着它通常在本地或至少从同一组机器中复制（而不是从网络或存储帐户恰好位于的任何地方）。

【讨论】：