railgun游戏服务端架构
以上是整个游戏服务器架构图，分为三部分。（这里把一个.exe服务器程序称为一个App）
1.网关 GateApp，可以多个
2.路由 RouterApp，暂定一个
3.一般的业务App
这三部分的一个大致区别是:
GateApp是监听了一个TCP端口，用于用户客户端来连接，并主动去连接(or拨号)RouterApp
RouterApp监听了一个TCP端口，等待其他server app来连接，server app包括gate app和一般业务的app
一般业务App只主动连接Router App，与用户客户端的交互都通过gate来转发。
这里简单说明一下为什么业务APP不监听一个端口，然后供客户端直连？
因为原C++的服务器架构也曾经采用过这种方式，但是在实际运行中发现管理用户上下线行为很不方便。最典型的是顶号登录行为，如果用户换了一个设备登录账号，需要断开原来的设备上的客户端连接的话，那就要挨个APP通知，以断开原来的用户连接。这样子的用户管理非常不方便，所以后来更改架构，只允许客户端和GATE之间建立TCP连接，其他APP要与客户端交互都通过gate。
PS:
这个golang的服务器框架是源于原来的C++游戏服务器框架，原来的C++游戏服务端目前最高同时在线人数在2W，目的是利用golang的高并发特性来尝试提高在线容量。
网络层在原来C++的设计思路上，还参考了
http://studygolang.com/articles/3184
https://github.com/funny/link
在这里顺便感谢一下这两位素不相识的大大
我的邮箱：[email protected]