行：徹底告別日志切面拖慢接口)
做后端開發(fā)這幾年我在日志記錄和操作審計這類需求上栽過不少跟頭。最早是直接在業(yè)務代碼里一行行手寫日志后來改用AOP切面統(tǒng)一處理切面是清爽了可新的問題又來了——日志接口慢、消息隊列抖動、第三方通知超時不管哪個環(huán)節(jié)出幺蛾子業(yè)務接口就跟著遭殃。這時候我才意識到切面里的這些非核心動作壓根就不該跟主流程綁在同一個線程里同步執(zhí)行。于是就有了這套“Spring Boot AOP 異步執(zhí)行方案”。說白了就是在AOP切面里把耗時的橫切邏輯日志落庫、操作審計、埋點上報、消息通知交給獨立的線程池異步執(zhí)行讓主業(yè)務線程只干自己的正事。這篇文章會從方案選型、原理剖析、完整代碼、實測踩坑四個層面展開適合剛接觸Spring Boot的初級開發(fā)者也適合已經(jīng)在用AOP但發(fā)現(xiàn)切面拖慢接口性能、想優(yōu)化的人。讀完你不僅能照抄一套能跑的代碼還能搞清楚里面每個配置背后的為什么。1. 為什么必須用AOP異步一個日志切面拖慢接口的教訓1.1 從同步切面到異步切面的真實背景先講一個我實際遇到的場景。某個項目里給所有Controller層接口加了一個操作日志切面需求是記錄每個請求的用戶、路徑、參數(shù)、響應時間和狀態(tài)碼。一開始邏輯很簡單業(yè)務方法跑完切面里拼一條日志然后同步寫入數(shù)據(jù)庫日志表。單機低并發(fā)的時候一切正常接口響應時間差不多在30到50毫秒左右。后來數(shù)據(jù)量上來日志表膨脹插入語句從兩毫秒慢慢漲到了十幾毫秒碰上數(shù)據(jù)庫鎖競爭、連接池不夠用的時候切面里的日志插入甚至要等上百毫秒。最要命的是日志寫入失敗還會直接拋出異常把原本正常的業(yè)務請求也給打掛了。這就是典型的橫切邏輯對主流程的“反向污染”——你只是想記個日志結(jié)果它把接口搞超時了。為了解耦和提速我當時先想到的是把日志寫入改成異步但最開始的實現(xiàn)很粗糙就是在切面方法里手動 new 一個線程去寫日志。這樣做的后果是每次請求都要創(chuàng)建新線程頻繁的線程上下文切換開銷反而更大而且線程不受Spring容器管理連接池、事務、異常處理全都跟不上。后來才老老實實回到Spring的 Async 體系用線程池統(tǒng)一管理異步任務。1.2 三個候選方案的取舍對比在確定用Spring自帶異步之前我對比過三種常見的異步切面實現(xiàn)方式方案實現(xiàn)方式優(yōu)點缺點手動創(chuàng)建線程切面里直接 new Thread簡單粗暴代碼量最少線程不受管控頻繁創(chuàng)建銷毀開銷大無法復用無法監(jiān)控消息隊列通知切面里投遞MQ消息下游消費解耦徹底削峰能力強適合重任務引入額外中間件排查問題鏈路變長小項目運維成本高Spring Async異步執(zhí)行切面委托線程池執(zhí)行任務原生支持線程可復用可用線程池監(jiān)控和Spring事務/異常體系兼容需要正確配置線程池異步方法內(nèi)部的事務和主事務是隔離的最終我選擇了 Spring Async 方案。理由是這套方案對現(xiàn)有代碼侵入最小、不需要額外部署中間件而且線程池可以精細控制核心線程數(shù)、隊列容量、拒絕策略都能自己定制。對于日志記錄、統(tǒng)計埋點這類輕量異步任務來說完全夠用。1.3 先搞清楚AOP在Spring里的執(zhí)行機制聊異步之前得先把AOP的底子捋一遍。Spring AOP的核心是動態(tài)代理它不像AspectJ那樣去修改字節(jié)碼而是利用JDK動態(tài)代理或CGLIB給目標Bean生成一個代理對象外部調(diào)用的時候?qū)嶋H調(diào)用的就是代理對象增強后的方法。JDK代理要求目標類實現(xiàn)接口生成的代理類只對接口方法生效CGLIB則是通過生成目標類的子類來實現(xiàn)代理不要求接口。Spring Boot 2.x之后默認優(yōu)先用CGLIB除非手動設(shè)置 proxyTargetClassfalse。理解這個機制的意義在于后面排查“AOP沒生效”時十有八九都和代理有關(guān)。AOP的通知類型里有五種Before前置、After后置、AfterReturning返回后、AfterThrowing異常后、Around環(huán)繞。在異步切面場景里位置不同語義完全不同。比如記錄用戶操作日志通常用Around比較合適因為它能同時拿到方法執(zhí)行前參數(shù)、執(zhí)行后的結(jié)果和執(zhí)行耗時而單純的接口訪問統(tǒng)計Before加AfterReturning就夠了。2. 核心原理剖析AOP切面里的異步到底發(fā)生了什么2.1 代理對象、切面Bean和異步執(zhí)行的協(xié)作關(guān)系可能有人會問AOP和異步這兩個機制是怎么串在一起的說出來其實很簡單Spring的 Async 底層用的也是代理機制。當你在某個方法上標注 AsyncSpring會為主Bean再次生成一層異步代理。也就是說如果你的業(yè)務Bean先被AOP增強再被異步代理包裹那調(diào)用鏈路就是外部調(diào)用 - 異步代理 - AOP代理 - 目標方法。這也是為什么異步切面方案里切面類本身既是一個Spring Bean被AOP機制掃描切面方法內(nèi)部又要調(diào)用異步Bean的方法去執(zhí)行耗時任務。兩者各司其職AOP負責攔截主流程的調(diào)用點異步代理負責把任務從當前線程中“丟”到線程池。有個關(guān)鍵細節(jié)必須強調(diào)切面切片只對Spring容器管理的Bean生效。如果你的目標類是被 new 出來的或者Bean的創(chuàng)建過程繞過了Spring IoC容器那么任何AOP都不會生效。很多新手把Controller、Service的實例手動new出來用結(jié)果切面一點反應都沒有就是栽在這里。2.2 異步方法的事務問題跨線程就是跨事務這是整套方案里最容易翻車的知識點。Spring事務的底層實現(xiàn)是基于ThreadLocal把數(shù)據(jù)庫連接綁定到當前線程上的DataSourceTransactionManager持有的連接本質(zhì)上屬于發(fā)起事務的那個線程。這意味著你在主線程里開啟了事務A然后調(diào)用了一個異步方法去更新數(shù)據(jù)那個異步方法執(zhí)行時用的是線程池里的另一個線程它不在事務A的上下文中只能自己開一個獨立的事務。畫個生活化類比事務就像一個只能在固定區(qū)間內(nèi)行駛的工作證主線程辦了證但異步線程是另一個區(qū)的員工沒有這個證進去就得重新辦一張臨時證。所以異步方法里提交的數(shù)據(jù)要么用自己的新事務要么完全不參與事務絕不會被主線程的事務統(tǒng)一回滾。這就帶來一個鮮明的實戰(zhàn)后果如果你在切面里異步寫日志主業(yè)務流程成功異步日志寫入?yún)s在最后一步失敗主流程不會感知日志也不會跟著回滾。對“日志能不能丟”這個問題業(yè)務上要有明確預期。我在做操作審計時這個特性其實是好事——審計和業(yè)務解耦業(yè)務失敗也照樣得記錄失敗日志。2.3 異步切面里的異常處理邊界異步方法拋出的異常默認不向上傳遞。主線程調(diào)異步方法的那一刻如果任務丟進線程池就返回了異常發(fā)生在其他線程主線程根本接不到。如果不處理線程池任務異常會被Executor吞掉連個日志都不留排查問題的時候特別憋屈。所以異步方法內(nèi)部的try-catch是必備操作尤其是做日志記錄這種不能因為子線程失敗影響主流程的場景。對需要感知結(jié)果的異步任務還可以用 Future 或 CompletableFuture 返回值主線程通過 get() 拿結(jié)果但要注意那樣又會引入阻塞等待和異步的初衷相矛盾。實操經(jīng)驗是日志、埋點、通知類任務徹底不關(guān)心結(jié)果用完即走狀態(tài)同步類任務最多用 CompletableFuture 在回調(diào)里處理后續(xù)邏輯而不是同步等待。3. 從零搭建一個完整的AOP異步執(zhí)行示例3.1 環(huán)境準備與依賴引入這部分的示例基于 Spring Boot 2.7.xJDK 8及以上都行。核心依賴只有一個Spring Boot的web和aop starter其他的按項目實際需要加。下面是我用的 pom.xml 關(guān)鍵片段dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-aop/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-jdbc/artifactId /dependency如果你是做日志落庫的場景還需要把數(shù)據(jù)庫相關(guān)的依賴加進來。但要注意aop starter是必須的它會把 aspectjweaver 和 Spring AOP 相關(guān)類都拉進來缺少這個依賴注解和切面類都不會生效。3.2 定義線程池配置核心參數(shù)的一次到位直接使用Spring默認的異步執(zhí)行器不是不行但坑太多。默認的 SimpleAsyncTaskExecutor 有個特點它每次執(zhí)行都會創(chuàng)建一個新線程不是真正意義上的復用高并發(fā)下線程數(shù)量會失控。更穩(wěn)妥的做法是自建一個 ThreadPoolTaskExecutor 并且指定線程名前綴方便排查日志時知道是哪個線程跑的。下面是我項目里比較成熟的一套配置核心參數(shù)以“IO密集型任務”為基準設(shè)計Configuration EnableAsync public class AsyncPoolConfig { Bean(asyncExecutor) public ThreadPoolTaskExecutor asyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); // 核心線程數(shù)日常并發(fā)量的大概值留點余量 executor.setCorePoolSize(8); // 最大線程數(shù)瞬時尖峰時的上限 executor.setMaxPoolSize(16); // 隊列容量當核心線程滿時任務先排隊 executor.setQueueCapacity(200); // 線程名前綴日志和監(jiān)控里一搜就能定位 executor.setThreadNamePrefix(async-log-); // 空閑線程存活時間 executor.setKeepAliveSeconds(60); // 拒絕策略隊列和線程都滿了由調(diào)用者線程執(zhí)行 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }這里的每個參數(shù)都不是拍腦袋定的需要結(jié)合業(yè)務量去推。核心線程數(shù)先按接口QPS估算一般日常請求量下查詢或插入日志的耗時如果是10毫秒一個線程一秒能處理100個任務那么100 QPS只需要一個線程就能撐住考慮到波動留三四倍余量選的8個核心線程足夠。隊列容量不要設(shè)得太大太大雖然不丟任務但會造成任務積壓日志延遲嚴重200這個值對日志類任務來說能容忍突發(fā)流量而不丟數(shù)據(jù)。拒絕策略我選 CallerRunsPolicy 是刻意的。線程池滿了之后這個策略會讓提交任務的線程也就是主業(yè)務線程自己去執(zhí)行任務相當于降級回同步模式。這樣做的優(yōu)點是絕對不丟任務代價是某種極端情況下主線程會被拖慢。相比丟棄任務丟日志我更愿意接受偶爾的全同步兜底關(guān)鍵日志一條都不能少。還要注意最后一行 executor.initialize() 不是隨便寫的。ThreadPoolTaskExecutor 在容器啟動時如果聲明成 Bean 且注入位置正確通常Spring會幫你初始化但有些場景下提前調(diào) getThreadPoolExecutor() 或使用 Lazy 注入時手動 initialize 能避免一些奇怪的懶加載問題。3.3 編寫一個自定義操作日志注解有了線程池我們還需要一個入口來標記“哪些方法要走異步切面”。這里我選擇自定義注解而不是直接寫 Around(execution(...)) 這種大范圍切點。自定義注解的好處是精確到方法級別想控制哪些接口需要記錄就在方法上標一個注解不用去匹配包路徑也不容易誤傷其他方法。Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) Documented public interface OperationLog { // 操作模塊名 String module() default ; // 操作類型如查詢、新增、修改、刪除 String type() default QUERY; // 備注信息 String desc() default ; }RetentionPolicy.RUNTIME 必須保留否則Spring AOP在運行期拿不到注解信息。這個注解本身不包含復雜邏輯它存在的意義是給切面一個“鉤子”。3.4 編寫異步切面類接下來是核心部分——異步切面。先直接放完整代碼然后再逐段解釋。Component Aspect public class OperationLogAspect { private static final Logger log LoggerFactory.getLogger(OperationLogAspect.class); Autowired private AsyncLogHandler asyncLogHandler; Around(annotation(operationLog)) public Object record(ProceedingJoinPoint joinPoint, OperationLog operationLog) throws Throwable { long startTime System.currentTimeMillis(); Object result; try { result joinPoint.proceed(); } catch (Throwable throwable) { // 業(yè)務方法執(zhí)行失敗也照常記錄日志讓審計知道發(fā)生了異常 asyncLogHandler.save(buildLog(joinPoint, operationLog, startTime, null, throwable.getMessage())); throw throwable; } long costTime System.currentTimeMillis() - startTime; // 業(yè)務成功異步記錄正常日志 asyncLogHandler.save(buildLog(joinPoint, operationLog, startTime, costTime, null)); return result; } private OperationLogEntity buildLog(ProceedingJoinPoint joinPoint, OperationLog operationLog, long startTime, Long costTime, String errorMsg) { OperationLogEntity entity new OperationLogEntity(); entity.setModule(operationLog.module()); entity.setType(operationLog.type()); entity.setDesc(operationLog.desc()); entity.setMethod(joinPoint.getSignature().toShortString()); Object[] args joinPoint.getArgs(); if (args ! null args.length 0) { entity.setParams(JSON.toJSONString(args)); } entity.setStartTime(new Date(startTime)); entity.setCostTime(costTime); entity.setErrorMsg(errorMsg); return entity; } }切面本身的執(zhí)行時機是在業(yè)務方法調(diào)用的線程里也就是說攔截、計時、參數(shù)拼接這些輕量操作依然消耗主線程時間只不過真正耗時的數(shù)據(jù)庫寫入被我們轉(zhuǎn)嫁到了異步線程池。注意到切面里 try-catch 了業(yè)務方法的異常目的是保證無論業(yè)務成功還是失敗操作系統(tǒng)日志都被記錄不會因為主流程報錯就丟失審計信息。可能有人會問既然用了Around通知是不是所有邏輯都寫在切面里就夠了為什么還要單獨搞一個 AsyncLogHandler Bean原因很簡單Async 注解必須作用在由Spring容器管理且通過代理調(diào)用的方法上如果你直接在切面類自己的方法上加 Async而被切面類內(nèi)部直接調(diào)用的方法是不經(jīng)過代理的異步就靜默失效了。所以把異步方法抽到另一個獨立Bean中通過自動注入來調(diào)用才能保證代理生效。Component public class AsyncLogHandler { private static final Logger log LoggerFactory.getLogger(AsyncLogHandler.class); Async(asyncExecutor) public void save(OperationLogEntity entity) { try { // 這里模擬真實落庫或發(fā)送到消息隊列 log.info(異步保存日志: {}, JSON.toJSONString(entity)); Thread.sleep(100); } catch (Exception e) { log.error(異步日志保存失敗, e); } } }AsyncLogHandler 的 save 方法上有 Async(asyncExecutor)這個注解告訴Spring調(diào)用這個方法時不直接在當前線程里執(zhí)行而是把它封裝成一個任務丟進 asyncExecutor 這個線程池。方法內(nèi)部我專門 try-catch 了一把雖然日志保存不會因為異常影響主流程但如果不捕獲異常信息可能直接丟了后續(xù)想排查日志缺失原因都沒得查。這里的 Thread.sleep(100) 是刻意模擬耗時場景用來在測試時驗證主線程確實沒被拖慢。如果只想對切面內(nèi)一小部分邏輯做異步而不想引入額外的Async方法也可以結(jié)合CompletableFuture在切面里提交任務但實際效果不如獨立異步Bean清晰推薦用上面的寫法。3.5 在業(yè)務方法上打上注解然后是業(yè)務側(cè)。拿一個簡單的訂單查詢接口舉例RestController RequestMapping(/order) public class OrderController { GetMapping(/detail) OperationLog(module 訂單模塊, type QUERY, desc 查詢訂單詳情) public ResultString getOrderDetail(RequestParam(orderId) Long orderId) { // 模擬業(yè)務處理比如查庫、調(diào)外部接口 return Result.success(訂單詳情數(shù)據(jù)); } }加上 OperationLog 之后這個接口一旦被調(diào)用切面就會攔截。你不需要在業(yè)務代碼里寫任何日志相關(guān)邏輯所有橫切關(guān)注點都集中在切面和異步處理器里代碼整潔度比過去一行行手寫日志高出一大截。3.6 啟動驗證與耗時對比寫一個小的測試Controller接口驗證異步效果。開啟兩個請求第一個走沒有異步切面的普通接口第二個走上文加了日志注解的接口。我用一個簡單的循環(huán)調(diào)用接口100次統(tǒng)計平均響應時間。測試結(jié)果非常直觀場景平均響應時間日志寫入是否完成無AOP切面25ms無日志AOP同步寫入日志145ms已完成AOP異步寫入日志38ms異步完成日志稍后落庫再看線程池日志輸出里會出現(xiàn)類似 async-log-1、async-log-2 的線程名而主線程是 http-nio-8080-exec-XX。這從側(cè)面印證了日志任務確實被移交給獨立線程處理了主線程沒有被阻塞。4. 實戰(zhàn)中的坑與排查技巧4.1 異步靜默失效為什么 Async 加了卻沒效果這個坑我遇到太多次了。典型場景是代碼里明明寫了 Async但是方法還是同步執(zhí)行接口依舊被拖慢。原因無非下面幾種首先檢查啟動類或配置類有沒有加 EnableAsync。這個注解是開啟異步代理的總開關(guān)漏了它Async 就是一個普通注釋Spring根本不會處理。其次是代理失效問題。如果異步方法是被同類中的另一個方法直接調(diào)用的比如在同一個Service里methodA() 調(diào) methodB()而 methodB() 上標注了 AsyncmethodA() 里直接調(diào) methodB() 時走的是 this.methodB()不經(jīng)過Spring生成的代理對象異步自然就失效了。正確做法是把 methodB 拆到另一個Service里或者注入自身的代理對象。再就是方法訪問修飾符問題。Spring AOP默認只能代理public方法如果 Async 標注在private或protected方法上代理邏輯根本不會生效。這和AOP的CGLIB機制有關(guān)確保方法是public是基本要求。排查這個問題時可以開啟Spring AOP的debug日志在 application.yml 里加這么一行配置logging: level: org.springframework.aop: DEBUG然后啟動看控制臺如果輸出中包含“proxy”相關(guān)的增強日志說明AOP代理創(chuàng)建成功了。也可以用強制類型轉(zhuǎn)換來驗證AsyncLogHandler handler applicationContext.getBean(AsyncLogHandler.class); System.out.println(是否為代理對象: (handler instanceof org.springframework.aop.framework.ProxyFactoryBean));或者直接打印類名看到class ...$$EnhancerBySpringCGLIB$$...這樣的后綴就說明代理生效了。4.2 事務不回滾異步任務里寫的數(shù)據(jù)庫到底算什么這個問題的場景特別容易混淆。假如你在一個事務方法里調(diào)用了異步日志方法異步方法內(nèi)部自己去更新另一張表接著主事務拋異常回滾。很多人第一反應是“我都回滾了異步里寫的數(shù)據(jù)也應該沒了”但實際上異步方法用的是單獨事務主事務的回滾管不到它。所以設(shè)計時有一條紅線需要心里有數(shù)凡是和主業(yè)務有強一致性要求的寫操作都不能放進異步切面。比如訂單金額變更后更新賬戶余額表就不能用這種異步方案一旦主流程成功但異步更新失敗數(shù)據(jù)就永久不一致了。只有日志、審計、通知這類允許最終一致甚至允許丟失的數(shù)據(jù)才適合放進異步邏輯。如果一定要在異步任務里做數(shù)據(jù)庫操作建議方法上顯式加上 Transactional(propagation Propagation.REQUIRES_NEW)讓異步方法自己開啟一個獨立事務并確保你不希望它被主事務影響時業(yè)務是接受的。不要指望Spring默認行為幫你兜底。4.3 線程池滿與拒絕策略的取舍線程池參數(shù)設(shè)計不合理最常見的現(xiàn)象有兩種。一種是核心線程數(shù)太小、隊列容量太小高并發(fā)時大量任務被拒絕日志大量丟失另一種是核心線程數(shù)開太大低并發(fā)時白白占著系統(tǒng)資源。我在線上項目經(jīng)歷過一次報警某次大促流量沖高接口QPS從平時的500飆到3000日志切面線程池隊列迅速填滿由于當時配置的是 DiscardPolicy 策略超出容量的任務全被靜默丟棄了。雖然業(yè)務接口沒受影響但事后復盤發(fā)現(xiàn)那段時間的操作日志缺口很大。從那之后我所有核心系統(tǒng)的線程池拒絕策略一律改成沒得商量的一條要么CallerRunsPolicy要么AbortPolicy加報警。丟數(shù)據(jù)永遠比拖慢接口更不可接受尤其是審計類數(shù)據(jù)少一條后續(xù)糾紛都說不清楚。CallerRunsPolicy雖然會讓主線程在極端情況下幫忙干異步活但這是保數(shù)據(jù)的底線操作。同時線程池監(jiān)控必須跟上。Spring的ThreadPoolTaskExecutor可以通過 Actuator 暴露指標或者你自己定時輸出線程池活躍數(shù)、隊列大小、任務完成數(shù)。我習慣在日志里每5分鐘打一次線程池狀態(tài)Scheduled(cron 0 */5 * * * ?) public void monitorAsyncPool() { ThreadPoolTaskExecutor executor SpringContextHolder.getBean(asyncExecutor); ThreadPoolExecutor poolExecutor executor.getThreadPoolExecutor(); log.info(線程池大小{}, 活躍數(shù){}, 隊列容量{}, 隊列當前{}, 完成任務數(shù){}, poolExecutor.getPoolSize(), poolExecutor.getActiveCount(), executor.getQueueCapacity(), poolExecutor.getQueue().size(), poolExecutor.getCompletedTaskCount()); }發(fā)現(xiàn)隊列容量長時間一半以上就要考慮擴容或者排查是否有慢任務卡住了線程。異步任務也不能完全撒手不管監(jiān)控在手心里不慌。4.4 異步任務內(nèi)容膨脹從輕量日志到“偽異步”還有一個實戰(zhàn)體會很多人搞完了異步切面覺得“反正都異步了”就把重業(yè)務邏輯也往異步里塞這是大忌。異步不改變?nèi)蝿毡旧淼暮臅r它只是讓耗時不再阻塞主線程但如果任務提交速度大于消費速度隊列會積壓最終表現(xiàn)為日志延遲越來越久甚至觸發(fā)拒絕策略。有一次我們接了一個需求用戶下單成功后切面異步調(diào)用推薦算法實時計算相似商品并更新推薦列表。這個算法單個就要跑兩三秒并發(fā)高的時候隊列里堆了幾千個任務用戶下單后可能十幾分鐘后才看到推薦更新。后來把這個重任務移到消息隊列由獨立服務異步消費才把問題解決。用AOP異步方案的準則是單個任務執(zhí)行時間不超過幾百毫秒任務本身無狀態(tài)不依賴主流程返回結(jié)果允許一定的延遲到達。凡是滿足不了這三點還是老老實實用MQ或定時任務去扛別在AOP切面里硬磨。5. 結(jié)合實際項目的一點總結(jié)與擴展建議這個方案在我項目里已經(jīng)穩(wěn)定運行一年多再聊幾個擴展方向。如果日志數(shù)據(jù)量很大不需要每個異步任務都去實時寫數(shù)據(jù)庫可以先寫到本地內(nèi)存隊列批量攢到一定條數(shù)或每隔幾秒統(tǒng)一刷庫減少數(shù)據(jù)庫I/O壓力。Spring的 Async 配合批量插入是天然契合的異步線程池本身就是一批一批地消費任務。如果對日志的完整性有更高要求還可以在切面里把日志實體先序列化為JSON異步任務里先寫本地文件再由其他組件同步到日志平臺。這樣切面幾乎零耗時也不依賴外部存儲的可用性。總之思路是固定的AOP負責“截”數(shù)據(jù)異步負責“搬”數(shù)據(jù)線程池負責“穩(wěn)住”吞吐。我在實際使用中還有一個體會可能就是這套方案最核心的底線思維異步化不能丟重點也不能全盤異步化。非核心動作才配異步核心鏈路該同步還是同步否則排查線上問題時你會發(fā)現(xiàn)明明功能正常數(shù)據(jù)卻到處缺角那個滋味比接口慢一點難受得多。比例怎么拿捏多踩幾次坑就有感覺了。 Spring Boot AOP異步執(zhí)行：徹底告別日志切面拖慢接口
做后端開發(fā)這幾年我在日志記錄和操作審計這類需求上栽過不少跟頭。最早是直接在業(yè)務代碼里一行行手寫日志后來改用AOP切面統(tǒng)一處理切面是清爽了可新的問題又來了——日志接口慢、消息隊列抖動、第三方通知超時不管哪個環(huán)節(jié)出幺蛾子業(yè)務接口就跟著遭殃。這時候我才意識到切面里的這些非核心動作壓根就不該跟主流程綁在同一個線程里同步執(zhí)行。于是就有了這套“Spring Boot AOP 異步執(zhí)行方案”。說白了就是在AOP切面里把耗時的橫切邏輯日志落庫、操作審計、埋點上報、消息通知交給獨立的線程池異步執(zhí)行讓主業(yè)務線程只干自己的正事。這篇文章會從方案選型、原理剖析、完整代碼、實測踩坑四個層面展開適合剛接觸Spring Boot的初級開發(fā)者也適合已經(jīng)在用AOP但發(fā)現(xiàn)切面拖慢接口性能、想優(yōu)化的人。讀完你不僅能照抄一套能跑的代碼還能搞清楚里面每個配置背后的為什么。1. 為什么必須用AOP異步一個日志切面拖慢接口的教訓1.1 從同步切面到異步切面的真實背景先講一個我實際遇到的場景。某個項目里給所有Controller層接口加了一個操作日志切面需求是記錄每個請求的用戶、路徑、參數(shù)、響應時間和狀態(tài)碼。一開始邏輯很簡單業(yè)務方法跑完切面里拼一條日志然后同步寫入數(shù)據(jù)庫日志表。單機低并發(fā)的時候一切正常接口響應時間差不多在30到50毫秒左右。后來數(shù)據(jù)量上來日志表膨脹插入語句從兩毫秒慢慢漲到了十幾毫秒碰上數(shù)據(jù)庫鎖競爭、連接池不夠用的時候切面里的日志插入甚至要等上百毫秒。最要命的是日志寫入失敗還會直接拋出異常把原本正常的業(yè)務請求也給打掛了。這就是典型的橫切邏輯對主流程的“反向污染”——你只是想記個日志結(jié)果它把接口搞超時了。為了解耦和提速我當時先想到的是把日志寫入改成異步但最開始的實現(xiàn)很粗糙就是在切面方法里手動 new 一個線程去寫日志。這樣做的后果是每次請求都要創(chuàng)建新線程頻繁的線程上下文切換開銷反而更大而且線程不受Spring容器管理連接池、事務、異常處理全都跟不上。后來才老老實實回到Spring的 Async 體系用線程池統(tǒng)一管理異步任務。1.2 三個候選方案的取舍對比在確定用Spring自帶異步之前我對比過三種常見的異步切面實現(xiàn)方式方案實現(xiàn)方式優(yōu)點缺點手動創(chuàng)建線程切面里直接 new Thread簡單粗暴代碼量最少線程不受管控頻繁創(chuàng)建銷毀開銷大無法復用無法監(jiān)控消息隊列通知切面里投遞MQ消息下游消費解耦徹底削峰能力強適合重任務引入額外中間件排查問題鏈路變長小項目運維成本高Spring Async異步執(zhí)行切面委托線程池執(zhí)行任務原生支持線程可復用可用線程池監(jiān)控和Spring事務/異常體系兼容需要正確配置線程池異步方法內(nèi)部的事務和主事務是隔離的最終我選擇了 Spring Async 方案。理由是這套方案對現(xiàn)有代碼侵入最小、不需要額外部署中間件而且線程池可以精細控制核心線程數(shù)、隊列容量、拒絕策略都能自己定制。對于日志記錄、統(tǒng)計埋點這類輕量異步任務來說完全夠用。1.3 先搞清楚AOP在Spring里的執(zhí)行機制聊異步之前得先把AOP的底子捋一遍。Spring AOP的核心是動態(tài)代理它不像AspectJ那樣去修改字節(jié)碼而是利用JDK動態(tài)代理或CGLIB給目標Bean生成一個代理對象外部調(diào)用的時候?qū)嶋H調(diào)用的就是代理對象增強后的方法。JDK代理要求目標類實現(xiàn)接口生成的代理類只對接口方法生效CGLIB則是通過生成目標類的子類來實現(xiàn)代理不要求接口。Spring Boot 2.x之后默認優(yōu)先用CGLIB除非手動設(shè)置 proxyTargetClassfalse。理解這個機制的意義在于后面排查“AOP沒生效”時十有八九都和代理有關(guān)。AOP的通知類型里有五種Before前置、After后置、AfterReturning返回后、AfterThrowing異常后、Around環(huán)繞。在異步切面場景里位置不同語義完全不同。比如記錄用戶操作日志通常用Around比較合適因為它能同時拿到方法執(zhí)行前參數(shù)、執(zhí)行后的結(jié)果和執(zhí)行耗時而單純的接口訪問統(tǒng)計Before加AfterReturning就夠了。2. 核心原理剖析AOP切面里的異步到底發(fā)生了什么2.1 代理對象、切面Bean和異步執(zhí)行的協(xié)作關(guān)系可能有人會問AOP和異步這兩個機制是怎么串在一起的說出來其實很簡單Spring的 Async 底層用的也是代理機制。當你在某個方法上標注 AsyncSpring會為主Bean再次生成一層異步代理。也就是說如果你的業(yè)務Bean先被AOP增強再被異步代理包裹那調(diào)用鏈路就是外部調(diào)用 - 異步代理 - AOP代理 - 目標方法。這也是為什么異步切面方案里切面類本身既是一個Spring Bean被AOP機制掃描切面方法內(nèi)部又要調(diào)用異步Bean的方法去執(zhí)行耗時任務。兩者各司其職AOP負責攔截主流程的調(diào)用點異步代理負責把任務從當前線程中“丟”到線程池。有個關(guān)鍵細節(jié)必須強調(diào)切面切片只對Spring容器管理的Bean生效。如果你的目標類是被 new 出來的或者Bean的創(chuàng)建過程繞過了Spring IoC容器那么任何AOP都不會生效。很多新手把Controller、Service的實例手動new出來用結(jié)果切面一點反應都沒有就是栽在這里。2.2 異步方法的事務問題跨線程就是跨事務這是整套方案里最容易翻車的知識點。Spring事務的底層實現(xiàn)是基于ThreadLocal把數(shù)據(jù)庫連接綁定到當前線程上的DataSourceTransactionManager持有的連接本質(zhì)上屬于發(fā)起事務的那個線程。這意味著你在主線程里開啟了事務A然后調(diào)用了一個異步方法去更新數(shù)據(jù)那個異步方法執(zhí)行時用的是線程池里的另一個線程它不在事務A的上下文中只能自己開一個獨立的事務。畫個生活化類比事務就像一個只能在固定區(qū)間內(nèi)行駛的工作證主線程辦了證但異步線程是另一個區(qū)的員工沒有這個證進去就得重新辦一張臨時證。所以異步方法里提交的數(shù)據(jù)要么用自己的新事務要么完全不參與事務絕不會被主線程的事務統(tǒng)一回滾。這就帶來一個鮮明的實戰(zhàn)后果如果你在切面里異步寫日志主業(yè)務流程成功異步日志寫入?yún)s在最后一步失敗主流程不會感知日志也不會跟著回滾。對“日志能不能丟”這個問題業(yè)務上要有明確預期。我在做操作審計時這個特性其實是好事——審計和業(yè)務解耦業(yè)務失敗也照樣得記錄失敗日志。2.3 異步切面里的異常處理邊界異步方法拋出的異常默認不向上傳遞。主線程調(diào)異步方法的那一刻如果任務丟進線程池就返回了異常發(fā)生在其他線程主線程根本接不到。如果不處理線程池任務異常會被Executor吞掉連個日志都不留排查問題的時候特別憋屈。所以異步方法內(nèi)部的try-catch是必備操作尤其是做日志記錄這種不能因為子線程失敗影響主流程的場景。對需要感知結(jié)果的異步任務還可以用 Future 或 CompletableFuture 返回值主線程通過 get() 拿結(jié)果但要注意那樣又會引入阻塞等待和異步的初衷相矛盾。實操經(jīng)驗是日志、埋點、通知類任務徹底不關(guān)心結(jié)果用完即走狀態(tài)同步類任務最多用 CompletableFuture 在回調(diào)里處理后續(xù)邏輯而不是同步等待。3. 從零搭建一個完整的AOP異步執(zhí)行示例3.1 環(huán)境準備與依賴引入這部分的示例基于 Spring Boot 2.7.xJDK 8及以上都行。核心依賴只有一個Spring Boot的web和aop starter其他的按項目實際需要加。下面是我用的 pom.xml 關(guān)鍵片段dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-aop/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-jdbc/artifactId /dependency如果你是做日志落庫的場景還需要把數(shù)據(jù)庫相關(guān)的依賴加進來。但要注意aop starter是必須的它會把 aspectjweaver 和 Spring AOP 相關(guān)類都拉進來缺少這個依賴注解和切面類都不會生效。3.2 定義線程池配置核心參數(shù)的一次到位直接使用Spring默認的異步執(zhí)行器不是不行但坑太多。默認的 SimpleAsyncTaskExecutor 有個特點它每次執(zhí)行都會創(chuàng)建一個新線程不是真正意義上的復用高并發(fā)下線程數(shù)量會失控。更穩(wěn)妥的做法是自建一個 ThreadPoolTaskExecutor 并且指定線程名前綴方便排查日志時知道是哪個線程跑的。下面是我項目里比較成熟的一套配置核心參數(shù)以“IO密集型任務”為基準設(shè)計Configuration EnableAsync public class AsyncPoolConfig { Bean(asyncExecutor) public ThreadPoolTaskExecutor asyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); // 核心線程數(shù)日常并發(fā)量的大概值留點余量 executor.setCorePoolSize(8); // 最大線程數(shù)瞬時尖峰時的上限 executor.setMaxPoolSize(16); // 隊列容量當核心線程滿時任務先排隊 executor.setQueueCapacity(200); // 線程名前綴日志和監(jiān)控里一搜就能定位 executor.setThreadNamePrefix(async-log-); // 空閑線程存活時間 executor.setKeepAliveSeconds(60); // 拒絕策略隊列和線程都滿了由調(diào)用者線程執(zhí)行 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }這里的每個參數(shù)都不是拍腦袋定的需要結(jié)合業(yè)務量去推。核心線程數(shù)先按接口QPS估算一般日常請求量下查詢或插入日志的耗時如果是10毫秒一個線程一秒能處理100個任務那么100 QPS只需要一個線程就能撐住考慮到波動留三四倍余量選的8個核心線程足夠。隊列容量不要設(shè)得太大太大雖然不丟任務但會造成任務積壓日志延遲嚴重200這個值對日志類任務來說能容忍突發(fā)流量而不丟數(shù)據(jù)。拒絕策略我選 CallerRunsPolicy 是刻意的。線程池滿了之后這個策略會讓提交任務的線程也就是主業(yè)務線程自己去執(zhí)行任務相當于降級回同步模式。這樣做的優(yōu)點是絕對不丟任務代價是某種極端情況下主線程會被拖慢。相比丟棄任務丟日志我更愿意接受偶爾的全同步兜底關(guān)鍵日志一條都不能少。還要注意最后一行 executor.initialize() 不是隨便寫的。ThreadPoolTaskExecutor 在容器啟動時如果聲明成 Bean 且注入位置正確通常Spring會幫你初始化但有些場景下提前調(diào) getThreadPoolExecutor() 或使用 Lazy 注入時手動 initialize 能避免一些奇怪的懶加載問題。3.3 編寫一個自定義操作日志注解有了線程池我們還需要一個入口來標記“哪些方法要走異步切面”。這里我選擇自定義注解而不是直接寫 Around(execution(...)) 這種大范圍切點。自定義注解的好處是精確到方法級別想控制哪些接口需要記錄就在方法上標一個注解不用去匹配包路徑也不容易誤傷其他方法。Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) Documented public interface OperationLog { // 操作模塊名 String module() default ; // 操作類型如查詢、新增、修改、刪除 String type() default QUERY; // 備注信息 String desc() default ; }RetentionPolicy.RUNTIME 必須保留否則Spring AOP在運行期拿不到注解信息。這個注解本身不包含復雜邏輯它存在的意義是給切面一個“鉤子”。3.4 編寫異步切面類接下來是核心部分——異步切面。先直接放完整代碼然后再逐段解釋。Component Aspect public class OperationLogAspect { private static final Logger log LoggerFactory.getLogger(OperationLogAspect.class); Autowired private AsyncLogHandler asyncLogHandler; Around(annotation(operationLog)) public Object record(ProceedingJoinPoint joinPoint, OperationLog operationLog) throws Throwable { long startTime System.currentTimeMillis(); Object result; try { result joinPoint.proceed(); } catch (Throwable throwable) { // 業(yè)務方法執(zhí)行失敗也照常記錄日志讓審計知道發(fā)生了異常 asyncLogHandler.save(buildLog(joinPoint, operationLog, startTime, null, throwable.getMessage())); throw throwable; } long costTime System.currentTimeMillis() - startTime; // 業(yè)務成功異步記錄正常日志 asyncLogHandler.save(buildLog(joinPoint, operationLog, startTime, costTime, null)); return result; } private OperationLogEntity buildLog(ProceedingJoinPoint joinPoint, OperationLog operationLog, long startTime, Long costTime, String errorMsg) { OperationLogEntity entity new OperationLogEntity(); entity.setModule(operationLog.module()); entity.setType(operationLog.type()); entity.setDesc(operationLog.desc()); entity.setMethod(joinPoint.getSignature().toShortString()); Object[] args joinPoint.getArgs(); if (args ! null args.length 0) { entity.setParams(JSON.toJSONString(args)); } entity.setStartTime(new Date(startTime)); entity.setCostTime(costTime); entity.setErrorMsg(errorMsg); return entity; } }切面本身的執(zhí)行時機是在業(yè)務方法調(diào)用的線程里也就是說攔截、計時、參數(shù)拼接這些輕量操作依然消耗主線程時間只不過真正耗時的數(shù)據(jù)庫寫入被我們轉(zhuǎn)嫁到了異步線程池。注意到切面里 try-catch 了業(yè)務方法的異常目的是保證無論業(yè)務成功還是失敗操作系統(tǒng)日志都被記錄不會因為主流程報錯就丟失審計信息。可能有人會問既然用了Around通知是不是所有邏輯都寫在切面里就夠了為什么還要單獨搞一個 AsyncLogHandler Bean原因很簡單Async 注解必須作用在由Spring容器管理且通過代理調(diào)用的方法上如果你直接在切面類自己的方法上加 Async而被切面類內(nèi)部直接調(diào)用的方法是不經(jīng)過代理的異步就靜默失效了。所以把異步方法抽到另一個獨立Bean中通過自動注入來調(diào)用才能保證代理生效。Component public class AsyncLogHandler { private static final Logger log LoggerFactory.getLogger(AsyncLogHandler.class); Async(asyncExecutor) public void save(OperationLogEntity entity) { try { // 這里模擬真實落庫或發(fā)送到消息隊列 log.info(異步保存日志: {}, JSON.toJSONString(entity)); Thread.sleep(100); } catch (Exception e) { log.error(異步日志保存失敗, e); } } }AsyncLogHandler 的 save 方法上有 Async(asyncExecutor)這個注解告訴Spring調(diào)用這個方法時不直接在當前線程里執(zhí)行而是把它封裝成一個任務丟進 asyncExecutor 這個線程池。方法內(nèi)部我專門 try-catch 了一把雖然日志保存不會因為異常影響主流程但如果不捕獲異常信息可能直接丟了后續(xù)想排查日志缺失原因都沒得查。這里的 Thread.sleep(100) 是刻意模擬耗時場景用來在測試時驗證主線程確實沒被拖慢。如果只想對切面內(nèi)一小部分邏輯做異步而不想引入額外的Async方法也可以結(jié)合CompletableFuture在切面里提交任務但實際效果不如獨立異步Bean清晰推薦用上面的寫法。3.5 在業(yè)務方法上打上注解然后是業(yè)務側(cè)。拿一個簡單的訂單查詢接口舉例RestController RequestMapping(/order) public class OrderController { GetMapping(/detail) OperationLog(module 訂單模塊, type QUERY, desc 查詢訂單詳情) public ResultString getOrderDetail(RequestParam(orderId) Long orderId) { // 模擬業(yè)務處理比如查庫、調(diào)外部接口 return Result.success(訂單詳情數(shù)據(jù)); } }加上 OperationLog 之后這個接口一旦被調(diào)用切面就會攔截。你不需要在業(yè)務代碼里寫任何日志相關(guān)邏輯所有橫切關(guān)注點都集中在切面和異步處理器里代碼整潔度比過去一行行手寫日志高出一大截。3.6 啟動驗證與耗時對比寫一個小的測試Controller接口驗證異步效果。開啟兩個請求第一個走沒有異步切面的普通接口第二個走上文加了日志注解的接口。我用一個簡單的循環(huán)調(diào)用接口100次統(tǒng)計平均響應時間。測試結(jié)果非常直觀場景平均響應時間日志寫入是否完成無AOP切面25ms無日志AOP同步寫入日志145ms已完成AOP異步寫入日志38ms異步完成日志稍后落庫再看線程池日志輸出里會出現(xiàn)類似 async-log-1、async-log-2 的線程名而主線程是 http-nio-8080-exec-XX。這從側(cè)面印證了日志任務確實被移交給獨立線程處理了主線程沒有被阻塞。4. 實戰(zhàn)中的坑與排查技巧4.1 異步靜默失效為什么 Async 加了卻沒效果這個坑我遇到太多次了。典型場景是代碼里明明寫了 Async但是方法還是同步執(zhí)行接口依舊被拖慢。原因無非下面幾種首先檢查啟動類或配置類有沒有加 EnableAsync。這個注解是開啟異步代理的總開關(guān)漏了它Async 就是一個普通注釋Spring根本不會處理。其次是代理失效問題。如果異步方法是被同類中的另一個方法直接調(diào)用的比如在同一個Service里methodA() 調(diào) methodB()而 methodB() 上標注了 AsyncmethodA() 里直接調(diào) methodB() 時走的是 this.methodB()不經(jīng)過Spring生成的代理對象異步自然就失效了。正確做法是把 methodB 拆到另一個Service里或者注入自身的代理對象。再就是方法訪問修飾符問題。Spring AOP默認只能代理public方法如果 Async 標注在private或protected方法上代理邏輯根本不會生效。這和AOP的CGLIB機制有關(guān)確保方法是public是基本要求。排查這個問題時可以開啟Spring AOP的debug日志在 application.yml 里加這么一行配置logging: level: org.springframework.aop: DEBUG然后啟動看控制臺如果輸出中包含“proxy”相關(guān)的增強日志說明AOP代理創(chuàng)建成功了。也可以用強制類型轉(zhuǎn)換來驗證AsyncLogHandler handler applicationContext.getBean(AsyncLogHandler.class); System.out.println(是否為代理對象: (handler instanceof org.springframework.aop.framework.ProxyFactoryBean));或者直接打印類名看到class ...$$EnhancerBySpringCGLIB$$...這樣的后綴就說明代理生效了。4.2 事務不回滾異步任務里寫的數(shù)據(jù)庫到底算什么這個問題的場景特別容易混淆。假如你在一個事務方法里調(diào)用了異步日志方法異步方法內(nèi)部自己去更新另一張表接著主事務拋異常回滾。很多人第一反應是“我都回滾了異步里寫的數(shù)據(jù)也應該沒了”但實際上異步方法用的是單獨事務主事務的回滾管不到它。所以設(shè)計時有一條紅線需要心里有數(shù)凡是和主業(yè)務有強一致性要求的寫操作都不能放進異步切面。比如訂單金額變更后更新賬戶余額表就不能用這種異步方案一旦主流程成功但異步更新失敗數(shù)據(jù)就永久不一致了。只有日志、審計、通知這類允許最終一致甚至允許丟失的數(shù)據(jù)才適合放進異步邏輯。如果一定要在異步任務里做數(shù)據(jù)庫操作建議方法上顯式加上 Transactional(propagation Propagation.REQUIRES_NEW)讓異步方法自己開啟一個獨立事務并確保你不希望它被主事務影響時業(yè)務是接受的。不要指望Spring默認行為幫你兜底。4.3 線程池滿與拒絕策略的取舍線程池參數(shù)設(shè)計不合理最常見的現(xiàn)象有兩種。一種是核心線程數(shù)太小、隊列容量太小高并發(fā)時大量任務被拒絕日志大量丟失另一種是核心線程數(shù)開太大低并發(fā)時白白占著系統(tǒng)資源。我在線上項目經(jīng)歷過一次報警某次大促流量沖高接口QPS從平時的500飆到3000日志切面線程池隊列迅速填滿由于當時配置的是 DiscardPolicy 策略超出容量的任務全被靜默丟棄了。雖然業(yè)務接口沒受影響但事后復盤發(fā)現(xiàn)那段時間的操作日志缺口很大。從那之后我所有核心系統(tǒng)的線程池拒絕策略一律改成沒得商量的一條要么CallerRunsPolicy要么AbortPolicy加報警。丟數(shù)據(jù)永遠比拖慢接口更不可接受尤其是審計類數(shù)據(jù)少一條后續(xù)糾紛都說不清楚。CallerRunsPolicy雖然會讓主線程在極端情況下幫忙干異步活但這是保數(shù)據(jù)的底線操作。同時線程池監(jiān)控必須跟上。Spring的ThreadPoolTaskExecutor可以通過 Actuator 暴露指標或者你自己定時輸出線程池活躍數(shù)、隊列大小、任務完成數(shù)。我習慣在日志里每5分鐘打一次線程池狀態(tài)Scheduled(cron 0 */5 * * * ?) public void monitorAsyncPool() { ThreadPoolTaskExecutor executor SpringContextHolder.getBean(asyncExecutor); ThreadPoolExecutor poolExecutor executor.getThreadPoolExecutor(); log.info(線程池大小{}, 活躍數(shù){}, 隊列容量{}, 隊列當前{}, 完成任務數(shù){}, poolExecutor.getPoolSize(), poolExecutor.getActiveCount(), executor.getQueueCapacity(), poolExecutor.getQueue().size(), poolExecutor.getCompletedTaskCount()); }發(fā)現(xiàn)隊列容量長時間一半以上就要考慮擴容或者排查是否有慢任務卡住了線程。異步任務也不能完全撒手不管監(jiān)控在手心里不慌。4.4 異步任務內(nèi)容膨脹從輕量日志到“偽異步”還有一個實戰(zhàn)體會很多人搞完了異步切面覺得“反正都異步了”就把重業(yè)務邏輯也往異步里塞這是大忌。異步不改變?nèi)蝿毡旧淼暮臅r它只是讓耗時不再阻塞主線程但如果任務提交速度大于消費速度隊列會積壓最終表現(xiàn)為日志延遲越來越久甚至觸發(fā)拒絕策略。有一次我們接了一個需求用戶下單成功后切面異步調(diào)用推薦算法實時計算相似商品并更新推薦列表。這個算法單個就要跑兩三秒并發(fā)高的時候隊列里堆了幾千個任務用戶下單后可能十幾分鐘后才看到推薦更新。后來把這個重任務移到消息隊列由獨立服務異步消費才把問題解決。用AOP異步方案的準則是單個任務執(zhí)行時間不超過幾百毫秒任務本身無狀態(tài)不依賴主流程返回結(jié)果允許一定的延遲到達。凡是滿足不了這三點還是老老實實用MQ或定時任務去扛別在AOP切面里硬磨。5. 結(jié)合實際項目的一點總結(jié)與擴展建議這個方案在我項目里已經(jīng)穩(wěn)定運行一年多再聊幾個擴展方向。如果日志數(shù)據(jù)量很大不需要每個異步任務都去實時寫數(shù)據(jù)庫可以先寫到本地內(nèi)存隊列批量攢到一定條數(shù)或每隔幾秒統(tǒng)一刷庫減少數(shù)據(jù)庫I/O壓力。Spring的 Async 配合批量插入是天然契合的異步線程池本身就是一批一批地消費任務。如果對日志的完整性有更高要求還可以在切面里把日志實體先序列化為JSON異步任務里先寫本地文件再由其他組件同步到日志平臺。這樣切面幾乎零耗時也不依賴外部存儲的可用性。總之思路是固定的AOP負責“截”數(shù)據(jù)異步負責“搬”數(shù)據(jù)線程池負責“穩(wěn)住”吞吐。我在實際使用中還有一個體會可能就是這套方案最核心的底線思維異步化不能丟重點也不能全盤異步化。非核心動作才配異步核心鏈路該同步還是同步否則排查線上問題時你會發(fā)現(xiàn)明明功能正常數(shù)據(jù)卻到處缺角那個滋味比接口慢一點難受得多。比例怎么拿捏多踩幾次坑就有感覺了。