微服务的气流架构答案

【问题标题】：Airflow Architecture for Microservices微服务的气流架构
【发布时间】：2020-08-05 16:12:47
【问题描述】：

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

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

我想问： 将 Airflow 与微服务结合使用的最佳方式是什么？我是否应该使用 DAG 中的任务与微服务进行通信（发布消息和微服务将订阅）？

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

【问题讨论】：

您能否解释一下您的“但是，我必须将所有功能作为任务放入 Airflow 的一个容器中；这不符合当前的微服务架构。”评论您如何具体地认为它不适合这样的架构？
嗨@joeb，如果我将这些微服务的所有功能集中到一个气流容器下，那将是一个整体。我想做的是让 Airflow 作为调度程序，同时保持所有微服务现在的样子。我读过几篇文章，但我还没有找到这个问题的答案（例如：eng.lyft.com/running-apache-airflow-at-lyft-6e53bb8fccff 或 astronomer.io/blog/airflow-infrastructure）。你怎么看？
你最后做了什么？我们有类似的问题@Whiskey

【解决方案1】：

像 Apache Airflow 这样的工作流引擎和像微服务这样的架构范式本质上是对立的。两者都是完全合法的，都很有价值，并且各有利弊，但它们是构建分布式系统的两种完全不同的方法。

您自己在评论中提到了它：

..如果我将这些微服务的所有功能集中到一个气流容器下，那将是一个整体。

此处违反的微服务原则称为“smart endpoints, dumb pipes”。

“智能微服务 A”的想法应该与“智能微服务 B”（直接或间接）通信，并且您不应该将“哑微服务 A”和“哑微服务 B”通过“智能工作流服务”连接在一起'。

再次重申，ESB 和 SOA 各有千秋，但微服务架构是一种不同的架构，本质上是不兼容的。

【讨论】：

谢谢你的解释，你能参考一些像气流这样的工具，它可以在这种情况下提供帮助，我们希望保留微服务架构，但希望能够做所有（大多数）事情气流帮助我们，比如 DAG，并内置了监控日志重试等功能。
我想你会想看看框架和一般的最佳实践。