Spring探秘,妙用BeanPostProcessor
最近,在給項目組使用Spring搭建Java項目基礎框架時,發現使用Spring提供的BeanPostProcessor可以很簡單方便地解決很多看起來有點難解決的問題。本文將會通過一個真實案例來闡述BeanPostProcessor的用法。
BeanPostProcessor簡介
BeanPostProcessor是Spring IOC容器給我們提供的一個擴展介面。介面聲明如下:
如上介面聲明所示,BeanPostProcessor介面有兩個回調方法。當一個BeanPostProcessor的實現類註冊到Spring IOC容器後,對於該Spring IOC容器所創建的每個bean實例在初始化方法(如afterPropertiesSet和任意已聲明的init方法)調用前,將會調用BeanPostProcessor中的postProcessBeforeInitialization方法,而在bean實例初始化方法調用完成後,則會調用BeanPostProcessor中的postProcessAfterInitialization方法,整個調用順序可以簡單示意如下:
--> Spring IOC容器實例化Bean
--> 調用BeanPostProcessor的postProcessBeforeInitialization方法--> 調用bean實例的初始化方法
--> 調用BeanPostProcessor的postProcessAfterInitialization方法
可以看到,Spring容器通過BeanPostProcessor給了我們一個機會對Spring管理的bean進行再加工。比如:我們可以修改bean的屬性,可以給bean生成一個動態代理實例等等。一些Spring AOP的底層處理也是通過實現BeanPostProcessor來執行代理包裝邏輯的。
BeanPostProcessor實戰
了解了BeanPostProcessor的相關知識後,下面我們來通過項目中的一個具體例子來體驗一下它的神奇功效吧。
先介紹一下我們的項目背景吧:我們項目中經常會涉及AB 測試,這就會遇到同一套介面會存在兩種不同實現。實驗版本與對照版本需要在運行時同時存在。下面用一些簡單的類來做一個示意:
HelloService有以下兩個版本的實現:
做AB測試的話,在使用BeanPostProcessor封裝前,我們的調用代碼大概是像下面這樣子的:
可以看到,這樣的代碼看起來十分不優雅,並且如果AB測試的功能點很多的話,那項目中就會充斥著大量的這種重複性分支判斷,看到代碼就想死有木有!!!維護代碼也將會是個噩夢。比如某個功能點AB測試完畢,需要把全部功能切換到V2版本,V1版本不再需要維護,那麼處理方式有兩種:
- 把A版本代碼留著不管:這將會導致到處都是垃圾代碼從而造成代碼臃腫難以維護
- 找到所有V1版本被調用的地方然後把相關分支刪掉:這很容易在處理代碼的時候刪錯代碼從而造成生產事故。
怎麼解決這個問題呢,我們先看代碼,後文再給出解釋:
現在我們可以停下來對比一下封裝前後調用代碼了,是不是感覺改造後的代碼優雅很多呢?那麼這是怎麼實現的呢,我們一起來揭開它的神秘面紗吧,請看代碼:
我簡要解釋一下思路:
- 首先自定義了兩個註解:RoutingInjected、RoutingSwitch,前者的作用類似於我們常用的Autowired,聲明了該註解的屬性將會被注入一個路由代理類實例;後者的作用則是一個配置開關,聲明了控制路由的開關屬性
- 在RoutingBeanPostProcessor類中,我們在postProcessAfterInitialization方法中通過檢查bean中是否存在聲明了RoutingInjected註解的屬性,如果發現存在該註解則給該屬性注入一個動態代理類實例
- RoutingBeanProxyFactory類功能就是生成一個代理類實例,代理類的邏輯也比較簡單。版本路由支持到方法級別,即優先檢查方法是否存在路由配置RoutingSwitch,方法不存在配置時才默認使用類路由配置
好了,BeanPostProcessor的介紹就到這裡了。不知道看過後大家有沒有得到一些啟發呢?歡迎大家留言交流反饋。
【作者簡介】楊宗良,攜程深圳機票研發部資深開發工程師,現參與國際機票Online項目的維護及JAVA重構工作。
沒看夠?更多攜程技術人一手乾貨,歡迎搜索關注「攜程技術中心」微信公號~
推薦閱讀:
※史上最簡單的SpringCloud教程: docker部署spring cloud項目
※Ribbon源碼分析系列(一)
※Spring Boot 1.5.x新特性:動態修改日誌級別
※Netflix Zuul與Nginx的性能對比
TAG:Spring |