面向服务的架构通信标准

Question

我曾参与构建一个使用面向服务的体系结构构建的数据处理应用程序。我有一系列服务，所有服务都由主服务管理，该服务将按顺序调用所有服务以处理我的数据。

然而，在这个过程中，我遇到了一些不喜欢的问题，即服务必须向主服务提供状态和错误反馈，并且我必须从头开始编写所有代码。

我的问题是，是否存在相互服务通信和管理的标准。诸如消息格式、错误恢复和状态报告等特定关注点。我将来需要重新构建SOA，我不想从头开始开发，而是希望符合更高的标准。我知道我的问题的一些答案会基于我的业务需求，但我想先看看是否存在这样的东西。

谢谢，mj

- mj_

---

请澄清一下您所说的SOA是什么意思，因为SOA更多地是一种方法，通过向外部公开服务，跨域实现业务流程并在企业中对齐业务和技术来帮助集成多个系统。但是我觉得您是在谈论单个应用程序的情况吗？ - Plamen Petrov

@PlamenPetrov 我有一系列的服务，每个服务都提供数据处理能力。其中一个检测损坏字符，另一个扫描重复数据等等。我有一个应用程序目前使用这些服务，并且我是这样构建它的，以便未来的应用程序可以利用相同的服务。我发现我经常重复功能，我想要独立的服务，可以尝试挤出性能优势。让我的主应用程序来回通信是我想要标准化的。 - mj_

你需要查看诸如IFX、FIX等协议。这些SOA SOAP协议都是为解决特定问题的SOA需求而设计的。IFX是一种可用于银行业务的XML协议，而FIX是股票交易协议等。有许多类似的协议可供使用，您可以直接使用它们，也可以根据自己的需求进行修改。 - Namphibian

Answer 1

编排服务时的ACID事务

在编排服务时，通常应避免具有多个相互依赖的调用以更新/创建数据的编排，以确保后端系统中数据的一致状态。然而，在现实中，经常存在需要多个这样的步骤的情况，您最终会得到由一组服务跨多个服务调用组成的事务。当然，您希望确保您的过程已作为ACID事务发生。

处理此问题的经典方法是使用2PC - 两阶段提交，通过为事务内的所有服务调用建立共同的事务上下文来处理。但是，在面向服务的架构中很少见到它，因为要么太昂贵了，要么根本不可能。它还将您的服务耦合到事务上下文中。

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

在我的实践中，我看到的是，通常会设计用于事务的服务具有相反的操作，以便允许进行补偿 - 例如，在名为Users的服务中，您将拥有像CreateUser和DeleteUser这样的操作。

如果您真的想遵循正式标准，并且您的服务是Web服务，您可以在此处查看WS-Coordination、WS-AtomicTransaction和WS-BusinessActivity规范，并自行决定是否过度。

---

状态报告

我在这里分享一下我的经验，bea。每个服务报告三种常见状态非常方便（根据服务上下文可能会有更多，但是所有服务都可以返回这三种）：

• OK - 操作成功（没有什么有趣的事情发生，每个人都很高兴但有点无聊）

• 可恢复错误 - 它告诉您的进程，如果重试调用服务，则很可能会解决错误。例如，系统暂时繁忙或离线。对于这种错误，您可以设置进程多次重试，然后放弃并进行回滚。

• 不可恢复错误 - 无论您重试多少次，都无法解决的错误 - 例如，您的请求格式不正确或缺少关键强制输入参数。在这些情况下，您需要进行回滚。 请注意，在谈论错误报告时，您必须考虑记录所有服务活动。

希望这可以帮助到您！

- Plamen Petrov