Looking for a little guidance/advice on ZMQ implementation. The following demonstrates the simplistic architecture that I'm considering. It doesn't take into consideration redundancy, load balancing at all levels (yet). The general flow of request/response traffic would be:
-> HTTP request from internet -> nginx (1 node) -> aiohttp + zmq-based frontend (1 or more nodes depending on system demands) -> zmq-based router (1 node) -> zmq-based worker (n nodes; scalable depending on dynamic demand) I want my system to work in environments where multicast/broadcast is not available (ie. AWS EC2 VPC) - so I believe a well-known node for service discovery is needed. With that in mind, all zmq-based nodes would: - register with the 'central' service discovery (SD) node on startup to make other nodes aware of its presence - separately SUBscribe to the service discovery node's PUB endpoint to receive topics of pertinent peer nodes' connection details In the nginx config, I plan to have an 'upstream' defined in a separate file that is updated by a zmq-based process that also SUBscribes to the service discovery node. ZMQ-based processes, and their relation to other ZMQ-based processes: - service discovery (SD) - zmq-based nginx upstream backend updater; registers with SD, SUBs to frontend node topic (to automatically add frontend node connection details to nginx config and reload nginx) - frontend does some request validation and caching; registers with SD, SUBS to router node topic (to auto connect to the router's endpoint) - router is the standard zmq DEALER/ROUTER pattern; registers with SD - worker is the bit that handles the heavy lifting; registers with SD, SUBS to router node topic (to auto connect to the router's endpoint) The whole point of this is that each node only ever needs to know the well-known service discovery node endpoint - and each node can auto-discover and hopefully recover in most downtime scenarios (excluding mainly if the SD node goes down, but that's outside of scope at the moment). Questions! 1. Does this architecture make sense? In particular, the single well-known service discovery node and every other node doin PUB/SUB with it for relevant endpoint topics? 2. Who should heartbeat to who? PING/PONG? ie. when a given node registers with the SD node, should the registering node start heartbeating on the same connection to the SD node, or should the SD node open a separate new socket to the registering node? The SD node is the one that will need to know if registered nodes drop off the earth, I think? I'll likely have followup questions - hope that's ok! Thanks, James
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
