RPC系统与企业服务总线的区别
RPC 系统（如 Twitter 的 Finagle）和企业服务总线（如 Mule）之间有什么区别？他们各自擅长解决什么样的问题？
What's the difference between an RPC System, like Twitter's Finagle, and an Enterprise Service Bus, like Mule? What kind of problems are each of them good at solving?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我将尝试以一种软解释的方式来回答这个问题，而不是功能的技术细分：
有人可能会说 Finagle 是一个异步消息传递库，它允许服务自由地相互连接（与体系结构系统集成标准没有紧密联系），同时支持多种协议。
来自 Finagle 网站：
另一方面，企业服务总线 (ESB) 是一种异步消息传递架构，通常遵循行业标准和协议。 ESB 提倡一种系统，其中消息流在系统之间进行控制和路由，服务器可以注册其服务，客户端可以注册他们感兴趣的消息。服务器提供的服务可以注册并进行版本控制。
您通常会发现 Finagle 在网站和后端服务之间使用。但是，您通常会在大型公司内部找到 ESB，它负责集成财务、支持、销售等系统。
这两种解决方案都提供异步消息传递和各种扩展的缓冲，但并不是为了解决相同的问题而设计的。对于 ESB，您可能会认为“严格、企业”，但对于 Finagle，您可能会认为“灵活、网络”。
希望这会有所帮助
更新：
不太相关，但如果您正在探索这个空间，我会看看这些天卡夫卡。
I will try to answer this as a soft explanation, rather than a technical breakdown of features:
One may say that Finagle is a asynchronous messaging library that allows services to connect to one another freely (not tightly tied to architectural system integration standards) while supporting multiple protocols.
From the Finagle website:
An enterprise service bus (ESB), on the other hand, is a asynchronous messaging architecture which typically adheres to industry standards and protocols. An ESB promotes a system where message flow is controlled and routed between systems, and where servers can register their service and clients can register what messages they are interested in. The services offered by servers can be registered and versioned.
You will typically find Finagle being used somewhere between a website and backend services. But, you will typically find an ESB inside a large corporate, where it's responsible to integrating systems like finance, support, sales, etc.
Both solutions offer asynchronous messaging and buffering to various extends, but are not designed to solve the same problem. For ESB, you would probably think 'strict, enterprise', but for Finagle you would probably think 'flexible, web'.
Hope this helps
Update:
Not quite related, but if you are exploring this space, I would look at Kafka these days.
RPC 和 ESB 是两种架构模式。虽然 RPC 通常是请求-答复且本质上是同步的，但 ESB 的工作原理是消息传递（简化解释）和异步的概念。 ESB 是任何 SOA 实施的基础。 ESB 支持松散耦合，从而促进真正的敏捷性。从实现的角度来看，一个简化的例子如下：
Web服务是一个典型的RPC。消费者与生产者紧密联系在一起，生产者一方合同的任何更改都将要求消费者一方进行更改。
在 ESB 中，服务使用者不会直接调用服务生产者。它只是将消息放入总线中，并根据规则（中介者），适当的服务生产者将处理它。如果服务使用者和服务生产者以不同的格式进行对话，ESB 会提供进行转换的工具（例如将邮政编码格式化为 xxxxx-xxxx、将名称拆分为名字和姓氏等）。
这只是简化的解释。有关更多信息，请检查以下链接：
为什么开发人员需要企业服务总线?
企业服务总线
RPC and ESB are two architectural patterns. While RPC is usually a request-reply and synchronous in nature, an ESB works on the concept of messaging (simplified explanation) and of asynchronous in nature. ESB is the foundation for any SOA implementation. ESB enables loose coupling thus promoting true agility. A simplified example from implementation perspective is as follows:
A web service is a typical RPC. The consumer is tightly bound to the producer and any change in the contract on the producer side, will require changes on the consumer side.
In ESB, the service consumer doesn't invoke the service producer directly. It just puts the message in the bus and based on the rules (mediator), appropriate service producer will handle it. If the service consumer and service producer talk in different formats, ESB provides the facility to do the transformation (like formatting the zipcode as xxxxx-xxxx, splitting the name into first name and last name, etc.).
This is just simplified explanation. For more information, please check the following links:
Why do developers need an Enterprise Service Bus?
Enterprise Service Bus
两者解决完全不同的问题：
Both solve completely different problems: