游戏开发之服务器技术选型浅析

　　欲作此篇文章的想法由来已久，基本上，它是我因各种原因（被动）了解、接触甚至使用了几个市面上相对而言较有知名度的开源的游戏服务器框架后的总结和反思。

　　本文尽量客观，但不可避免或会有不少带个人偏好的观点与看法；而限于个人目前的能力学识及眼界，本文所述内容或仅适于当前阶段我的认知。

　　先摆个人观点一：不推荐诸如 Pomelo 及 Skynet 等框架。
　　使用这类服务器框架的原因，主要无外乎名气大、能快速出活（有不少示例），但，事实真如此么？
　　这两个框架无一例外，都是以脚本作为主要甚至唯一的开发语言（JavaScript、Lua），不可避免的，脚本语言的劣势和短板在它们身上会被放大甚至大大放大，尤其当服务器程序逻辑比较庞杂时/后。
　　静态类型检查、调试便利度（譬如 Skynet，调试？聊胜于无吧）、代码可读性、性能表现（譬如 Pomelo，其表现委实较差即便有 V8 加持）、维护重构成本（脚本一时爽XXXXX 当然只是调侃）...等等，这些都要审慎考虑。
　　本质上，动态脚本只是胶水语言（JavaScript、Python纷纷表示强烈反对，毕竟语言特性丰富且各类库多如牛毛），或许，适度地在适合的场合适量地使用它们更符合它们的设计定位。而譬如 Skynet，虽然其宿主程序以 C 编写，但在使用上，它“鼓励”以 Lua 来编写几乎所有的逻辑，当然，譬如某些性能敏感的模块等，可以 C/C++ 编写动态库供其调用——麻烦么？有点。
　　印象里在 Skynet 的 wiki 里看到其作者解释为何 Skynet 官方版本不支持 Windows，大意是因 Windows 的网络性能不行——呵呵，这得有多大的并发多大的流量呢？IOCP 性能不行？。真考虑性能，哪还会如此重度的使用脚本？再考虑到可能大部分程序员的开发工作恐怕都在 Windows 下，需得先将脚本全部上传至 Linux 后服务器程序才能运行起来，不费时费事么？
　　Lua 在游戏行业的普遍使用，恐怕或多或少有 WOW 这一鲜活案例的原因。而国内大量使用脚本编写游戏逻辑的开发模式，估计网易首创。slua 的作者说的好，“经过良好设计的游戏引擎，都是思考过什么应该引擎层做，什么应该脚本化”——服务器框架也同理。
　　我很难想象，譬如 WOW，若其服务器代码大部分甚至绝大部分模块和逻辑都要以 Lua 编写，该是怎样的景象。
　　当然，如果只是练手或小游戏等，拿这些框架来使无可厚非，顺带能学习下其设计什么的——但恐怕也仅限如此了。譬如一些休闲类小游戏，技术要求本来就不高甚至较低，与其去熟悉诸如 Pomelo 等“较重”的框架，多研究多参考自己写一套也并非什么难事，且更可控可定制，也更能提升水平经验。
　　至于稍微上规模或较复杂的游戏，几乎可以肯定，基本不大会使用这些服务器框架——譬如市面上热门或较有知名度的游戏，哪个使用了这些服务器框架？譬如各类大小游戏公司，有哪几家在用这些服务器框架？恩，Skynet 作者自己的公司在用，似乎畅游貌似在尝试 Pomelo（虽然网易自己都不用，其有自己的 MobileServer 引擎）。
　　基本上，正在使用或使用过这些游戏服务器框架的，几乎都是没什么技术积累、技术水平还较一般的小公司小团队。譬如腾讯等，技术积累深厚，人才多，耍的是 C++ + Lua 之类。
　　或许，若日常工作主要都是撸脚本（譬如 Lua），对个人的成长影响是较负面的，即便只是螺丝钉，也不应仅局限于此。

　　再摆个人观点二：除却 C++，Go 是开发后台程序的利器。
　　当然还有 Java，虽然重了些，但毕竟资源多、人才大把，后端技术栈基于之断不失是个较实用的选择。
　　而 C++，恐怕在技术积累和人才都不是问题的前提下才是较好的选择，而似乎可以断定的是，恐怕相当部分的小团队甚至中小团队等，都不太具备这个能力。C++ 本身的复杂度、开发效率甚至靠谱的可选人才等，都是相当现实的问题。
　　综合这些因素等，或许可以尝试基于 Golang 建立后端技术栈：学习成本低、使用已不可谓不广、业界及游戏界早已在用且不乏成功案例（BAT、TMD、巨人、游族等等）、大腿粗（Google 家出的且其内部使用较普遍，爹又是当初搞 C、Unix、UTF-8 等的那帮人）。
　　基本上，有些编程底子的技术人员，能较快地了解熟悉它，并能在较短时间内上手写码——当然，这个是要看人的。
　　而 Go 自身的语言设计也比较适合开发后台程序，开源及参考资料也较多，调试分发也很方便，等等。

　　应该是我水平差眼界低吧，我很难理解譬如云风为何偏执于 Lua，可能大牛站得高想得多吧。
　　而我也只是“不推荐使用这些服务器框架”而已，它们拓宽了游戏服务器的技术选型面，或多或少也是优秀的参考学习资源，从这些方面看，它们都是有实用价值的开源项目。

　　游戏服务器不可避免的会有类似“热更”之类需求（所以才会是 C++ + Lua，而非只是 C++），配置类的热更当然没啥好讨论的，至于逻辑代码的修补热更，譬如 Go，若习惯与 Lua 脚本交互的方式，成熟的参考当然有，如这个。
　　记得去年初我在搞基于 xLua 的客户端热更框架时，很赞同其作者的“若非热更新之故，恐怕是没多少人喜欢使用脚本的”之论断，C# 多强大，Lua 好蛋疼...当然如写习惯了，也凑合吧。毕竟，脚本有脚本的用武之地，作为技术人员，在合适的场合适度使用脚本即可，仅此而已。