Service Fabric 中来宾可执行文件的缓慢升级部署答案

【问题标题】：Slow upgrade deployment of guest executable in Service FabricService Fabric 中来宾可执行文件的缓慢升级部署
【发布时间】：2018-03-11 11:58:17
【问题描述】：

我有来宾可执行文件（真正的 .net core 1.1 控制台应用程序），第一次部署只需要几分钟。升级部署需要 12 分钟以上。 5 节点集群上有 3 个服务实例。 SF 是面向开发者的，没有工作量。

来宾可执行文件是 start.cmd

<EntryPoint>
    <ExeHost>
        <Program>start.cmd</Program>
        <Arguments />
        <WorkingFolder>CodePackage</WorkingFolder>
    </ExeHost>
</EntryPoint>

Start.cmd 真的很简单

start /b /wait "SomeWebAPI" "C:\Program Files\dotnet\dotnet.exe" SomeWebAPI.dll

感谢任何修复缓慢升级的建议。

【问题讨论】：

标签： azure-service-fabric guest-executable

【解决方案1】：

确实，在某些情况下升级可能需要比初始部署更长的时间。之所以发生这种情况，是因为 SF 应用了非常强大的工作流程，以确保在对特定升级域进行更新后一切正常。它会根据运行状况策略执行多项运行状况检查，这些检查会在为您的集群定义的特定时间间隔内进行。以下是一些定义升级行为的参数：

HealthCheckWaitDurationSec 在升级域上完成升级后，Service Fabric 评估应用程序的运行状况之前等待的时间（以秒为单位）
HealthCheckStableDurationSec 在移动到下一个升级域或完成升级之前验证应用程序是否稳定的持续时间（以秒为单位）。
UpgradeHealthCheckInterval 检查健康状态的频率。

...等等。 Stateless 和 Statefull 服务的升级方式也有所不同，这由 UpgradeReplicaSetCheckTimeout 参数决定。查看Application upgrade parameters 和Service Fabric application upgrade 了解更多详情。

【讨论】：

感谢您的回复。这是一般性建议，对解决问题没有帮助。

【解决方案2】：

看起来 SF 不喜欢从 cmd 启动的应用程序作为另一个进程。

我找到了解决问题的方法。升级部署时间从 12 分钟减少到 4 分钟。主要是你需要直接从你的 SF 运行可执行文件。以下是使用 .Net Core 1.1 实现它的步骤。

通过将以下部分添加到项目文件中将其编译为 EXE (Build .NET Core console application to output an EXE?)
```
<PropertyGroup>
    <RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>
</PropertyGroup>
```
创建独立的应用程序
```
dotnet publish -c Release -r win10-x64
```

为您的可执行文件设置入口点

<EntryPoint>
    <ExeHost>
        <Program>SomeWebAPI.exe</Program>
        <Arguments />
        <WorkingFolder>CodePackage</WorkingFolder>
    </ExeHost>
</EntryPoint>

【讨论】：