學過 Spring 的小伙伴相信都知道 AOP，AOP 學的好的小伙伴相信對 AOP 的概念也是輕車熟路：面向切面編程、切點、切面、通知，Aspect、Pointcut、Advice 等如數(shù)家珍。

AOP 之所以這么重要，是因為它在項目中有著非常廣泛的應用，今天這篇文章，松哥就來和大家總結一下，我們在日常開發(fā)中，都有哪些典型場景需要用到 AOP。

先來一句話總結下，AOP 的使用，基本上都會涉及到自定義注解，一個非常常見的組合，就是自定義注解+AOP。

在日常的開發(fā)中，有很多重復的代碼，我們總是希望將之簡化，AOP 就是一個非常常用的簡化手段。簡化的思路一般是這樣：

• 首先，自定義一個注解。
• 定義 AOP 切面，在切面中，定義切點和通知，切點，也就是方法的攔截規(guī)則，我們可以按照注解來攔截，也就是某一個帶有自定義注解的方法，將被我攔截下來。
• 攔截下來之后，前置通知、后置通知、異常通知、返回通知還是環(huán)繞通知，就可以隨便寫了。

所以，這些涉及到自定義注解的地方，基本上都可以算是 AOP 的使用場景了，因為自定義注解，需要用 AOP 來解析。

接下來我們來看幾個比較典型的例子。

1. 冪等性處理

接口冪等性的處理，其實有很多種不同的方案，例如：

• Token 機制
• 去重表
• 利用 Redis 的 setnx
• 設置狀態(tài)字段
• 上鎖

無論是哪種方案處理冪等性，每個方法里邊都去寫一遍冪等性的處理顯然是不現(xiàn)實的，因此，一般都是將冪等性的處理通過自定義注解+AOP給封裝起來，大致的思路如下：

首先自定義一個注解。

自定義切點，攔截所有加了自定義注解的方法。

定義環(huán)繞通知，在環(huán)繞通知中，先通過上述五種思路中的任意一種，對方法執(zhí)行的冪等性進行判斷，判斷通過了，再執(zhí)行目標方法，判斷不通過，則直接拋出異常，不執(zhí)行目標方法。

這就是自定義注解+AOP 的一個典型應用場景。

2. 接口限流

對于接口限流，目前來說，一個比較成熟的方案是使用 Alibaba 的 Sentienl，簡單配置一下就可以實現(xiàn)接口限流了。

但是如果沒有用這個工具呢？如果是我們自己寫呢？毫無疑問，還是自定義注解+AOP，思路大致如下：

• 自定義注解。
• 在需要進行限流的接口方法上添加自定義注解，同時還可以設置一些限流的參數(shù)，例如時間窗口值、流量大小等。
• 自定義切點，攔截規(guī)則就是所有添加了自定義注解的方法，攔截到方法之后，在環(huán)繞通知中，可以通過 Redis 插件 redis-cell、通過漏斗算法去處理限流，這個我這里就不羅嗦了，之前的文章中都寫過了。限流計算沒問題的話，就執(zhí)行目標方法，否則將操作攔截下來。

大致思路如上，說白了就是自定義注解+ AOP，道理雖然簡單，但是真正做起來，還是有很多細節(jié)。

3. 日志處理

說到 AOP，所有人都能想到的使用場景了，這個我就不羅嗦了，松哥之前也有過專門的文章介紹，沒看過的小伙伴們戳這里：記錄項目日志，一個注解搞定。

4. 多數(shù)據(jù)源處理

有時候我們項目中存在多個不同的數(shù)據(jù)源，在實際使用中需要進行切換，網(wǎng)上也有一些開源的解決方案，不過這個東西其實并不難，我們也可以自己寫。

自定義多數(shù)據(jù)源的處理，大致上思路如下：

從 Spring2.0.1 中引入了 AbstractRoutingDataSource 類，（注意是 Spring2.0.1 不是 Spring Boot2.0.1，所以這其實也算是 Spring 一個非常古老的特性了）, 該類充當了 DataSource 的路由中介，它能夠在運行時, 根據(jù)某種 key 值來動態(tài)切換到真正的 DataSource 上。

大致的用法就是你提前準備好各種數(shù)據(jù)源，存入到一個 Map 中，Map 的 key 就是這個數(shù)據(jù)源的名字，Map 的 value 就是這個具體的數(shù)據(jù)源，然后再把這個 Map 配置到 AbstractRoutingDataSource 中，最后，每次執(zhí)行數(shù)據(jù)庫查詢的時候，拿一個 key 出來，AbstractRoutingDataSource 會找到具體的數(shù)據(jù)源去執(zhí)行這次數(shù)據(jù)庫操作。

基于以上知識，我們可以自定義一個注解，在需要切換數(shù)據(jù)源的方法上，添加這個注解，然后通過 AOP 去解析這個自定義注解，當目標方法被攔截下來的時候，我們跟進注解中的配置，重新設置要執(zhí)行的數(shù)據(jù)源，這樣將來 service 中的方法在執(zhí)行的過程中，就會使用到切換之后的數(shù)據(jù)源了。

5. 方法權限處理

這個其實也跟前面的差不多。

方法級別的權限處理，一般來說也是基于注解來完成的。如果你使用了 Spring Security 之類的權限框架，就不用自己解析權限注解了，按照框架的要求直接來使用就行了。

有的時候，我們可能沒有使用 Spring Security，想自己處理權限注解，也是可以的。用戶自定義權限注解，為注解添加屬性，然后將注解添加到目標方法上，再通過 AOP 去解析這個注解，AOP 將目標方法的執(zhí)行攔截下來，然后判斷用戶是否具備所需要的權限，如果具備，就執(zhí)行目標方法，否則就不執(zhí)行。

前兩天松哥剛剛分享的在微服務中，服務內部的權限校驗，就是自定義一個注解，將從其他微服務上來的請求給攔截下來，然后判斷請求的來源，如果是從其他微服務上來的，就執(zhí)行目標方法，如果不是從其他微服務上來的，而是從外部來的請求，那么就將之攔截下來拋出異常，不執(zhí)行目標方法。

6. 事務處理

這個倒是不需要自定義注解，對于聲明式事務，直接用現(xiàn)成的注解就行了，但是本質上也是 AOP，如果有小伙伴在 Spring 的 XML 中配置過事務的話，就知道這個東西底層也是 AOP。

好啦，梳理了幾個簡單的案例，希望小伙伴們了解到 AOP 并不是屠龍術，而是在日常開發(fā)中有著廣泛應用的技術。