0

我有来宾可执行文件（真正的 .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

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

4

2 回答 2

1

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

  • HealthCheckWaitDurationSec 在升级域上完成升级后，Service Fabric 评估应用程序运行状况之前的等待时间（以秒为单位）

  • HealthCheckStableDurationSec 在移动到下一个升级域或完成升级之前验证应用程序是否稳定的持续时间（以秒为单位）。

  • UpgradeHealthCheckInterval 检查健康状态的频率。

...等等。Stateless 和 Statefull 服务的升级方式也有所不同，这由UpgradeReplicaSetCheckTimeout参数决定。有关更多详细信息，请查看应用程序升级参数和Service Fabric 应用程序升级。

于 2017-09-29T17:19:41.237 回答
0

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

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

  • 通过将以下部分添加到项目文件中将其编译为 EXE（构建 .NET Core 控制台应用程序以输出 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>
于 2017-10-02T14:12:38.363 回答