I am currently working on a project that has client applications communicating with a server process. The client applications could be local to the same machine as the server process, on the same network, or over the internet. I had written a single-threaded asynchronous RPC module for the server process using Boost ASIO while Google Protobuf was used for RPC message serialization. The architecture was a pretty simple client-server model where a client would pack a request into protobuf message and send it to the server which would send back a response. The server process is written in C++ and the client applications were in varying languages. The main use case for this was to present a GUI to allow users to monitor, and interact with, the server process.
In the future, the server process is going to be separated into functionally separate processes instead of one monolithic process. This presents an issue wherein I now have multiple processes for the client applications to connect to. I don't think this would be a problem in the case of the local or lan client applications but, over the internet, this could become unwieldy if the number of processes grow. Furthermore, I may want to enable IPC between server processes by sending each other RPC messages.
I'm not sure what distributed application architecture would best fit this system going forwards. I don't want to reinvent the wheel if it's not necessary so I've taken cursory glances at D-bus and ZeroMQ, but seeing as I don't really have my architecture settled I thought I'd ask you fellow programmers.
Would it be wise to have a single server process handling communication between client applications and server processes or is there a better architecture style I should be considering? If I want to enable IPC between server processes should I have them directly send messages to each other or should I use the single server process mentioned previously? Should I be looking at something like a publish/subscribe model?
Best Answer
I think you should have one main process as the gateway. To put less load on it, you can have other processes that do part of work. To scale the main process you can have it listen to an IP and port but advertise the IP as a URL. Then you can use DNS providers which give more than 1 IP on look up (they change the order so both IPs get traffic)
That is what small and big websites do. They serve web pages and you would have your app listening on its own ports (could be 80 if over HTTP or any other that you have opened in your firewall)
The sub processes can have sync or async methods. In Java we have containers and ejbs that do this, will have to do more research for such systems in c++