項目中應用eventbus解決的問題

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

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

真的簡單嗎？

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

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

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

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

@Autowired
private SearchService searchService;
@Autowired
private MailService mailService;
@Autowired
private 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而不是依賴實際的檢索服務，郵件服務等

@Service
public 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方法時就不會出現問題了,最後簡化後的結果如下：

@Autowired
EventListenerManager 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應用得當可以簡化程式複雜性，提高代碼可讀性，降低開發維護成本。