Golang Walk

In accordance with this article , the application interface module and the playground interact through RPC calls. To support scaling, each instance and playground can be created for the application interface.

Playground Infrastructure Overview

I ask myself what / are the patterns (solutions) for balancing the load between the external request and the internal instance while maintaining the RPC.

One solution could be to use one global work queue, where tasks are placed inside it with the "Reply-To" heading. This header should point to one queue of the instance of the interface on which the responses are placed. Something like the following schema (from the RabbitMQ Tutorial ) with rpc_queue shared between internal instances: RabbitMQ RPC format

I'm not sure if this would be a good way to make it especially the fact that if the general queue is disabled, the whole system fails (but how to take care of this?).

Thanks.

+6
source share
1 answer

In response to the following comments that I received in the first post, I developed Indenter, a small proof of concept based on the idea proposed by the service discovery daemon (however, I just use etcd instead of ZooKeepr).

I wrote an article about this and released a code if someone might be interested one day:

Indenter: A scalable, fault tolerant distributed web service that replicates go playground architecture.

+1
source

All Articles