我过去曾致力于构建使用面向服务架构构建的数据处理应用程序。我有一系列服务都可以通过主服务进行管理，主服务可以串行调用所有服务来处理我的数据。
我碰到了一些我不喜欢的东西，因为服务必须向主服务提供状态和错误反馈，我不得不从头开始编写所有代码。
我的问题是，是否存在用于服务间通信和管理的标准。我特别关注消息格式，错误恢复和状态报告等内容。我将来必须重建一个SOA，而且我不想从头开始开发＃34;＆＃34;但宁可遵守更高的标准。我知道我的问题的一些答案将基于我的业务需求，但是我想看看这个问题是否有任何问题。
谢谢，
MJ
答案 0 :(得分：0)
协调服务时的ACID交易
在编排服务时，您通常希望避免编排，因为您有多个相互依赖的调用来更新/创建数据，以确保后端系统中的数据状态一致。但是，实际上通常会出现需要多个此类步骤的情况，并且您最终会拥有一个包含跨一组服务的多个服务调用的事务。当然，您需要确保您的流程已作为ACID交易发生。
通过为事务中的所有服务调用建立公共事务上下文，使用2PC - 2阶段提交时，会想到一种经典方法。然而，在面向服务的体系结构中很少见到它，因为要么太昂贵，要么完全不可能。它还将您的服务与交易环境相结合。
更实用的方法是使用名为 Compensaton 的方法。与 2PC 相比，它为您提供了更好的灵活性和解耦性。作为补偿，如果步骤失败，并且在此之前已经完成了一些成功的写作，则可以根据您的情况做一些适当的补偿 - 例如您可以调用另一个服务来回滚更改，或者执行删除/停用记录的现有服务的其他操作。这种方法使业务逻辑（在您的流程服务中）变得更加复杂，但它使您能够更轻松地创建服务，而不必因为必须关心事务上下文而使它们复杂化。
我在实践中看到的是，通常在交易中使用的服务设计有相反的操作以便允许补偿 - 例如在名为Users的服务中，您将拥有CreateUser和DeleteUser等操作。
如果您真的想遵循正式标准，而您的服务是网络服务，那么您可以在此处查看WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity规范，并自行决定是否过度杀伤。
状态报告
我将在这里分享我的经历，bea。让每个服务报告三种常见状态非常方便（根据服务上下文可能有更多，但所有服务都可以返回这三种）：
确定 - 操作成功（没有任何有趣的事情发生，每个人都很开心，但有点无聊）
可恢复的错误 - 它会告诉您的进程在您重试调用服务时很可能会解决的错误。例如，系统暂时忙或离线。出现此类错误，您可以设置进程多次重试，然后放弃并进行回滚。
不可恢复的错误 - 一个错误，无论您重试多少次，都无法解决 - 例如您的请求格式错误，或者缺少关键的强制性输入参数。在这些情况下，您进行回滚。 请注意，在谈论错误报告时，您必须考虑记录所有服务活动。
希望这有帮助！