最近完成了一个回合制网游的服务器架构

最近在弄服务器架构，现在基本算是完成了，朋友泰兰德の記憶在过程中帮了很多忙，在此谢谢他。


   考虑到是回合制网游，所以交叉逻辑（即用户与用户之间的交互操作）会少于一般的A-RPG游戏，所以最终采用的是按照逻辑对等均分所有的GameLogicServer。
   整个架构采用的是多进程，单线程的模式进行开发，我个人认为这样的开发模式好处远远大于单进程多线程的开发模式，我深深的信奉一个原则，那就是团队强才是真的强，极大的提高团队整体的编程容错率，才能做好项目。
   由于是单线程，不用担心多线程之间数据锁的问题，整体服务器集群内部采用的还是tcp socket通讯，尽量做到单个输入点，或者是单个输出点。
 
  对等的GameLogicServer统一都注册到一个中心服务器，也可以称为WorldServer，由这台服务器做均衡负载，而整个的登陆流程是独立出来的，也就是LoginServer，由于公司是内部统一的账号通行证，提供的是http协议接口进行交互，所以独立出来，并且生成一个唯一且仅可用一次的ukey来发给用户，用于游戏服务器的一次性登陆。

  网络底层用的是第三方网络库 boost asio，大量的商业级应用告诉我们，这是一个经得起考验的网络库，当然了，也在于用它的人和怎么用。有的朋友说boost过于庞大，庞大又怎么样。。。难道服务器差那点硬盘空间。。又有的朋友说，boost编译很慢。。。市面上动态分布编译工具很少吗？IncrediBiuld是干什么的。。。总之我选择了它。。。

下面说架构的理由。。

  整体架构的优点在于，逻辑承载可以实时动态部署（无论是逻辑服务器还是物理服务器，均可以实时根据人数动态部署），目前还没有考虑排队系统的开发，毕竟是IOS游戏，玩家量和页游端游还是有一定差距的，不过也做好相关准备吧。

  另外一个优点就是，单大区的服务器人数上线是和逻辑承载量没有关系，决定单大区服务器人数上线的 就是gate的网络吞吐量，IOCP模型是以网络吞吐量著称的，所以这样的架构应该可以满足需求了。

  唯一不好的地方，这种流水式的架构，在服务端开启的时候是一个麻烦，要按一定顺序开启，这里我目前想到两个解决方案

  1.之前研究别人的服务器的时候，看到过一个类似处理批处理的东西，就是每一个进程下面配置好所有信息，由一个外部程序打开，外部程序可以是mfc，也可以是一个批处理，就是由一个类似《内务总管》的软件，将所有的服务器进程打开。

 2.第二个解决方案就是写一个 NameServer， 这个NameServer也就是集群内部的DNS服务器，采用类似pop3的协议，在每一个进程启动的时候，把自己的信息注册到这里，同时也提供服务器，供任何的Server来查询内部服务器群组任何一个服务所在的IP地址，然后来达到注册。。
  
好像这两个解决方案并不冲突啊。。。可以写一个NameServer，同时再用一个独立程序一起打开他们，如果在NameServer没有找到需要的相关服务的话，就等待，直到有了目标服务。。嗯，这是一个好的方法。。

好了，很晚了，今天健身房搞到两条小腿同时抽筋，休息了