前言

        由于这边需要对接游戏研发后台,基本就是开服,封禁.角色日志等,但是每个游戏提供的接口都是不一样的,所以为了统一处理提前进行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的获取

       

        如果有合适的场景，也建议大家可以考虑一下如何进行设计，在以后的开发中会带来比较大的变化，比如在下一个游戏的对接，只需要实现子类即可了