The story began where I was once asked how to build such HTTP-gate (api endpoint), which proxies requests to a group of lower-level servers (“upstreams”), without any knowledge about their exact IP address, or their quantity, or “health” state. In addition, each request must be processed by the least loaded server in the moment, and the response should be sent synchronously – as plain HTTP response (not as secondary callback).
I do not pretend to be original, but will tell you how we did it:
Put a “typical” web server at the entrance point, written on any programming language, even PHP script (will be call it as “input script”). It accepts HTTP-request and assigns them an unique UID. Then, it creates a temporary queue in the AMQP-server, signing it with the key to the exchange (by routing key based on the UID). Then he puts the contents of the request in a general “ingoing” queue, accompanying it with the same UID, and begins to listen to his temporary queue.
The message is pulled from “ingoing” queue by first free backend server (worker). The request is processed, passed through the jungle of business logic, and in the end the result will be published out (as a new AMQP message) with the routing key based on original UID.
Our input script instance (remember – it “halts” on his personal temporary queue) catches this message with the result and publish it as a typical HTTP response – as response to the original request. Then, the script simply finishes his execution, and temporary queue will be destroyed automatically.
That’s all. No need to go to the back-end server, no need to orchestrate their addresses (at this point), no need to asking their status, no need to be aware of their fall / restoration and etc. The lack of this scheme, of course, is the overhead to work with queues.
