服务结构流模式

时间:2017-10-04 10:03:18

标签: azure communication microservices azure-service-fabric

为了在单独的表和数据库中维护大量数据,我已经编写了多个具有不同职责的控制台应用程序。例如,一个应用程序可以为数据库设定种子,下一个应用程序可以处理该新数据,并且最后一个应用程等等。

现在服务是按顺序(手动)运行的。 根据此类应用程序的结果,您可能必须运行上一个应用程序。

为了使这个流程自动化,我正在考虑使用Service Fabric,因为我发现服务可能会相互通信。
是一种模式,其中一个主要的'控制一个服务输入/输出并将其发送到正确的服务的服务?或者我是否过度/过度地考虑使用Service Fabric?

1 个答案:

答案 0 :(得分:0)

我说Service Fabric是一个非常灵活和强大的野兽来满足许多不同的需求,你绝对应该能够构建所需的架构。

要创建和控制流,您可以考虑使用SF Actors。您可以轻松地构建一个管道或某种链,其中每个Actor只知道如何完成其​​任务,下一个Actor调用成功的内容以及如果某些内容失败则向谁投诉。为避免Actors执行长时间运行和密集的I / O工作或其他事情,您可以利用提醒。例如,当输入的新部分到达时,调用另一个SF服务(实际工作者),其中实现控制台应用程序逻辑以启动作业,将任务ID或任何其他属性保存在演员的状态以识别' worker',并设置提醒以检查正在进行的任务的状态。 SF为其服务提供了许多不同的通信方式,因此您可以在Actors和' workers'之间建立交互。眨眼之间。

如果您的控制台应用程序具有巨大的非平凡逻辑,并且您不想花费大量时间在您的十字军开始时迁移代码,那么您也可以在SF中使用GuestExecutables。

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

<强> P.S。

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