搞業務開發的時候，發現有一些代碼的開發會讓人感覺非常簡便舒服，有一些代碼的開發卻有時候會讓人感覺心智負擔比較大。

逐步總結的過程中，發現讓開發人員寫起來感覺舒服的代碼，大概率是因為當前模塊與其他模塊代碼耦合度低，開發人員無需花費過多的精力去關注其他模塊的實現，只需要專注于當前自己的功能實現即可。

而通過實地對多個項目代碼設計的對比，發現都有一個非常通用的設計模式，后面再通過閱讀一些經驗分享文章中，發現大部分后臺項目也都運用這個模式，充分實現了模塊之間的解耦，極大提高了開發人員的幸福感，這個通用的設計模式便是：發布訂閱模式（游戲后臺通常也叫事件監聽模式 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與一些活動服的交互，通過跨機事件來實現需求便是一個非常好的選擇。所以這個是后續設計需要考慮的問題。

本文參考了一些內部文章不方便在此發出，在此僅以衷心的感謝致敬引用的文章的作者。

這里僅是一家之言，其實還有很多地方沒說到，如這個設計模式的具體實現上，其實還有很多方式，包括跨機事件的設計上也是非常值得討論的，后續再繼續完善。