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?