https://yennj12.js.org/yennj12_blog_V4/tags/gke/Recent content in GKE on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part2-cluster-autoscaling/Sun, 09 Nov 2025 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part2-cluster-autoscaling/Part 2 of the Kubernetes Autoscaling series: Comprehensive guide to cluster-level autoscaling covering Cluster Autoscaler, Karpenter, cloud provider-specific solutions (EKS, GKE, AKS), and emerging technologies for intelligent node provisioning and cost optimization.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part21-async-longrunning-agent-zh/Thu, 04 Jun 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part21-async-longrunning-agent-zh/HTTP 請求的超時通常是 30~60 秒。 你的 Agent 需要 30~60 分鐘。 這不只是「把 timeout 調大」的問題—— 這是一個需要重新設計請求/回應模型的架構問題。 面試情境 面試官： 「客戶想打造一個自動化市場競品分析 Agent。當用戶輸入指令，Agent 需要搜尋 50 個網頁、調用大數據分析工具、撰寫 20 頁報告。整個工作流需要 30 分鐘到 1 小時。你如何設計後端分散式架構？如果執行到第 25 分鐘時某個節點崩潰，如何確保不從頭來過？」 一、核心問題：同步 HTTP 模型的三個致命限制 同步模型（不可行）： 用戶發出請求 │ ▼ HTTP Request ───────────────────────────────── 等待 60 分鐘？ │ HTTP Response ← 60 分鐘後 ← 如果連線斷了呢？ 如果手機鎖屏了呢？ 如果用戶換了瀏覽器分頁呢？ 三個根本限制： 限制 1：HTTP 超時 └─ 大多數 Load Balancer、API Gateway 的 timeout 是 30~300 秒 Agent 跑 60 分鐘，連線早就被中斷 限制 2：無法容錯 └─ 如果 Worker 在第 25 分鐘崩潰 用戶必須從頭開始，浪費 25 分鐘的 Token 成本 限制 3：無法水平擴展 └─ 一個請求佔用一個 Thread 60 分鐘 100 個並發用戶 → 需要 100 個長期佔用的 Thread → 資源利用率極低 二、解決方案：解耦架構（Decoupled Architecture） 核心設計原則： 請求接收 和 任務執行 完全解耦 用戶 和 任務結果 透過 異步機制溝通 ┌──────────────────────────────────────────────────────────────┐ │ 完整系統架構 │ │ │ │ ┌────────────────────────────────────────────────────────┐ │ │ │ 用戶端（Frontend） │ │ │ │ ┌──────────────────────────────────────────────────┐ │ │ │ │ │ 1.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part43-async-cart-agent-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part43-async-cart-agent-zh/大多數工程師看到「購物車 Agent」，第一反應是加一個 HTTP 呼叫。 資深工程師看到的是：200 萬個並發狀態機、隨時會蒸發的 Pod、以及絕不允許重複扣款的業務紅線。 前者寫了一個能示範的 Demo，後者設計了一個能活過黑五的系統。 差距不在代碼行數，在於你把「失敗」當作例外還是當作設計輸入。 面試情境 面試官提問（Staff FDE L6 考題）： 你的電商平台計劃在黑五期間為 200 萬名在線用戶 同時運行「自動購物車談判 Agent」。 Agent 必須在背景異步監控庫存、與供應鏈 Agent 協商折扣，並在完成後推送通知。 已知 GKE 節點在大促期間會因搶佔（Preemption）和 OOM 隨機重啟， 請問你如何設計這個系統的異步架構？ 當一個執行到第 5 輪反思循環（Reflection Loop）的 LangGraph Agent Pod 突然消失時， 你如何保證不遺失狀態、不重複通知、不重複扣款？ 一、核心問題：為什麼同步 HTTP 在這裡是個死路 1.1 規模帶來的物理上限 200 萬在線用戶同時觸發購物車事件，假設每個 Agent 執行一次完整談判流程需要 8–15 秒（含多輪 LLM 推理、供應鏈 API 呼叫），同步模型意味著： 同步 HTTP 模型的致命算術 ───────────────────────────────────────────────────── 並發請求量 ：2,000,000 個用戶 × 黑五流量因子 3× = 6M req 平均持續時間 ：~12s（5 輪反思 × 2.