应用抽象的开发感想

      最近一段时间在设计新项目的服务器架构，以及服务器基础模块和框架代码的编写，目前已基本成型。

     这次是完完全全从头开始按照自己的想法来设计整个服务器的实现，经过前三年两三个项目的积累，或多或少对服务器架构及实现有了些自己的想法，包括以前觉得做的不够好，不够合理，但又无法彻底去改变的地方，这次有了机会来做一个全新的尝试。

    每天都在给自己讲一些理由，分析出每个模块，每种方案的优劣点，列出一二三四来进行比较权衡。每天又都能推翻自己昨天定下的做法，再给自己一些合理的解释。就这样，在不断的自我肯定与否定中，一个在自己看来还算合理的基础框架逐见原形。

 

    实现的细节并无多大差异，从我所了解的其他项目和公司的做法来看，基本上都是大同小异，或者说都已有了固定的实现模式，只是上层的接口与协议有些许不同，但就是这些不同反映在模块的使用上就有些不一样了。

    基础框架的设计是为上层应用服务的，所以要尽可能的方便别人使用，也就是在设计之初就要考虑到上层应用会如何去用，综合考虑所有可能的使用环境，这样才能制定出一个合理的接口方案。

 

    为了消除“不同机器上进程间通讯”与“同一机器上进程间通讯”的差异，我们使用了一个消息中间件，这个东西有些类似于云风在其<<游戏服务器组间的通讯>>一文中曾提到过的“邮局”，只是目前我们的实现还比较原始。

    “邮局”的实现并不难，难的是如何将上层应用逻辑抽象成“邮局”的使用过程。比如玩家从登录服验证通过到进入游戏场景服务器这一步，涉及到使用“邮局”将玩家的认证密钥从登录服发往游戏场景服的过程。

     整个协作流程大致为，玩家登录成功生成认证密钥，决定要去往的游戏场景服务器，登录服将认证密钥通过“邮局”寄往目标场景服务器，登录服在收到“邮件回执”后通知客户端连接目标场景服务器，客户端连接目标场景服务器并验证密钥。

     有了这么一个过程描述，“邮局”需要提供怎样的功能，各个功能接口该有怎样的参数就都一目了然了，最后如何去实现这些接口都有一些固定的套路。

 

    一组游戏服务器可能会分为多个功能独立的部分，如处理玩家登录请求的登录服，处理连接代理的网关服，处理场景逻辑的场景服和处理世界管理的世界服，以及其他可能存在的独立进程。

    这些进程处理的业务逻辑虽然都不一样，但其模块构成及运行流程却都大致相同，比如大都需要有日志功能，定时器队列，网络模块，异步数据库调用模块，脚本支持模块，服务器控制命令处理等等。

    服务器进程的处理游戏也就是顺序地处理这些模块数据，比如：

    while (1)

    {

        处理网络数据

        处理定时器队列的回调

        处理数据库异步执行完成的通知

        处理队列中的服务器控制命令

    }

    所以这些模块及游戏很显然可以抽象成业务无关的公共平台或框架，各应用进程通过派生或包含的方法来扩展业务功能，以实现最终的服务进程。

    这个框架或者公共平台的抽象也需要对各模块的实际使用环境及业务逻辑做足够的归纳整理，最终确定一个可扩展，并且易用的接口。

    其间的过程不可简单言表，每个模块的接口都会经过再三推敲，反复重构，直到找到一个自己使用起来比较顺手的框架。目前，我的这个过程还在继续中。