4

我目前参与的项目要求业务逻辑必须在 Web 服务中实现，该服务将由表示层组件（即 Web 应用程序）使用。

该公司有一个企业服务总线，最新的几乎所有开发的 Web 服务都通过这个总线公开。我询问了周围的一些同事何时通过 ESB 公开服务，我得到了以下答案：

  • 如果有 ESB，则通过它公开所有内容：有几个好处，例如负载平衡和位置透明性
  • 如果 ESB 仅充当代理 - 即没有消息转换 - 就不要使用它：您将超载 ESB 并失去性能。您最好进行点对点连接。
  • 如果存在协议转换（例如将存储过程公开为 SOAP 服务），则应通过 ESB 公开组件。如果这不存在，你最好去点对点。

所以我很好奇是否有关于何时通过它公开 Web 服务的一般协议或最佳实践。任何阅读/参考都会有很大帮助。

4

1 回答 1

7

从我的角度来看，经过 4 年的 SOA 技术经验，使用 ESB 总是会使系统过载，因为您正在添加一个新层并让您的所有通信都通过它。如果没有 ESB，转换（消息传递或协议）和路由并不难完成，并且点对点通信将具有更高的吞吐量。业务流程自动化也是如此，有一些方法可以在不需要 ESB 的情况下实现。

另一方面，使用 ESB 在公司范围内有几个好处，但它必须在愿景和战略范围内。最好的例子之一是一家长期使用各种工具的公司，每个工具都有特定的目的，这使得公司分布在各自为政的团队中，团队相互隔离。很长一段时间后，这使得团队之间的交互变得复杂而缓慢。精心策划的 SOA 策略将有助于集成所有这些工具，并开始将它们替换为更有意义的轻量级项目。

所以，恕我直言，在没有企业战略的情况下使用 ESB 来解决单个项目中的几个“问题”并不是一个好主意，最终，当问题不存在时， SOA一词将在您的公司中被禁止SOA 本身就缺乏远见和企业战略。

关于 ESB 的使用，我发现的唯一经验法则是：在单个项目中对转换、路由、业务流程自动化（有或没有人工交互）等的要求并不是 SOA 的征兆（几乎每个项目必须执行转换、路由和业务流程自动化），但是当这些需求是整个公司的需求时，从业务角度考虑它是值得的，而不是技术角度。如果没有业务视角，那么 SOA 就会失败。

这是一个非常广泛的话题，讨论可能会持续很长时间，我建议您提供几个链接以供进一步阅读：

于 2012-08-09T16:03:51.793 回答