把网络游戏服务器分拆成多个进程，分开部署。这种设计的好处是模块自然分离，可以单独设计。分担负荷，可以提高整个系统的承载能力。
缺点在于，网络环境并不那么可靠。跨进程通讯有一定的不可预知性。服务器间通讯往往难以架设调试环境，并很容易把事情搅成一团糨糊。而且正确高效的管理多连接，对程序员来说也是一项挑战。
前些年，我也曾写过好几篇与之相关的设计。这几天在思考一个问题：如果我们要做一个底层通用模块，让后续开发更为方便。到底要解决怎样的需求。这个需求应该是单一且基础的，每个应用都需要的。
正如 TCP 协议解决了互联网上稳定可靠的点对点数据流通讯一样。游戏世界实际需要的是一个稳定可靠的在游戏系统内的点对点通讯需要。
我们可以在一条 TCP 连接之上做到这一点。一旦实现，可以给游戏服务的开发带来极大的方便。
可以把游戏系统内的各项服务，包括并不限于登陆，拍卖，战斗场景，数据服务，等等独立服务看成网络上的若干终端。每个玩家也可以是一个独立终端。它们一起构成一个网络。在这个网络之上，终端之间可以进行可靠的连接和通讯。
实现可以是这样的：每个虚拟终端都在游戏虚拟网络(Game Network)上有一个唯一地址 (Game Network Address , GNA) 。这个地址可以预先设定，也可以动态分配。每个终端都可以通过游戏网络的若干接入点 ( GNAP ) 通过唯一一条 TCP 连接接入网络。接入过程需要通过鉴权。
鉴权过程依赖内部的安全机制，可以包括密码证书，或是特别的接入点区分。（例如，玩家接入网络就需要特定的接入点，这个接入点接入的终端都一定是玩家）
鉴权通过后，网络为终端分配一个固定的游戏域名。例如，玩家进入会分配到 player.12345 这样的域名，数据库接入可能分配到 database 。
游戏网络默认提供一个域名查询服务（这个服务可以通过鉴权的过程注册到网络中），让每个终端都能通过域名查询到对应的地址。
然后，游戏网络里所有合法接入的终端都可以通过其地址相互发起连接并通讯了。整个协议建立在 TCP 协议之上，工作于唯一的这个 TCP 连接上。和直接使用 TCP 连接不同。游戏网络中每个终端之间相互发起连接都是可靠的。不仅玩家可以向某个服务发起连接，反过来也是可以的。玩家之间的直接连接也是可行的（是否允许这样，取决于具体设计）。
由于每个虚拟连接都是建立在单一的 TCP 连接之上。所以减少了互连网上发起 TCP 连接的各种不可靠性。鉴权过程也是一次性唯一的。并且我们提供域名反查服务，我们的游戏服务可以清楚且安全的知道连接过来的是谁。
系统可以设计为，游戏网络上每个终端离网，域名服务将广播这条消息，通知所有人。这种广播服务在互联网上难以做到，但无论是广播还是组播，在这个虚拟游戏网络中都是可行的。
在这种设计上。在逻辑层面，我们可以让玩家直接把聊天信息从玩家客互端发送到聊天服务器，而不需要建立多余的 TCP 连接，也不需要对转发处理聊天消息做多余的处理。聊天服务器可以独立的存在于游戏网络。也可以让广播服务主动向玩家推送消息，由服务器向玩家发起连接，而不是所有连接请求都是由玩家客互端发起。
虚拟游戏网络的构成是一个独立的层次，完全可以撇开具体游戏逻辑来实现，并能够单独去按承载量考虑具体设计方案。非常利于剥离出具体游戏项目来开发并优化。
最终，我们或许需要的一套 C 库，用于游戏网络内的通讯。api 可以和 socket api 类似。额外多两条接入与离开游戏网络即可。
[68] 