怎樣實際項目中運用責任鏈模式

1 模式概要

1.1 簡介

• 責任鏈模式爲請求建立一個接收者對象鏈，每一個接收者都包含對另外一個接收者的引用，若是一個對象不能處理該請求，那麼它會把請求傳給下一個接收者，依此類推
• 責任鏈模式避免了請求的發送者和接收者耦合在一塊兒，讓多個對象都有可能接收請求，將這些對象連成一條鏈，而且沿着這條鏈傳遞請求，直到有對象處理它爲止。

1.2 責任鏈模式優缺點

優勢

下降耦合度。它將請求的發送者和接收者解耦

簡化了對象，使得對象不須要知道鏈的結構 

加強給對象指派職責的靈活性，容許動態地新增或者刪除責任鏈 

增長新的請求處理類方便

缺點

不能保證請求必定被接收；

系統性能將受到必定影響，調試時不方便，可能會形成循環調用

2 模式結構

2.1 對象定義

Handler（抽象處理者）  ： 定義一個處理請求的接口，提供對後續處理者的引用 

ConcreteHandler（具體處理者）  ： 抽象處理者的子類，處理用戶請求，可選將請求處理掉仍是傳給下家；在具體處理者中能夠訪問鏈中下一個對象，以便請求的轉發

2.2 類圖及設計

責任鏈

代碼詳解：

抽象處理者

具體處理者 

在當前處理者對象沒法處理時，將執行權傳給下一個處理者對象

Client  客戶端調用

ifelse 

2.3 適用場景：

• 有多個對象能夠處理同一個請求，具體哪一個對象處理該請求由運行時刻自動肯定
• 在不明確指定接收者的狀況下，向多個對象中的某一個對象提交一個請求
• 可動態指定一組對象的處理請求

3 Spring中的過濾器

咱們來分析Spring中Filter的 加載流程和執行流程

3.1 初始化流程

初始化過濾器加載數據流以下：

filter初始化加載時序圖

關鍵性代碼

configure() 

無論是數據走哪裏，最終會經過 System.arraycopy  數組擴容，增長過濾器信息到  private FilterMap[] array  這個數組中。 

最後調用StandardContext類中的  filterStart()  方法完成過濾器的初始化

3.2 執行過程

主要分兩步， 建立過濾器責任鏈 和 執行責任鏈

3.2.1 建立過程

建立filterChain方法主要在 ApplicationFilterFactory.createFilterChain(request, wrapper, servlet)  中，部分代碼講解：

在StandardWrapperValue類的 invoke()  方法中調用ApplicationFilterChai類的  createFilterChain()  方法 

在ApplicationFilterChai類的  createFilterChain()  方法中調用ApplicationFilterChain類的  addFilter()  方法 

在ApplicationFilterChain類的  addFilter()  方法中給ApplicationFilterConfig數組賦值

生成調用鏈

3.2.2 執行責任鏈

調用ApplicationFilterChain的 doFilter()  方法中最後會調用一個  internalDoFilter()  方法，目的就是執行ApplicationFilterChain中的所有過濾器，從代碼中能夠發現它調用了  doFilter  ，而在  doFilter  又會調用  internalDoFilter  從而使全部Filter都得以調用

這樣，一個完整的過濾器鏈就造成，而後進行調用

4 項目中的實際運用

業務場景

咱們在項目中使用了阿里的MQ消息中間件，來加快請求的響應時間和異步解耦處理。RocktMQ主要能夠按Topic來分區，而後按Tag分組，不一樣的業務區分不一樣的 tag 

好比： 在此我向你們推薦一個架構學習交流裙。交流學習裙號：687810532，裏面會分享一些資深架構師錄製的視頻錄像

短信類的消息 messageTag  
手機推送消息 pushTag  
延時任務消息 delayTag  

等等。。。

常規寫法

ifelse 

具體設計方案以下：

設計UML類圖

類圖

抽象公共監聽器  ，主要用到了單例模式獲取常量

具體監聽器  ，監聽器主要用於MQ監聽消費Topic

consume() 

抽象處理者

具體處理者  :推送消息Handler

具體處理者  :延時訂單處理Handler

模式工廠  HandlerFactory

getHandlerResponsibilityChain() 

客戶端調用

getHandlerResponsibilityChain()