目前,我们将资源密集型处理作为具有Web角色的Cloud Service运行。服务包仅包含经常更改的.NET程序集。还有一个对C ++ DCOM服务器的依赖,它大约有一千兆字节的代码和数据。 DCOM服务器被打包到一个存档中并放入blob存储中。当角色实例启动其OnStart()
下载存档时,将其解压缩到本地文件系统并注册DCOM服务器,然后.NET代码将使用DCOM服务器。
它可以正常工作,但扩展速度非常慢 - 将横向扩展操作发送到Azure管理服务并运行角色OnStart()
需要大约两到五分钟(然后运行大约需要一分钟) {1}})。我听说HyperV容器几乎可以用于扩展 - 它们几乎可以立即扩展。我还听说Azure Service Fabric使用容器来托管服务实例。因此,我假设Azure Service Fabric可用于解决缓慢扩展的问题。
问题是 - 在OnStart()
中可以对长时间运行的代码做些什么。让每个服务实例运行该代码类型会使容器失败 - 它们会快速扩展,然后陷入初始化代码。
Azure Service Fabric可以执行类似双阶段初始化的操作,其中等效于OnStart()
的内容在部署服务时首先在单个实例中运行,然后快速“克隆”完全初始化的实例以扩展按需服务?它可以为描述的场景做更好的事情吗?
答案 0 :(得分:1)
在Service Fabric中,理想情况下,依赖项将作为应用程序包的一部分(可选地进行容器化)来承载,这意味着它们在尝试启动实际服务之前将被复制到盒子中 - 此外,应用程序映像已经是在Service Fabric群集中上传,这意味着它通常在本地或至少从同一组计算机中复制(而不是从网络中或存储帐户所在的任何位置)。