我有一个架构，其中我们拥有大约6-10个无状态（微）服务，这些服务公开API端点“ POST / run_job arg1 arg2 arg3 ...”，并使用它们自己的工作产生机制（python-rq） Redis作为队列和主干模式。这些工作需要几分钟到几个小时，最常见的是处理一些数据和/或进行一些数据转换。有些工作依赖于其他工作，因此有必要触发作业1完成后（消耗人工制品）的作业2。因此，显然会有一些流程，有时需要用户手动批准。当前，用户被迫从根本上手动控制流程，或在job1完成时触发job1（在进行协调时没有任何总体服务）。大多数服务都是无状态的。
由于整个系统是由非工程师操作的，因此要求透明（“我的流处理是否很好？是否失败了？为什么？现在处于什么状态？”）
GCP的kubernetes中现在有了完整的架构，具有定义良好的应用程序（12要素应用程序）以及良好的监视和日志记录。一切都在CI / CD下。有时会使用Pubsub，但无论如何都不用于控制流，只是在不适合使用HTTP的地方发送数据。
很显然，这不是可行的方法，而且由于我希望系统扩展到更多的步骤，因此这是不可持续的。
因此，我正在考虑如何解决此问题。有AFAIK这些方法：编排和编排。两者混合使用：全局编排和局部编排（1），但是我不知道如何在用例中使用它。
从理论上讲，编排似乎是执行此操作的好方法，但是很难想象如果没有实际的状态（大部分是用户反馈部分），这一切将如何工作。
编排似乎是我想要的-例如使用Argo，我们基本上应该摆脱那些微服务，而只是将它们的“作业”部分（没有自己的工作产生或API）用作定义良好的流程的一部分，这些流程内部具有整个流程（job1，job2） ，等待用户确认，作业3，...），状态等。另一方面，这是令人担心的单点故障和流程内部的耦合（“服务”-现在是作业-仍会独立开发并发布为只要它们符合界面-CLI）。
我可以遵循哪些程序来决定这两者？我正在阅读例如：
1) https://www.simpleorientedarchitecture.com/modelling-long-running-processes-choreography-versus-orchestration/
2) https://www.ben-morris.com/events-sagas-and-workflows-managing-long-running-processes-between-services/
3) https://blog.bernd-ruecker.com/why-service-collaboration-needs-choreography-and-orchestration-239c4f9700fa
4) https://netflix.github.io/conductor/
但是我对任何解决方案都没有足够的信心。