Microservices 具有可变依赖关系的用例的气流dag定义

我想在以下用例中使用气流：

• 计算给定网站的每日报告（需要处理约150个网站）。每份报告的计算方法如下：
  • 应在站点级别运行的一组任务
  • 一组应在页面级别运行的任务，每个网站包含约10k个页面
  • 执行上述两组任务后，将运行第三组任务以聚合结果并生成报告

注意：这里描述的每个气流任务实际上都是对远程微服务的简单调用（grpc调用）

到目前为止，我想到的设计是：

• 我最初希望在一个任务中执行与页面相关的所有流程，以便使用一个简单、定义良好的dag，只需执行几个任务。 但是需要在页面上执行的处理是复杂的，有外部依赖项和队列（只有在收到来自外部系统的通知时才会触发下一个任务，这些通知可能会在几个小时后到达）=>我希望使用气流来处理此过程
• 鉴于上述观点，我现在倾向于一种模型，即一个网站的所有进程都被嵌入到一个dag中，包括页面的任务。理想情况下，我希望使用子DAG来处理与页面相关的任务，但从我目前所读到的内容来看，这个功能还不稳定。 每个网站将生成一个新的dag，其中包含一组新的任务（因为dag的结构取决于页面的数量）。 因此，每个dag的任务数量将相对重要（10k）

我的问题是:

• 对于这个用例来说，airflow是一个可接受的框架（即您是否运行过类似的用例）还是其他框架，如luigi、oozie。。。在这方面有明显的优势吗
• 上述方法（每个网站一个dag，没有子dag，在dag中包含页面任务）是否合理？你认为这有什么问题吗
• web ui是否仍然可以用于这些任务？我用几百个任务做了一个快速测试，我有几个超时，我想知道它是否与我的配置相关
• 芹菜是正确的后端吗？我想知道“LocalExecutor”实际上是否更适合这个用例，因为事实上气流工作者没有直接执行计算（他们只调用远程服务）

---

你最初的想法是我赞同的。拥有150个不同的工作流，每个工作流包含10K任务，这将导致一个完全动态且不可管理的场景。一方面，您说每个任务只是一个简单的gRPC，但同时您提到页面级任务在单个任务后面封装起来非常复杂，并且存在可能导致以小时为单位的流量瓶颈的外部依赖关系
如果我是你，我会重新设计解决方案，并将页面级报告转移到另一层。例如，创建一个能够进行所有这些复杂计算的服务，比尝试在应用程序中实现这一点更好。这样，您可能会显著减少页面级任务的数量
关于你的具体问题：
• 气流是不可知的-每一种情况都可能是完美的，这取决于 设计。Oozie真的很老派，笨重，而且缺乏太多的经验 翼型提供的集成功能。路易吉，我没用过
• 如前所述，这种方法同时具有不可预测性和不可管理性。我预见到了混乱：）
• 获得挂起的UI是一个很好的指标，您应该重新审视您的实现设计。但用户界面应该是你最关心的问题——如何在一个工作流中监控和管理10000个任务？正确-你不能。再乘以150
• 不久前，我读了一篇文章，来自一家公司，他们在使用芹菜进行扩展时遇到了一些问题，他们决定扩大规模，在同一个VM上并行运行许多调度程序进程。不太确定这是否是一种对您的场景有显著好处的设置

---

如果我是你，我会为所有150个站点提供一个单一的工作流程。我会为每个网站创建一个子DAG（顺便说一句，在中没有提到“不稳定”一词），并尝试将复杂的计算操作卸载到不同的层，以便尽可能减少页面级任务的数量。
谢谢！你是对的，可能有更好的方法来组织它，这里真正的痛点是那些具有长延迟回调的外部服务，但我会想办法；）