前言
由于这边需要对接游戏研发后台,基本就是开服,封禁.角色日志等,但是每个游戏提供的接口都是不一样的,所以为了统一处理提前进行sass封装,以便后续可以更好的兼容
同时还涉及了多数据源的问题,因为有些日志太大不可能直接去http调用,会使用直接查询游戏研发的数据库方式这一块依然可以进行封装
这里只讨论开发\封禁\角色日志\聊天记录等,其他的接口和功能都是类似的,这里主要是讨论设计方案
前提设计数据库表
游戏表(核心)
| id | game_code | root_path | app_key |
| 主键id | 游戏编码(核心) | 游戏请求根路径 | 游戏密钥 |
| 1 | zxcGame | http://192.168.0.1/path | sdfsdfdsfdf |
服务器器(sass)
| id | server_id | game_id | status |
| 主键id | 服务器id | 关联的游戏id | 状态 0-闭服 1-开服 |
| 1 | 100045 | 1 | 0 |
Http设计方案
涉及类图
相关描述
AbstractGameCall: 用于抽象定义,并封装了子类可以通用的方法,比如getGame()
ForestImpactGameCallImpl: 其中一个实现子类, 这里是封装的意义,子类实现自己逻辑即可
ForestImpactHttpUtils: 跟子类相匹配的Http请求类,与游戏具体的对接
GameCallContext: 接口上下文, 客户端只需要跟这个类打交道即可
这样的设计以后如果有其他的游戏对接,只需要提供对应的实现和http实现类即可,项目内部会通过getGameCode()方法获取到具体的实现类,这里是唯一需要匹配的地方,抽象类提供的getGame()也是给子类提供了便利,因为gameCode是唯一值所以是可以这样去做的
sass方面设计
主要存在于以下的几方面
1: 通过getGameCode便可以实现getGame通用方法,进而在进行http调用时,可以获取到具体的appKey进行加密处理,以及rootPath根请求
2: 假设在进行服务器修改状态时,那么就可以根据服务器绑定的gameId获取到具体的实现类,然后再进行相应的处理,只需要在入库时绑定这个关联即可
3: 对外暴露接口时需要对方传递一个固定的gameId参数,那么就可以把接口根据不同游戏来查询数据进行返回,以及解密也可以通过这个来进行自动的匹配
4: 以上几点保证了后续如果有新游戏只需要对提供实现类即可,底层的逻辑是不需要进行调整的
可能存在问题
解设不同游戏有不同参数,那么也可以在调用过程中通过添加参数,然后子类进行相应的处理即可,当然了还可以提供回调函数的方式让不同实现类进行传输,如果没有多余参数不进行涉及即可
多数据源数据设计方案
其实逻辑跟上面差不多的,只是像角色信息、聊天信息、用户日志等这部分日志过大，不是很适合用http传递过来，一个是数据量过大，一个是这边也没有那么多的磁盘来存储数据
所以这个就需要依赖对方提供数据库，然后我们这边到不同的数据库中进行数据的获取了，但是仍然可以复用sass的功能对gameId区分然后进行处理
大概结构也是差不多的，到时看看有时间就补上来一下，待定
结语
其实用了很多设计模式后发现很多时候都跟抽象类、策略、模板等基本模式脱不了关系，个人认为设计模式绝对是有利于编码的，因为在思考的过程中会自然的把一些可以通用的逻辑封装起来，比如getGame(), 以及appKey和rootPath的获取
如果有合适的场景，也建议大家可以考虑一下如何进行设计，在以后的开发中会带来比较大的变化，比如在下一个游戏的对接，只需要实现子类即可了
