为了在单独的表和数据库中维护大量数据，我编写了多个具有不同职责的控制台应用程序。例如，一个应用程序可能会为数据库播种，下一个应用程序可能会处理新数据，最后一个应用程序过滤旧数据和新数据。等等。
现在服务是按顺序运行的（手动）。 根据此类应用程序的结果，您可能必须运行前一个应用程序。
为了自动化这一流程，我正在考虑使用 Service Fabric，因为我发现服务可以相互通信。
是否存在一个“主要”服务控制一个服务的输入/输出并将其发送到正确的服务的模式？还是我过度/低估了 Service Fabric 的使用？
【问题讨论】：
标签： azure communication microservices azure-service-fabric
我会说 Service Fabric 是一种非常灵活且功能强大的野兽，可以满足许多不同的需求，您绝对应该能够构建所需的架构。
要创建和控制流程，您可以考虑使用 SF Actor。您可以轻松地构建一个管道或某种链，其中每个 Actor 只知道如何完成其任务、下一个 Actor 需要调用成功以及如果某事失败了该向谁抱怨。为了避免让 Actor 进行长时间运行和密集的 I/O 工作或其他事情，您可以利用提醒。例如，当输入的新部分到达时，调用另一个 SF 服务（一个实际的工作人员），其中实现了控制台应用程序逻辑来启动作业，将任务 ID 或任何其他属性保存在参与者的状态中以识别“工作人员”，并设置提醒以检查正在进行的任务的状态。 SF 为其服务之间的通信提供了许多不同的方式，因此您可以在眨眼之间设置 Actor 和“工人”之间的交互。
如果您的控制台应用程序具有庞大的非平凡逻辑并且您不想在十字军东征之初花费太多时间迁移代码，您也可以在 SF 中使用 GuestExecutables。
这只是最初的想法和一些非常通用的设计。我的观点是，当涉及到“做”服务时，SF 是一个非常好的选择，因为有多种不错的、强大的选项可以处理许多不同的情况。
附言
查看Service Fabric Reliable Services Pipeline design。讨论涉及类似的主题，并阐明了您可能会发现方便的细节。
【讨论】：