2

我们的主编排有多个子编排。所有根编排都是事务类型:无,因此所有子编排也具有相同的性质。现在,任何异常都会在主编排的父范围内被捕获,并且我们有一些步骤,例如日志记录。使用来自 App SQL 的消息激活编排。所以每次发生异常时,比如说由于间歇性的事情,比如无法连接到 Web 服务。我们以后去手动重新触发。

我正在考虑将 orch 修改为自我修复,例如从异常捕获块中它根据说明问题的条件重新初始化消息,问题是间歇性的。像 app issue-null reference 这样的东西,我们不想重新发送消息,因为 orch 永远不会工作。

有一个称为补偿的概念,但这是基于事务的 orch-n 步骤,如果任何 1 失败,则执行 m 其他步骤(这将执行替代操作或清理)。

我唯一的想法是根据异常中的关键字进行查找并决定重新发送消息。但我希望 some1 挑战这一点或提出更好的方法

4

1 回答 1

1

我一直认为最好离线处理故障。因此,如果编排失败,请终止它。但在您终止之前,请发送一条消息。如果事实证明存在导致失败的临时问题,此消息将包含恢复消息处理所需的所有信息。消息可以由负责恢复的“看守”进程使用。

这类似于 Erlang OTP 框架实现高可用性的方式。流程快速失败,看守流程确保恢复发生。

于 2012-09-05T09:02:41.097 回答