一、響應式服務編程以及Flower框架
響應式服務編程有以下幾個特點:
-
即時響應,應用的調用者可以即時得到響應,無需等到整個應用程序執行完畢,也就是說應用調用是非阻塞的。
-
回彈性,當應用程序部分功能失效的時候,應用系統本身能夠進行自我修復,保證正常運行,保證響應,不會出現系統崩潰和宕機。
-
彈性,能夠對應用負載壓力做出響應,能夠自動伸縮以適應應用負載壓力,根據壓力自動調整自身的處理能力,或者根據自身的處理能力,調整進入系統中的訪問請求數量。
-
消息驅動,功能模塊之間、服務之間,通過消息進行驅動,完成服務的流程。
Flower如何解決這個問題的?
2
對 Flower 而言,只需要有限的幾個線程,就可以完成全部的用戶請求操作。當併發用戶到達應用服務器的時候,Flower 只需要極少的容器線程就可以處理所有的併發用戶請求。這個線程並不會執行真正的業務操作,它只是將用戶的請求變爲請求對象以後,將請求對象異步交給 Flower 的 Service 去處理,自身立刻就返回。因爲容器線程不做太多的工作,所以極少的線程就可以滿足高併發的用戶的請求,用戶的請求不會被阻塞,不會因爲線程不夠而無法處理。
用戶請求交給 Flower 的 Service 對象以後,Service 之間依然是使用異步的消息通訊的方式進行調用,Service 之間也不會直接進行阻塞式的調用。一個 Service 完成業務邏輯處理計算以後,會返回一個處理結果,這個結果以消息的方式異步發送給它的下一個 Service,Service 之間使用了 AKKA Actor 進行消息通信,也是隻需要有限的幾個線程就可以完成大量的 Service 處理和消息傳輸。
上面提到 Web 應用主要的線程阻塞,是因爲數據庫的訪問導致的線程阻塞。Flower 支持異步數據庫驅動,用戶請求數據庫的時候,將請求提交給異步數據庫驅動,立刻就返回,不會阻塞當前線程,異步數據庫訪問連接遠程的數據庫,進行真正的數據庫操作,得到結果以後,將結果以異步回調的方式發送給 Flower 的 Service 進行進一步的處理,這個時候依然不會有線程被阻塞。也就是說使用 Flower 開發的系統,在一個典型的 Web 應用中,幾乎沒有任何地方會被阻塞,所有的線程都可以被不斷複用,有限的線程就可以完成大量的併發用戶請求,從而極大地提高了系統的吞吐能力,也極大地提高了系統的響應時間。
主要應用了AKKA的Actor進行通信。那麼 AKKA Actor 又是如何實現異步消息通信的呢?下面是 AKKA Actor 架構圖。
3
定義:
- 每一種模式都描述了一種問題的通用解決方案。這種問題在我們的環境中,不停地出現。
- 設計模式是一種可重複使用的解決方案。
一個設計模式的四個部分:
模式的名稱 - 由少量的字組成的名稱,有助於我們表達我們的設計。
待解問題 - 描述了何時需要運用這種模式,以及運用模式的環境(上下文)。
解決方案 - 描述了組成設計的元素(類和對象)、它們的關係、職責以及合作。但這種解決方案是抽象的,它不代表具體的實現。
結論 - 運用這種方案所帶來的利和弊。主要是指它對系統的彈性、擴展性和可移植性的影響。
設計模式的分類
從功能分
創建模式(Creational Patterns)
☞ 對類的實例化過程的抽象。
結構模式(Structural Patterns)
☞ 將類或對象結合在一起形成更大的結構。
行爲模式(Behavioral Patterns)
☞ 對在不同的對象之間劃分責任和算法的抽象化。
從方式分:類模式和對象模式
下面分別講述了一些設計模式。有大量的參考資料,不再贅述。
以JUnit爲例,講述了工廠模式。以Spring爲例講述了工廠模式和單例模式。重點是Spring的DI和IoC的實現。
作爲前端框架,Spring也不可避免的使用了MVC模式。
三、Panthera代碼解析
Panthera是一種大數據倉庫引擎,分析了這個引擎中的組合模式和裝飾器模式。回顧了抽象語法樹 AST。