我过去致力于构建使用面向服务的架构构建的数据处理应用程序。我有一系列服务，这些服务全部由主服务管理，该主服务将串行调用所有服务来处理我的数据。
我遇到了一些我不喜欢的事情，因为服务必须向主服务提供状态和错误反馈，而我必须从头开始编写所有代码。
我的问题是，是否存在服务间通信和管理的标准。诸如消息格式、错误恢复和状态报告之类的事情是我特别关心的。将来我将不得不重建 SOA，并且我不想“从头开始”开发，而是宁愿遵守更高的标准。我知道我的问题的一些答案将基于我的业务需求，但是我想先看看是否有任何关于此的内容。
Thanks,
mj
编排服务时的 ACID 事务
在编排服务时，您通常希望避免进行多个相互依赖的更新/创建数据的调用的编排，以确保后端系统中数据的一致状态。然而，实际上，经常存在需要多个此类步骤的场景，并且您最终会得到一个由跨一组服务的多个服务调用组成的事务。当然，您需要确保您的流程已作为ACID http://en.wikipedia.org/wiki/ACID交易。
我想到的处理这个问题的经典方法是使用2PC http://en.wikipedia.org/wiki/Two-phase_commit_protocol – 两阶段提交通过为事务中的所有服务调用建立公共事务上下文。然而，它在面向服务的架构中很少见，因为它要么成本太高，要么根本不可能。它还将您的服务与事务上下文耦合起来。
更实用的方法是使用一种称为补偿。与相比，它为您提供了更好的灵活性和解耦性2PC。作为补偿，如果某个步骤失败，并且在此之前已经完成了一些成功的写作，您可以根据您的上下文采取适当的措施来进行补偿 - 例如您可以调用另一个服务来回滚更改，或者调用现有服务的另一个操作来删除/停用记录。这种方法使业务逻辑（在您的案例中的流程服务中）变得更加复杂，但它使您能够更轻松地创建服务，而不必担心事务上下文而使它们变得复杂。
我在实践中看到的是，交易中使用的服务通常被设计为具有相反的操作，以便允许补偿 - 例如在名为“用户”的服务中，您将具有诸如“创建用户”和“删除用户”之类的操作。
如果你确实想遵循正式标准并且你的服务是Web服务，你可以看看WS-协调、WS-AtomicTransaction 和 WS-BusinessActivity https://msdn.microsoft.com/en-gb/library/ms996526.aspx#wsac_topic4此处的规格并自行决定是否过度杀伤。
状态报告
我只是在这里分享我的经验，bea。让每个服务报告三种常见状态非常方便（根据服务上下文，您可能会报告更多状态，但所有服务都可以返回这三种状态）：
OK– 操作成功（没什么有趣的事情发生，大家都很高兴但有点无聊）
可恢复的错误– 它告诉您的进程，如果您重试调用该服务，很可能会解决一个错误。例如，系统繁忙或暂时离线。出现此类错误时，您可以将进程设置为重试多次，然后再放弃并回滚。
不可恢复的错误– 无论您重试多少次都无法解决的错误 – 例如您的请求格式错误，或者缺少关键的强制输入参数。在这些情况下，您需要进行回滚。
请注意，在谈论错误报告时，您还必须考虑记录所有服务活动。
希望这可以帮助！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
