一、響應式服務編程以及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。