As someone who has used RabbitMQ in production for many years, you should rather consider using NATS [1] for RPC.<p>RabbitMQ's high availability support is, frankly, terrible [2]. It's a single point of failure no matter how you turn it, because it cannot merge conflicting queues that result from a split-brain situation. Partitions can happen not just on network outage, but also in high-load situations.<p>NATS is also a <i>lot</i> faster [3], and its client network protocol is so simple that you can implement a client in a couple hundred lines in any language. Compare to AMQP, which is complex, often implemented wrong, and requires a lot of setup (at the very least: declare exchanges, declare queues, then bind them) on the client side. NATS does topic-based pub/sub out of the box, no schema required.<p>(Re performance, relying on ACK/NACK with RPC is a bad idea. The better solution is to move retrying into the client side and rely on timeouts, and of course error replies.)<p>RabbitMQ is one of the better message queue implementations for scenarios where you need the bigger features it provides: durability (on-disk persistence), transactions, cross-data center replication (shovel/federation plugins), hierarchical topologies and so on.<p>[1] <a href="http://nats.io" rel="nofollow">http://nats.io</a><p>[2] <a href="https://aphyr.com/posts/315-jepsen-rabbitmq" rel="nofollow">https://aphyr.com/posts/315-jepsen-rabbitmq</a><p>[3] <a href="http://bravenewgeek.com/dissecting-message-queues/" rel="nofollow">http://bravenewgeek.com/dissecting-message-queues/</a>
IMO this is an emerging anti pattern to use Rabbit to connect "microservices". It often introduces a single point of failure to your "distributed" system and has problems with network partitions. If critical functionality stops working when Rabbit is down, you're probably doing it wrong.
Looks pretty cool, but doing RPC over RMQ is quite expensive. I would rather see good abstractions over ZMQ - that would be really cool.<p>Also as many people here pointed out, RMQ is a single point of failure which might be acceptable for some cases. To me, the problem is that by design this architecture has a bottleneck which is really hard to get rid off.
OpenStack has had this as a common design pattern across a lot of the services for a while.<p>It works quite well for us now - there was a period 2-3 years ago where rabbitmq was the bane of my existence, and the cause of many a page but newer versions have been fine.<p>We do assume that everything in the queue can go away, and only in flight calls will fail - and (at least in the service I work on) we do retries if something falls through the cracks.<p>There is a shared library we use for it - <a href="http://docs.openstack.org/developer/oslo.messaging/" rel="nofollow">http://docs.openstack.org/developer/oslo.messaging/</a><p>It also has drivers for ZMQ, and QPID afaik.
How does this compare to Autobahn / crossbar.io?<p><a href="http://autobahn.ws/" rel="nofollow">http://autobahn.ws/</a><p><a href="http://crossbar.io/" rel="nofollow">http://crossbar.io/</a><p>I really like the service discovery in Crossbar ("routed RPC").
This looks cool. I wrote a less developed than this and unreleased RabbitMQ-based microframework that combines RPC and one-way event streams to integrate an ecommerce site in one datacenter with a back office in another. At another company I used ZeroMQ to make a job processing cluster.<p>Comments by others suggesting the use of http are kind of missing the point of message queues. The latency added by http(s) made interactive RPC sluggish, and made batch back office updates take hours instead of minutes with AMQP.<p>If I had Alchemy two years ago I might have used this instead of rolling my own.
this is helpful. we already use rabbitmq for our golang services. This would ease the task of setting up publishers and subscribers in the node APIs we're building.
I've been working on something similar but decided to go with Kafka as the message bus because I want the messages to persist. This allows for more error recovery solutions and auditing. Still having all that data around also allows me to come up with new ideas to use that days after the fact.
I feel like this is a bit silly. Feel like one could just speak HTTP or Thrift, and use etcd or zookeeper for discovery. RabbitMQ just complicates the stack. Also, it's HA options are generally... disappointing.
as someone who's used RabbitMQ in a SaaS app to run millions of tasks, heed my warning, RabbitMQ is great if you are low on memory but the overhead was too much to deal with. Celery also contributed to this but if I could travel back in time, I would stop myself from using RabbitMQ. Instead, Redis is a much better alternative for micro-service.