這個系列帶著習慣 Thread、Executor 傳統並發思維的 Java 或後端工程師,從最基礎的 suspend function 開始建立 Kotlin 協程的觀念地基,再進入 Spring Boot 3 生態系整合、高併發控制與效能調校,最終完成一個具備可觀測性與部署經驗的實戰系列。
全系列帶著讀者透過一個逐步擴充的示範情境,加上 Structured Concurrency、Dispatchers、WebFlux、R2DBC、逾時取消、背壓、連線池搭配⋯⋯等主題,30 天收斂成一個具備監控、壓測、部署經驗的完整後端服務。
Day 09:小結:四個核心觀念如何在一次請求中協同運作 結尾留下一個還沒正面回答的問題:協程終究要活在一個真實的 Spring Boot 應用程式裡,它要接...
在上一篇文章 Day 10:在 Spring MVC 裡寫 suspend function,能動但有代價 最後留下一個問題:如果限制的源頭是底層容器骨架,有沒...
Day 11:WebFlux 是什麼,協程與反應式模型的分工 停在一個尚未回答的風險上:即使應用程式用 WebFlux 搭配協程,整條請求處理鏈路理論上可以是非...
Day 12:R2DBC,讓資料庫存取也不阻塞執行緒 結尾留下一個問題:資料庫存取這一段的非阻塞問題解決了,但真實的訂單查詢與扣庫存流程往往不只跟資料庫打交道,...
Day 13:協程搭配訊息佇列與外部 API 呼叫的常見模式 結尾把問題攤開來了:這幾天累積的技術選型各自看起來都理解了,但實務上該根據什麼判斷依據去選擇,還沒...
Day 14:小結:三種技術選型的判斷依據,MVC、WebFlux 各用在哪 結尾留下一個尖銳的問題:即使底層是 WebFlux 搭配 R2DBC 這種從骨子裡...
Day 15:併發限制,用 Semaphore 保護下游別被打爆 結尾留下一個問題:Semaphore 確實能保護下游資源不被瞬間打爆,但如果同時湧入的請求量遠...
Day 16:逾時與取消,讓卡住的協程別拖垮整個系統 結尾留下一個問題:withTimeout 解決的是某個協程異常卡住太久的狀況,但如果問題根本不是卡住,而是...
Day 17:背壓是什麼,生產太快時該怎麼踩煞車 結尾留下一個問題:背壓機制確實能避免資料無限制堆積,但消費端實際處理這些資料時,往往需要依賴某項數量有限的資源...
Day 18:協程遇上 R2DBC 連線池,小心連線被偷偷耗盡 結尾留下一個問題:協程模型相對於 Thread-per-Request 模型,實際上能帶來多少效...