項目中應用eventbus解決的問題，項目eventbus

項目中應用eventbus解決的問題，項目eventbus

  在項目開發過程中，往往有些功能表面看起來簡單，但實際開發的結果非常複雜，仔細分析下原因發現很多都是因為附加了許多的額外功能。

  真的簡單嗎？

  比如我們對一個電商平台的商品資料做修改的功能來講，其實非常簡單，無非就是運營人員在管理平台中對商品進行修改資料，然後點擊提交，核心功能的確很簡單，但可能有人會要求對商品的修改都需要增加動作記錄，還有人提出需要在商品資料修改後自動去更新檢索系統中的資料，有人提要在商品資料修改後需要經過審核人的審核才會生效，還有人提需要給運營人員發郵件通知等等，如此一來這個商品修改的功能就不是那麼簡單了，它除了完成自己的使命，還需要去調用其它的服務來完成，活動類似如下：

 橫向的主流程，上下四個小方框是附加功能，複雜的原因包含如下兩點：

•   附加功能導致功能開點變多，工作量加大
•   附加功能導致程式邏輯複雜，在程式中需要去訪問其它的服務，還需要考慮資料完整性，效能，服務依賴等各種問題。

  剛開始我們在項目中開發時，使用的就是最簡單的強耦合去直接調用服務，比如在調用完資料儲存的方法後，去調用logService的log方法記錄日誌，調用esService的方法去更新檢索系統，調用mailService的方法去發郵件，這樣會導致我們的productService強耦合這些與商品儲存邏輯沒有直接關聯的服務，這樣看起來商品儲存的功能變得不那麼單純，也就是我們文前提到的複雜了，會出現類似代碼：

@Autowiredprivate SearchService searchService;@Autowiredprivate MailService mailService;@Autowiredprivate ProductLogService productLogService;//如下下儲存商品的程式碼片段itemDao.save(product);searchService.update(product.getId());mailService.post(product.getId());logService.log(product.getId());

  問題如下：

• 對無業務直接關聯的服務強耦合
• 可能存在效能問題，比如你需要關心郵件發送是否會影響主流程
• 代碼可讀性變差，過多的邏輯容易導致分不清主體核心功能

  如果解決呢？有一個設計模式可以解決，那就是觀察者模式，之前學習.net時專門寫過一篇(老生常談：觀察者模式)，裡面提到有傳統的實現方式以及事件機制，事件機制的實現比較簡單一些，這裡我們在解決這個問題時引用了guava組件中提供的eventbus，它與之前那篇觀察者模式的實現很相似，看下面這張圖，功能之間沒有錯綜複雜的依賴。

  註：guava的eventbus是個進程內層級的，無法跨進程，後面我抽時間再整理下基於訊息佇列的分布式事件總結。

 

  這裡我並不介紹如何使用EventBus，而是重點來說明我們項目中對它的應用，哪些是做的不好的地方。

  第一：要有觀察者，這裡我們根據不同的業務封裝不同的觀察者，下面是更新檢索系統資料的類

@Service  public class SearchEventListener {    @Autowired()    ProductUpdateMgr productSearchUpdateMgr;    private final static Logger logger = LoggerFactory.getLogger(SearchEventListener.class);    @Subscribe    public void listen(String itemLegacyId) {        try        {            productSearchUpdateMgr.markProductDirty(itemLegacyId);        }        catch(Exception ex)        {            logger.error("更新檢索異常:" + ex.getMessage() + ex.getStackTrace());        }    }    }

  第二：需要有將觀察者註冊到eventbus中去，我們專門寫了一個類來做這件事情，完成兩件事情：

• 註冊觀察者到eventbus中
• 進一步封裝post方法以便調用者以服務形式調用，讓productService依賴eventbus而不是依賴實際的檢索服務，郵件服務等

@Servicepublic class EventListenerManager {    EventBus mmsProductEventBus;    EventBus mmsItemEventBus;    EventBus mmsSearchEventBus;    EventBus mmsRebuildAllSearchEventBus;    EventBus mmsCommonLogEventBus;    @Autowired    ItemEventListener itemListener;    @Autowired    ProductEventListener productListener;    @Autowired    SearchEventListener searchListener;    @Autowired    RebuildAllSearchEventListener rebuildAllSearchListener;    @Autowired    MmsCommonLogEventListener commonLogListener;    @PostConstruct    private void init() {        mmsProductEventBus = new EventBus();        mmsItemEventBus = new EventBus();        mmsSearchEventBus = new EventBus();        mmsRebuildAllSearchEventBus=new EventBus();        mmsCommonLogEventBus=new EventBus();        mmsItemEventBus.register(itemListener);        mmsProductEventBus.register(productListener);        mmsSearchEventBus.register(searchListener);        mmsRebuildAllSearchEventBus.register(rebuildAllSearchListener);        mmsCommonLogEventBus.register(commonLogListener);    }    public void notifyItemLog(Long itemId) {        mmsItemEventBus.post(itemId);    }    public void notifyProductLog(Long productId) {        mmsProductEventBus.post(productId);    }    public void notifyUpdateSearch(String itemLegacyId) {        mmsSearchEventBus.post(itemLegacyId);    }    public void notifyRebuildAllSearch() {        mmsRebuildAllSearchEventBus.post("");    }    public void notifyAddCommonLog(MmsCommonLogModel log) {        mmsCommonLogEventBus.post(log);    }} 

 

  上面的實現以及我們在剛學習使用guava eventbugs時遇到哪些問題呢？
  問題一：為什麼上面的代碼有這麼多的eventbus而不是一個呢？注意下enventbus的post方法，我們再看下它的源碼：它是根據參數的類型來找觀察者註冊的方法的，而我們寫的觀察者類中的方法中的參數都是一些primitive類型的，總共有10個左右方法，要想根據參數類型來正確的在一個eventbus中識別調用哪個方法，是比較困難的。
 

public void post(Object event) {    Set<Class<?>> dispatchTypes = flattenHierarchy(event.getClass());    boolean dispatched = false;    for (Class<?> eventType : dispatchTypes) {      subscribersByTypeLock.readLock().lock();      try {        Set<EventSubscriber> wrappers = subscribersByType.get(eventType);        if (!wrappers.isEmpty()) {          dispatched = true;          for (EventSubscriber wrapper : wrappers) {            enqueueEvent(event, wrapper);          }        }      } finally {        subscribersByTypeLock.readLock().unlock();      }    }    if (!dispatched && !(event instanceof DeadEvent)) {      post(new DeadEvent(this, event));    }    dispatchQueuedEvents();  }

  如何解決？可以針對每個方法的參數封裝一個類，比如更新檢索的方法參數叫SearchChangeEvent，發送審核郵件的參數叫ApprovalChangeEvent等等，這樣我們就可以將所有的觀察者註冊到一個eventbus中，調用post方法時就不會出現問題了,最後簡化後的結果如下：

@AutowiredEventListenerManager eventManager;//如下下儲存商品的程式碼片段itemDao.save(product);eventManager.post(new SearchChangeEvent(product.getId));eventManager.post(new MailChangeEvent(product.getId));eventManager.post(new LogChangeEvent(product.getId));

  問題二：效能問題，之前有提到過附加的功能會導致原本單純的事物不單純，比如調用某些服務時可能影響整體效能，當時我們想當然的認為使用了enventbus本身就是非同步，其實如果用eventbus它是同步的，要想使用非同步需要使用這個類來完成AsyncEventBus。

  問題三：強耦合問題，由於有了EventListenerManager,我們在具體業務中就不需要依賴不直接相關的服務了，只需要依賴EventListenerManager這個看起來與任務業務都無關的管理類就可以了。

  通過實際項目中對eventbus的應用來分析它能解決的問題以及當初應用有待提高的地方。很顯示eventbus應用得當可以簡化程式複雜性，提高代碼可讀性，降低開發維護成本。