文章目錄
背景
由於livy官方文檔並不是很全，工作又要用到，所以，需要對livy進行源碼剖析，並解決工作用遇到的一些問題所要做的
本人對其進行了擴展分析，並對每個類進行了細分與功能的描述，本問從livy的啓動階段以及用戶交互階段（本文只對交互式對象進行分析，批量處理就很容易自行彌補了）分別進行解讀，目前是以0.8.0-incubator版本進行的解讀（更新到2019-12-05日）
這裏感謝 前行中632 博主提供的時序圖，利用時序圖概念，對這個框架進行了比較宏觀的理解。
希望讀者在閱讀如下內容的時候，對store， servlet，manager，listener，filter，batch，interactive這些英文單詞有個比較感性的認識。store就是存儲東西的地方，servlet就是小服務一般對應到的是web服務器中的servlet專門處理請求的服務部門，manager，就是管理者，管理什麼就看你要管理什麼了。listener，監聽器，在web服務器中，監聽器對象在整個應用生命週期中有且只有一份，且在應用開啓的時候，會觸發具體的初始化事件，方便開發者自定義一些功能，filter過濾器，其實這個過濾器是針對web每次請求都會進行過濾的，對於哪些會過濾，這裏就不細說了，batch就是批處理，其實對應的是spark中的一次可以終結的任務，interactive，就是交互式的意思，在spark中的spark-shell就是類似於交互式的。
啓動階段
livy啓動圖 ，讀者先仔細看看這個東東，結合時序圖，依次順序的讀
注1:由圖中所示帶圈圈的，均表示對象單例實例，也就是在啓動階段是全局只有一份。在後續的與livy交互過程中是不會生成多例的
注2： 要特別留意深顏色的單例實例，因爲這些實例與用戶交互階段息息相關
注3： 爲什麼有兩條虛線呢？其實個人覺得這兩條虛線也就是注入操作完全可以由manager執行，不過這也不傷大雅，因爲軟件的升級維護，是在不斷進行的，可以肯定在新版本中，會去掉這些虛線的，確保每個對象職責單一原則，這裏按下不表
livyServer [livy-server模塊]
該類是livy服務的啓動入口，通過如下命令開啓livy服務
bin/livy-server start
webserver
這個是livyServer啓動類啓動的一個由jetty框架編寫的web服務單例對象，這個服務主要的功能就是注入一些小服務（servlet），用來與用戶或者客戶端進行rest-api交互用的，同時也會注入一些filter用來做安全驗證方面的過濾，
小服務分類
小服務主要的作用是注入到web服務中的並能與用戶（客戶端）進行交互的容器對象，經過圖中可以看到在 livy啓動階段會生成兩個manager單例，一個是用來管理interactiveSessions的，另一個是用來管理batchSessions的，這裏的sessions在 用戶階段中會有詳細剖析，這裏只要簡單理解爲，當一個瀏覽器向webserver服務發起一個請求的時候，就會在整個應用中生成對用的sessions實例，後續的所有交互使用都是通過這個這個創建的session進行交互的，因此，需要有個管理者（manager）對其進行管理，確保這個管理者在LivyServer應用中有且只有一份，不然不好管理的（試想 一個員工既被一個領導管理，又被另一個領導管理，到時候要分配工作的時候，這兩個領導肯定會相互掐…）。兩個manager同時共用一份sessionStore對象，這個sessionStore就類似於對工作人員管理的檔案室，所有檔案信息都會放入這個sessionStore中，確保這個檔案室有且只有一個，這個是機密文檔，一定只能由一個檔案室管理。
接下來對這些小服務進行功能上的剖析
interactiveSessionServlet
這個是用戶發起 請求的時候觸發創建一個交互式session的servlet，並且在用戶新建session的時候，會自動把這個session的相關信息，注入到sessionStore中，用來對session進行管理
batchSessionServlet
這個是用戶發起 請求的時候觸發創建一個批處理session的servlet，並且在用戶新建session的時候，會自動把這個session的相關信息，注入到sessionStore中，用來對session進行管理
其他servlet
其他servlet就是對靜態資源的讀取，比如web網頁查看具體信息的servlet，以及重定向規則和版本控制均會放在這裏進行處理。這裏並不是重點，對於用戶交互階段，最關心的應該是上面兩個servlet，所以這裏就不再細說了。
用戶交互階段
右擊打開圖
上類關係圖
（未完待續，圖也在完善中）
Livy官網
Livy Github 源項目
