这是一个关于在容器中托管哪些类型的有效负载的更普遍的问题。在我们的例子中，我们将使用 Service Fabric 来宾可执行文件。对于这篇文章，我将只使用 Container 一词来指代两者。我这样做的原因是它们具有相似的属性，并且认为更多的人可能比 SF Guest Exe 了解容器。
需要扩展的 WebAPI/服务非常适合容器，但这个问题与我们所说的“批处理”作业有关。这个命名法来自旧的 .bat 文件，但在我们的例子中，我们使用的是 .NET Framework 或 Core .exe（控制台应用程序）。
目前，Windows 任务计划程序启动在 VM 上的服务帐户下运行的批处理。我们希望处理发生在一天中的某个时间或一周中的某一天，而不是之前或之后。这里没有任何真正的缩放。有一个实例可能是多线程的，也可能不是多线程的，平均而言，它们通常运行 2-15 分钟然后停止。有些跑得更长，有些跑得更短。我知道这种方法有局限性，但这是我在这里讨论的有效负载类型。
随着我们对技术堆栈进行现代化改造，我们希望尽可能多地使用 Orchestrator。作为一名技术人员，我一直试图了解我们工具带中的不同工具，而不是仅仅因为那是我最后使用的工具而使用工具，而是使用正确的工具来完成任务。
我们一开始不再编写任何 .net 控制台应用程序。相反，我们将这些“批次”的业务逻辑放入 WebApi 中。然后让任务调度程序在需要执行其操作时调用 API。如果我将它放入 Service Fabric 并托管它，我担心的是系统资源在不使用时每天会消耗 23 小时 45 分钟。这似乎与您在使用容器时所期望的相反。
现在，如果我可以按需启动 Service Fabric Guest Exe/Container，然后在它完成后销毁可以满足需要的应用程序实例。这样我就可以享受编排器的好处，而不会阻止它一直消耗资源。我希望淘汰批处理服务器（VM），因为硬件的使用没有优化，而是向集群添加资源。
更新
看看 Vaclav 的 Scalability Doco，我认为这里可能有一个用例？https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-concepts-scalability他使用“工作负载管理器服务”与 CreateServiceAsync 结合，按需启动服务实例。我想我会将应用程序部署到图像商店，但在需要之前不会创建应用程序的实例。那我要搞清楚怎么结束了，是不是像改Program.cs里的无限循环一样简单？问题是来宾可执行文件中似乎没有 Program.cs。
这看起来像是一种运行包直到完成的方法，这是作为 7.1 的一部分发布的。但是我们如何开始服务的第二次执行呢？我想根据进来的请求执行。 https://docs.microsoft.com/en-us/azure/service-fabric/run-to-completion
想法？