spring - 每秒或什至不到一秒安排简单的 GET 批处理 - 应该选择 Spring Cloud Task、Spring Batch 或 springframework.scheduling

Question

背景:在我的国家，11 月将有一种新的即时付款方式。基本上，中央银行将提供两个端点:(1)一个 POST 端点，我们发布单笔汇款；(2)一个 GET 端点，我们在那里获得之前发送的汇款结果，它可能完全无序。它将仅对 Money Transfer 结果进行回复，并且在其标题中会通知我们是否必须获取另一个结果。它永远不会告知有多少结果可用。如果有结果，它会返回 Get 响应，并且只通知它是最后一个还是有剩余的用于下一个 GET。
最高限制:从最终用户在他/她的移动应用程序中单击转移按钮的那一刻起，直到最终结果显示在他/她的移动屏幕上(如果成功或失败)是 10 秒。
策略:我想要一个每秒或什至不到一秒触发一次 Get to Central Bank 的时间表。调度程序基本上会调用一个简单的函数，它 (1) 调用 Get 端点，(2) 将其推送到 Kafka 或持久保存在数据库中，以及 (3) 如果在答案标题中通知有更多结果可用，则再次启动相同的函数.
问题:由于我们是 Spring 用户/追随者，我虽然我的决定是在 Spring Batch 与 org.springframework.scheduling.annotation.SchedulingConfigurer/TaskScheduler 之间。我已经成功地使用了 Spring Batch 一段时间，但从未使用过这么短的时间触发(从未使用过 1 秒)。我在讨论中跌跌撞撞，这让我思考如果在我的情况下，一个非常简单但周期很短的任务，我应该考虑 Spring Cloud Data Flow 或 Spring Cloud Task 而不是 Spring Batch。
根据 this answer “...... Spring Batch 是......设计用于构建复杂的计算问题......如果需要，您可以使用 Spring Scheduler 编排 Spring Batch 作业”。基于此，我似乎不应该使用 Spring Batch，因为我的情况并不复杂。挑战设计决策更多地是关于短期触发和从当前批次触发另一个批次，而不是转换、计算或 ETL 过程。尽管如此，据我所知，带有 tasklet 的 Spring Batch 是为重新启动、恢复和重试而精心设计的，并且非常适合永远不会完成的场景，而 org.springframework.scheduling 似乎只是一种基于周期触发事件的方法配置。嗯，这是我根据个人使用和研究的填充。
根据某人询问有关组合任务的编排的回答 this answer “……您可以使用 Spring Cloud Data Flow 和 Spring Cloud Task/Spring Batch 来实现您的设计目标……”。就我而言，我看不到组合任务。就我而言，第二个触发器不依赖于前一个触发器的结果。这听起来更像是“链式”任务而不是“组合”。我从未使用过 Spring Cloud Data Flow，但它似乎是管理/查看/控制台/仪表板触发任务的不错选择。尽管如此，我没有发现任何关于短期触发器和“链式”触发器的限制或经验法则。
所以我的直接问题是:目前推荐的 Spring 成员是什么来触发这么短的时间？假设 Spring Cloud Data Flow 用于管理器/仪表板，那么在如此短的触发器场景中推荐的 Spring 触发器成员是什么？似乎 Spring Cloud Task 是为调用复杂函数而设计的，而 Spring Batch 似乎添加的太多超出了我的需要，并且 org.springframework.scheduling.* 缺少与 Spring Cloud Data Flow 的集成。作为类比而不是比较，在 AWS 中，文档明确指出“不要使用 CloudWatch 少于一分钟。如果您想要少于一分钟，请每分钟启动 CloudWatch，每秒启动另一个调度程序/cron”。对于需要每秒甚至不到一秒触发并利用 Spring 家族的方法/关注点/经验的简单任务，可能有一个众所周知的经验法则。

Answer 1

这可能是愚蠢的答案。为什么这里需要调度程序？一个永无止境的工作难道不会在这里实现目标吗？

你开始工作，它做了一个 GET请求，将结果推送到 kafka ,

如果GET响应表明，它有更多的结果，它立即执行 GET再次将结果推送到 kafka

如果GET响应表明，没有更多结果，sleep for 1 second ，做 GET再次请求。