前言
最近一直被無盡的業務需求淹沒，沒時間喘息，終于接到一個能讓我突破代碼舒適區的活兒，解決它的過程非常曲折，一度讓我懷疑人生，不過收獲也很大，代碼方面不明顯，但感覺自己抹掉了 java、tomcat、spring 一直擋在我眼前的一層紗。對它們的理解上了一個新的層次。
好久沒輸出了，于是挑一個方面總結一下，希望在梳理過程中再了解一些其他的東西。由于 java 繁榮的生態，下面每一個模塊都有大量的文章專門講述。所以我選了另外一個角度，從實際問題出發，將這些分散的知識串聯起來，各位可以作為一個綜述來看。各個模塊的極致詳細介紹，大家可以去翻官方文檔或看網絡上的其他博客。
需求很簡單清晰，跟產品們提的妖艷需求一點也不一樣：在我們的 web 框架里添加一個 通用 的 appkey 白名單校驗功能，希望它的擴展性更好一些。
這個 web 框架是部門前驅者基于 spring-boot 實現的，介于業務和 spring 框架之間，做一些偏向于業務的通用性功能，如 日志輸出、功能開關、通用參數解析等。平常是對業務透明的，最近一直忙于把需求做好，代碼寫好，甚至從沒注意過它的存在。
傳統aop
對于這種需求，首先想到的當然是 spring-boot 提供的 aop 接口，只需要在 controller 方法前添加切點，然后再對切點進行處理即可。
實現
其使用步驟如下：
1、使用 @aspect 聲明一下切面類 whitelistaspect ；
2、在切面類內添加一個切點 whitelistpointcut() ，為了實現此切點靈活可裝配的能力，這里不使用 execution 全部攔截，而是添加一個注解 @whitelist ，被注解的方法才會校驗白名單。
3、在切面類中使用 spring 的 aop 注解 @before 聲明一個通知方法 checkwhitelist() 在 controller 方法被執行之前校驗白名單。
切面類偽代碼如下
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
@aspectpublic class whitelistaspect { @before(value = "whitelistpointcut() && @annotation(whitelist)") public void checkappkeywhitelist(joinpoint joinpoint, whitelist whitelist) { checkwhitelist(); // 可使用 joinpoint.getargs() 獲取controller方法的參數 // 可以使用 whitelist 變量獲取注解參數 } @pointcut("@annotation(com.zhenbianshu.whitelist)") public void whitelistpointcut() { }} |
4、在controller方法上添加 @whitelist 注解實現功能。
擴展
本例中使用了 注解 來聲明切點，并且我實現了通過注解參數來聲明要校驗的白名單，如果之后還需要添加其他白名單的話，如通過 uid 來校驗，則可以為此注解添加 uid() 等方法，實現自定義校驗。
此外，spring 的 aop 還支持 execution（執行方法） 、bean（匹配特定名稱的 bean 對象的執行方法） 等切點聲明方法和 @around（在目標函數執行中執行） 、@after（方法執行后） 等通知方法。
如此，功能已經實現了，但領導并不滿意=_=，原因是項目中 aop 用得太多了，都用濫了，建議我換一種方式。嗯，只好搞起。
interceptor
spring 的 攔截器(interceptor) 實現這個功能也非常合適。顧名思義，攔截器用于在 controller 內 action 被執行前通過一些參數判斷是否要執行此方法，要實現一個攔截器，可以實現 spring 的 handlerinterceptor 接口。
實現
實現步驟如下：
1.定義攔截器類 appkeyinterceptor 類并實現 handlerinterceptor 接口。
2.實現其 prehandle() 方法；
3.在 prehandle 方法內通過注解和參數判斷是否需要攔截請求，攔截請求時接口返回 false；
4.在自定義的 webmvcconfigureradapter 類內注冊此攔截器；
appkeyinterceptor 類如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
@componentpublic class whitelistinterceptor implements handlerinterceptor { @override public boolean prehandle(httpservletrequest request, httpservletresponse response, object handler) throws exception { whitelist whitelist = ((handlermethod) handler).getmethodannotation(whitelist.class); // whitelist.values(); 通過 request 獲取請求參數，通過 whitelist 變量獲取注解參數 return true; } @override public void posthandle(httpservletrequest request, httpservletresponse response, object handler, modelandview modelandview) throws exception { // 方法在controller方法執行結束后執行 } @override public void aftercompletion(httpservletrequest request, httpservletresponse response, object handler, exception ex) throws exception { // 在view視圖渲染完成后執行 }} |
擴展
要啟用 攔截器還要顯式配置它啟用，這里我們使用 webmvcconfigureradapter 對它進行配置。需要注意，繼承它的的 mvcconfiguration 需要在 componentscan 路徑下。
|
1
2
3
4
5
6
7
8
|
@configurationpublic class mvcconfiguration extends webmvcconfigureradapter { @override public void addinterceptors(interceptorregistry registry) { registry.addinterceptor(new whitelistinterceptor()).addpathpatterns("/*").order(1); // 這里可以配置攔截器啟用的 path 的順序，在有多個攔截器存在時，任一攔截器返回 false 都會使后續的請求方法不再執行 }} |
還需要注意，攔截器執行成功后響應碼為 200 ，但響應數據為空。
當使用攔截器實現功能后，領導終于祭出大招了：我們已經有一個 auth 參數了，appkey 可以從 auth 參數里取到，可以把在不在白名單作為 auth 的一種方式，為什么不在 auth 時校驗？emmm... 吐血中。
argumentresolver
參數解析器是 spring 提供的用于解析自定義參數的工具，我們常用的 @requestparam 注解就有它的影子，使用它，我們可以將參數在進入controller action之前就組合成我們想要的樣子。spring 會維護一個 resolverlist ， 在請求到達時，spring 發現有自定義類型參數（非基本類型）， 會依次嘗試這些 resolver，直到有一個 resolver 能解析需要的參數。要實現一個參數解析器，需要實現 handlermethodargumentresolver 接口。
實現
1.定義自定義參數類型 authparam，類內有 appkey 相關字段；
2.定義 authparamresolver 并實現 handlermethodargumentresolver 接口；
3.實現 supportsparameter() 接口方法將 authparam 與 authparamresolver 適配起來；
4.實現 resolveargument() 接口方法解析 reqest 對象生成 authparam 對象，并在此校驗 authparam ，確認 appkey 是否在白名單內；
5.在 controller action 方法上簽名內添加 authparam 參數以啟用此 resolver;
實現的 authparamresolver 類如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
@componentpublic class authparamresolver implements handlermethodargumentresolver { @override public boolean supportsparameter(methodparameter parameter) { return parameter.getparametertype().equals(authparam.class); } @override public object resolveargument(methodparameter parameter, modelandviewcontainer mavcontainer, nativewebrequest webrequest, webdatabinderfactory binderfactory) throws exception { whitelist whitelist = parameter.getmethodannotation(whitelist.class); // 通過 webrequest 和 whitelist 校驗白名單 return new authparam(); }} |
擴展
當然，使用參數解析器也需要單獨配置，我們同樣在 webmvcconfigureradapter 內配置：
|
1
2
3
4
5
6
7
8
|
@configurationpublic class mvcconfiguration extends webmvcconfigureradapter { @override public void addargumentresolvers(list<handlermethodargumentresolver> argumentresolvers) { argumentresolvers.add(new authparamresolver()); }} |
這次實現完了，我還有些不放心，于是在網上查找是否還有其他方式可以實現此功能，發現常見的還有 filter 。
filter
filter 并不是 spring 提供的，它是在 servlet 規范中定義的，是 servlet 容器支持的。被 filter 過濾的請求，不會派發到 spring 容器中。它的實現也比較簡單，實現 javax.servlet.filter 接口即可。
由于不在 spring 容器中，filter 獲取不到 spring 容器的資源，只能使用原生 java 的 servletrequest 和 servletresponse 來獲取請求參數。
另外，在一個 filter 中要顯示調用 filterchain 的 dofilter 方法，不然認為請求被攔截。 實現類似：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
public class whitelistfilter implements javax.servlet.filter { @override public void init(filterconfig filterconfig) throws servletexception { // 初始化后被調用一次 } @override public void dofilter(servletrequest request, servletresponse response, filterchain chain) throws ioexception, servletexception { // 判斷是否需要攔截 chain.dofilter(request, response); // 請求通過要顯示調用 } @override public void destroy() { // 被銷毀時調用一次 }} |
擴展
filter 也需要顯示配置：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
@configurationpublic class filterconfiguration { @bean public filterregistrationbean somefilterregistration() { filterregistrationbean registration = new filterregistrationbean(); registration.setfilter(new whitelistfilter()); registration.addurlpatterns("/*"); registration.setname("whitelistfilter"); registration.setorder(1); // 設置過濾器被調用的順序 return registration; }} |
小結
四種實現方式都有其適合的場景，那么它們之間的調用順序如何呢？
filter 是 servlet 實現的，自然是最先被調用，后續被調用的是 interceptor 被攔截了自然不需要后續再進行處理，然后是 參數解析器，最后才是 切面的切點。我將四種方式在一個項目內全部實現后，輸出日志也證明了這個結論。
跳出具體實現，轉身來看這些實現，其實都有一些面向切面的影子。由于之前自己的編程方式更偏向于面向過程編程，在使用 java 面向對象后對比 aop 和 面向過程中的勾子，有些感悟，改日寫文整理一下。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：http://www.cnblogs.com/zhenbianshu/p/9326057.html
