常見的限流功能一般有兩個關注點：

1.限流原則，即以什麼樣的條件對請求進行識別以及放行。常見的作法是給予每個調用API的系統不同的唯一編碼，用於監控某一編碼的調用是否超出上限。

2.限流機制，即通過什麼樣的機制實現限流。常見的作法是通過Redis中Key的TTL失效機制來限制訪問頻率。

比較常見的處理方案是使用Redis中Key的TTL失效機制來限制訪問頻率，然後通過切面實現處理限流邏輯，並使用自定義註解將零散的關注點集中起來。

接下來按照上述兩個關注點對EL-ADMIN中如何實現的介面限流進行拆解：

首先是它的限流原則：

圖一，限流使用實例

通過me.zhengjie.modules.system.rest.LimitController的test方法就可以看到EL-ADMIN對限流的封裝還是比較易用的，只需通過註解設置指定時間段內允許訪問的次數以及限流的鍵名（前綴+key），其中name是指的該介面的功能備註，並不會影響限流的功能，只是方便在日誌中檢索對應介面的資訊。

圖二，限流切面

但是不止於此（見上圖），進一步挖掘處理這個註解的Around類型切面（me.zhengjie.aspect.LimitAspect）的時候發現限流的原則不止是通過key的方式還有通過客戶端IP的方式來限制，Around切面可以理解為在所有Limit註解處添加了一個執行攔截器，判斷是否滿足允許執行的條件後通過joinPoint.proceed()執行原來的方法（這裡類似攔截器的過濾鏈處理模式）。總結如下：在使用Redis作為限流核心機制的設計方案中，Key的設置直接決定了限流原則。

 

其次是它的限流機制：

通過圖二的限流切面分析可知，相比於一般的限流邏輯，EL-ADMIN進一步對Redis的操作做了優化，使用了Lua腳本來執行限流的判斷機制。具體的限流機制是通過將介面地址結合Limit註解的prefix+key+url的方式構建了一個介面對應的唯一鍵，通過查詢Redis上該鍵TTL（生命周期period）時間段內的值（訪問次數count）實現限流的邏輯。限流機制這部分的核心Lua實現如下圖所示，需要注意的是在第6行和第7行，在Redis中假如直接對一個key執行incr命令會將這個key設置為1。

圖三，限流機制Lua腳本

另外相比一般場景下使用RedisTemplate執行這一系列操作，使用Lua腳本操作Redis的優勢如下：

1.保證對Redis操作的原子性，防止出現對同一個key的非原子性操作。

2.減少網路數據傳輸節省頻寬。

這裡提到的功能許可權一般是指使用者能否使用系統的功能，數據許可權同理則是指使用者能否訪問對應的數據，如果看過上一篇《RuoYi-Vue學習筆記-分析》就不難理解這裡的數據許可權的使用場景了。

常見的功能許可權的解決方案是使用Spring Security + Jwt Token前者提供了成套的許可權過濾器，只需要將我們設計許可權系統的判斷邏輯接入過濾器即可，後者則有效的解決了客戶端身份盜用以及服務端的橫向擴展的問題。數據許可權在使用MyBatis框架時可以通過超類冗餘欄位+請求處理切面實現，在使用Spring Boot Jpa中的具體實現可以探索一番。在這一章節我們可以拆解以下兩個功能的具體實現：

 

1.Spring Boot Jpa的數據許可權解決方案的實現。

2.基於Spring Security框架實現的功能許可權如何實現全局介面自定義許可權放行，即通常情況下需要使用@PreAuthorize(“hasAnyRole(‘admin’,’menu:edit’)”)這類註解才能讓介面放行，但是超管可以訪問所有的介面，那麼我們就要給每個介面都添加admin的註解值了，這樣做是效率很低的，通過全局介面自定義許可權放行的方案即可實現在一處配置即可全局介面免去這個配置（這一特性的具體實現在之後的第三章節進行解構）。

 

首先，一起來看看EL-ADMIN對數據許可權的封裝，在拆解這部分之前需要先對Jpa有個大概的了解，不然會對這部分實現拆解的理解會有影響。當下常見的應用訪問數據的方式有以下兩種，一種是以Hibernate為首的信奉”程式設計師就不該寫SQL“的一眾ORM框架，這類框架不會讓程式設計師寫一行SQL，統統都交給框架處理，與之對應的則是封裝了SQL變化的一眾註解以及類（個人感覺這個抽象層的機制比SQL還難…）；一種是以MyBatis為代表的通過JDBC橋接了資料庫，讓程式設計師能夠靈活的自定義SQL語句來執行，這類框架則是注重靈活，與之對應的則是需要有一定的SQL基礎。

JPA就是Hibernate所遵守的標準名稱，使用這個標準的框架可以通過以下列表的註解實現SQL語句的對等功能。

圖四，JPA註解及其功能

 

參考RuoYi對數據許可權的處理，要想實現數據許可權至少有兩個點需要關注，

一是查詢前用戶數據許可權的獲取；

二是查詢時數據許可權注入；

 

首先是用戶數據許可權的獲取，這部分數據一般是通過登錄的時候放置在用戶的cookies中或是登錄後的session中，這部分在EL-ADMIN中是通過下圖中的幾步實現的，需要注意的是使用了Vuex的非同步介面請求的功能(圖中第一步)。

圖五，前端登錄流程

至此，系統已經獲取到了用戶的數據許可權的資訊，系統前端請求介面的時候攜帶對應的用戶Token即可，後端介面在登錄的時候已經對Token和用戶資訊（包含了用戶數據許可權記錄）進行了綁定和Redis快取，便於介面調用的時候直接通過快取獲取。接下來就是第二步查詢時數據許可權注入的拆解，這部分RuoYi是使用了註解+切面+超類基本和業務程式碼不侵入的方式實現的，EL-ADMIN的實現對比之下和業務程式碼的耦合性較大（這個鍋其實和JPA的設計哲學「程式設計師絕不寫SQL」有關，也不能讓EL-ADMIN背）。如下圖所示，自定義數據許可權註解在這個功能中的職責一如既往的是用來實現查詢條件以及欄位的個性化的注入到查詢過程中。

圖六，後端數據許可權查詢拼接流程

上圖中需要注意的有這麼兩點：

1.左側line62，數據許可權資訊獲取中是通過Spring Security提供的用戶資訊容器SecurityContextHolder獲取的，可以理解為通過執行緒池綁定了用戶資訊構成的上下文。

2.右側line45同理，也是通過1中的這個上下文獲取的用戶對應的數據許可權資訊。

 

 

 

這個特性其實是特性二的補充，相當於在介面前做了一個切面，針對特定的角色可以不去做許可權校驗。針對這個特性，一般的解決方案是通過註解對介面的許可權進行標記，然後通過切面/攔截器/過濾器對介面調用的請求進行匹配判斷。至此引出這一特性的幾個關注點：

1.用於標記攔截以及放行的自定義註解

2.整合入Spring Security的切面/過濾器/攔截器

首先關注攔截以及放行的註解，這部分標記許可權攔截的註解使用了常見的@PreAuthorize，只不過其中的值是使用了“@el.check(‘****’)“這種形式的字元串。這部分是通過SpringEL表達式獲取了容器中的Bean，然後計算對應的結果，這部分邏輯可以參考原始的hasAnyRole方法返回的結果來實現的。究其本質就是針對許可權判斷這部分，框架其他的部分不做變更，添加一個模組輸入輸出的類型不變，那麼就是可以契合原有框架的，通過下圖的原生的寫法比對更好理解一些，可以看到兩者的返回類型都是布爾值，且根據面向介面編程的規範我們甚至可以實現一個該方法所在的介面實現類來訂製我們自己的許可權判斷邏輯。

圖七，自定義許可權判斷規則

 

放行的則是使用了自定義的註解，值得一看的是EL-ADMIN通過對Spring MVC的@RequestMapping註解的擴展實現了框架需要的功能，充分的體現了六大設計原則之一的開閉原則。如下圖所示，放行的註解有以下兩種使用場景，一是針對現有程式碼直接添加註解即可，一是針對新的方法可以把對應的註解當作SpringMVC框架原生的註解使用。

圖八，自定義註解的放行策略

自定義註解實現的放行策略這部分需要注意的有幾處：

1.通過圖八中的方法，通過覆蓋原有的註解實現帶有許可權放行+路由功能的自定義註解。

2.自定義許可權放行和Spring Security框架的整合，通過SpringMVC中提供的Bean收集所有帶有放行註解的路由實現無配置自動化的放行。

3.放行所有的Options為HTTP請求動詞的請求，這是因為跨域請求需要用到這類動詞的請求，攔截就無法實現跨域了。

 

 

 

 

 

 

一般來說統一的異常攔截都可以通過過濾器或是攔截器實現，Spring很貼心的幫我們做了這部分的封裝，這一章節主要是拆解前後端結合的異常攔截的工程實踐方案。

 

1.首先需要在前端對響應有全局的處理邏輯，讓所有的響應都能通過前端邏輯進行轉化提示，說白了就是axios做的事情了。

 

這裡主要對後端的實現做拆解，常見的異常處理機制都是在業務層、控制層拋出，通過@ExceptionHandler註解處理異常拋出的過程。該機制的實現是通過切面實現的，其中切面的切點聲明是通過註解@RestControllerAdvice或@ControllerAdvice實現。

 

基於切面，這部分功能特性可以做的拓展有異常處理（註解@ExceptionHandler），初始化數據綁定器用於特定數據格式的參數綁定（註解@InitBinder），特殊請求參數的綁定（註解@ModelAttribute）。對應的使用場景分別是，根據拋出的不同的異常封裝不同的請求流轉以及響應，將前端請求的字元串類型的日期轉化為Date類型的日期，不通過控制器層將參數綁定到Model中。

 

總之，將@ControllerAdvice這個註解理解為在過濾器，攔截器，之後的最後一道攔在請求和我們應用的處理邏輯之間的處理流程即可。通過這個切面結合註解@ExceptionHandler可以將控制器層以及業務層拋出的所有異常根據異常類型，異常所屬的包進行差異化的攔截處理。

 

 

 

 

 

這個特性已經讓EL-ADMIN脫離了後端框架的定位了，雖然這個功能還是比較常用的，但是這個特性中包含的功能只要單獨拿出來，然後稍微拓展就可以當作伺服器管理工具來用了。

通過官方文檔的描述可以把重點放在這幾個功能的實現上：

通過下圖九可以更好的理解上述的特性點，首先是第一步，用戶通過本地和EL-ADMIN的交互將應用包上傳到伺服器上，此時應用文件會通過相關的配置參數推送到遠端的伺服器，然後通過部署腳本進行部署。這裡比較關鍵點是需要能夠監控遠端伺服器此時指定的應用的狀態，一般使用微服務架構的應用可以使用服務註冊與發現中心來實現這個監控，如果是單體的巨石應用則可以監控對應的埠進程狀態即可。

圖九，用戶對遠程伺服器應用部署與管理

上述幾個功能用到了兩個開源組件以及一個之前所沒有接觸過的技術點，分別是：

    jsch，連接指定的機器後執行shell命令，並獲取對應的返回值。

    ganymed-ssh2，連接指定的機器後獲取文件或上傳文件的工具。

    websocket，這個技術的確是做CURD Boy不經常接觸的技術點，定義是這樣描述的：

WebSocket 是 HTML5 開始提供的一種在單個 TCP 連接上進行全雙工通訊的協議。

這裡有兩個點需要解釋一下，一個是單個，怎麼理解這個單個呢，一般來說你在網頁上點擊一個超鏈接就是單個的概念了，一個請求就是單個TCP連接了。其次就是全雙工的定義，這是一個通訊概念，同屬一類的有單工，半雙工，全雙工。他們的區別就是從兩個維度上來區分，其一是資訊的傳遞是單向的還是雙向的，單向的就是單工，雙向的就是雙工。其二是發送和接受能否同時執行，能夠就是全雙工，不能就是半雙工。對應我們實際在開發中使用到的通訊技術和協議，http，ajax這些就是半雙工的，因為請求時資訊的流向時雙向的，但是不能同時進行接受資訊和發送資訊，websocket則是提供了一種在發送消息的時候接受消息的技術標準。

 

有了websocket這個新玩具， EL-ADMIN把它用到了遠端伺服器狀態的實時資訊推送，比如應用部署完成，應用卸載，應用當前運行狀態的獲取等等。在廣闊的業務場景中，因為websocket的實時性比ajax要高的多，所以也可以用到聊天的場景中。

 

 

 

 

參考文獻：

[0]EL-ADMIN特性//el-admin.vip/guide/kslj.html#%E9%A1%B9%E7%9B%AE%E7%AE%80%E4%BB%8B

[1]Lua語法//www.runoob.com/lua/lua-basic-syntax.html

[2]Redis中使用Lua腳本//www.cnblogs.com/kaituorensheng/p/11098194.html

[3]JPA常見註解//blog.csdn.net/wang_1220/article/details/107915815

[4]數據許可權//www.cnblogs.com/anderson-question/articles/14907553.html