服务结构流模式

Question

用于在单独的表和数据库中维护大量数据我编写了多个具有不同职责的控制台应用程序。例如，一个应用程序可以创建一个数据库，下一个可以处理新数据，最后一个过滤器可以处理旧数据和新数据。等

现在服务顺序（手工）运行。 根据这样的应用程序的结果，您可能需要运行前一个。

为了实现这个流程的自动化，我考虑使用服务结构，因为我发现服务可能会相互通信。
是一种模式，其中有一个“主”服务控制一个服务的输入/输出并将它发送到正确的服务？或者我疯狂地过度/不重视使用服务结构？

Answer 1

我想说Service Fabric是一个非常灵活和强大的野兽，以迎合许多不同的需求，你应该一定能够构建所需的架构。

要创建和控制流程，可以考虑使用SF Actor。你可以很容易地建立一个流水线或某种链，每个Actor只知道如何完成它的任务，下一个Actor要求成功，以及如果某件事失败，则投诉谁。为了避免让Actor们执行长时间运行和密集的I/O工作或某些事情，您可以利用提醒。例如，当输入的新部分到达时，调用其中实现了控制台应用程序逻辑的另一SF服务（实际工作人员）来启动作业，将任务标识或任何其他属性保存在参与者状态中以标识“工作人员”并设置提醒以检查正在进行的任务的状态。 SF为其服务提供了许多不同的方式来相互沟通，因此您可以眨眼间建立演员与“工作人员”之间的互动。

如果你的控制台应用程序有一个巨大的不平凡的逻辑，并且你不想在你的十字军东征开始时花太多时间迁移代码，那么你也可以在SF中使用GuestExecutables。

这只是第一个想法和一些非常通用的设计。我的观点是，当涉及到“做”服务时，SF是一个非常好的选择，因为各种各样的好的和强大的选项可以处理许多不同的情况。

P.S.

结帐Service Fabric Reliable Services Pipeline design。讨论涉及到类似的主题，并阐明了您可能会发现的细节。