网络游戏架构与微服务架构简单对比
笔者十年前做过网络游戏，当第一次看到微服务架构就发现它和网络游戏架构很像，如下图：
先来简单介绍一下这个网游架构，有些东西记不清了，如今的网游大牛看到可别丢砖头。
用户下载网游客户端，登录网游，首先会执行登录服务，登录服务主要就是给你分配一个网关，因为网关后面连接的才是真正的游戏服务器。登录后，进入游戏，发出指令，比如你移动到某个位置，这个指令会先发送到网关，然后再由网关识别发送到“移动系统”服务，移动系统计算后再经由网关发送给玩家客户端，玩家客户端执行一个动画让你移动到某个位置。
假如子服务间要通信也是通过网关转发，比如任务系统里面要购买物品，那么任务系统发一个指令消息给网关，网关再转发给物品系统等等。图中的“游戏A服务器集群”，其中“游戏A”代表你所属的游戏服务器，每个游戏服务器能承载的人数是有限的（当时的技术一个服务器组最多同时在线也就几千人），人数满了，你就要登录到另外的服务器。“集群”表示服务部署的集群。每一个明面上的游戏服务器，对应一个N台服务器构成的游戏服务集群，但只对应一个用户数据库，数据库没有使用集群技术，因为你即使使用了数据库集群技术，在实时性方面也跟不上。
从编程上来讲，包括以下应用：
客户端.exe
网关.exe
移动系统.exe
聊天系统.exe
….
说到这里，了解微服务的人可能看出来了，上面的网关就好比nginx反向代理服务器，每一个游戏服务就好比微服务中的服务，如果你的微服务通信协议使用的是TCP那后面服务部分基本就一模一样了。网络游戏中数据访问没有分层直接放到业务处理模块，在游戏中每一个游戏执行逻辑不管是加载脚本、配置数据还是账户数据都是在同一个逻辑中处理的，不会去划分出什么数据库访问层、脚本访问层，这样处理有一个很大的好处，那就是可以处理复杂的逻辑，而又不用丧失效率。
在网游中，因为服务间通信的是二进制消息，在编程时解析消息和组装消息非常麻烦，因此需要设计一个统一的类库，这个类库把二进制消息传递直接变成面向对象调用。比如你调用了一个方法，其实就是向网关发送了一个二进制消息。这用在微服务这里也是一样的，让接口的收发消息变成面向对象调用，可以提高编程开发的效率，又能降低通信所产生的bug，孢子框架中的接口访问层也完成类似功能。
至于说分布式事务的问题，在网游开发中比较容易就可以解决（即使解决不了还有客服），因为所有事物相关数据都在一个数据库，即使不在一个数据库也是通过消息去同步。比如你砍了怪物一刀，你的等级数据上升、体力下降都在一个服务里计算的，假如怪物被砍了一刀的计算不在这个服务里，那么会发一个消息给那个服务，那个服务计算怪物被砍了一刀，如果计算失败，再回发一个消息给前一个服务来协同这方面，如果被砍死了掉物品了，就发一个消息给物品服务去计算，物品服务再回发消息与主计算协同。这其实就是通过消息机制进行事务协同最原始的版本。
和微服务对比归纳一下：
游戏（Gate网关）相当于：微服务（nginx或API Gateway）
游戏（个体服务）相当于：微服务（个体服务）
游戏（接口访问层）相当于：孢子框架（接口访问层）
另外微服务中流行的分布式事务解决方法也是通过消息来实现，比如支付，调用方调用支付接口失败，发一个失败消息给消息队列，支付接口服务监听消息队列并处理支付失败。
补充：少了场景服务，场景服务管理进入某地图的所有资源，比如一个人要移动，计算完个人移动后，还要向地图内（可视范围内）所有人发送移动消息。
