前言
最近一直被無盡的業(yè)務(wù)需求淹沒，沒時(shí)間喘息，終于接到一個(gè)能讓我突破代碼舒適區(qū)的活兒，解決它的過程非常曲折，一度讓我懷疑人生，不過收獲也很大，代碼方面不明顯，但感覺自己抹掉了 java、Tomcat、Spring 一直擋在我眼前的一層紗。對它們的理解上了一個(gè)新的層次。
好久沒輸出了，于是挑一個(gè)方面總結(jié)一下，希望在梳理過程中再了解一些其他的東西。由于 Java 繁榮的生態(tài)，下面每一個(gè)模塊都有大量的文章專門講述。所以我選了另外一個(gè)角度，從實(shí)際問題出發(fā)，將這些分散的知識串聯(lián)起來，各位可以作為一個(gè)綜述來看。各個(gè)模塊的極致詳細(xì)介紹，大家可以去翻官方文檔或看網(wǎng)絡(luò)上的其他博客。
文章歡迎轉(zhuǎn)載，請尊重作者勞動成果，帶上原文鏈接：https://www.cnblogs.com/zhenbianshu/p/9326057.html
需求很簡單清晰，跟產(chǎn)品們提的妖艷需求一點(diǎn)也不一樣：在我們的 web 框架里添加一個(gè)通用的 appkey 白名單校驗(yàn)功能，希望它的擴(kuò)展性更好一些。
這個(gè) web 框架是部門前驅(qū)者基于 spring-boot 實(shí)現(xiàn)的，介于業(yè)務(wù)和 Spring 框架之間，做一些偏向于業(yè)務(wù)的通用性功能，如 日志輸出、功能開關(guān)、通用參數(shù)解析等。平常是對業(yè)務(wù)透明的，最近一直忙于把需求做好，代碼寫好，甚至從沒注意過它的存在。
傳統(tǒng)AOP
對于這種需求，首先想到的當(dāng)然是 Spring-boot 提供的 AOP 接口，只需要在 Controller 方法前添加切點(diǎn)，然后再對切點(diǎn)進(jìn)行處理即可。
實(shí)現(xiàn)
其使用步驟如下：
使用?@Aspect?聲明一下切面類?WhitelistAspect；
在切面類內(nèi)添加一個(gè)切點(diǎn)?whitelistPointcut()，為了實(shí)現(xiàn)此切點(diǎn)靈活可裝配的能力，這里不使用?execution?全部攔截，而是添加一個(gè)注解?@Whitelist，被注解的方法才會校驗(yàn)白名單。
在切面類中使用 spring 的 AOP 注解?@Before?聲明一個(gè)通知方法?checkWhitelist()?在 Controller 方法被執(zhí)行之前校驗(yàn)白名單。
切面類偽代碼如下
@Aspect
public class WhitelistAspect {
? ? @Before(value = "whitelistPointcut() && @annotation(whitelist)")
? ? public void checkAppkeyWhitelist(JoinPoint joinPoint, Whitelist whitelist) {
? ? ? ? checkWhitelist();
? ? ? ? // 可使用 joinPoint.getArgs() 獲取Controller方法的參數(shù)
? ? ? ? // 可以使用 whitelist 變量獲取注解參數(shù)
? ? }
? ? @Pointcut("@annotation(com.zhenbianshu.Whitelist)")
? ? public void whitelistPointCut() {
? ? }
}
在Controller方法上添加?@Whitelist?注解實(shí)現(xiàn)功能。
擴(kuò)展
本例中使用了 注解 來聲明切點(diǎn)，并且我實(shí)現(xiàn)了通過注解參數(shù)來聲明要校驗(yàn)的白名單，如果之后還需要添加其他白名單的話，如通過 UID 來校驗(yàn)，則可以為此注解添加?uid()?等方法，實(shí)現(xiàn)自定義校驗(yàn)。
此外，spring 的 AOP 還支持?execution（執(zhí)行方法） 、bean（匹配特定名稱的 Bean 對象的執(zhí)行方法）等切點(diǎn)聲明方法和?@Around（在目標(biāo)函數(shù)執(zhí)行中執(zhí)行） 、@After（方法執(zhí)行后）?等通知方法。
如此，功能已經(jīng)實(shí)現(xiàn)了，但領(lǐng)導(dǎo)并不滿意=_=，原因是項(xiàng)目中 AOP 用得太多了，都用濫了，建議我換一種方式。嗯，只好搞起。
Interceptor
Spring 的 攔截器(Interceptor) 實(shí)現(xiàn)這個(gè)功能也非常合適。顧名思義，攔截器用于在 Controller 內(nèi) Action 被執(zhí)行前通過一些參數(shù)判斷是否要執(zhí)行此方法，要實(shí)現(xiàn)一個(gè)攔截器，可以實(shí)現(xiàn) Spring 的?HandlerInterceptor?接口。
實(shí)現(xiàn)
實(shí)現(xiàn)步驟如下：
定義攔截器類?AppkeyInterceptor?類并實(shí)現(xiàn) HandlerInterceptor 接口。
實(shí)現(xiàn)其?preHandle()?方法；
在 preHandle 方法內(nèi)通過注解和參數(shù)判斷是否需要攔截請求，攔截請求時(shí)接口返回?false；
在自定義的?WebMvcConfigurerAdapter?類內(nèi)注冊此攔截器；
AppkeyInterceptor?類如下：
@Component
public 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 獲取請求參數(shù)，通過 whitelist 變量獲取注解參數(shù)
? ? ? ? return true;
? ? }
? ? @Override
? ? public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
? ? ? ? // 方法在Controller方法執(zhí)行結(jié)束后執(zhí)行
? ? }
? ? @Override
? ? public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
? ? ? ? // 在view視圖渲染完成后執(zhí)行
? ? }
}
擴(kuò)展
要啟用 攔截器還要顯式配置它啟用，這里我們使用?WebMvcConfigurerAdapter?對它進(jìn)行配置。需要注意，繼承它的的?MvcConfiguration?需要在 ComponentScan 路徑下。
@Configuration
public class MvcConfiguration extends WebMvcConfigurerAdapter {
? ? @Override
? ? public void addInterceptors(InterceptorRegistry registry) {
? ? ? ? registry.addInterceptor(new WhitelistInterceptor()).addPathPatterns("/*").order(1);
? ? ? ? // 這里可以配置攔截器啟用的 path 的順序，在有多個(gè)攔截器存在時(shí)，任一攔截器返回 false 都會使后續(xù)的請求方法不再執(zhí)行
? ? }
}
還需要注意，攔截器執(zhí)行成功后響應(yīng)碼為?200，但響應(yīng)數(shù)據(jù)為空。
當(dāng)使用攔截器實(shí)現(xiàn)功能后，領(lǐng)導(dǎo)終于祭出大招了：我們已經(jīng)有一個(gè) Auth 參數(shù)了，appkey 可以從 Auth 參數(shù)里取到，可以把在不在白名單作為 Auth 的一種方式，為什么不在 Auth 時(shí)校驗(yàn)？emmm... 吐血中。
ArgumentResolver
參數(shù)解析器是 Spring 提供的用于解析自定義參數(shù)的工具，我們常用的?@RequestParam?注解就有它的影子，使用它，我們可以將參數(shù)在進(jìn)入Controller Action之前就組合成我們想要的樣子。Spring 會維護(hù)一個(gè)?ResolverList， 在請求到達(dá)時(shí)，Spring 發(fā)現(xiàn)有自定義類型參數(shù)（非基本類型）， 會依次嘗試這些 Resolver，直到有一個(gè) Resolver 能解析需要的參數(shù)。要實(shí)現(xiàn)一個(gè)參數(shù)解析器，需要實(shí)現(xiàn)?HandlerMethodArgumentResolver?接口。
實(shí)現(xiàn)
定義自定義參數(shù)類型?AuthParam，類內(nèi)有 appkey 相關(guān)字段；
定義?AuthParamResolver?并實(shí)現(xiàn) HandlerMethodArgumentResolver 接口；
實(shí)現(xiàn)?supportsParameter()?接口方法將 AuthParam 與 AuthParamResolver 適配起來；
實(shí)現(xiàn)?resolveArgument()?接口方法解析 reqest 對象生成 AuthParam 對象，并在此校驗(yàn) AuthParam ，確認(rèn) appkey 是否在白名單內(nèi)；
在 Controller Action 方法上簽名內(nèi)添加 AuthParam 參數(shù)以啟用此 Resolver;
實(shí)現(xiàn)的 AuthParamResolver 類如下：
@Component
public 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 校驗(yàn)白名單
? ? ? ? return new AuthParam();
? ? }
}
擴(kuò)展
當(dāng)然，使用參數(shù)解析器也需要單獨(dú)配置，我們同樣在?WebMvcConfigurerAdapter?內(nèi)配置：
@Configuration
public class MvcConfiguration extends WebMvcConfigurerAdapter {
? ? @Override
? ? public void addArgumentResolvers(List<HandlerMethodArgumentResolver> argumentResolvers) {
? ? ? ? argumentResolvers.add(new AuthParamResolver());
? ? }
}
這次實(shí)現(xiàn)完了，我還有些不放心，于是在網(wǎng)上查找是否還有其他方式可以實(shí)現(xiàn)此功能，發(fā)現(xiàn)常見的還有?Filter。
Filter
Filter 并不是 Spring 提供的，它是在 Servlet 規(guī)范中定義的，是 Servlet 容器支持的。被 Filter 過濾的請求，不會派發(fā)到 Spring 容器中。它的實(shí)現(xiàn)也比較簡單，實(shí)現(xiàn)?javax.servlet.Filter?接口即可。
由于不在 Spring 容器中，F(xiàn)ilter 獲取不到 Spring 容器的資源，只能使用原生 Java 的 ServletRequest 和 ServletResponse 來獲取請求參數(shù)。
另外，在一個(gè) Filter 中要顯示調(diào)用 FilterChain 的 doFilter 方法，不然認(rèn)為請求被攔截。 實(shí)現(xiàn)類似：
public class WhitelistFilter implements javax.servlet.Filter {
? ? @Override
? ? public void init(FilterConfig filterConfig) throws ServletException {
? ? ? ? // 初始化后被調(diào)用一次
? ? }
? ? @Override
? ? public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
? ? ? ? // 判斷是否需要攔截
? ? ? chain.doFilter(request, response); // 請求通過要顯示調(diào)用
? ? }
? ? @Override
? ? public void destroy() {
? ? ? ? // 被銷毀時(shí)調(diào)用一次
? ? }
}
擴(kuò)展
Filter 也需要顯示配置：
@Configuration
public class FilterConfiguration {
? ? @Bean
? ? public FilterRegistrationBean someFilterRegistration() {
? ? ? ? FilterRegistrationBean registration = new FilterRegistrationBean();
? ? ? ? registration.setFilter(new WhitelistFilter());
? ? ? ? registration.addUrlPatterns("/*");
? ? ? ? registration.setName("whitelistFilter");
? ? ? ? registration.setOrder(1); // 設(shè)置過濾器被調(diào)用的順序
? ? ? ? return registration;
? ? }
}
小結(jié)
四種實(shí)現(xiàn)方式都有其適合的場景，那么它們之間的調(diào)用順序如何呢？
Filter 是 Servlet 實(shí)現(xiàn)的，自然是最先被調(diào)用，后續(xù)被調(diào)用的是 Interceptor 被攔截了自然不需要后續(xù)再進(jìn)行處理，然后是 參數(shù)解析器，最后才是 切面的切點(diǎn)。我將四種方式在一個(gè)項(xiàng)目內(nèi)全部實(shí)現(xiàn)后，輸出日志也證明了這個(gè)結(jié)論。
跳出具體實(shí)現(xiàn)，轉(zhuǎn)身來看這些實(shí)現(xiàn)，其實(shí)都有一些面向切面的影子。由于之前自己的編程方式更偏向于面向過程編程，在使用 Java 面向?qū)ο蠛髮Ρ?AOP 和 面向過程中的勾子，有些感悟，改日寫文整理一下。
關(guān)于本文有什么問題可以在下面留言交流
歡迎工作一到五年的Java工程師朋友們加入Java程序員開發(fā)： 854393687
群內(nèi)提供免費(fèi)的Java架構(gòu)學(xué)習(xí)資料（里面有高可用、高并發(fā)、高性能及分布式、Jvm性能調(diào)優(yōu)、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個(gè)知識點(diǎn)的架構(gòu)資料）合理利用自己每一分每一秒的時(shí)間來學(xué)習(xí)提升自己，不要再用"沒有時(shí)間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個(gè)交代！
