分析需求引入事件機制

使用spring的事件機制有助於對我們的專案進一步的解耦。假如現在我們面臨一個需求：
我需要在使用者註冊成功的時候，根據使用者提交的郵箱、手機號資訊，向用戶傳送郵箱認證和手機號簡訊通知。傳統的做法之一是在我們的UserService層注入郵件傳送和簡訊傳送的相關類，然後在完成使用者註冊同時，呼叫對應類方法完成郵件傳送和簡訊傳送
但這樣做的話，會把我們郵件、簡訊傳送的業務與我們的UserService的邏輯業務耦合在了一起。耦合造成的常見缺點是，我（甚至假設很頻繁的）修改了郵件、簡訊傳送的API，我就可能需要在UserService層修改相應的呼叫方法，但這樣做人家UserService就會很無辜並吐槽：你改郵件、簡訊傳送的業務，又不關我的事，幹嘛老改到我身上來了？這就是你的不對了。

對呀！根據職責分明的設計原則，人家UserService就只該管使用者管理部分的業務邏輯，你老讓它幹別人乾的事，它當然不高興了！
那該怎麼拌？涼拌？不不不。。。我們可以通過spring的事件機制來實現解耦呀。利用觀察者設計模式，設定監聽器來監聽userService的註冊事件（同時,我們可以很自然地將userService理解成了事件釋出者），一旦userService註冊了，監聽器就完成相應的郵箱、簡訊傳送工作(同時，我們也可以很自然地將傳送郵件、傳送簡訊理解成我們的事件源）。這樣userService就不用管別人的事了，只需要在完成註冊功能時候，當下老大，號令手下（監聽器）,讓它完成簡訊、郵箱的傳送工作。

spring的事件通訊常按下列流程進行

Created with Raphaël 2.1.0事件釋出者廣播事件（源）監聽器收到廣播，獲取事件源監聽器根據事件源採取相應的處理措施

事件例項分析

在這裡面，我們涉及到三個主要物件：事件釋出者、事件源、事件監聽器。根據這三個物件，我們來配置我們的註冊事件例項：

1. 定義事件源

利用事件通訊的第一步往往便是定義我們的事件。在spring中，所有事件都必須擴充套件抽象類ApplicationEvent,同時將事件源作為建構函式引數，在這裡，我們定義了發郵件、發簡訊兩個事件如下所示

/*****************郵件傳送事件源*************/
public
 
 class SendEmailEvent extends ApplicationEvent {
    //定義事件的核心成員：傳送目的地，共監聽器呼叫完成郵箱傳送功能
    private String emailAddress;

    public SendEmailEvent(Object  source,String emailAddress ) {
        //source字面意思是根源，意指傳送事件的根源，即我們的事件釋出者
        super(source);
        this.emailAddress = emailAddress;
    }

    public String getEmailAddress() {
        return emailAddress;
    }
}
/*****************簡訊傳送事件源*************/
public class sendMessageEvent extends ApplicationEvent {

    private String phoneNum;

    public sendMessageEvent(Object  source,String phoneNum ) {
        super(source);
        this.phoneNum = phoneNum;
    }

    public String getPhoneNum() {
        return phoneNum;
    }
}

2. 定義事件監聽器

事件監聽類需要實現我們的ApplicationListener介面，除了可以實現ApplicationListener定義事件監聽器外，我們還可以讓事件監聽類實現SmartApplicationListener（智慧監聽器）介面，。關於它的具體用法和實現可參考我的下一篇文章《spring學習筆記(14)趣談spring 事件機制[2]：多監聽器流水線式順序處理 》。而此外，如果我們事件監聽器監聽的事件型別唯一的話，我們可以通過泛型來簡化配置。
現在我們先來看看本例定義：

public class RegisterListener implements  ApplicationListener  {
    /*
    *當我們的釋出者釋出時間時，我們的監聽器收到訊號，就會呼叫這個方法
    *我們對其進行重寫來適應我們的需求
    *@Param event:我們的事件源
    */
    @Override
    public void onApplicationEvent(ApplicationEvent event) {
        //我們定義了兩個事件：發簡訊，發郵箱，他們一旦被髮布都會被此方法呼叫
        //於是我們需要判斷當前event的具體型別
        if(event instanceof SendEmailEvent){//如果是發郵箱事件
            System.out.println("正在向" + ((SendEmailEvent) event).getEmailAddress()+ "傳送郵件......");//模擬傳送郵件事件
            try {
                Thread.sleep(1* 1000);//模擬請求郵箱伺服器、驗證賬號密碼，傳送郵件耗時。
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("郵件傳送成功！");
        }else if(event instanceof sendMessageEvent){//是發簡訊事件
            event = (sendMessageEvent) event;
            System.out.println("正在向" + ((sendMessageEvent) event).getPhoneNum()+ "傳送簡訊......");//模擬傳送郵簡訊事件
            try {
                Thread.sleep(1* 1000);//模擬傳送簡訊過程
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("簡訊傳送成功！");
        }
    }

}
/******************通過泛型配置例項如下******************/
public class RegisterListener implements  ApplicationListener<SendEmailEvent>  {//這裡使用泛型
    @Override//因為使用了泛型，我們的重寫方法入參事件就唯一了。
    public void onApplicationEvent(SendEmailEvent event) {
        .....
    }
    ....
}

3. 定義事件釋出者

事件傳送的代表類是ApplicationEventPublisher我們的事件釋出類常實現ApplicationEventPublisherAware介面，同時需要定義成員屬性ApplicationEventPublisher來發布我們的事件。
除了通過實現ApplicationEventPublisherAware外，我們還可以實現ApplicationContextAware介面來完成定義，ApplicationContext介面繼承了ApplicationEventPublisher。ApplicationContext是我們的事件容器上層，我們釋出事件，也可以通過此容器完成釋出。下面使用兩種方法來定義我們的釋出者
在本例中，我們的時間釋出者自然就是我們的吐槽者，userService：

/**********方法一：實現除了通過實現ApplicationEventPublisherAware介面************/
public class UserService implements ApplicationEventPublisherAware {

    private ApplicationEventPublisher applicationEventPublisher;//底層事件釋出者

    @Override
    public void setApplicationEventPublisher(//通過Set方法完成我們的實際釋出者注入
            ApplicationEventPublisher applicationEventPublisher) {
        this.applicationEventPublisher = applicationEventPublisher;
    }

    public void doLogin(String emailAddress,String phoneNum) throws InterruptedException{
        Thread.sleep(200);//模擬使用者註冊的相關業務邏輯處理
        System.out.println("註冊成功！");
        //下列向用戶傳送郵件
        SendEmailEvent sendEmailEvent = new SendEmailEvent(this,emailAddress);//定義事件
        sendMessageEvent sendMessageEvent = new sendMessageEvent(this, phoneNum);
        applicationEventPublisher.publishEvent(sendEmailEvent);//釋出事件
        applicationEventPublisher.publishEvent(sendMessageEvent);
    }
    //...忽略其他使用者管理業務方法
}
/**********方法二：實現除了通過實現ApplicationContext介面************/
public class UserService2 implements ApplicationContextAware {

    private ApplicationContext applicationContext;

    @Override
    public void setApplicationContext(ApplicationContext applicationContext)
            throws BeansException {
        this.applicationContext = applicationContext;
    }

    public void doLogin(String emailAddress,String phoneNum) throws InterruptedException{
        Thread.sleep(200);//模擬使用者註冊的相關業務邏輯處理
        System.out.println("註冊成功！");
        //下列向用戶傳送郵件
        SendEmailEvent sendEmailEvent = new SendEmailEvent(this,emailAddress);//定義事件
        sendMessageEvent sendMessageEvent = new sendMessageEvent(this, phoneNum);
        applicationContext.publishEvent(sendEmailEvent);//釋出事件
        applicationContext.publishEvent(sendMessageEvent);
    }
    //...忽略其他使用者管理業務方法
}

4. 在IOC容器註冊監聽器

<!-- 在spring容器中註冊事件監聽器，
應用上下文將會識別實現了ApplicationListener介面的Bean,
並在特定時刻將所有的事件通知它們 -->
<bean id="RegisterListener" class="test.event.RegisterListener" />
<!-- 註冊我們的釋出者，後面測試用到 -->                    
<bean id="userService" class="test.event.UserService" />

5. 測試方法

public static void main(String args[]) throws InterruptedException{
    ApplicationContext ac = new ClassPathXmlApplicationContext("classpath:test/event/event.xml");
    UserService userService = (UserService) ac.getBean("userService");
    Long beginTime = System.currentTimeMillis();
    userService.doLogin("[email protected]","12345678911");//完成註冊請求
    System.out.println("處理註冊相關業務耗時" + (System.currentTimeMillis() - beginTime )+ "ms");
    System.out.println("處理其他業務邏輯");
        Thread.sleep(500);//模擬處理其他業務請求耗時
    System.out.println("處理所有業務耗時" + (System.currentTimeMillis() - beginTime )+ "ms");
    System.out.println("向客戶端傳送註冊成功響應");
}

6. 測試結果及分析

呼叫上面測試方法，控制檯列印資訊

註冊成功！
正在向[email protected]傳送郵件……
郵件傳送成功！
正在向12345678911傳送簡訊……
傳送成功！
處理註冊相關業務耗時2201ms
處理其他業務邏輯開始..
處理其他業務邏輯結束..
處理所有業務耗時2701ms
向客戶端傳送註冊成功響應

在本例中，我們通過事件機制完成了userService和郵件、簡訊傳送業務的解耦。但觀察我們的測試結果，我們會發現，這樣的使用者體驗真是糟糕透了：天吶，我去你那註冊個使用者，要我等近3秒鐘！這太久了！
為什麼會這麼久？我們根據方法分析：
1. 註冊查詢資料庫用了200ms(查詢使用者名稱、郵箱、手機號有沒被使用，插入使用者資訊到資料庫等操作)
2. 傳送郵件用了1000ms
3. 傳送簡訊用了1000ms
4. 處理其他業務邏輯（儲存使用者資訊到session,其他資訊資料處理等）
第1,4步的時間耗損我們很難優化，但2,3步是主要耗時的地方，我們能不能想辦法把它縮減掉了，它把我們的正常的業務處理堵塞了。什麼？堵塞，想到堵塞，我們會很自然地想到非堵塞，那就通過非同步來完成2,3唄！

7. 非同步拓展。

在spring3以上，拓展了自己獨立的時間機制，我們可以使用@Async來完成非同步配置。
首先我們需要在我們的IOC容器增加

<!--先在名稱空間中增加我們的task標籤，注意它們的新增位置
xmlns 多加下面的內容：
xmlns:task="http://www.springframework.org/schema/task"
然後xsi:schemaLocation多加下面的內容
http://www.springframework.org/schema/task
http://www.springframework.org/schema/task/spring-task-3.0.xsd
-->
<!-- 我們的非同步事件配置，非常簡單 -->
 <!--開啟註解排程支援 @Async @Scheduled-->  
<task:annotation-driven/>       

然後在我們的事件監聽器中新增@Async註解

/***************我們可以在類名上新增****************/
@Async
public class RegisterListener implements  ApplicationListener  {
    ......
}
/****************也可以在方法體上新增************/
@Async
public class RegisterListener implements  ApplicationListener  {

    @Override
    public void onApplicationEvent(ApplicationEvent event) {
        .....
    }
}

然後，再呼叫我們的同樣的測試方法，這次我們的結果變成：

註冊成功！
正在向[email protected]傳送郵件……
處理註冊相關業務耗時201ms ————此時郵件傳送還沒有結束，和郵件傳送非同步了
正在向12345678911傳送簡訊….. ————–簡訊傳送和郵件傳送和主業務處理程式都非同步了！
處理其他業務邏輯開始..
處理其他業務邏輯結束..
處理所有業務耗時701ms
向客戶端傳送註冊成功響應 ——客戶端耗時701ms就收到響應了。
郵件傳送成功！ —-這個時候郵箱才發完
簡訊傳送成功！

從以上的測試結果我們，我們的郵箱傳送和簡訊傳送都分別單獨地非同步完成了，大大縮短了我們主業務處理事件，也提高了使用者體驗

小結

1. 從本例可以看出，不同業務功能的生硬組合，會出現邏輯處理混亂的嚴重耦合現象，比如userService類既處理自己的使用者邏輯，還要處理郵箱等傳送的邏輯，這是不是也意味著，如果以後我們拓展更多的功能，我們的userService類還要出現更多的邏輯處理，來個大雜燴？，這同時還可能會為我們主要業務處理帶來不必要的阻塞。當然，為了防止阻塞，我們還可以建立新的執行緒來非同步，但這樣原來的類就顯得更加雜亂臃腫了。
2. 使用spring事件機制能很好地幫助我們消除不同業務間的深耦合關係。它強大的任務排程還能幫助我們簡潔地實現事件非同步。

例項程式碼下載