ESB 和 EAI 之间的区别
在大多数文章中，我看到 ESB 和 EAI 之间的主要区别是“EAI 中的单点故障”。
我的问题是：
在 EAI 中，如果集线器发生故障，我们是否会说这是单点故障。在 ESB 中，如果总线发生故障，我们也可以说是单点故障。这是对的吗？如果没有，请简要解释一下。
In most of articles I have seen that the major difference between ESB and EAI is "Single Point Failure in EAI".
My Question here is :
In EAI if Hub fails are we saying that this is single point of failure. In ESB also if Bus fails we can say single point failure. Is this right? If not please briefly explain about this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
ESB 和 EAI 之间的主要区别不是单点故障。
话虽如此，如果 ESB 总线发生故障，那么，是的，这就是一个故障点。最终，这些只是基础设施中的应用程序，它们是否是单点故障取决于它们的部署（例如集群），而不是底层概念集成模式。
就我个人而言，我将 ESB（企业服务总线）归类为 EAI（企业应用程序集成）的一种。许多试图向您推销产品而不是概念的公司会有不同的争论。
ESB 只是 EAI 的新模式，而不是 Hub-Spoke。我不会太陷入差异之中。当你深入研究时，它们很少而且相隔很远。
The major difference between ESB and EAI is not Single-Point-Of-Failure.
Having said that, if the ESB Bus fails then, yes, it is a point of failure. Ultimately these are just applications in your infrastructure and whether they are a single point of failure or not is dependent on their deployment (eg. clustering) and not on the underlying conceptual integration pattern.
Personally I would classify ESB (Enterprise Service Bus) as a type of EAI (Enterprise Application Integration). Many companies trying to sell you a product instead of a concept would argue differently.
ESB is just the new pattern for EAI instead of Hub-Spoke. I wouldn't get too caught up in the differences. When you dig into it they are few and far between.
请参阅此评论
ESB 是下一代企业集成技术，接管 EAI（中心辐射）的空白。
应用程序与外界交互的地方。 ESB 允许每个端点呈现
本身作为使用 WSDL 等标准的服务，并且无需编写独特的接口
对于每个应用程序。集成智能可以本地部署在端点（客户端和
服务器）本身。绕过规范格式，直接将有效负载格式化为
目标格式。这种方法有效地消除了 EAI 固有的复杂性
产品。
分布式架构。当程序之间的每次交互都已完成时，集中式枢纽就有意义了。
转换为规范格式。 ESB 分发更多的
处理逻辑到端点。
与 EAI 产品结合的专有功能堆栈。随着时间的推移，这些集成堆栈得到了
整体性强，需要深厚的专业知识才能使用。相比之下，ESB 是相对较薄的软件层
可以使用开放标准应用其他处理层。例如，如果 ESB 用户
想要部署特定的业务流程管理工具，它可以轻松地与
ESB 使用行业标准接口（例如 BPEL）来协调业务流程。
ESB 方法的直接短期优势是它实现了相同的整体效果
与 EAI（中心辐射）方法一样，但总拥有成本要低得多。这些节省并没有实现
不仅可以通过减少硬件和软件费用，还可以通过以下方式节省劳动力：
使用分布式且灵活的框架。
Refer this comment
The ESB is the next generation of enterprise integration technology, taking over where EAI(hub-spoke) leaves off.
where the application interfaces with the outside world. The ESB allows each endpoint to present
itself as a service using standards such as WSDL and obviates the need for a unique interface written
for each application. Integration intelligence can be deployed natively on the end-points (clients and
servers) themselves. Canonical formats are bypassed in favor of directly formatting the payload to
the targeted format. This approach effectively removes much of the complexity inherent in EAI
products.
distributed architecture. A centralized hub made sense when each interaction among programs had
to be converted to a canonical format. An ESB, distributes much more of the
processing logic to the end points.
stacks of proprietary features wedded to the EAI product. Over time these integration stacks got
monolithic and require deep expertise to use. ESBs, in contrast, are a relatively thin layer of software
to which other processing layers can be applied using open standards. For example, if an ESB user
wants to deploy a particular business process management tool, it can be easily integrated with the
ESB using industry standard interfaces such as BPEL for coordinating business processes.
The immediate short-term advantage of the ESB approach is that it achieves the same overall effect
as the EAI(hub-spoke) approach, but at a much lower total-cost-of-ownership. These savings are realized not
only through reduced hardware and software expenses, but also via labor savings that are realized by
using a framework that is distributed and flexible.
我们需要避免它成为集群设置的单点故障 - 它可以是 HA 集群或 FO 集群。
We need to avoid it becoming a single point of failure with a clustered set up - it can be a HA cluster or a FO cluster.