1. 為什么要做異步調(diào)用從一次接口超時說起先講一個真實的場景。之前我給某個后臺管理系統(tǒng)做導(dǎo)出功能用戶在前端點了一個“導(dǎo)出報表”后端同步去數(shù)據(jù)庫里查幾十萬條數(shù)據(jù)再拼裝Excel最后返回文件流。單次執(zhí)行時間普遍在15秒以上前端請求早超時了用戶反復(fù)點了幾次后臺直接堆了好幾個線程在處理同一件事。這個問題的根源不在代碼性能而是同步阻塞的調(diào)用模型。請求線程從接收到返回全程霸占著不放導(dǎo)出的耗時越長能用線程就越少數(shù)據(jù)庫連接池、Tomcat線程池都被拖累服務(wù)整體吞吐跟著掉。SpringBoot下的異步調(diào)用就是面向這類場景的標(biāo)準(zhǔn)解法把耗時操作丟給另一個線程去執(zhí)行請求線程立刻返回調(diào)用方不需要干等。本文會從三種主流實現(xiàn)方式展開基于Async注解的線程池異步、基于WebFlux的響應(yīng)式異步、以及消息隊列的最終解耦同時把實際開發(fā)中容易踩的失效、線程耗盡、上下文丟失這幾個坑一并講清楚。2. SpringBoot異步調(diào)用整體方案盤點2.1 同步、異步、阻塞、非阻塞幾個概念先理清聊異步之前得先把概念統(tǒng)一一下不然下面代碼容易看混。同步和異步說的是調(diào)用方的處理方式。調(diào)一個方法必須等它跑完才能繼續(xù)做別的事就是同步調(diào)用后立即返回結(jié)果通過回調(diào)、輪詢、Future或事件來獲取就是異步。阻塞和非阻塞說的是線程的狀態(tài)。線程在等待結(jié)果期間被掛起、不能做別的事就是阻塞線程發(fā)起操作后不等待繼續(xù)往下執(zhí)行就是非阻塞。“異步”不等于“快”它只是讓當(dāng)前線程不被拖住。真正省時間的是并行的計算資源所以異步方案幾乎必須配套線程池否則異步任務(wù)全堆在單線程里反而更慢。2.2 三套方案怎么選方案核心機制適合場景需要注意的點Async 線程池AOP代理 獨立線程池執(zhí)行方法業(yè)務(wù)代碼里局部耗時的操作比如發(fā)通知、寫日志、生成報表自調(diào)用無效、線程池參數(shù)要配好WebFlux 響應(yīng)式異步基于Netty事件循環(huán) 響應(yīng)式流高并發(fā)IO密集型接口網(wǎng)關(guān)層、數(shù)據(jù)聚合接口全鏈路要反應(yīng)式不能混用阻塞調(diào)用消息隊列異步生產(chǎn)者發(fā)消息消費者獨立處理跨系統(tǒng)解耦、削峰填谷、可靠投遞場景需要額外中間件要考慮消息冪等這三套方案不是互相替代的關(guān)系。一個大型項目里接口內(nèi)部會用Async處理局部任務(wù)核心入口用WebFlux扛流量系統(tǒng)之間再用消息隊列解耦各管一段。3. Async注解最常用的異步實現(xiàn)方式3.1 第一個Demo從配置到生效Async是Spring框架自帶的能力SpringBoot里用起來很方便。先在啟動類或者配置類上加上EnableAsync意思是開啟異步調(diào)用的注解掃描SpringBootApplication EnableAsync public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }然后寫一個異步服務(wù)把需要異步執(zhí)行的方法用Async標(biāo)記Service public class NotificationService { Async public void sendSms(String mobile, String content) { // 模擬短信接口耗時 try { Thread.sleep(3000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } System.out.println(短信發(fā)送完成: mobile); } }調(diào)用方正常注入Service調(diào)用方法就行RestController RequestMapping(/api/order) public class OrderController { private final NotificationService notificationService; public OrderController(NotificationService notificationService) { this.notificationService notificationService; } PostMapping(/create) public String createOrder() { // 訂單業(yè)務(wù)邏輯 notificationService.sendSms(138****1234, 您的訂單已創(chuàng)建); return 下單成功; } }運行起來請求接口后響應(yīng)立刻返回不會等那3秒。短信任務(wù)在獨立的線程里執(zhí)行這就是最基礎(chǔ)的Async用法。3.2 為什么Async能生效代理機制要明白這是理解Async的關(guān)鍵點也是后續(xù)排查失效問題的理論基礎(chǔ)。Spring容器在啟動時掃描到Async注解的方法會給Bean生成一個代理對象。當(dāng)我們從容器里拿到這個Bean并調(diào)用方法時實際調(diào)用的是代理對象代理對象會先把任務(wù)提交給線程池然后返回。也就是說異步邏輯是被“包裝”進(jìn)去的而不是你寫的那個方法本身變成了異步?；谶@個原理有兩個經(jīng)典結(jié)論第一Async方法必須被Spring容器管理也就是放在Service、Component這些Bean里。第二同一個類內(nèi)部調(diào)用帶Async的方法不會走代理等于直接調(diào)用原方法異步失效。后面第6部分我會專門講這個坑。3.3 自定義線程池讓異步任務(wù)跑在正確的線程上默認(rèn)情況下Async用的是Spring自帶的SimpleAsyncTaskExecutor這個類每次執(zhí)行都會新建一個線程沒有復(fù)用機制。高并發(fā)場景下線程數(shù)無上限增長系統(tǒng)資源很快耗盡。生產(chǎn)環(huán)境必須自定義線程池。推薦用Java配置類創(chuàng)建ThreadPoolTaskExecutorConfiguration public class AsyncConfig { Bean(taskExecutor) public Executor taskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); // 核心線程數(shù)正常情況下常駐的線程數(shù)量 executor.setCorePoolSize(10); // 最大線程數(shù)高峰期最多能擴展到的線程數(shù)量 executor.setMaxPoolSize(50); // 隊列容量核心線程全忙時新任務(wù)先放隊列 executor.setQueueCapacity(200); // 線程名前綴排查問題時好識別 executor.setThreadNamePrefix(async-task-); // 拒絕策略隊列也滿的時候怎么處理新任務(wù) executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }參數(shù)大小怎么定這是被問得最多的。核心線程數(shù)參考機器的CPU核數(shù)和任務(wù)類型。IO密集型任務(wù)調(diào)遠(yuǎn)程接口、讀寫文件等待時間占比高核心線程數(shù)可以設(shè)成CPU核數(shù)的2倍以上CPU密集型任務(wù)大量計算設(shè)成CPU核數(shù)加1到2個就夠。設(shè)核心線程10、最大線程50、隊列200意思是正常情況下10個線程在跑任務(wù)多的時候先排隊隊滿之后才會把線程數(shù)往上提最多50個還是處理不過來就觸發(fā)拒絕策略。使用自定義線程池時Async注解里要指定名字Async(taskExecutor) public void sendSms(String mobile, String content) {如果不指定Spring會按類型查找默認(rèn)執(zhí)行器找到唯一實現(xiàn)類就自動使用。建議還是顯式寫名字多個線程池并存時不容易混。3.4 有返回值的異步調(diào)用Future與CompletableFuture現(xiàn)實中很多異步任務(wù)需要帶結(jié)果回來。Async支持Future類型的返回值最常用的是CompletableFuture。Service public class ReportService { Async(taskExecutor) public CompletableFutureString generateReport(Long userId) { // 耗時邏輯比如統(tǒng)計數(shù)據(jù) String reportContent 用戶 userId 的報表數(shù)據(jù)...; return CompletableFuture.completedFuture(reportContent); } }調(diào)用方可以主動組合多個異步任務(wù)public String handleReportRequest() throws Exception { CompletableFutureString reportFuture reportService.generateReport(1001L); CompletableFutureString otherFuture otherService.generateOtherData(1002L); // 等待兩個任務(wù)都完成并合并結(jié)果 String result CompletableFuture.allOf(reportFuture, otherFuture) .thenApply(v - reportFuture.join() otherFuture.join()) .get(30, TimeUnit.SECONDS); return result; }allOf會等所有任務(wù)完成后再執(zhí)行合并邏輯get方法設(shè)置超時時間避免任務(wù)卡死導(dǎo)致調(diào)用方無限等待。這里有一個細(xì)節(jié)CompletableFuture.join和get的區(qū)別。get拋受檢異常需要try-catch或向上拋出join不拋受檢異常直接在RuntimeException里包裝。業(yè)務(wù)代碼里我更習(xí)慣用get帶超時至少不會把控制權(quán)無限交給異步任務(wù)。3.5 異步任務(wù)的異常處理Async方法默認(rèn)的異常處理方式是如果方法沒有返回值異常會被吞掉日志里可能什么都看不到。這是新手最容易忽略的點。處理方案有兩種。第一種方法返回Future異常會封裝在Future里調(diào)用get時拋出由調(diào)用方處理。這種方式能讓異?；氐綐I(yè)務(wù)鏈路但調(diào)用方需要等待結(jié)果有些場景不算理想。第二種實現(xiàn)AsyncUncaughtExceptionHandler配置成自定義的異步異常處理器Configuration public class AsyncExceptionConfig implements AsyncConfigurer { Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(200); executor.setThreadNamePrefix(async-); executor.initialize(); return executor; } Override public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() { return (ex, method, params) - { // 這里統(tǒng)一記錄異常日志或者接入告警系統(tǒng) System.err.println(異步方法執(zhí)行異常: method.getName()); ex.printStackTrace(); }; } }注意如果實現(xiàn)AsyncConfigurergetAsyncExecutor里返回的Executor就是全局默認(rèn)的線程池所有沒指定名稱的Async都會用它。如果類里還有其他配置方式要避免兩個配置源互相覆蓋。異常處理選哪種取決于對這個異步任務(wù)結(jié)果的依賴程度。純通知類任務(wù)用自定義Handler記錄異常就夠了核心流程的分支任務(wù)建議返回Future讓主流程能感知失敗。3.6 Async與事務(wù)的疊加效果Async和Transactional同時使用時很多人以為事務(wù)會正常工作實際上需要分情況。Spring的事務(wù)也是通過代理實現(xiàn)的Transactional默認(rèn)只在當(dāng)前線程內(nèi)生效。Async方法把邏輯推到了另一個線程事務(wù)注解如果只寫在異步方法上事務(wù)還是有效的——只要事務(wù)管理器能拿到對應(yīng)的連接。但組合時的經(jīng)典問題是事務(wù)傳播。假設(shè)主方法開啟事務(wù)調(diào)用本類里一個被Async標(biāo)記的方法這個方法又寫了Transactional此時它跑在另一個線程里主線程的事務(wù)上下文傳不過去兩個事務(wù)互相獨立。如果異步方法內(nèi)部對同一數(shù)據(jù)做了修改主事務(wù)提交失敗時異步事務(wù)可能已經(jīng)提交了數(shù)據(jù)一致性就出問題了。實操建議把異步和事務(wù)當(dāng)成兩個獨立的邊界。事務(wù)管理交給主流程異步方法里的數(shù)據(jù)一致性靠消息確認(rèn)、狀態(tài)機或者定時補償來解決不要指望跨線程的兩個代理還能保持完整的ACID語義。4. WebFlux響應(yīng)式異步換一種執(zhí)行模型4.1 WebFlux不是“異步版的SpringMVC”有些人把WebFlux理解成“用起來更異步的MVC框架”這是不對的。WebFlux改變了底層的執(zhí)行模型。SpringMVC基于Servlet規(guī)范每個請求占用一個Tomcat工作線程線程阻塞時這個線程什么都不能干。WebFlux基于Netty事件循環(huán)用的是少量線程配合事件回調(diào)來處理海量并發(fā)請求。線程不阻塞等待而是注冊回調(diào)數(shù)據(jù)來了再觸發(fā)后續(xù)邏輯。所以WebFlux的高并發(fā)能力來自它極低的線程占用。同樣一臺機器MVC能扛幾百并發(fā)時WebFlux往往能扛幾千甚至更高前提是代碼里不能有阻塞調(diào)用。引入WebFlux在pom里加依賴dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-webflux/artifactId /dependency注意如果項目里同時引入了spring-boot-starter-webMVC要移除其中一個或者明確端口配置否則兩個容器會沖突。4.2 響應(yīng)式寫法的基本形態(tài)接口返回Mono或Flux類型表示這個結(jié)果是“未來某個時刻才會出現(xiàn)的”RestController RequestMapping(/api/user) public class UserReactiveController { private final UserService userService; public UserReactiveController(UserService userService) { this.userService userService; } GetMapping(/{id}) public MonoUser getUser(PathVariable Long id) { return Mono.fromCallable(() - userService.findById(id)) .subscribeOn(Schedulers.boundedElastic()); } }這個接口里findById這個阻塞型操作被丟到boundedElastic線程池里執(zhí)行而Netty事件循環(huán)線程立刻返回不阻塞。等數(shù)據(jù)查到了再通過回調(diào)把響應(yīng)寫回客戶端。4.3 響應(yīng)式鏈路的寫法規(guī)范響應(yīng)式異步的關(guān)鍵在于整條鏈路都要保持響應(yīng)式。如果Service層用的是JPA的findById這本身就是阻塞調(diào)用。把它包在Mono.fromCallable里的效果是異步線程執(zhí)行了阻塞查詢這確實能提升并發(fā)但底層依賴的還是線程池本質(zhì)上是“用線程池隔離阻塞”而不是真正的全鏈路響應(yīng)式。真正做到全鏈路響應(yīng)式要求數(shù)據(jù)訪問層也返回響應(yīng)式類型。比如用R2DBC訪問數(shù)據(jù)庫public interface UserRepository extends ReactiveCrudRepositoryUser, Long { FluxUser findByStatus(String status); } RestController public class UserController { private final UserRepository userRepository; public UserController(UserRepository userRepository) { this.userRepository userRepository; } GetMapping(/active) public FluxUser getActiveUsers() { return userRepository.findByStatus(ACTIVE); } }這種寫法下從HTTP入口到數(shù)據(jù)庫驅(qū)動全程沒有阻塞等待。每個環(huán)節(jié)都是“準(zhǔn)備好了就通知下一個環(huán)節(jié)”線程利用率極高。4.4 實際項目里的語句WebFlux適合網(wǎng)關(guān)層、聚合層比如給App提供統(tǒng)一的聚合接口同時調(diào)用訂單服務(wù)、支付服務(wù)、用戶服務(wù)的接口把它們的結(jié)果合并返回。每個下游調(diào)用都返回響應(yīng)式結(jié)果合并時用zippublic MonoOrderDetailVO getOrderDetail(String orderId) { MonoOrder orderMono orderClient.getOrder(orderId); MonoListPayment paymentMono paymentClient.getPayments(orderId); MonoUser userMono userClient.getUserByOrderId(orderId); return Mono.zip(orderMono, paymentMono, userMono) .map(tuple - { Order order tuple.getT1(); ListPayment payments tuple.getT2(); User user tuple.getT3(); return buildVO(order, payments, user); }); }三個下游調(diào)用并行執(zhí)行全部返回后組裝成VO發(fā)給客戶端。如果是MVC寫法這種聚合要么串行請求要么手動管理線程池代碼冗長且容易出錯。4.5 WebFlux的代價響應(yīng)式不是免費的午餐。它最大的問題是調(diào)試?yán)щy。傳統(tǒng)代碼的堆棧在線程切換后變得支離破碎異常信息經(jīng)常不會指向真正出問題的位置。響應(yīng)式代碼的學(xué)習(xí)曲線也陡峭flatMap、concatMap、switchIfEmpty這些操作符的語義不熟悉的人很容易寫出性能極差的代碼。我的個人結(jié)論是中小型項目業(yè)務(wù)邏輯復(fù)雜團(tuán)隊也沒有響應(yīng)式經(jīng)驗不要強行上WebFlux。用Async配合線程池改造局部痛點性價比高得多。WebFlux適合高并發(fā)、IO密集、業(yè)務(wù)鏈路清晰的下游聚合或網(wǎng)關(guān)項目。5. 消息隊列跨系統(tǒng)異步解耦5.1 什么時候需要消息隊列Async解決的是進(jìn)程內(nèi)的異步消息隊列解決的是跨進(jìn)程的異步。訂單創(chuàng)建后要通知積分系統(tǒng)、短信平臺、物流系統(tǒng)如果通過RPC同步調(diào)用任何一個下游出問題都會拖累下單主流程而且下游流量波動還會反過來擠壓訂單服務(wù)的資源。消息隊列的方案是訂單服務(wù)把“訂單創(chuàng)建完成”這個事件以消息的形式寫入隊列下單請求到這里就結(jié)束了。積分服務(wù)、短信服務(wù)分別訂閱這個主題各自來消費。訂單服務(wù)不再依賴下游的可用性下游也通過訂閱的方式解耦了與訂單服務(wù)的強綁定。流程訂單服務(wù)作為Producer發(fā)送消息到Topic消息隊列Broker持久化消息確認(rèn)收到積分服務(wù)、物流服務(wù)作為Consumer訂閱Topic各自消費消息更新自己的數(shù)據(jù)5.2 消息隊列和Async怎么配合消息隊列兩側(cè)都會用到Async。Producer側(cè)發(fā)送消息本身是快速操作但網(wǎng)絡(luò)異常重試時可能耗時所以發(fā)送邏輯可以用Async異步化避免阻塞業(yè)務(wù)主流程。Consumer側(cè)如果一次拉取到多條消息單條消息處理耗時較長可以在消費者內(nèi)部再用Async把每條消息的業(yè)務(wù)處理丟到線程池并發(fā)執(zhí)行提升消費吞吐。要注意的是消費端的并發(fā)度控制。如果消費者線程池開得太大消息處理太快可能壓垮下游數(shù)據(jù)庫。一般建議消費線程池的最大線程數(shù)跟數(shù)據(jù)庫連接池大小掛鉤保證線程數(shù)不超過連接數(shù)的上限。5.3 消息隊列的可靠性問題消息隊列把同步調(diào)用變成了異步通知同時也引出了一個新的問題怎么保證消息不丟、不重、不亂序。不丟Producer發(fā)送時開啟確認(rèn)機制Broker持久化完成后再返回成功Consumer消費后處理完業(yè)務(wù)再提交位點。不重消費端要做冪等因為消息隊列的語義是“至少一次”重復(fù)消費是正?，F(xiàn)象。常見做法是消費端先查本地狀態(tài)已經(jīng)處理過的直接返回成功或者用唯一業(yè)務(wù)ID去重。不亂序同一業(yè)務(wù)的消息要保證分區(qū)鍵一致讓它們進(jìn)同一個分區(qū)消費者單線程消費這個分區(qū)。這部分的坑主要集中在冪等上。很多項目剛開始只做了“不丟”沒做“不重”線上跑一段時間就發(fā)現(xiàn)重復(fù)數(shù)據(jù)。做消息隊列異步第一件要設(shè)計好的事就是冪等方案而不是消息發(fā)送本身。6. 三大高階問題失效、線程耗盡、上下文丟失6.1 Async失效的幾種常見場景熟悉了代理原理之后失效問題基本都能自己排查。最常見的失效場景有四種第一種方法通過this調(diào)用。比如一個Service里面methodA調(diào)用methodBmethodB標(biāo)了Async。因為this指的是原始對象而不是Spring代理所以Async不生效。解決辦法注入自身代理或者把異步方法拆到另一個Service里。第二種異步方法不是public。Spring的代理默認(rèn)只能攔截public方法private和protected方法不會進(jìn)入代理邏輯。第三種異步方法所在Bean沒有被Spring管理。比如自己new出來的對象Spring根本不知道它的存在。第四種配置類上沒有EnableAsync。這個看起來低級但項目里多模塊化之后經(jīng)常出現(xiàn)主啟動類掃描不到配置類的情況。6.2 線程池被打滿的排查方法異步任務(wù)量大時線程池可能被打滿任務(wù)進(jìn)隊列隊列也滿了觸發(fā)拒絕策略。CallerRunsPolicy會把這個任務(wù)交給調(diào)用方線程執(zhí)行看起來是“降級”但調(diào)用量巨大時會把請求線程拖死。排查時主要靠日志。所以自定義線程池時setThreadNamePrefix非常重要executor.setThreadNamePrefix(async-notify-);日志里搜async-notify線程能看到線程數(shù)是否接近maximumPoolSize隊列深度是否持續(xù)增長。如果隊列長期堆積說明核心線程數(shù)偏低或者任務(wù)量超過預(yù)期要調(diào)整參數(shù)而不是無限加線程。另外一個容易忽略的點是如果任務(wù)里都有數(shù)據(jù)庫查詢線程池配置不能只看服務(wù)本身的指標(biāo)還要看數(shù)據(jù)庫連接池的可用連接數(shù)。線程數(shù)設(shè)50數(shù)據(jù)庫連接池默認(rèn)只有1050個線程同時查庫10個持有連接剩下40個在等待這比不異步還要糟糕。線程池參數(shù)必須與會話外資源聯(lián)動評估。6.3 異步線程里丟失請求上下文Async方法里需要拿到當(dāng)前登錄用戶信息、請求頭、traceId時經(jīng)常發(fā)現(xiàn)是null。這是因為請求線程的數(shù)據(jù)存在ThreadLocal里而異步任務(wù)跑在不同的線程上ThreadLocal不共享。常用解決辦法是裝飾器模式主線程在提交任務(wù)前把關(guān)鍵上下文拷貝一份傳給目標(biāo)線程。Spring提供了TaskDecorator接口可以優(yōu)雅地實現(xiàn)上下文傳遞Bean(taskExecutor) public Executor taskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(200); executor.setThreadNamePrefix(async-); // 任務(wù)提交時將主線程的上下文復(fù)制到子線程 executor.setTaskDecorator(runnable - { // 實際項目中這里會把請求上下文對象暫存 MapString, String contextMap copyContextFromCurrentThread(); return () - { try { setContextToCurrentThread(contextMap); runnable.run(); } finally { clearContext(); } }; }); executor.initialize(); return executor; }如果是Spring Cloud鏈路追蹤的場景也可以用類似方式把traceId從主線程傳到異步線程保證全鏈路日志能串起來。具體到邏輯執(zhí)行這段decorator是為了展示結(jié)構(gòu)實際會把traceId、用戶信息請求上下文做成一個線程私有對象。6.4 異步事務(wù)隔離與資源共享異步任務(wù)共享數(shù)據(jù)庫連接池、Redis連接池時要考慮資源競爭問題。之前幫別人排查過一個線上故障異步線程池核心線程從5調(diào)到了20數(shù)據(jù)庫連接池沒動結(jié)果每個異步任務(wù)里都有大約300ms的數(shù)據(jù)庫查詢20個線程同時查詢連接池不夠用主業(yè)務(wù)的請求也開始等連接整個服務(wù)響應(yīng)變慢。這類問題的排查步驟是看監(jiān)控里線程池活躍線程數(shù)看數(shù)據(jù)庫連接池活躍連接數(shù)看兩者是否存在明顯的共同增長趨勢計算單個任務(wù)的平均IO時間反推需要的并發(fā)度不要盲目調(diào)高線程池資源配置是聯(lián)動的關(guān)系。7. 常見問題速查與避坑清單下面這個表是根據(jù)我在項目中遇到過的真實情況整理的方便直接對照排查。問題可能原因解決思路Async方法同步執(zhí)行this自調(diào)用、方法非public、Bean未被Spring管理拆Service、改public、確認(rèn)包掃描異步異常無日志輸出方法無返回Future且未配置異常處理器自定義AsyncUncaughtExceptionHandler線程數(shù)暴增使用了默認(rèn)SimpleAsyncTaskExecutor自定義線程池并指定名稱隊列任務(wù)堆積核心線程數(shù)過少或任務(wù)量突增壓測后調(diào)參結(jié)合隊列容量一起評估異步方法內(nèi)用戶信息為空ThreadLocal無法跨線程傳遞使用TaskDecorator拷貝上下文接口偶爾變得很慢異線程池觸發(fā)了拒絕策略CallerRunsPolicy監(jiān)控線程池指標(biāo)動態(tài)調(diào)參異步事務(wù)數(shù)據(jù)不一致跨線程事務(wù)隔離導(dǎo)致主流程管事務(wù)異步靠補償WebFlux接口里用了Thread.sleep阻塞了事件循環(huán)線程改為非阻塞延時或換到boundedElastic補充幾個容易忽略的實踐細(xì)節(jié)每個異步任務(wù)都要有業(yè)務(wù)標(biāo)識。日志里把業(yè)務(wù)ID、用戶ID、traceId全部打出來排查問題的時候能直接定位到是哪個任務(wù)、哪個線程在跑。線程池參數(shù)要支持動態(tài)調(diào)整。生產(chǎn)環(huán)境用配置中心管理核心線程數(shù)、最大線程數(shù)壓測發(fā)現(xiàn)問題后可以在不重啟服務(wù)的情況下修改效果比改代碼快很多。異步任務(wù)要有熔斷或者降級方案。線程池滿時的拒絕策略不要只選一種結(jié)合業(yè)務(wù)的容忍度來選?？梢詠G棄不重要任務(wù)DiscardPolicy也可以讓調(diào)用方自己跑CallerRunsPolicy但要做到心里有數(shù)知道每種策略的副作用。8. 異步調(diào)用的監(jiān)控指標(biāo)與可觀測性設(shè)計用了異步之后問題排查難度確實會上升。同步模式下一個請求從開始到結(jié)束是一條清晰的調(diào)用鏈異步線程切來切去傳統(tǒng)日志就斷了。所以異步用得越多可觀測性越要跟上。至少要監(jiān)控四個指標(biāo)線程池活躍線程數(shù)隊列積壓數(shù)量任務(wù)執(zhí)行耗時P99分位被拒絕的任務(wù)數(shù)量活躍線程數(shù)能看出線程池是否持續(xù)處于高水位隊列積壓數(shù)量能提前預(yù)警任務(wù)堆積執(zhí)行耗時能看出單個任務(wù)的健康狀況被拒絕的任務(wù)數(shù)量直接反映系統(tǒng)是否已經(jīng)超出容量。日志配合MDC來做traceId傳接我在上一部分提過用TaskDecorator傳上下文就是為了讓異步線程的日志也帶上同一個traceId。每個異步任務(wù)開始和結(jié)束時各打一條日志記錄線程名、任務(wù)名、業(yè)務(wù)ID、耗時自己畫一條時間軸基本能還原出任務(wù)執(zhí)行的完整路徑。監(jiān)控指標(biāo)都接好之后判斷線程池參數(shù)是否合理的依據(jù)就變得具體了。線程池穩(wěn)定在核心線程數(shù)附近、隊列偶爾積壓但能在幾秒內(nèi)排空這是比較健康的狀態(tài)。如果線程數(shù)長期貼近最大線程數(shù)、隊列持續(xù)有積壓說明系統(tǒng)已經(jīng)滿負(fù)荷了加線程不如削任務(wù)。9. 異步改造的實際落地順序不管項目里選擇哪種異步方案都不建議一次性大規(guī)模改造。我見過的所有改造失敗案例幾乎都是因為“把異步當(dāng)成了萬能的性能開關(guān)”一口氣把所有服務(wù)都標(biāo)成Async結(jié)果線上問題此起彼伏又不知道從哪里排起。比較穩(wěn)的推進(jìn)方式是分四步走。第一步盤點場景。把項目里所有耗時超過1秒的操作都列出來標(biāo)注它們是否依賴主流程的結(jié)果。比如發(fā)送短信、生成日志、統(tǒng)計數(shù)據(jù)這些明顯是分支任務(wù)適合異步化。第二步先做Async打底。給這些分支任務(wù)加上線程池和異步注解同時把異常處理器、日志、監(jiān)控配套做好。這一步投入小見效快也是積累異步經(jīng)驗最快的方式。第三步局部引入WebFlux。當(dāng)某個入口的并發(fā)瓶頸特別明顯比如聚合接口、網(wǎng)關(guān)入口而這個服務(wù)的業(yè)務(wù)鏈路又相對清晰這部分可以嘗試換成響應(yīng)式編程。不要一開始就把所有Service都改成Mono和Flux鏈路過深會讓改造成本成倍增長。第四步涉及跨系統(tǒng)的異步再上消息隊列。消息隊列引入的是整個中間件的運維成本如果沒有明確的削峰、解耦需求就不要為了用而用。10. 一點個人經(jīng)驗收尾做異步調(diào)用這些年最大的體會是異步方案從來不是技術(shù)問題而是取舍問題。它把當(dāng)前線程的“等待時間”轉(zhuǎn)移給了別的線程換來的是接口響應(yīng)速度的提升和系統(tǒng)吞吐量的改善代價是代碼復(fù)雜性、排查難度的上升以及分布式場景下一致性問題的新增。實際動手時我的習(xí)慣是先畫一張簡單的調(diào)用鏈路圖標(biāo)出每個環(huán)節(jié)的耗時、線程、依賴再考慮在這個鏈路的哪個環(huán)節(jié)插入異步。不看鏈路就動手加注解往往是在給系統(tǒng)埋雷。如果你剛上手SpringBoot異步調(diào)用不用急著把三套方案都吃透先在自己項目里找一個實實在在的痛點比如每次下發(fā)通知都阻塞請求、導(dǎo)出數(shù)據(jù)超時、日志寫入拖慢業(yè)務(wù)用Async配合線程池改造一遍把代理失效、上下文傳遞、異常監(jiān)控這幾個點親手踩一遍比看再多文檔都有用。工具選型也一樣沒有絕對最好的方案。進(jìn)程內(nèi)的異步優(yōu)先Async高并發(fā)聚合優(yōu)先WebFlux跨系統(tǒng)解耦優(yōu)先消息隊列。每個方案的代價不一樣選適合自己項目階段的已經(jīng)足夠。