微服务的Airflow架构

Question

微服务的Airflow架构

pythonarchitecturemicroservicesetlairflow

5

我的当前平台架构有一个微服务用于下载/收集数据，一个微服务用于ETL，另一个微服务用于处理一些复杂的SQL脚本。

我想使用Airflow来调度和监控工作流程。我尝试了它，它的效果非常好。但是，我必须将所有功能作为任务放入Airflow的一个容器中；这不符合当前的微服务架构。我的想法是使用Airflow作为调度程序并与其他微服务通信。

我想问： 在微服务中使用Airflow的最佳方法是什么？我应该使用DAGs中的任务来与微服务通信（发布消息，而微服务将订阅）吗？

DAG可以描述如下。请注意，还有其他任务，例如在下载数据后进行验证，但我已经简化了它。 DAG

- Whiskey

你能详细说明一下你所说的“但是，我必须将所有功能作为任务放入Airflow的一个容器中；而这并不符合当前的微服务架构。”吗？具体来说，你认为它不适合这样的架构的原因是什么？ - joebeeson

嗨@joeb，如果我将所有微服务的功能集成到一个Airflow容器中，那就会变成单块架构。我想要做的是将Airflow作为调度程序，同时保持所有微服务现在的状态。我已经阅读了一些文章，但没有找到这个问题的答案（例如：https://eng.lyft.com/running-apache-airflow-at-lyft-6e53bb8fccff或https://www.astronomer.io/blog/airflow-infrastructure/）。你觉得呢？ - Whiskey

你最终做了什么？我们在@Whiskey遇到了类似的问题。 - Zia Ul Rehman Mughal

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，

- Sean Connolly · Accepted Answer

一个像Apache Airflow的工作流引擎和微服务这样的架构范式天然是对立的。两者都是完全合法、有价值的，都有优缺点，但它们是构建分布式系统的两种完全不同的方法。你在评论中自己就提到了： “如果我将所有这些微服务的功能聚合到Airflow容器下，那就会变成单块式。” 这里违反了微服务原则中所说的“智能端点，愚蠢管道”。意思是说，“智能微服务A”应该与“智能微服务B”进行通信（无论是直接还是间接），而你不应该通过“智能工作流服务”将“愚蠢微服务A”和“愚蠢微服务B”连接在一起。后者更像是企业服务总线（ESB）或面向服务的架构（SOA）设计。再次强调，ESB和SOA各有其用处，但微服务架构是一种不同类型的架构，并且本质上是不兼容的。