最近设计的反思

Posted 2020-06-26 lifehacker

最近完成了邮箱的功能。

 

邮箱的设计参考了mmzb的设计，基于一套msgsrv来实现。msgsrv是一个消息中转的服务，这个服务是为了简化玩家之间消息传递的过程。比如邮箱要向一个离线玩家发信，为了避免对离线玩家的数据进行修改，会通过msgsrv发送到玩家对应的msgbox里。玩家上线后，会自动查询自己的msgsrv，检索未读消息。当玩家上线时，会主动在msgsrv中发起订阅。每当有新的消息进入，msgsrv会直接发送到玩家所在的agent上，实现实时通知。唯一例外的情况，是全局消息的发送。一条全局消息发送的时候，只是向一个全局的队列里插入一份数据。玩家只会在登录时检索一次这个全局队列，并记住自己的检索位置。缺点是全局消息的通知不及时，需要玩家离线再上线才能收到。需要实时的消息，可以通过聊天系统解决。

 

这个设计相对来说还是比较简单的。但是，这个功能的提交，涉及到46个文件。我提交Pull Request的时候，自己都惊到了。当然，这其中并不是全部都是代码的修改。这些修改可以简单的分为三块。一块，是配置之类的修改，比如新增服务的参数，新增服务的数据存储对应的数据库定义，玩家数据库对象新增的结构描述。这里占了7个文件。第二块，是在lualib里提供的新api，为其他服务提供新功能的入口。其中还包含一些趁手的工具函数，方便以后功能的开发。这里占了8个文件。第三块是大头，实现了msgsrv的逻辑部分，以及邮箱的业务代码。这一块有31个文件，是这个PR的主要部分。

 

除了玩家自身的成长系统外，其他系统基本都涉及到两部分。一部分，是挂在玩家的agent身上的，另一部分，则是对公有数据的修改。先看看agent的部分。agent身上需要有对应服务的api，供客户端通过sproto协议来远程调用。还需要有对应的api，供相应的skynet内服务的调用。一般还会有一套额外的gm api，供客户端进行测试的时候使用。这三组api，功能覆盖的面差不多，最终都会操作玩家身上的数据，通知到玩家的客户端。就这次提交的邮件PR来看，这些api占住了7个文件。玩家数据部分的管理，是由几个类完成的。这里占用了3个。总的来看，agent身上一共改了15个文件，稍微有点多。

 

剩下的文件，集中在对公有数据的修改上，即msgsrv的主体部分。其中有4个是用于执行功能测试的测试脚本，暂且不提。剥开msgsrv，首先是一层command，然后是对全局消息的管理器，对个人msgbox的管理器，对这两者的管理器，以及管理msgsrv服务的启动脚本、退出脚本、gm指令。这里的优化空间应该比较大，按照CRUD的四字法划分，个人消息管理器和全局消息管理器都有着多个“R”，多个“U”，正交性不够好，还要锤炼一下。

 

优化现有的设计，主要目标是希望修改能够更简洁而清晰。不再因为添加一个小小的功能，就产生数十个文件的修改。对我来说，涉及的文件数量太多，就经常记不住细节，导致api改动的时候，常常出现漏改漏测。目前看到的可以优化的地方，就是各种自发现。比如lualib里面提供一个通用的调用api封装，只要传入方法名和服务名，就能自动调用对应服务的command api。数据结构的定义，能够实现自动发现，不需要修改引用文件。（待续）