我希望有人可以激发一些想法或提供在PHP 5中创建“事务协调器”实现的材料的参考。该驱动程序基于多供应商单一业务流程集成。由于潜在的失败点，我想避免意大利面条代码与大量的if，switch，try..catches并有一个协调器，可以拦截方法调用，跟踪对后续调用的响应，并询问方法属性，以确定什么补偿功能用来扭转交易。目的是创建像处理一样的“ACID”。我可以引用的结束事项是.Net中的TransactionScope对象。
示例场景：
ServiceA
ServiceB
ServiceC
ServiceA->DoSomething() - passes
ServiceB->DoSomething() - passes
ServiceC->DoSomething() - fails
此时A＆amp; B必须采用某种类型的补偿策略来调用将返回状态的功能，无论是数据库，第三方集成还是以其他方式返回其原始状态。
我最初的想法是使用某种类型的AOP来保持对补偿器的参考以及完成逆转活动的状态要求。比协调员需要跟踪执行情况，以及返回的执行状态以允许调用补偿器。
答案 0 :(得分：1)
不要尝试ACID，因为你不能这样做。试图伪造它会在某些时候泄漏，所以最好不要先尝试。正如您自己写的那样，使用服务A执行一个步骤，稍后看到服务C失败，您需要告诉服务A撤消所采取的一个步骤。如果无法撤消单个步骤，则解决方法可能是使用服务A重新启动，执行重置以及所有先前执行的步骤，而不使用事务中的最后一个步骤。这听起来根本不是ACID。假装它会在某些时候失败。
在为流程建模时，请使用有限状态机。它独立于您的服务可以做什么或不能做什么，但是您可以跟踪需要采取的步骤，可能是以哪种顺序，如果步骤失败该怎么做，并且在任何时候都相对容易扩展。
关于你的评论，你最终可能会陷入混乱的if，switch和try / catch：这完全取决于你，但与实现一个过程无关。
如果您正在寻找状态机的实现，那么PHP就没有那么多。 PEAR有一个非常PHP4风格的旧版本，可能仍然可以工作（看看：http://pear.php.net/package/FSM），但更好的实现是https://github.com/Metabor/Statemachine - 这家伙写了“状态机”在那里，我看到了一些非常好的功能，例如将通过回调执行工作的代码移交给转换，然后通过事件更改转换。这样做的好处是，您的状态机可以完全控制可以执行和不可执行的操作，如果可以执行，则可以通过回调完成。
一个简洁的功能是您可以将定义的状态和转换保持为图像。