H5游戏开发的架构总结(二) 服务器端

【服务器端】
1.关于Go语言
我们的H5游戏服务器框架是用Go语言开发的。以前做页游的时候是用的php和python，都是动态语言。在上线之后，高并发的时候，单机有性能问题，一直没有好的解决办法！
13年的时候我原来的领导开始转用Go来开发手游的服务器端，所以我也跟着转型了！
正如七牛的许世伟所说，用go开发，是可以降低程序员心智负担的！静态编译的优点不用赘述，语言简洁，开发效率高，特别是goroutine和chanel两大神器，专治各种疑难杂症。
Go语言这两年的发展非常迅猛，特别是在中国的很多重量级互联网公司得到大量运用。
而且语言本身已经发展到1.6版本，GC时间从原来饱受诟病的几秒下降到了1毫秒，除非是对延迟要求非常苛刻的应用场景，绝大部分的应用场景都能hold住！

2.关于通讯协议
我们这套框架，最开始是手游的游戏服务器。所以只支持tcp socket。
后来转H5之后，又加入了对websocket协议的支持，两者放在一起，做了封装。
后来为了兼容不支持websocket协议的android手机，又加入了对http协议的支持，因为http属于应用层协议，tcp是传输层协议，没法简单的封装在一起，所以就写了两套。
但是发送和接受的内容都是一样的：加密之后的自定义格式的二进制数据。


3.关于缓存和数据库
我们的数据库用的是mysql，缓存同时支持memcache和redis。
在业务层和数据库之间，封装了一层k-v的cache，可以通过配置分别使用memcache或者redis。
每张数据表都有自增长的id主键，并且有一个类似java bean的struct与之相对应.
针对单表的sql操作，根据类型不同有不同的处理机制：
1)select操作就根据id去缓存里面取值，没有就查mysql，然后缓存结果.
2)update/insert/delete操作，就直接操作mysql，同时删除对应缓存.

如果是对多表的联合查询，一般都是直接走sql，不走缓存。

这样就可以在高并发的时候，减轻数据库的访问压力。
目前是只用到一个主库。后期压力上来可以改成1主多从。


4.关于单元测试
Go语言对单元测试的原生支持，让测试驱动开发成为一种本能！
但是单元测试也有不同的重量级，有的功能需要依赖项目启动时读取的配置文件，有的功能还需要玩家的特殊状态。
再加上多人协作开发的时候，需要控制每个人的私有单元测试边界和公用的单元测试范围，免得互相影响，因为引入不必要的测试而导致测试总时长增加！
在项目开始的时候，强调单元测试的重要性，并做好整个项目的单元测试的组织规划和部署，非常重要，可以事半功倍，节省大量后期测试和纠错的时间！


5.关于excel工具链
策划的数值表都是excel，我们用go写了个转换工具可以通过命令行把指定的excel转成服务器端需要的json格式文件。
其中有些json文件的内容是客户端需要的，于是又用python写了个转换脚本，提取和组合服务器端的json文件内容，生成客户端需要的json格式文件。
有了这两个工具，就可以实现自动化部署，方便测试在单独的数据测试服上调数据！


6.关于服务器端AI
碰碰车的联网比赛场里的AI行为比客户端复杂，策划在AI行为数据表里进行配置，转成json，在比赛场里根据AI配置文件控制NPC的行为。
将计算之后的NPC的位置和角度等状态发送给客户端，客户端只负责呈现！


7.关于联网纠偏
碰碰车的联网比赛，服务器端在房间里会模拟客户端的帧update事件，更新频率在80毫秒一次。
每次update的时候都需要计算房间内所有agent的位置，进行碰撞检测，以及其他逻辑。并把更新后的信息，通过纠偏事件下行给所有玩家。
这个更新频率太短和太长都不好。太短会造成服务器和客户端CPU压力太大和网络流量的增加，太长会造成客户端收到的位置和自身计算的位置差距太大，
如果不做线性补偿，直接以服务器端为准进行更新，会有跳跃感。


8.关于微服务和全球统一服
我们一开始做这套游戏框架的目标就是支持高并发的全球统一服。
单机的性能再怎么优化都有天花板，微服务和容器云是目前互联公司应对类似需求场景的通用解决方案！
按计划分三步走：
第一步：单块系统，通过命令行来打包和发布。目前已在线上运行！
第二步：通过docker创建容器，实现自动化打包和发布。目前已经在本地mac实现docker创建容器和运行测试，还没有部署到线上！
第三步：进行微服务拆分，通过docker容器云实现动态扩容，支持高并发，实现全球统一服。


9.关于服务监测
go是静态语言，所以编译运行的web应用如果出现panic，整个进程就退出了，所有连接都会被断开。
这跟php这种动态语言提供的web应用还不太一样，一个连接的服务挂了，其他连接不受影响。
所以必须充分的测试，尽量做到线上的服务不要panic。但是人难免会犯错，程序也不可能百分百没有bug，所以必须做好监控和预防措施！
我们的解决方案是有个定时程序每分钟检查一次服务器程序的进程是否还在，如果没有就说明程序panic了，就重启服务器应用，将影响降至最低。
同时邮件通知相关技术。技术收到邮件之后可以通过日志查看panic的原因，解决bug之后，测试通过，再发布更新！


10.关于压力测试
1）测并发链接数上限，并以此为参考，设定登录排队系统的人数限制！
2）测比赛场的玩家数上限，这个需要提前准备足够的AI玩家数据，然后同时进入指定比赛场，
   一是看自动分房间功能是否正常，而是看有没有并发死锁和chanel挂起等问题发生。这些问题在开发的时候，本地单元测试是发现不了的！

H5游戏开发的架构总结(一) 客户端