『網際網路架構』軟體架構-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，進行控制。
>>原創文章，歡迎轉載。轉載請註明：轉載自，謝謝！>>原文連結地址：上一篇:已是最新文章