【问题标题】:Are workflow engine and event stream framework alternatives for an orchestration layer?工作流引擎和事件流框架是编排层的替代方案吗?
【发布时间】:2020-02-19 00:07:40
【问题描述】:

我必须实现一个文档管理服务作为一个编排层,它在存储、解析、防病毒扫描等底层服务之间进行编排。要求是使该层灵活,以便可以为不同类型的文档提供不同的流快速实施
一种方法是将其建模为事件驱动系统,并使用 Apache Flink 等框架实现事件处理管道。
另一种思考方式是工作流。将其设计为在 Apache Airflow 或 Uber Cadence 等工作流引擎上运行的工作流。
有什么更好的方法。

【问题讨论】:

    标签: architecture workflow system-design event-driven-design


    【解决方案1】:

    免责声明:我是 Temporal Workflow 的技术主管,也是 Cadence Workflow 的前技术主管。但我 know something about Flink 和 Airflow :)。

    使用 Flink 实现编排会非常困难。原因是 Flink 是一种流处理解决方案,针对每个请求的快速处理进行了优化。编排应该处理缓慢的请求或长时间关闭的服务。 Flink 不支持开箱即用的此类场景。它还将处理建模为静态图,而编排通常是一个非常动态的状态机。

    气流也基于静态图。所以它并不真正适合不适合其 DAG 范式的复杂场景。 Airflow 更严重的问题是其可扩展性非常有限。这就是为什么我从来没有听说过它被用于数据管道控制平面之外的服务编排,而这种情况并不真正需要可扩展性。

    Temporal Workflow 从一开始就构建为一个非常动态且高度可扩展的编排系统。许多依赖 Temporal 的公司在生产中有许多高吞吐量服务编排用例。其中一些列在case studies。

    【讨论】:

    • 你如何区分静态图和动态图?你能举个例子吗??
    • 例如,第一个活动返回要执行的操作列表,然后工作流执行这些操作。但更简单的例子是当算法的迭代次数事先不知道时的 ML 学习。
    • 你能详细说明你的第一段吗?当您说“缓慢的请求或服务长时间停机”时,听起来这意味着它最适合每秒数百而不是数百万的事件,但我想“小费驱动程序”以很高的速率发生。服务长时间停机是什么意思?我最初的看法是,听起来 Cadence 最适合为公司现有的微服务增加可靠性和稳定性,但不像使用 Spring Boot 微服务来尝试执行大型实时、基于事件时间的处理任务。
    • @MaximFateev 基本上,Flink 无法处理的 Cadence 的理想用例是什么?
    • 例如货币交易。参与服务可能会长时间中断。
    【解决方案2】:

    有些人在 Flink 之上构建平台,这些平台支持的用例更像您所描述的,而不是 Flink 本身直接完成的。特别是,我想建议你看看Stateful Functions,它是来自 Flink 的原始创建者 Ververica 的一个新的开源库。根据我对您的要求的了解,这似乎很合适。

    Cogynt 是在 Flink 之上构建平台以支持 Flink 本身难以实现的用例的趋势的另一个例子,同时利用其高性能、容错、精确一次的流处理引擎。

    免责声明:我为 Ververica 工作。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2022-07-29
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-10-03
      • 2012-12-12
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多