『網際網路架構』軟體架構-spring之AOP場景實戰(11)
面試的時候,經常被面試官問到AOP在你的專案中用到了那些場景,我一般的回答是日誌,許可權,事務處理,方法的統計,效能的監控。其實許可權和事務都是跟業務相關的,咱們一起來想想針對其他幾個如何來設計。重點是設計的思路。原始碼:https://github.com/limingios/netFuture/tree/master/tuling-enhance-plugin-master
AOP能幹什麼?
- 日誌
- 新增的日誌
有必要列印。
- 查詢的日誌
對於系統來說基本都是寫少,讀多的,是不是所有的日誌都有必要打。是不是列印很多無用的日誌,其實看日誌就是看傳遞的引數有沒有問題,也就是說有問題了才看日誌,是不是可以這樣理解其實百分之90以上的日誌是無用日誌,列印其實是無用的,我說的場景,其實如果是日誌分析工作,可能所有的日誌都有必要,但是可能有些日誌不需要埋點,沒有必要埋點對吧。也就是日誌是特定日誌需要列印,根據業務來說。
傳統的AOP的弊端
- 不夠靈活
一般都是通用功能,基本無人做定製化。想列印那些,就列印那些。程式碼寫死了,如果需要改必須重啟系統來完成。
- 對業務造成侵入
程式碼寫在業務功能裡面了,根據業務功能一起釋出一起升級。寫在了業務功能裡面了。耦合進去了。
- 釋出困難
要針對某個增加,需要寫程式碼,進行業務的釋出和升級。很麻煩,如果一個系統改就改了,如果有成百上千的業務,都需要增加。成本高。太重了。效能監控可能都需要寫,10個專案寫10次。
解決方法
- 可以低成本的介入非業務功能
比傳統的寫AOP成本更低,可以遠端的裝載外掛。不重啟的專案。我們之前的方式每次設計一張表,表裡設計了很多個引數,每次過業務方法其實都需要讀一遍資料庫,因為很慢後來換成了redis,但是更改了值後,需要刪除redis內的內容。這種方法也不是最好的。不重啟的狀態下,保證了靈活性。
- 非常的靈活
動態的更新外掛,啟用和停止外掛。自動下載外掛,就算重啟應用也有本地快取,儲存之前的設定。
原始碼結構圖
PS:詳細得我不多說了,直接看原始碼把,主要理解這個思路里面有classload載入對應的class,通過spring的IOC載入bean的方式獲取Advice,進行控制。
>>原創文章,歡迎轉載。轉載請註明:轉載自,謝謝!>>原文連結地址:上一篇:已是最新文章