Hello Blarg, Not sure if you are referring to folks using the serialization framework standalone with messaging or if you are referring to folks using the RPC system with a messaging transport.
One of the great features of Thrift is its IDL driven serialization layer. A number of folks use Thrift as a cross language serialization framework for messaging. One of the great things about adopting Thrift serialization is that you can then use it for both RPC and messaging. Given that the serialization framework supports plug in protocols, you can swap JSON for Compact for Binary for Custom easily. You can use JSON for reach and Bin or Compact for serialization speed. Being able to describe your interfaces (in this case types which will be communicated via messaging) once in a crisp IDL for all languages is a benefit in and of itself. Some folks use messaging (ZeroMQ in particular) as a transport for Thrift RPC (maybe what you are seeing). This gives you the benefits of RPC (simple programming model, etc.) but with many of the benefits of loosely coupled systems, particularly when you use Thrift async clients. As you mentioned, this unbinds the client from the server (using the MOM as a stand in). You can route the RPC traffic to any end point (fail-over), load balance, log copies of the traffic for replay, etc. Hope this helps, Randy On Thu, Jan 23, 2014 at 10:28 AM, Software Dev <[email protected]>wrote: > I've come across some examples of AMQP broker sitting between a client and > service (Thrift). Can someone explain the benefits of this approach as > opposed to just having the client speak directly to the service via the one > of the native thrift transports? > > There are two reasons I can think of: > > 1) Loadbalancing. If we have multiple services as a consumer for a topic, > we essentialy get loadbalancing for free. > > 2) No need to configure the service endpoints up front. We only need to > write to the broker and not care about which machine, ip, etc can handle > the request. > > Neither of which do I find as a compelling reason to add a broker. In use > case 1 we can simply load balance via hardware or HAProxy. Use case two, if > needed, be fixed with some distributed configuration management software > (Zookeeper) where automatic detection is possible. > > Can someone please chime in with any input. Thanks >
