什么是 ESB？它有什么用处？
在之前的工作中，有很多关于“企业服务总线”（ESB）的讨论。 我读了一本关于它的概念书的部分内容，但从未真正理解如何具体实施/集成它。 我熟悉 SOA/队列/目录服务/等。 但我不明白 ESB 到底是什么。
它是一个具体的东西（服务/服务器/代理/等），您只需以不同的方式将所有应用程序连接到它，或者它只是一种设计系统的概念方式？
任何解释或好例子的链接将不胜感激。 谢谢。
At a previous job, there was lots of talk about "Enterprise Service Bus" (ESB). I read parts of a conceptual book about it, but never really understood how you would implement/integrate it in concrete terms. I'm familiar with SOA/queueing/directory services/etc. but I don't understand what exactly an ESB is.
Is it a concrete thing (service/server/broker/etc.) that you just hook all your apps up to it in different ways, or is it more just a conceptual way to design systems?
Any explanations or links to good examples would be greatly appreciated. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这是一个相当高层次的抽象概念。 核心概念是 ESB 提供中间件和接口，允许企业无需编写代码即可连接其应用程序。
这可能包括协调不兼容的协议、数据和交互的中介。
一切都通过中央总线的想法为额外的抽象层提供了机会。 使用行业标准将其他应用程序、客户端等“插入”该总线，使得连接新服务、数据源、具有不同需求的客户端变得相对容易。
实际实施
就实际实施而言，这是超大型企业支持业务的领域。 虽然它很流行，但目标是一个理想的目标，在某种程度上可以通过与互联网的比较来理解：
与互联网的相似性
一个具有广泛不同用途和数据的大型通信总线，但都运行标准化协议。
事实上，我们可以编写一个 HTTP 到 FTP 连接器，允许浏览器访问 FTP 站点，而无需调用 FTP 客户端（现在通常内置于浏览器中）。
混搭
混搭演示了一个有趣的实现 - 从旧金山当局获取一些公交车路线数据，从谷歌获取一些地图，从雅虎获取寿司吧位置的评级，然后运行一个简单的查询，为您提供最近的寿司店，对其进行加权，以便您可以愿意走远一点去更好的酒吧。
所有完全不同的服务，它们本身不兼容，但使用标准连接器（例如雅虎管道）可以将它们拉在一起形成一个有凝聚力且有用的整体。
-亚当
It's a fairly high level concept of abstraction. The central concept is that the ESB provides the middleware and interfaces that allow businesses to connect their applications without writing code.
This could include mediation to reconcile incompatible protocols, data, and interaction.
The idea of a central bus on which everything passes gives opportunity for additional layers of abstraction. Using industry standards to "plug" other applications, clients, and such into this bus makes it so that connecting new services, data sources, clients with disparate needs is relatively easy.
Actual implementations
As far as actual implementations, that's the domain of very large enterprise support businesses. While it's very buzzwordy, the goal is an ideal that on some small level can be understood through comparison with the internet:
Similarity to Internet
One big communications bus with widely different uses and data, but all running standardize protocols.
One can, in fact, write an HTTP to FTP connector that would allow browsers to access FTP sites without invoking an FTP client (usually built into the browser now).
Mashups
Mashups demonstrate an interesting implementation - take some bus route data from the San Francisco authority, map from google, and sushi bar locations from yahoo with ratings and run a simple query that gives you the closest sushi bar, weighting it so that you'd be willing to travel a little further for a better bar.
All completely different services, incompatible by themselves, but using standard connectors (yahoo pipes, for instance) they can be pulled together into a cohesive and useful whole.
-Adam
免责声明：我在 IBM 工作并提供 WebSphere ESB 咨询，这是一款旨在构建 ESB 的 IBM 产品。 以下是我的观点，并不一定反映 IBM 的立场。
不幸的是，ESB 对于不同的人来说是不同的。
对我来说，ESB 是一种可以插入到 SOA（面向服务的架构）中的任何技术，允许您将不同的系统连接在一起。 它通常执行协议转换、消息修改、路由、日志记录、充当安全网关等功能。 例如，您可以使用 ESB 将以前仅作为 Web 服务提供的服务也公开为基于 JMS 的服务。
在这方面，ESB 实现（或者更准确地说，出售用于构建 ESB 的软件 - 例如我咨询的软件）通常在技术上类似于过去所谓的消息传递或队列代理，尽管目的有些不同，因为（正如缩写词所暗示的那样）它面向服务，而不是将消息从一个地方移动到另一个地方。 这种区别在技术上有多重要是一个见仁见智的问题。
Disclaimer: I work for IBM and consult on WebSphere ESB, an IBM product designed to build ESBs with. The following are my opinions and don't necessarily reflect IBM's position.
An ESB is different things to different people, unfortunately.
To me, an ESB is a any technology that you can insert into an SOA (Service-Oriented Architecture), allowing you to connect disparate systems together. It often performs the functions of protocol transformation, message modification, routing, logging, acting as a security gateway, and so on. For example, you might use an ESB to expose a service previously only available as a Web Service as a JMS-based service as well.
In this respect, ESB implementations (or to be more precise, software sold to build ESBs with - such as that I consult on) are often technologically similar to what used to be known as a messaging or queueing broker, although the purpose is somewhat different, because (as the acronyms imply) it's oriented around services rather than moving messages from one place to another. How important the distinction is technologically is a matter of opinion.
我对商业 ESB 的体验是，它是一种过度夸大且昂贵的技术，它所解决的问题和所产生的问题一样多。 ESB 将连接新系统和旧系统，消息将在总线上传输，所有东西都能够无缝地与其他东西通信。 加上一些弹性、编排，您就拥有了一个非常强大的企业应用程序软件。
当您尝试实际使用它们时，问题就出现了，编写总线、创建消息结构等的开销可能会超过好处。 作为一种高成本项目，ESB 被视为解决所有技术问题的灵丹妙药，但事实并非如此，
太多时间花费在总线上，而不是花费在连接的应用程序/数据上。 通常情况下，多个相互竞争的标准会在同一组织中争夺霸主地位，从而导致这些系统实际上应该修复的经典技术主导的孤岛。
恕我直言，最好使用创建少量特定接口，通常仅在需要它的系统之间使用 Web 服务。
My experience with commercial ESB is it's an overblown and expensive technology that creates as many problems as it solves. The ESB will link new systems and legacy, messages will fly over the bus and everything will be able to talk to everything else seamlessly. Throw in some resilience, orchestration and you have a very powerful piece of enterprise application software.
The problem comes when you try to use them for real, the overhead of writing for the bus, creating the message structures and so on, can outweight the benefits. As a high cost item, the ESB is seen as the panacea for all tech issues which it isn't,
too much time is spent on the bus and not on the applications/data being connected. It's often the case that multiple competing standards will fight for supremacy in the same organisation leading to the classic tech dominated silos that these systems should actually be fixing.
IMHO it is far better to use create a small number of specific interfaces, typically using web services between only those system that need it.
它基本上是一种设计系统的概念方法 - 软件公司试图通过在其上贴上“ESB”标签来向您推销更多产品，而经理们会喜欢，因为从“更高级别”看，ESB 看起来不错。
ESB 基本上是一个 MOM（面向消息的中间件），添加了数据模型和结构定义管理。 该总线上的所有应用程序和适配器都有一个通用的数据定义（可以是具有共享 XSD 的 XML）。 任何连接的东西都必须发送符合此数据定义的信息。 ESB 支持此通用数据定义的加载、共享和版本控制。
将新组件连接到 ESB 时，您可以期望比将其连接到 MOM 时具有更多开箱即用的“兼容性”。 该总线上的每个组件在概念上都被视为“资源” - 因此引入了一个额外的抽象来将发送者与接收者分离。
示例：假设您想在标准的面向消息的中间件中连接应用程序 A 和应用程序 B，我们以 JMS 为例。 您与处理应用程序 B 的同事交谈，就主题、消息类型和字段达成一致并发送（伪代码）：sendJms("TRADE.MSFT", {MapMessage trader="pete" Price=101.4 vol=100})
如果您在面向服务的架构中做同样的事情，您需要
vol=100}) - 注意目标是从 ESB 注入的
第一次可能有点痛苦，但我想你可以习惯它，就像你可以习惯 EJB 一样;-)
你可以说是 MOM 系统是“无类型”（动态结构），而 ESB 是“类型”（静态结构）。 原始消息传递与 ESB 的权衡与其他非类型化/类型化选择类似：
对于较小的项目，最好进行讨论功能快速（例如 Groovy 代码），但对于较大的项目，最好有一个调试器（例如 Java），在出现问题时提前收到警告，并在人们提交项目之前制定一个标准。
因此，如果您的项目因太多人通过检查未经验证的更改而破坏系统，请转向更多的结构（ESB 而不是 MOM）。
如果您的项目无法及时完成足够的事情 - 选择更简单、无类型的解决方案。
如果两者兼而有之 - 找一位顾问（开个玩笑；-）
It's basically a conceptual way to design a system - software companies try to sell you more by sticking on the 'ESB' sticker on it and managers like because an ESB looks good from a 'higher-level'.
An ESB is basically a MOM (message oriented middleware) with an added data model and structure definition management. You have a common data definition for all applications and adapters on that bus (could be XML with a shared XSD). Anything that connects MUST send it's information adhering to this data definition. The ESB supports loading, sharing and versioning of this common data definition.
When connecting a new component to an ESB, you can expect more 'compatibility' out of the box than when connecting it to a MOM. Each component on that bus is conceptually treated as a 'resource' - so there's an additional abstraction introduced to decouple sender from receiver.
Example: let's say you want to connect application A with application B in a standard message oriented middleware, let's take JMS. You talk to your colleagues working on application B, agree on a topic, message type and fields and send it (pseudo code): sendJms("TRADE.MSFT", {MapMessage trader="pete" price=101.4 vol=100})
If you do the same thing in a service oriented architecture, you need to
vol=100}) - note the destination is injected from the ESB
The first time it's probably a bit painful, but I guess you can get used to it, just like you can get used to EJB's ;-)
You could say a MOM system is 'untyped' (dynamic structure) while an ESB is 'typed' (static structure). The trade-offs of raw Messaging vs. ESB are similar to other untyped/typed choices:
For smaller projects it's nice to hash out functionality quickly (e.g. Groovy code) but for larger projects it's good to have a debugger (e.g. Java), to be warned in advance when things break and to have a standard for people before they commit to the project.
So if your project suffers from too many people breaking the system by checking in unvalidated changes - move towards more structure (ESB instead of MOM).
If your projects suffers from not getting enough things done in time - choose the simpler, untyped solution.
If it's both - get a consultant (just kidding ;-)
好吧，这取决于你问的是谁......许多人会说它是一个“中间件”，它将各个“业务逻辑”连接在一起，以从这些模块之间的消息传递中进行编码。 我认为这是一个足够笼统的定义，但我相信您已经通过维基百科等了解了这个定义。
那些希望伟大的 ESB 能够拯救世界的人将其视为最常见的呈现方式，即做所有事情的中心。 大多数 ESB 实现都致力于封装我们在业务软件中看到的所有重复任务。 这意味着大多数 ESB 负责数据传输、安全性、日志记录、协议转换、事件系统、通过 Web 服务公开 API 等。
我想我已经说得很清楚了……希望有所帮助。
Well, that depends on who you ask... Many would say it's a piece of "Middleware" that connects various pieces of "business logic" together to take the coding out of messaging between these modules. I think that's a general enough definition, but I'm sure you've already gotten there via Wikipedia and whatnot.
Those who would have the great ESB save the world see it as it's most commonly presented, a hub for doing everything. Most ESB implementations effort to encapsulate all repetitive tasks we see in business software. That means most ESBs take care of data transfer, security, logging, protocol translation, event systems, api exposure via web services, etc.
I think that's as clear as I can be... Hope that helps.
除了标准定义之外，您还可以从 Wikipedia 获得。 我发现它是跨多个平台和技术连接一堆遗留系统的绝佳工具。 它也是构建分布式工作流程和状态管理系统（例如总账）的好工具。
然而，它相当昂贵、复杂且维护和扩展不方便，这使得它作为扩展应用程序的通用工具来说是一个糟糕的技术选择。
Beyond a the standard definition you can get from Wikipedia. I find it to be a great tool for connecting a bunch of legacy systems across multiple platforms and technologies. It's also a good tools for building distributed workflows and state management systems( such as general ledger).
However, it's rather expensive, complex and inconvenient to maintain and extend which makes it a poor technology choice as a general purpose tool for scaling you applications.