技術債與彈性之間：我把 LLM 微服務拆出來了

這週幾乎都在跟 LLM 微服務搏鬥：為了彈性、金鑰池、供應商切換、逃生門到 fallback 機制的完善，再到 Sentry 與 Redis 限流的整合。這些改動使用者不一定看得到，但對穩定性與後續擴充很關鍵。

本週進展

• LLM 微服務成功從 Ingrelens 主專案抽離，架構變得清晰，API 調用與 fallback 逐步穩定。
• 資料庫改用 JSONB。短期有 schema 管理的負擔，但彈性更高，能更貼近未來需求。
• 大幅清理程式碼與統一術語。捨棄舊碼雖不捨，但維護成本明顯下降。
• 錯誤監控與限流整合完成：Sentry 分環境配置讓追蹤更有信心；Redis 限流避免流量暴增時崩潰。意外的是，幾萬筆資料僅佔 100 多 MB，我卻給了 8G 記憶體，算是有餘裕。

遇到的問題與解法

• 彈性 vs. 穩定性：JSONB 帶來彈性，也帶來 schema 驗證與演進成本。目前以 validation layer 管理格式，後續評估是否需要更嚴謹的 schema 工具。
• 供應商 fallback：不同供應商的錯誤訊息差異大，錯誤處理邏輯不得不複雜。現階段能應付多數情境，但仍需定期回頭調整以避免 edge cases。

反思

原本該專注在微服務架構，卻被 JSONB 的 schema 管理拉走不少注意力。短期很難完全避免，但需要更清楚區分「當下急件」與「長期架構」，避免戰術消耗戰略。整體技術正往「分散模組化」前進，帶來擴充與維護優勢，同時也提高複雜度，監控與管理工具勢必要跟上。

下週計畫（2025-05-19 ~ 2025-05-25）

• 針對 LLM 微服務做效能與壓力測試，檢驗高流量下的 fallback 穩定性。
• 研究 JSONB schema 驗證與 migration 的成熟方案，避免資料失控。
• 整理產品術語，安排半天盤點與統一。

預期挑戰與應對

• 高併發下的效能瓶頸與限流臨界值設定：事先準備監控，定義清楚測試場景，快速定位問題。
• Schema 工具選擇：避免過度工程化，優先選擇可快速落地、能持續演進的方案。

創業路上，開坑容易、填坑更難。重要的是每次填坑都讓架構更穩、路徑更清楚，為未來的自己減輕負擔。