我们有一个非常复杂的现有程序，它的核心业务逻辑类似于：
使用kafka消息（id，...）->检查并验证数据（如果已验证）->从Redis缓存中检索一些基本数据（结果1）->根据给定的id从外部api检索数据（结果1）->通过将结果1和结果2连接到结果3进行计算->从外部api检索其他数据（结果4）->结果4的某些字段的总和，然后与结果3的某些字段的总和进行比较，得到最终结果
该计算可能一天触发几次，或者每天可能只运行一次以获取一批ID。
我应该将整个逻辑纳入Flink吗？这样是否符合Flink的最佳实践？ 消耗Kafka消息（Flink源）->上述复杂逻辑（Flink转换）->保留最终结果（Flink接收器）
或者，仅将“计算”部分重构为flink样式？但是业务逻辑的其他部分呢？在规则业务世界中，可能存在比我上面列出的5或6个步骤更复杂的逻辑。 如果尝试这样做，如何在“业务逻辑”代码和Flink转换之间进行交互？
是否有任何将现有代码重构为Flink样式的准则或最佳实践？
任何想法都欢迎！
谢谢！