套接字服务器和游戏服务器是否应该是独立的进程？

假设一个简单的标准客户端/服务器游戏。对于服务器，是否值得拥有一个单独的进程来侦听客户端的连接和消息，并通过本地套接字或stdin将数据发送到运行实际游戏服务器的另一个进程？

另一种选择是使这两项都在一个过程中完成。对传入的消息进行排队并以正确的顺序执行它们，这不会造成停顿问题。

我想知道将两个“活动”分开的额外资源是否真的值得。我应该如何决定？我想听听任何利弊。

从API设计的角度来看，在决定制作多个单独的通信程序还是仅制作一个通信程序时，问题是：每个程序都可以有意义地发挥功能，而无需其他程序吗？答案将根据您的项目和偏好而有所不同。

如果他们做不到，那是不值得考虑的。显然，它们是如此紧密地联系在一起，以至于它们并不是真正独立的过程。

如果可以，并且您会看到自己希望将来使用不同的组件来替换它们，则OS提供的流程抽象可能会有所帮助。

究竟有多少帮助取决于您其余的技术堆栈。例如，Erlang已经在内部将事物建模为进程，因此将其拆分为OS进程也不会从概念上获得很多好处。除非您考虑使用其他语言重写服务器的那些部分。C ++程序的内部组件通常紧密耦合在一起，因此很难交换出来，因此，如果可以预见到这样的重新安排，将它们拆分为不同的OS进程可以节省以后的工作。

是否值得有一个单独的进程来侦听客户端的连接和消息，并通过本地套接字或stdin将数据发送到运行实际游戏服务器的另一个进程？

要回答是否值得，您必须先问自己，通过添加专用排队服务要解决的问题是什么。如果它解决了这个问题，那是值得的。如果它不能解决问题，或者您一开始就没有问题要解决，那么可能就不会。

让我们看看一些服务器为何使用多层体系结构的原因：

1. 负载平衡-如果要将工作负载分散到多台工作机上，负载平衡才有意义。如果您的程序具有要通过在同一台计算机上同时存在多个并发工作进程来解决的瓶颈，那么从长远来看，最好是实际解决该瓶颈，但是从短期的解决方法来看，产生工作进程是可行的。
2. 特权分离-也许您不希望聊天服务器的安全漏洞自动获得对游戏服务器的访问权限，反之亦然。如果您的游戏服务器与游戏中的聊天服务器是分开的，则可以将游戏服务器和聊天服务器配置为驻留在单独的安全域中（例如，以不同的用户身份运行，具有不同的访问权限，不同的进程限制等）。
3. 零宕机时间升级-如果要实现零宕机时间升级，则需要具有多个层并配置系统，以便在关闭一台服务器进行服务时，其请求将被重定向到同一层中的其他服务器，以确保连续服务。
4. 超出限制-如果达到套接字限制，文件描述符限制，全局解释器锁定等，则可以通过运行多个进程来解决该限制。解决此问题的另一种方法是更改​​限制，但这并不总是那么容易，因为您可能必须重新编译内核，否则可能会涉及安全性或性能。
5. 限制资源泄漏-您希望编写不会泄漏资源的软件，但是即使使用完全垃圾管理的语言，这在长期运行的过程中也极其困难，更糟的是，在开发环境中很难复制。多层体系结构允许您在一定时间或数量的请求后杀死并重生游戏服务器，以限制资源泄漏造成的损失，而不会中断服务。

我同意棘轮怪胎。只要有一个游戏服务器，就不值得为此烦恼。

但是，当您需要水平扩展时，此体系结构可能会很有用。当一个游戏服务器不再足够，并且出于性能原因而需要在多个游戏服务器上分发游戏时，可以很容易地将“套接字服务器”体系结构调整为将套接字服务器转变为负载平衡器，该负载平衡器会自动将连接路由到多个后端之一服务器。

但是，当您不确定是否需要此功能时，此时可能会过度开发两个单独的服务器应用程序。

可能不是，大多数语言都具有异步套接字，这些套接字允许您一次使用多个连接，而不会在数据等待时阻塞。这会将“套接字服务器”部分转移到OS /内核。

使用显式套接字服务器，当您通过本地套接字传递数据时，您将招致一些额外副本的费用。会破坏可伸缩性的一件事是不需要它们的多余副本。