Unity3D游戏开发之网络游戏服务器架构设计培训(如何做一名好主程)
今天给大家讲一下如何做一个好的主程
入手
假如，我现在接手一个新项目，我的身份还是主程序。在下属人员一一到位之前，在和制作人以及主策划充分沟通后，我需要先独自思考以下问题：
1、服务器跑在什么样的操作系统环境下？
猜谜语大全2、采用哪几种语言开发？主要是什么？
3、服务器和客户端以什么样的接口通讯？
4、采用哪些第三方的类库？
除了技术背景之外，考虑这些问题的时候一定要充分考虑项目需求和所能拥有的资源。
我觉得，先不要想一组需要几台机器各有什么功能这样的问题，也不要想需要多少个daemon进程。假设就一台服务器，就一个进程，把所需要的资源往最小了考虑，把架构往
最简单的方向想，直到发现，“哦，这么做无法满足策划要求的并发量”，再去修改设计方案。
操作系统：越单一越好。虽然FreeBSD的网络性能更好、虽然Solaris非常稳定，但选什么就是什么，最好别混着来。前端是FreeBSD，后端是Solaris，运营的人会苦死。也不要瞧不起用Windows的人，用Windows照样也能支持一组一万人在线，总之，能满足策划需求，好招程序员，运营成本低是要点。不同的操作系统有不同的特性，如果你真的对它们都很熟悉，那么必定能到一个理由，一个足够充分的理由让你选择A而不是B而不是C。但做决策的时候要注意不要因小失大。
Programming Language：传统来说，基本都是C/C++。但是你也知道，这东西门槛很高，好的C/C++程序员很难招。用Perl/Python/Lua行不行？当然可以。但是纯脚本也不好，通常来说是混合着来。你要明白哪些是关键部分，我是说执行次数最多的地方而不是说元宝，这些必须用性能高的语言实现（比如C/C++比如Java），其它像节日活动这样很久才执行一次的，随便吧。脚本的好处是，可以快速搭原型。所以，尽早的，在你做完基本的地图和战斗模块之后，立马跑机器人测试吞吐量。这时候项目开发进度还不到10%，
不行就赶紧改。
此处特别举个例子就是Java GC的问题。既然你要用java，而jvm需要通过执行garbage collection来回收内存，而garbage collection会使整个应用停顿，那你不妨试一试，内存在达到峰值的时候会停多久？策划可以接受吗？如果不可以，你可以采用其它的GC策略再试一试。这个问题应该不是Java独有的。网游和网站应用相比它很注重流畅性。这是你务必需要考虑的。
至于选择什么样的脚本语言，以及脚本在你的游戏中究竟是占80%还是20%？需要根据需求来看。有没有游戏完全不用脚本？有。有没有游戏滥用脚本？也有。如果你引入脚本的目的是因为策划不会C/C++而你希望策划能自己独立实现更多的游戏功能。你希望策划去写脚本？脚本也是程序，策划写的脚本难道就比程序员写脚本好？还是因为策划工资便宜？策划因为脚本写错了导致大故障还少吗（此处特别以网易的产品举例）？综合权衡下，还是算了吧。问问你一起工作的程序员哥们儿，他们最喜欢什么语言，什么用起来最顺手，就用什么当脚本。注意不光要考虑开发速度快，还要考虑调试方便。
总体来说，操作系统和编程语言的选择，随大流即可。标新立异没什么好处。小地方的实现你可以玩玩，整体还是要越保守越好。
通信
然后说通讯的问题。服务器和客户端怎么连接上的？
往最下面看，物理和链路层。有可能是以太网，有可能是ADSL，在北京还有很多像歌华宽带这样的采用75欧同轴电缆或者电力线上网的。你不要企图在这一层做什么优化，你要充分考虑的是不同的网络传输媒质网络延迟不一样。更恶心的是你正常的数据包可能会被某些网吧的SB路由器当做P2P数据包给封掉，或是甚至被解析成Wake-On-Lan这样的含义。杨建还会给你讲，什么是MTU，把数据包限制在多大才能尽量让请求在一个包内发完。是的，这些很精细的东西，等咱游戏做的差不多了再慢慢研究。先略过。
往上看，IP层。再往上，你要考虑用TCP还是UDP或是二者混合。UDP的优势是overhead小、延迟低，典型的用例就是《天下贰》，据说是纯UDP。再比如《龙之谷》，据说是有小部分是UDP。负面的一点呢，就是它太过于简单所以用起来太过于复杂。你要是对自己没信心，TCP吧，随大流就好。
往上，采用什么样的应用协议。大多数rpc协议都是既支持TCP又支持UDP的。我所用过的
有sun rpc、corba、webservice、json、java RMI以及一些专有协议。如果你有精力，还是自己搞一套吧，网游所用的东西，还是越专有越好，给抓包做外挂的人加一点门槛。这里非常强调的一点，你采用什么样的序列化方式与你采用什么样的网络协议是无关的，你的应用协议和你传输协议应该也是无关的（既支持TCP又支持UDP的）。如果做框架的人把自己限制的太死或者耦合太紧，那么用框架的人会非常痛苦。所以，没必要在此为了性能做过多优化。结构简单清晰是王道。
很多人对网络开发的认识还停留在定义一个struct、memcpy到socket buffer、send，然后一个劲的给别人强调遇到指针怎么办、数组的长度不能超过多少、整个包的长度不能超过多少等等。序列化其实是面向对象程序设计的一个很核心的要素。连glib/gtk/Berkeley DB这些纯C的框架都是基于OOP设计的，所以我觉得您就算是C程序员也没必要排斥它。我讲这个是说，你应当做应用的人尽可能的避免用memcpy/memset这样的方式初始化数据、传送数据。如果你是C程序员，你多提供一些g_object_new这样的函数；如果你是C++程序员，写好你的构造和析构函数；如果你是JAVA程序员还死活不懂OOP，那算了吧，改行吧。
网络这一层有些很精妙的东西，尤其是当你规模扩大需要分布式扩展的时候。你想想看为什么sun rpc需要先去rpcbind询问一次然后才连真正的进程呢？RMI返回的时候为什么需要同时返回IP和端口号呢？web service那么通用，大部分浏览器都支持直接从浏览器调用web service那么为什么主流的方式却是json呢？
sun rpc是所有RPC机制中历史最久的吧？它在设计第一版的时候，每个rpc调用都是由一问一答来组成，称为two-way messaging。客户端在发出请求之后，一直等服务器的答复，如果一直到指定时间后依然没收到答复，那么执行timeout逻辑。在第一个请求收到答复（或者timeout）之前，无法发起第二个答复。直到某一天，Sun的程序发现他们需要异步处理一些事情，于是设计了one-way messaging，客户端在发起请求的时候，只要把这个东西塞到本地的IO队列里，就返回。但是如果socket buffer满了怎么办？还是会等在那里。于是觉得这个还不彻底，于是又做了Non-Blocking Messaging，在kernel的socket buffer前面加了一个用户态的rpc buffer，大多数时候它都是空的，当socket buffer堆满了的时候，再往这里面塞。如果这个buffer也满了怎么办？我觉得无非就三种处理手段：
１、阻塞。如果这么做，就是说本来是套非阻塞的设计但是某些情况下还是会阻塞？那么
给用的人解释起来太麻烦用起来也太麻烦。算了。 
２、悄然丢弃。 不是所有的数据都可以丢。聊天的无所谓，但是交易的就不行。所以需要在消息类型上加判断。 
３、关闭连接。 最简单粗暴，却也最有效。
在使用two-way messaging的时候，一定要记住设置超时，省得像某些傻瓜一样因为一个请求把整个server堵死。但是我觉得timeout设多久完全是个经验值，太大了没作用，太小了失败的太多。
至少在有一点我们可以大松一口气，就是不用担心数据量大到需要多网卡同时分担中断。通常来说网络游戏的流量都是很小的，对玩家来说一个56K的猫或者128K的DSL就够了。如果你的策划给你提了一个很BT的需求导致要耗费大量带宽，那么你最好把这个应用分到单独的tcp 连接上，省得因为它阻塞而导致关键的业务（比如地图消息）停滞。
我一直想把rpc的部分实现塞到kernel里。对客户端的好处是增加了逆向工程的成本，对服务器的好处是网关可以很高效。就像LVS那样，前端收完包之后在kernel里处理完然后立刻转出去，不用切换到用户态。而GameServer处理完之后，甚至不用经过网关，直接回复。
目的不在于分担网关的压力，而是说降低响应延迟。就算让法人委托书范本GameServer承担部分加密和压缩的计算量，它的CPU也足够用。
现在的热门专业不过对于网游，考虑动态扩容为时太早。一般都是新开几组服务器。
 
数据
我在做服务器安装包的时候，分的很清楚：程序、配置文件、数据库。
程序，就是编译好的二进制文件。最好是全静态编译，因为它简单。动态链接的优点以及其它一些高级话题我后面讲，但是通常来说，动态的复杂的结构得不偿失。
配置文件总体来说可以分为文本文件和二进制文件（废话）。文本文件的好处是开发过程中易于调试和修改，最终发布后也易于追踪问题。二进制文件的好处是小、精巧、不易把信息泄露给外人知道。java的打jar包的技术算是一个折衷的优势吧？我最看重的是易于调试和修改，所以基本都用文本文件。而这其中，表现力最强的就是xml，所以基本都是xml。
但是xml多了怎么管理就是个问题。我得整理份文档，每个xml都是什么格式，做什么用途的，最好每个xml再写一个xsd。事实是配置文件是随着需求变化最频繁的部分，而换个角度说我之前强调的序列化。所以，正确的思路是这样：
1、程序员分析需求文档，确定需要什么样的对象来表示配置
2、某套序列化框架，它利用某种xml解析库把xml变成内存中的对象口碑最好十大护肤品
3、策划提供xml
只要这个框架做的好，根本不需要文档或xsd来描述xml。我这里说策划提供xml，那么策划怎么提供xml呢？按照我所看见的策划的习惯，他们最喜欢的是两种方式：
1、对于结构简单的数据，编辑excel表
2、对于结构复杂的（如涉及树、环的），提供专门的编辑工具
对于1，我们可以给excel做plugin,或者做一个工具从excel表导出成xml。对于2，让编辑工具可以导出成xml。但是最终很重要很重要很重要的一点就是要让所有的工具集成在一起，做好版本管理以及跨版本diff和merge生活家演员。如何管理数据要比如何定义数据如何描述数据更难更重要。
很多同事和我的共识都是：要做一款好游戏，工具很重要。多个项目做完后，外人能看见的最大的积累就是工具和流程。
数据库
数据库在游戏中的重要性，是一个很令人玩味的东西。你可以听见很多人告诉你说，我们做游戏根本不需要数据库。是的，像单机游戏那样，在某个目录下创建一个文件，save/load就行了。这就是我所看到的当今的大型网游的主流做法。
哦，你要反对了。你说你知道某某游戏用的是mysql，某某游戏用的是oracle，等等。是的，你手上的信息可能比我多很多很多倍，但是关键点在于，数据库在整个系统中的角到底是什么？
典型的场景是这样：启动一个单独的进程称之为DB Gate。当用户登录的时候，逻辑服务器DB Gate要数据，DB Gate没有于是就去后面的Mysql要，然后读过来之后就放在这里，DB Gate就是一个类似于memcached的东西。所以后面无论是用mysql还是oracle赫敏扮演者还是plain text都可以，但实际上会在其它方面有些细微的差别。