多进程RPC体系结构设计

Question

我目前正在从事一个项目，该项目的客户端应用程序与服务器进程进行通信。客户端应用程序可以与服务器进程、在同一网络上或通过internet在同一台机器上本地使用。我使用Boost ASIO为服务器进程编写了一个单线程异步RPC模块，而Google用于RPC消息序列化。该体系结构是一个非常简单的客户机-服务器模型，客户端将一个请求打包到protobuf消息中，并将其发送到服务器，服务器将返回一个响应。服务器进程是用C++编写的，客户端应用程序以不同的语言编写。这方面的主要用例是提供一个GUI，允许用户监视服务器进程并与其交互。

在未来，服务器进程将被分离为功能分离的进程，而不是一个单块进程。这是一个问题，我现在有多个客户端应用程序要连接的进程。我不认为这在本地或局域网客户端应用程序中会是一个问题，但是，在互联网上，如果进程数量增加，这可能会变得难以处理。此外，我可能希望通过相互发送RPC消息在服务器进程之间启用IPC。

我不确定什么分布式应用程序体系结构最适合这个系统的未来。如果没有必要的话，我不想重新发明方向盘，所以我粗略地看了一下D总线和ZeroMQ，但是考虑到我的架构还没有确定下来，我想我可以问问各位程序员。

有一个服务器进程处理客户端应用程序和服务器进程之间的通信是明智的吗?还是我应该考虑更好的架构风格？如果我想在服务器进程之间启用IPC，应该让它们彼此直接发送消息，还是应该使用前面提到的单个服务器进程？我应该看看像发布/订阅模型这样的东西吗？

Answer 1

我认为你应该有一个主要的过程作为网关。为了减少负载，您可以使用其他进程来完成部分工作。要扩展主进程，您可以让它监听IP和端口，但将IP作为URL进行广告。然后，您可以使用DNS提供程序，在查找时提供超过一个IP (它们更改顺序，使两个IP都获得通信量)。

这就是小的和大的网站所做的。它们提供网页，您可以让应用程序监听自己的端口(如果通过HTTP或在防火墙中打开的任何其他程序，则可能是80 )。

子进程可以有同步或异步方法。在Java中，我们有容器和ejb来实现这一点，因此必须在c++中对这样的系统进行更多的研究。