搞业务开发的时候，发现有一些代码的开发会让人感觉非常简便舒服，有一些代码的开发却有时候会让人感觉心智负担比较大。

逐步总结的过程中，发现让开发人员写起来感觉舒服的代码，大概率是因为当前模块与其他模块代码耦合度低，开发人员无需花费过多的精力去关注其他模块的实现，只需要专注于当前自己的功能实现即可。

而通过实地对多个项目代码设计的对比，发现都有一个非常通用的设计模式，后面再通过阅读一些经验分享文章中，发现大部分后台项目也都运用这个模式，充分实现了模块之间的解耦，极大提高了开发人员的幸福感，这个通用的设计模式便是：发布订阅模式（游戏后台通常也叫事件监听模式 or 事件分发模式）。

一、什么是发布订阅（事件监听）设计模式

发布订阅模式是一个简单通用的模式，一般来说会专门实现一个类如LogicEventDispatch的类来负责维护发布者与订阅者之间关系，也就是下图红框的位置。

发布者有事件需要抛出时，只需要把事件传给LogicEventDispatch，再由LogicEventDispatch去调用各个订阅者的OnEventUpdate函数。以此来完成一次事件的发布与通知的整个流程。

此处参考：观察者模式与订阅发布模式的区别 - 一像素 - 博客园

上面这种实现只是一种通用实现之一。为何发布订阅模式可以充分解耦模块之间的耦合呢？因为各个模块只需要关注自己需要的事件，不需要关注各个模块具体实现是什么，开发者只需要知道只要有事件抛出他就处理，其他事情与现有功能开发无关，因此各个模块实现更加内聚，责任更加清晰，由各个模块负责人各自保证自己的代码质量，尽量减少多人同时修改同一个模块的行为。

二、为何需要发布订阅（事件监听）设计模式

发布订阅（事件监听）设计模式其最大功能便是实现模块之间的解耦。解耦的意义大家的都知道好，但是好在哪呢？这就要从项目研发状况说起：

游戏需求变更快，开发量大，特别是在项目临近测试节点时，策划同学经常性会有临时新增需求（临近测试，基本各个模块功能测试同学都会逐一验证，会经常性发现有功能遗漏），这种需求一般排期都是比较紧张，开发人员很难同时兼顾开发效率与开发质量。为了开发效率，开发人员通常来说很难去完全通读原有设计，所以就会出现各式各样的if判断语句，而这种类型的代码也是最容易引发bug的地方之一。究其根源，原因有两个：

2.1 耦合重度的模块之间存在网状依赖。

大量的网状依赖，导致开发人员想新增代码的时候基本上都需要走读一遍整个调用代码后，才敢新增代码，而且也很难新增代码，耗费时间长，容易有bug。举个例子：

为了更有代入感，我们假设每个类的定位跟将游戏后台里面的类代入一下，网状依赖中，会有部分代码出现环状链路依赖，我们通过一个更具体的例子来展现：

我们假设有这样的代码，ClassA::Func1接口调用 ClassB::Func1接口， ClassB::Func1接口调用 ClassC::Func1接口， ClassCFunc1 接口调用 ClassA::Func2接口，但是ClassA::Func2接口又调用了ClassA::Func1接口，这里形成了环状调用，为什么没有造成递归？是因为ClassA::Func1里面写了if语句去阻止递归。我们可以想象一下，如果开发人员需要给ClassA::Func1新增功能代码，其心智压力之大，可见一斑。

可能有人会说这种代码怎么可能会存在，但是实际情况是，这种代码还是会存在的。只不过在项目节奏放缓时或者出现问题时会被有心的同学重构掉。但是如果一个开发人员排期很紧，那么他的开发压力就很大了，因为重构需要测试保证，开发人员没有太多的时间去做这么多的开发，那么这就意味新的临时代码又将会再次增加，即Class::Func1的if语句将会再次大概率增加。从去除网状依赖的角度出发，我们需要解耦，需要从框架去考虑尽可能解耦各个模块。

1.2 老模块功能已经不完全符合现有需求，老模块负责人不愿意改动其代码，新功能代码必须僵硬适配老模块接口，引发项目内新增大量临时适配代码。

两个模块相互耦合，在业务团队内归属两个不同的开发人员负责。举个例子，开发人员A负责角色模块，开发人员B负责角色伙伴模块。由于项目需求的更迭，角色伙伴模块除了角色模块初始化时不满足现有功能外，其他都还是满足现有需求的。这个时候开发人员A希望开发人员B可以按照现有需求修改一下角色伙伴功能模块的代码，来解决初始化不符合规范的问题。但是开发人员B认为开发人员A可以通过写一些特殊适配接口来适配他的代码，两人有可能无法互相说服。

这最后的结果大概率就是开发人员A在角色伙伴模块写了很多if语句去解决初始化不规范的问题。这又再次导致了项目临时代码的增加。从这个角度出发我们也需要尽可能实现模块之间的解耦。

三、如何设计发布订阅（事件监听）设计模式

设计一个发布订阅（事件监听）设计模式，一定要充分站在开发者使用的角度去设计这个事件模式，开发人员用起来感觉简便清晰，那么便是设计的成功。

下面介绍一种设计思路，关键在于事件参数传参的设计（下面以C++语言作为具体语言进行举例）：

// 触发事件模式，如LogicRole 触发事件：
class LogicRole {int HandleServiceA() {LogicEventDispatch::Instance().NotifyEvent(event_para);}
}// 事件分发调用
class LogicEventDispatch {int NotifyEvent() {for(auto handler : handlerList) {// step1. 派生事件先入队// step2. 处理主事件handler->OnEventUpdate(event_para);// step3. 处理派生事件队列}}
}// 事件处理, 开发人员只需要关注register操作与OnEventUpdate两个函数，然后便是自己的业务代码
class LogicRolePartner {int init() {LogicEventDispatch::Instance().RegisterEventHandler(event_a, this);LogicEventDispatch::Instance().RegisterEventHandler(event_b, this);}int OnEventUpdate(EventPara* event_para) {switch(event_para->type) {case event_a: {HandleEventA(event_para);break;}case event_b: {HandleEventB(event_para);break;}//...}}
}

四、发布订阅（事件监听）设计模式需要注意的问题

1、需要防止事件递归。事件再次触发同类型的业务需求是存在的。举个例子，为玩家添加一个道具会抛一个使用道具变化事件，同时这个道具是一个服务器自动使用的道具，那么当服务器底层将这个道具使用之后，便会再次抛出道具变化事件。或者任务完成事件会触发另外一个任务完成事件。所以事件触发抛同类型事件是有业务需求的，所以这里需要将派生事件全部先入队，处理完主事件，再处理派生事件，然后限制派生事件队列长度，当派生队列长度超过配置值时，需要立即告警（通过微信，企业微信等办公协作工具通知）以保证开发人员可以在测试环境发现问题并处理。

2、事件执行模块是无序的。使用这个模式不可以假定事件的执行顺序，举个例子某个事件会触发为玩家添加角色的功能，这个时候技能模块与角色模块同时关注这个事件，但是技能模块先接到这个事件，但是玩家角色模块还未初始化角色数据，这样会导致技能模块在处理事件的时候产生大量报错。通常来说这种情况出现比较少，可以在业务设计上来规避这个问题。

五、发布订阅（事件监听）设计模式不适用场景

1、业务设计流程要求顺序执行功能。有顺序执行的需求一般都是各种初始化逻辑，如角色初始化，因为像属性的初始化需要依赖于技能，所以这一块的逻辑代码需要按照顺序执行，直接调用各个模块的代码去执行初始化。如依次初始化角色技能，角色伙伴，角色属性等等。

2、事件处理不能包含异步流程。如果事件处理代码中包含异步流程如请求数据库，这个事件的处理需要依赖玩家Player对象的。当处理事件过程，请求数据库，当前事务或者协程切出。这个时候玩家Player对象被销毁，那么当数据库回包，协程恢复时就会找不到Player对象导致一系列报错与带来数据不一致的风险。

因为从目前项目看来，跨机（跨进程）事件的需求还是比较弱，所以框架层上的实现未考虑跨机事件的设计。但从需求上来看，如战斗单局需要与带有Player对象的gamesvr交互，或者gamesvr与一些活动服的交互，通过跨机事件来实现需求便是一个非常好的选择。所以这个是后续设计需要考虑的问题。

本文参考了一些内部文章不方便在此发出，在此仅以衷心的感谢致敬引用的文章的作者。

这里仅是一家之言，其实还有很多地方没说到，如这个设计模式的具体实现上，其实还有很多方式，包括跨机事件的设计上也是非常值得讨论的，后续再继续完善。