Whi*_*key 5 python architecture etl microservices airflow
我当前的平台架构有一个用于下载/收集数据的微服务、一个用于 ETL 的微服务和另一个用于处理一些复杂 SQL 脚本的微服务。
我想使用 Airflow 来安排和监控工作流程。我尝试了一下，效果非常好。然而，我必须将所有功能作为任务放入 Airflow 的一个容器中；这不符合当前的微服务架构。我想要的是使用 Airflow 作为调度程序并与其他微服务进行通信。
我想问： 将 Airflow 与微服务结合使用的最佳方式是什么？我是否应该使用 DAG 中的任务与微服务进行通信（发布消息，微服务将订阅）？
DAG 可以描述如下。请注意，还有其他任务，例如下载数据后的验证，但我只是简化了它。 有向无环图
像 Apache Airflow 这样的工作流引擎和像微服务这样的架构范式本质上是对立的。两者都是完全合法的，都很有价值，并且都有优点和缺点，但它们是构建分布式系统的两种完全不同的方法。
您自己在评论中提到了这一点：
..如果我将这些微服务的所有功能收集到一个气流容器中，那么这将是一个整体。
这里违反的微服务原则被称为“智能端点，哑管道”。
“智能微服务 A”的想法应该与“智能微服务 B”进行通信（直接或间接），并且您不应该通过“智能工作流服务”将“哑微服务 A”和“哑微服务 B”连接在一起。
后者更多的是企业服务总线（ESB）或面向服务的架构（SOA）设计。
同样，ESB 和 SOA 各有其地位，但微服务架构是一种不同类型的架构，并且本质上是不兼容的。
