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 (\u201cupstreams\u201d), without any knowledge about their exact IP address, or their quantity, or \u201chealth\u201d 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).<\/p>\n
I do not pretend to be original, but will tell you how we did it:<\/p>\n
Put a \u201ctypical\u201d web server at the entrance point, written on any programming language, even PHP script (will be call it as \u201cinput script\u201d). 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 \u201cingoing\u201d queue, accompanying it with the same UID, and begins to listen to his temporary queue.<\/p>\n
The message is pulled from \u201cingoing\u201d 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.<\/p>\n
Our input script instance (remember – it \u201chalts\u201d 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.<\/p>\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 (\u201cupstreams\u201d), without any knowledge about their exact IP address, or their quantity, or \u201chealth\u201d state. In addition, each request must be processed by the least loaded server in the moment, and … Continue reading “Queues: web cluster without upstreams orchesration”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[4,7,16],"class_list":["post-16","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-amqp","tag-cluster","tag-queues"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t