某ARPG网页游戏djws服务器端（java）程序结构分析

一、通信架构：
基于Mina 2.0.4 

• MdcInjectionFilter：用于记录相关信息到日志中，以便开发者进行bug诊断。
• ByteAttackFilter:限制 最大连接数，最大活动连接数，BLOCKED_IPS，BLOCKED_PLAYER_IDS（虽然进行了这个判断，但是没有获取到playerId,所以不起过滤作用），字节数防洪
• CmdAttackFilter：BLOCKED_IPS，BLOCKED_PLAYER_IDS（不起过滤作用），数据包防洪
• ProtocolCodecFilter(ProtocolCodecFactory)：用于消息的解码和编码ProtocolCodecFactory包装了decoder和encoder的实现RequestDecoder和ResponseEncoder。
  其中：
  1.RequestDecoder负责处理消息断包、粘包 和反序列化。支持两种反序列化方式：AMF3反序列化成ASObject；java class反序列化成java object。
  2.ResponseEncoder负责消息序列化、封包，可序列化对象包括IoBuffer、byte[]和Response。支持两种序列化方式：AMF3和java class序列化。注：在djws-server中，response消息 可序列化对象只有Response。
• ExecutorFilter(OrderedThreadPoolExecutor)：配置了IoHandler处理请求消息的线程池。对于一个session，线程池将按io event/request message先后顺序进行处理。
• IoHandler：request消息处理器。WarriorsServerHandler的职能：
  1.收到消息时，IP黑名单的过滤，匿名cmd的校验（有的命令必须是登陆过的用户才能发送）、管理员必须为mis客户端；
  2.转发request到ServerHanlder中（之后再由ServerHanlder调用Dispatcher转发器，根据消息类型(moduleId),把消息转发给相应的handler模块处理）；
  3.session关闭时，触发ContainerFacade中的登出listener（并删除玩家数据）；session打开时，判断是否是MIS ip和管理员配置的open ip。
  
  二、Request处理过程
  Module与Handler一一对应。在一个handler中，包含若干个cmd。 Cmd与Invoker一一对应。
  
   之后invoker从ASObject中读取请求数据，调用封装好的facades和managers进行业务处理。

三、消息格式：基于二进制字节流

修正：最后一张图是response protocol，其中的最后一个字段也是respoonse value:object
四、业务架构：
Module:

public static final int ADMIN = 10000;
  public static final int CHAT = 1;
  public static final int CHANNEL = 2;
  public static final int USER = 3;
  public static final int MAP = 4;
  public static final int TASK = 5;
  public static final int PROPS = 6;
  public static final int SKILL = 7;
  public static final int FIGHT = 8;
  public static final int SHOP = 9;
  public static final int FRIENDS = 10;
  public static final int TEAM = 11;
  public static final int ALLIANCE = 13;
  public static final int MERIDIAN = 14;
  public static final int LOOT = 15;
  public static final int TRAIN = 16;
  public static final int FLYSHOES = 17;
  public static final int CAMP = 18;
  public static final int DUNGEON = 19;
  public static final int PET = 20;
  public static final int MORTAL = 21;
  public static final int HORSE = 22;
  public static final int TRADE = 23;
  public static final int MARKET = 24;
  public static final int TITLE = 25;
  public static final int DUNGEONTASK = 26;
  public static final int NOTICE = 27;
  public static final int RANK = 28;
  public static final int LOTTERY = 29;
  public static final int VIP = 30;
  public static final int GIFT = 31;
  public static final int TREASURE = 32;
  public static final int ACTIVE = 33;
  public static final int CAMP_BATTLE = 34;
  public static final int MAIL = 35;
  public static final int BATTLE_FIELD = 36;
  public static final int ACHIEVE = 37;
  public static final int RECHARGE_GIFT = 38;

 

五、程序组织结构/分层：

1.通用组件 （jar）

eventBus、dbservice、 resourceService 、SessionManager 、Scheduler、Pusher

2.game common：

--Service(ResourceAdapter )、voFactory、--Pusher、astar、commonConstant(common result code)

3.单一模块 内部结构

 

为了提高复用性，--Pusher 一般只在façade层调用。

金字塔的任何一层，可能会调用通用组件、common 模块和其他模块的facade、manager。

 

4.包结构组织还是很清晰的，值得借鉴：

.......
 

 

评论

1 楼 hepeng19861212 2014-09-15  

问：CacheServiceImpl中，COMMON_CACHE和ENTITY_CACHE的区别？
答：ENTITY_CACHE仅用于存放entity，即项目中BaseModel的所有子类的实例。而common cache之所以就是common的，是因为它可以存储所有的数据结构，比如Integer，Long，Map<>，List<>等等结构。
    此外，ENTITY_CACHE本身就支持缓存过期时间。但是common cache其实也是支持entity cache的所有特性，就是说common cache中也可以放入CacheObject，从而支持缓存entity、过期时间的特性。
    使用者在使用cacheService和CachedServiceAdpter两套api时，就要根据上述原则来使用了。