railgun项目的不足和将来会逐步新增的模块

问答:

Q：这个框架适合做什么类型的游戏?

A：适合棋牌类、卡牌类（炉石传说）、回合制（梦幻西游）、半回合制（阴阳师）。暂时不适合即时类游戏（星际争霸、DOTA、LOL、CS）

不足:

1.数据库操作的封装模块没有考虑sql注入的问题，golang讨论群里的大神说我这个可能会存在sql注入风险。如果有需要将来可能会写个sql语句关键字过滤器，来过用户输入里的滤掉诸如and or select delete之类的关键字（我对这个问题研究不是很深所以不确定）

2.routeragent没有正式处理RegisterAppRsp，还是因为有些业务代码尚待剥离

3.现在基本上所有重要结构体的里的map类型的成员变量的value都是一个struct类型，我认为讲struct类型变为* struct类型可能程序运行效率会更高，因为map在每次查找时应该会重新构造一个新的结构体类型变量作为返回结果，因为以前C++是有容器的iterator来对查找到的elem进行直接操作的。但是golang的map没有iterator的做法，所以我想如果构造一个指针应该比构造一个结构体效率要高。如果我的猜想是正确的，将来会做相应的改进

4.因为sql.db已经是一个数据库池了，他可以同时保持多个sql连接。存在重复生成了sql.db这个对象的问题。但是因为CAdoDatabase这个类里还包含数据存储的数据结构，如果所有数据库协程公用同一个CAdoDatabase对象，恐怕会产生数据dirty的问题，所以这个问题将来有空会做调整，这个优先级不高

5.会将agent按照类型拆分成单个.go文件，这样会显得直观点

6.当前服务端架构的瓶颈显而易见在于RouterApp。如果采用多个 RouterApp作为路由集群的话，在我们原来的C++框架中出现了报文发送顺序和抵达顺序不一致的问题，因为如果是多个RouterApp集群的话，在转发到RouterApp时，假设先发送的报文抵达了一个繁忙的router,后发送的报文抵达了一个空闲的router就会出现报文的先后顺序问题。

原来的C++的解决方案是如果对业务报文有先后顺序要求的，那么就一直固定向同一个routerApp发送，没有顺序要求的随机选一个routerApp发送。这样每当新增一个报文就要带来判断这个报文和原有报文是否有先后顺序要求，会增加逻辑复杂度。所以目前就用一个RouterApp，将来有需要可能会改为多RouterApp集群

计划内将新增的模块：

1.日志打印，现在程序内都是fmt.Println来打印，将来会将打印日志保存为本地文件

2.json配置文件，现在程序入口main()函数的各项参数都是手工写的，将来会读取json格式的配置文件，这样比方说有5个GateApp要启动，那么就只要改配置文件的内容就可以换监听的端口地址了

3.web监控界面，可以用web网页对所有APP程序进行监控和运维管理，（因为我以前没写过web程序，所以要重新开始学怎么用golang写web,这个时间不确定）

4.U3D客户端，将来我会写修改U3D官方教程《坦克大战》，以这个 《坦克大战》为模板，配合protobuf-net这个第三方库，写一个简单的U3D客户端，作为范例

5.与《坦克大战》搭配的话，自然会写在当前服务端框架的基础上，将C/S模式修改为帧序列模式服务端。这样这个服务器框架也能用于即时操作类型的游戏

剩下的以后想到会补充

我的邮箱：[email protected]