网络游戏架构与微服务架构简单对比

  笔者十年前做过网络游戏,当第一次看到微服务架构就发现它和网络游戏架构很像,如下图:

  

  先来简单介绍一下这个网游架构,有些东西记不清了,如今的网游大牛看到可别丢砖头。

       用户下载网游客户端,登录网游,首先会执行登录服务,登录服务主要就是给你分配一个网关,因为网关后面连接的才是真正的游戏服务器。登录后,进入游戏,发出指令,比如你移动到某个位置,这个指令会先发送到网关,然后再由网关识别发送到“移动系统”服务,移动系统计算后再经由网关发送给玩家客户端,玩家客户端执行一个动画让你移动到某个位置。      

       假如子服务间要通信也是通过网关转发,比如任务系统里面要购买物品,那么任务系统发一个指令消息给网关,网关再转发给物品系统等等。图中的“游戏A服务器集群”,其中“游戏A”代表你所属的游戏服务器,每个游戏服务器能承载的人数是有限的(当时的技术一个服务器组最多同时在线也就几千人),人数满了,你就要登录到另外的服务器。“集群”表示服务部署的集群。每一个明面上的游戏服务器,对应一个N台服务器构成的游戏服务集群,但只对应一个用户数据库,数据库没有使用集群技术,因为你即使使用了数据库集群技术,在实时性方面也跟不上。

从编程上来讲,包括以下应用:

       客户端.exe

       网关.exe

       移动系统.exe

       聊天系统.exe

       ….

       说到这里,了解微服务的人可能看出来了,上面的网关就好比nginx反向代理服务器,每一个游戏服务就好比微服务中的服务,如果你的微服务通信协议使用的是TCP那后面服务部分基本就一模一样了。网络游戏中数据访问没有分层直接放到业务处理模块,在游戏中每一个游戏执行逻辑不管是加载脚本、配置数据还是账户数据都是在同一个逻辑中处理的,不会去划分出什么数据库访问层、脚本访问层,这样处理有一个很大的好处,那就是可以处理复杂的逻辑,而又不用丧失效率。

       在网游中,因为服务间通信的是二进制消息,在编程时解析消息和组装消息非常麻烦,因此需要设计一个统一的类库,这个类库把二进制消息传递直接变成面向对象调用。比如你调用了一个方法,其实就是向网关发送了一个二进制消息。这用在微服务这里也是一样的,让接口的收发消息变成面向对象调用,可以提高编程开发的效率,又能降低通信所产生的bug,孢子框架中的接口访问层也完成类似功能。

       至于说分布式事务的问题,在网游开发中比较容易就可以解决(即使解决不了还有客服),因为所有事物相关数据都在一个数据库,即使不在一个数据库也是通过消息去同步。比如你砍了怪物一刀,你的等级数据上升、体力下降都在一个服务里计算的,假如怪物被砍了一刀的计算不在这个服务里,那么会发一个消息给那个服务,那个服务计算怪物被砍了一刀,如果计算失败,再回发一个消息给前一个服务来协同这方面,如果被砍死了掉物品了,就发一个消息给物品服务去计算,物品服务再回发消息与主计算协同。这其实就是通过消息机制进行事务协同最原始的版本。

       和微服务对比归纳一下:

       游戏(Gate网关)相当于:微服务(nginx或API Gateway)

       游戏(个体服务)相当于:微服务(个体服务)

       游戏(接口访问层)相当于:孢子框架(接口访问层)

       另外微服务中流行的分布式事务解决方法也是通过消息来实现,比如支付,调用方调用支付接口失败,发一个失败消息给消息队列,支付接口服务监听消息队列并处理支付失败。

 

补充:少了场景服务,场景服务管理进入某地图的所有资源,比如一个人要移动,计算完个人移动后,还要向地图内(可视范围内)所有人发送移动消息。

posted @ 2015-10-30 11:21 lzhou666 阅读(...) 评论(...) 编辑 收藏