architecture - 既然 ESB 标准化和改变了系统间消息的数据格式，是否也应该负责标准化错误消息？

Question

我正在寻找有关基于 ESB 的 SOA 架构中的错误处理的更多信息。我在使用多个数据源的项目中，每个数据源的实现方式都非常不同。我工作的公司刚刚推出 ESB，还没有制定标准。在我们的环境中，我观察到许多违反标准的行为（比如 200 响应实际上是一个错误，需要根据内容重新解释）。我们正在讨论错误处理方案，基本上我们正在考虑两种选择：

1. 每个终端系统负责解释来自他们正在与之通信的系统的错误消息。在这种情况下，消息总线以尽可能少的翻译传递错误消息。
2. 消息总线正在标准化错误消息，从而减轻了端点系统的一些责任。它们将具有相同的结构并确保防止违规 - ESB 将不得不解释一些消息，例如这些 200 ok 是错误的

我担心以下方面：

• 每个场景的可扩展性
• 整个企业的工作量 - ESB 团队很昂贵，但所有其他团队的工作也是如此
• ESB 团队的可用性是有限的

有没有关于错误处理的标准？集成层通常需要多少？还有其他我们需要考虑的方面吗？哪个方面应该（可能）对组织更重要？

也许我们应该整体采用不同的策略？也许提供可以处理错误处理细节的集成库（例如，用于 JAVA 的 JARS 和用于 .NET 的 DLL），而不是标准化纯 json 消息？

标签： architectureesb