背景：公司的棋牌游戏需要任务系统。并且在玩家登陆和大厅等环节返回给用户。考虑到c++的维护成本，不打算继续增加游戏服务器的复杂度了，计划c++服务器仅用于游戏逻辑，包括坐下，判断出牌胡牌等。其他功能全部交给另外的扩展服务器处理。c++服务器进需要进行数据上报和反馈给用户，其中的处理和判断都不需要再关心。这么做的好处是，有效降低了c++服务器复杂度，相同功能开发完也不需要多次更新。只需要重启扩展服务器即可。
技术选型：
扩展服务器技术选型：方案很多，目标是一定要脚本语言，开发简单，扩展包多，可以随时更新。备选有skynet，golang，nodeJS等。一开始打算使用skynet，国产精品，并且lua语言也和现在前端技术栈可以对接。但是问题是skynet的文档还是偏少，并且对于新手，一开始上手有点麻烦。也考虑过如日中天的golang，但是综合扩展包和市场成熟度来看，nodeJS更胜一筹，再加上一个阿里的同学给我看了他们的招聘方向，node赫然在列！遂对其前景还是非常有信心的，不再犹豫，直接搞起。node有非常多好用的扩展，当时打算使用网易的pomelo，好处是rpc和负载均衡都已经实现，问题是c++使用websocket各种麻烦，并且tcp直连pomelo还得解决分包粘包问题。
RPC技术选型：其实一开始是否使用RPC我是拒绝的。毕竟一下子使用两套新技术有点担心稳定性等问题，游戏服务器和node的tcp直连也做得差不多的。但是问题出现了，玩家收到结算消息后会立刻断开服务器的socket，但是这时因为socket异步的，有可能数据还没回来，也就是说玩家都下线了，他得到新功能的消息才过来。因此这里必须要考虑同步阻塞的问题。在确定使用RPC之前，对其性能进行了大量调查，基于阿里云内网也做了测试，平均一次请求小于10ms。满足性能要求。接下来就是选哪套rpc方案了，综合grpc，thrift以及百度的brpc等，能支持c++的选型不多，也就只有thrift了。grpc虽然也可以，但是得vs2015才能编译。
具体实现：
基于vs2012编译thrift是条不是很好走的路，需要boost库，如果需要异步还得libevent，这些都要通过vs2012编译出来，这样各个lib都是基于同一个版本vs，兼容性问题肯定最小。网上参考的解决方案还是挺多的，基本上主要需要在vs工程删除缺失的文件以及添加没有包含进去的文件，最后生成静态lib，倒到游戏服务器就可以正常使用了。
node相对来说比较好实现，基本上一键安装好后，写好的js，直接通过node命令跑起来就行。但是node也有个坑的地方，npm安装扩展包虽然简单，但是由于node升级很快，很多以前旧版本node能用的包，新版本已经无法使用了，mssql就是个例子，最后选择了6.x.x版本才能正常使用。访问redis倒是很顺利。
有个不得不说的地方就是node的异步模式，真是成也异步败也异步。虽然IO效率的确是高，就怕遇到需要顺序执行，以及等待上次执行完后再继续下去的情况，再加上我们服务器每次上报的数据不确定需要处理多少次异步。总之使用node或者设计方案前，一定要对node的异步有深入理解才行。
我们在项目中就同时用到了async.parallel和递归。并且async.parallel处理通过for循环插入不确定数目的同步执行函数。