thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Abernethy <randy.aberne...@gmail.com>
Subject Re: Using thrift with a message broker. Why?
Date Thu, 23 Jan 2014 19:30:52 GMT
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 <static.void.dev@gmail.com>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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message