『網際網路架構』軟體架構-spring之AOP場景實戰（11）

面試的時候，經常被面試官問到AOP在你的項目中用到了那些場景，我一般的回答是日志，權限，事務處理，方法的統計，性能的監控。其實權限和事務都是跟業務相關的，咱們一起來想想針對其他幾個如何來設計。重點是設計的思路。源碼：https://github.com/limingios/netFuture/tree/master/tuling-enhance-plugin-master

日志

新增的日志

有必要列印。

查詢的日志

對于系統來說基本都是寫少，讀多的，是不是所有的日志都有必要打。是不是列印很多無用的日志，其實看日志就是看傳遞的參數有沒有問題，也就是說有問題了才看日志，是不是可以這樣了解其實百分之90以上的日志是無用日志，列印其實是無用的，我說的場景，其實如果是日志分析工作，可能所有的日志都有必要，但是可能有些日志不需要埋點，沒有必要埋點對吧。也就是日志是特定日志需要列印，根據業務來說。

不夠靈活

一般都是通用功能，基本無人做定制化。想列印那些，就列印那些。代碼寫死了，如果需要改必須重新開機系統來完成。

對業務造成侵入

代碼寫在業務功能裡面了，根據業務功能一起釋出一起更新。寫在了業務功能裡面了。耦合進去了。

釋出困難

要針對某個增加，需要寫代碼，進行業務的釋出和更新。很麻煩，如果一個系統改就改了，如果有成百上千的業務，都需要增加。成本高。太重了。性能監控可能都需要寫，10個項目寫10次。

可以低成本的介入非業務功能

比傳統的寫AOP成本更低，可以遠端的裝載插件。不重新開機的項目。我們之前的方式每次設計一張表，表裡設計了很多個參數，每次過業務方法其實都需要讀一遍資料庫，因為很慢後來換成了redis，但是更改了值後，需要删除redis内的内容。這種方法也不是最好的。不重新開機的狀态下，保證了靈活性。

非常的靈活

動态的更新插件，啟用和停止插件。自動下載下傳插件，就算重新開機應用也有本地緩存，儲存之前的設定。

PS：詳細得我不多說了，直接看源碼把，主要了解這個思路裡面有classload加載對應的class，通過spring的IOC加載bean的方式擷取Advice，進行控制。