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

　　笔者十年前作过网络游戏，当第一次看到微服务架构就发现它和网络游戏架构很像，以下图：

　　

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

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

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

从编程上来说，包括如下应用：

       客户端.exe

       网关.exe

       移动系统.exe

       聊天系统.exe

       ….

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

       在网游中，由于服务间通讯的是二进制消息，在编程时解析消息和组装消息很是麻烦，所以须要设计一个统一的类库，这个类库把二进制消息传递直接变成面向对象调用。好比你调用了一个方法，其实就是向网关发送了一个二进制消息。这用在微服务这里也是同样的，让接口的收发消息变成面向对象调用，能够提升编程开发的效率，又能下降通讯所产生的bug，孢子框架中的接口访问层也完成相似功能。

       至于说分布式事务的问题，在网游开发中比较容易就能够解决（即便解决不了还有客服），由于全部事物相关数据都在一个数据库，即便不在一个数据库也是经过消息去同步。好比你砍了怪物一刀，你的等级数据上升、体力降低都在一个服务里计算的，假如怪物被砍了一刀的计算不在这个服务里，那么会发一个消息给那个服务，那个服务计算怪物被砍了一刀，若是计算失败，再回发一个消息给前一个服务来协同这方面，若是被砍死了掉物品了，就发一个消息给物品服务去计算，物品服务再回发消息与主计算协同。这其实就是经过消息机制进行事务协同最原始的版本。

       和微服务对比概括一下：

       游戏（Gate网关）至关于：微服务（nginx或API Gateway）

       游戏（个体服务）至关于：微服务（个体服务）

       游戏（接口访问层）至关于：孢子框架（接口访问层）

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

 

补充：少了场景服务，场景服务管理进入某地图的全部资源，好比一我的要移动，计算完我的移动后，还要向地图内（可视范围内）全部人发送移动消息。