面向服务的体系结构通信标准

Question

我过去的工作是构建一个使用面向服务体系结构结构化的数据处理应用程序。我有一系列的服务，它们都将通过一个主服务来管理，主服务将串行地调用所有服务来处理我的数据。

我遇到了一些我不喜欢的事情，因为服务必须向主服务提供状态和错误反馈，而我必须从头开始编写所有代码。

我的问题是，是否存在服务间通信和管理的标准。消息格式、错误恢复和状态报告等内容对我来说尤其重要。我将不得不在未来重新构建SOA，我不想“从头开始”开发，而是更愿意遵循更高的标准。我知道我的问题的一些答案将基于我的业务需求，但是我想先看看在这方面是否有什么。

谢谢,

mj

Answer 1

编排服务时的ACID事务

在编排服务时，为了确保后端系统中数据的状态一致，您通常会希望避免编排，在这种编排中，您有多个相互依赖的调用来更新/创建数据。然而，在现实中，通常存在需要多个这样的步骤的场景，并且您基本上最终拥有一个由跨越一组服务的多个服务调用组成的事务。当然，您需要确保您的流程已作为ACID事务发生。

处理此问题的经典方法是通过为事务内的所有服务调用建立一个公共事务上下文来使用2PC - 2-Phase-Commit。然而，它在面向服务的体系结构中非常少见，因为它要么成本太高，要么完全不可能。它还将您的服务耦合到事务上下文。

更实用的方法是使用一种称为补偿的方法。与2PC相比，它为您提供了更好的灵活性和解耦能力。作为补偿，如果一个步骤失败了，并且在此之前已经完成了一些成功的写入，那么您可以根据您的上下文做一些适当的事情来进行补偿-例如，您可以调用另一个服务来回滚更改，或者执行删除/停用记录的现有服务的另一个操作。这种方法使业务逻辑(在您的案例中是在流程服务中)变得更加复杂，但它使您能够更轻松地创建服务，而不必关心事务上下文而使它们复杂化。

我在实践中看到的是，在事务中使用的服务通常是使用相反的操作来设计的，以便允许补偿-例如，在名为Users的服务中，您将拥有CreateUser和DeleteUser等操作。

如果您真的想遵循正式的标准，并且您的服务是web服务，那么您可以在这里查看WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity规范，并自行决定它是否过于夸张。

状态报告

我就在这里分享我的经验吧，比伊。让每个服务报告三种常见状态非常方便(根据服务上下文，您可能会有更多状态，但您的所有服务都可以返回这三种状态)：

• OK -操作成功(没有什么有趣的事情发生，每个人都很高兴，但有点像bored)
• Recoverable Error -它告诉你的进程一个错误，如果你重试调用服务，这个错误很可能会得到解决。例如，系统暂时处于繁忙或脱机状态。对于这样的错误，您可以设置您的进程重试多次，然后放弃并生成rollback.
• Non-Recoverable Error -无论您重试多少次，它都不会得到解决-例如，您的请求格式不正确，或者缺少关键的强制输入参数。在这些情况下，您可以进行回滚。请注意，在讨论错误报告时，您必须同时考虑记录所有服务活动。

希望这能有所帮助！