一，支持介面限流，避免惡意請求導致服務層壓力過大
常見的限流功能一般有兩個關注點： 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學習筆記-分析》就不難理解這里的資料權限的使用場景了， 一般的功能權限都是基于RBAC思想設定一套基于角色的權限授予方案，讓用戶的權限通過角色這一層抽象和系統中的權限發生互動， 常見的功能權限的解決方案是使用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做的事情了， 2.然后在后端通過過濾器，切面，攔截器等等實作對回應的修改操作， 這里主要對后端的實作做拆解，常見的例外處理機制都是在業務層、控制層拋出，通過@ExceptionHandler注解處理例外拋出的程序，該機制的實作是通過切面實作的，其中切面的切點宣告是通過注解@RestControllerAdvice或@ControllerAdvice實作， 基于切面，這部分功能特性可以做的拓展有例外處理（注解@ExceptionHandler），初始化資料系結器用于特定資料格式的引數系結（注解@InitBinder），特殊請求引數的系結（注解@ModelAttribute），對應的使用場景分別是，根據拋出的不同的例外封裝不同的請求流轉以及回應，將前端請求的字串型別的日期轉化為Date型別的日期，不通過控制器層將引數系結到Model中， 總之，將@ControllerAdvice這個注解理解為在過濾器，攔截器，之后的最后一道攔在請求和我們應用的處理邏輯之間的處理流程即可，通過這個切面結合注解@ExceptionHandler可以將控制器層以及業務層拋出的所有例外根據例外型別，例外所屬的包進行差異化的攔截處理，
五，支持運維管理，可方便地對遠程服務器的應用進行部署與管理
這個特性已經讓EL-ADMIN脫離了后端框架的定位了，雖然這個功能還是比較常用的，但是這個特性中包含的功能只要單獨拿出來，然后稍微拓展就可以當作服務器管理工具來用了， 通過官方檔案的描述可以把重點放在這幾個功能的實作上：
- 新增服務器，整合ssh客戶端連接服務器，
- 新增應用，通過ftp等命令將應用發送至服務器指定目錄，
- 部署應用，通過shell命令實作應用的部署，啟動等操作，結合2后還可以執行上傳的sql腳本，
圖九，用戶對遠程服務器應用部署與管理
上述幾個功能用到了兩個開源組件以及一個之前所沒有接觸過的技術點，分別是：
jsch，連接指定的機器后執行shell命令，并獲取對應的回傳值，
ganymed-ssh2，連接指定的機器后獲取檔案或上傳檔案的工具，
websocket，這個技術的確是做CURD Boy不經常接觸的技術點，定義是這樣描述的：
WebSocket 是 HTML5 開始提供的一種在單個 TCP 連接上進行全雙工通訊的協議，
這里有兩個點需要解釋一下，一個是單個，怎么理解這個單個呢，一般來說你在網頁上點擊一個超鏈接就是單個的概念了，一個請求就是單個TCP連接了，其次就是全雙工的定義，這是一個通訊概念，同屬一類的有單工，半雙工，全雙工，他們的區別就是從兩個維度上來區分，其一是資訊的傳遞是單向的還是雙向的，單向的就是單工，雙向的就是雙工，其二是發送和接受能否同時執行，能夠就是全雙工，不能就是半雙工，對應我們實際在開發中使用到的通信技術和協議，http，ajax這些就是半雙工的，因為請求時資訊的流向時雙向的，但是不能同時進行接受資訊和發送資訊，websocket則是提供了一種在發送訊息的時候接受訊息的技術標準，
有了websocket這個新玩具， EL-ADMIN把它用到了遠端服務器狀態的實時資訊推送，比如應用部署完成，應用卸載，應用當前運行狀態的獲取等等，在廣闊的業務場景中，因為websocket的實時性比ajax要高的多，所以也可以用到聊天的場景中，
參考文獻： [0]EL-ADMIN特性https://el-admin.vip/guide/kslj.html#%E9%A1%B9%E7%9B%AE%E7%AE%80%E4%BB%8B [1]Lua語法https://www.runoob.com/lua/lua-basic-syntax.html [2]Redis中使用Lua腳本https://www.cnblogs.com/kaituorensheng/p/11098194.html [3]JPA常見注解https://blog.csdn.net/wang_1220/article/details/107915815 [4]資料權限https://www.cnblogs.com/anderson-question/articles/14907553.html [5]JpaSpecificationExecutor的使用https://zhuanlan.zhihu.com/p/139107843 [6]SringMVC例外處理https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-exceptionhandlers
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/300148.html
標籤：Java