attachments-2021-09-sBEITfF0613c05db377c1.jpg
golang 游戏框架简介:
一、参考游戏服务器架构通识

attachments-2021-09-uDcpsK9d613c04f4dbae6.jpgattachments-2021-09-TxC4EzWc613c04faa6a8b.jpgattachments-2021-09-INW1PYxA613c0501e33c7.jpgattachments-2021-09-qlQTEZ9x613c05084240a.jpg


对游戏服务器历史有了基本了解后,成熟形态的游戏服务器很容易理解。简单来说,就是把逻辑服务器单个进程的压力分摊到多个服务器。难点在逻辑的设计上,要像做手术一样把本来是一体的功能切开,并抽象出若干个API来保持联系(服务器之间是TCP连接)。

在分解时,要找联系相对最薄弱的环节入手,比如场景和场景之间分开、单独抽出聊天服务、组队服务、好友服务。无论如何分解,最终结果只能是有限个服务。而且分解的越细,开发难度就越大。因为跨服务器逻辑是把简单的同步逻辑变成了异步Callback逻辑,而且容易出现时序问题等不易测试的问题。

单个场景服务几乎是无法分解的。分解单个场景难度巨大以至于出现了BigWorld引擎来专门的解决场景分割问题,后面会谈到。这种成熟形态的游戏服务器已经能满足现实中99%的频繁交互类网游需求,是大型MMO端游、页游的主流形式。当然有实力的公司在这个基础上会做很多改动,实现动态开辟副本、相位技术等等,但是万变不离其宗,其本质和上图没有什么区别。

二、横向对比

attachments-2021-09-jjvJGkIC613c051689cad.jpg

在架构上面,一般访问量不是很大的网站是只有一台服务器的,访问量高的才会进行分布式设计或者集群设计。而大部分游戏服务器都是需要分布式设计的。在现有的网络游戏服务器端架构中,多是以功能和场景来划分服务器结构的。具体的划分是根据项目的需求进行的,并没有一个十分通用的架构。