項目中應用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應用得當能夠簡化程序複雜性，提升代碼可讀性，下降開發維護成本。