使用 Camel 处理长期进程的方法
我正在研究基于 Camel 的小型流程引擎的 PoC。要求是能够执行一系列结果步骤，每个步骤可能需要几个小时才能执行。在这种情况下，异步通信风格是显而易见的选择，但我很难让“流程”部分正确。
当向外部系统发送消息时，我需要等待完成。只要可能需要很多时间，我就会考虑在发送消息后停止具体步骤的处理，然后在收到完成消息后开始新的“工作”。因此，每个步骤的字面处理将被处理为从同一 JMS 队列开始的 Camel 路由，然后基于内容的路由器将根据消息头或其内容决定应执行哪些具体逻辑。
然而，问题是如何避免潜在的消息丢失。例如，在具体步骤中，我发送消息并停止处理。由于某种原因，外部系统没有处理消息，因此我的系统没有收到任何通知。这意味着进程被卡住，除非其他组件生成消息来唤醒它。
此外，只要系统可以在任何时间关闭，我就必须构建逻辑以在重新启动后继续处理消息（这意味着某种消息持久性、重新传递和事务管理策略）。
所有这些问题加起来，因此我想请经验丰富的 Camel 冠军提供有关如何使用 Camel 设计此类逻辑的建议。我知道专用的 BPM 产品或 ESB 可能会更轻松地处理这个问题，但我不想让解决方案变得臃肿。
欢迎提出任何建议，特别是在 Camel 功能方面，可以帮助简化解决方案。
I'm working on PoC for small process engine based on Camel. Requirements are to have ability to execute set of consequence steps and each of them could potentially take hours to execute. Asynchronous communication style is obvious choice in this case but I'm struggle with getting "process" part right.
When sending message to external system I need to wait for completion. As long as it might take lot of time I'm thinking about stopping processing of concrete step after I sent message and then starting new "job" upon getting completion message back. So literally processing of each step will be handled as a Camel route starting at same JMS queue and then content-based router will decide which concrete logic should be executed based on headers of message or its content.
The problem, however, is to how to avoid potential of messages loss. For example, at concrete step I'm sending message and stop processing. The external system for some reason did not process message thus my system does not receive any notification. This means that process is stuck unless some other component will generate message to wake it up.
Also as long as system could be shutdown at any point of time I have to build in logic to continue processing messages after restart (which implies some kind of message persistence, redelivery and transaction management strategy).
All this issues add up thus I'd like to ask experience Camel champions to provide suggestions on how to design such kind of logic using Camel. I know that dedicated BPM product or ESB might handle this problem much more easier but I don't want to bloat the solution.
Any advices are welcomed, especially in terms of Camel capabilities that could help in simplification of solution.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Camel 的 BAM 支持应该为您提供一些长期进程支持（超时、错误处理场景） ， ETC）。另外， JMS 和 交易 将有助于满足可靠/持久的消息传递要求等。
祝您好运，如果您采用替代方法，请告诉我们...
Camel's BAM support should provide you with some of the long-lived process support (timeouts, error handling scenarios, etc). Also, JMS and transactions will help with reliable/persistent messaging requirements, etc.
good luck and let us know if you land on an alternate approach...
我建议声明检查模式最适合在长时间运行的外部调用之间持久保存状态。在发送出站消息之前检查进程的状态。
处理外部进程未回复检测的一种方法是发布两条消息。一条消息发送到外部进程，另一条消息发送到内部队列。我将第二个消息称为进程超时消息。这是一条非常小的消息，仅包含相关 ID 和适当的过期时间。如果该进程是从外部进程接收的，则接收进程将具有相关 ID，并且能够从进程超时队列中删除该消息。如果外部进程没有回复，那么进程超时队列的死信队列应该连接到一个驼峰路由，该路由向管理员发出警报或采取适当的自动操作，例如检索声明检查等。这应该允许持久状态开销最小，没有 BPM 工具，因此没有单点故障。
I would suggest the Claim Check pattern is the most appropriate for persisting state between long running external invocations. Check-in the state of your process before sending the outbound message.
One way to handle detection of the non-reply from the external process is to post two messages. One message goes to the external process, another goes to an internal queue. I'll call the second one the process timeout message. It is a very small message with just the correlation ID and an appropriate expiration time. If the process is received from the external process, the receiving process will have the correlation id and be able to remove the message from the process timeout queue. If the external process does not reply, then the dead-letter-queue for the process timeout queue should be connected to a camel route that alerts an administrator or takes appropriate automatic action, e.g. retrieving the claim check, etc. This should allow persistent state with a minimum of overhead and no BPM tool and hence no single point of failure.