在上一篇，我們提過說不定有一天 AI 可以自己看系統程式碼，覺得哪裡可能有問題，就設計實驗去跑看看，最後自己觀察，自己寫報告，自己修復。

沒有錯，有一天就是今天！？現在的 AI 非常強大了，所以我想實踐這個想法。

要完成這個計畫，得先準備幾樣東西。第一個當然是主角，也就是拿來做實驗的系統。接著要有監控，實驗跑下去才看得到系統的反應。最後是知識庫，讓 AI 可以反覆讀取系統資料、設計實驗和記錄報告。

網路上雖然有很多微服務系統的範例，但我沒有參與設計，很難完全掌握架構和運作流程。所以我還是跟 AI 規劃一套自己的系統。後面交給 AI 做實驗時，我才有能力判斷它到底有沒有亂講。

由於目前在金融業做維運，平常不太會碰到完整的系統架構和複雜業務邏輯，所以只從最基本的存款、提款和轉帳開始發想，再跟 AI 規劃出一套簡單的微服務系統 lite-bank。這套系統主要拿來當後續實驗的環境，效能和架構先不要太認真。（怕被噴，先打預防針）

接下來就水一下篇幅，簡單介紹這套系統由哪些服務組成，以及它的 Monitoring 架構。

lite-bank 架構圖

lite-bank 是一套模擬銀行日常操作的微服務系統，包含登入、帳戶查詢、存款、提款、轉帳與換匯等功能。

以下是架構圖。

核心服務可以劃分為以下三個層次：

1. 資料層服務 (Data Layer Services)

這層服務職責單一，主要負責與 PostgreSQL 資料庫互動，提供核心的資料存取與驗證：

• User Service：負責使用者登入、認證與個人資料管理。
• Account Service：提供帳戶資訊的查詢與驗證（此服務是唯讀的，不允許修改任何帳戶餘額）。
• Transaction Service：整套系統中唯一能夠修改帳戶餘額的服務。為了防止在併發扣款時發生死鎖，它在寫入時會使用悲觀鎖來確保交易的原子性。
• Exchange Rate Service：提供貨幣轉換的匯率資訊 (Mock 資料)。

2. 業務流程層服務 (Business Process Layer Services)

這層服務不直接寫入資料庫，主要負責呼叫多個資料層服務，把完整的業務流程串起來：

• Teller Service：負責把帳戶驗證、扣款與交易紀錄串起來，完成存款、提款和轉帳。
• Exchange Service：負責取得匯率、確認帳戶並建立交易，完成換匯流程。

3. 事件處理層服務 (Event-Driven Layer Services)

這層服務透過 Kafka 處理交易後續的工作，不會擋住主要交易流程：

• Analytics Processor：接收交易事件，整理每日與每月的收支統計。
• Analytics Query：提供 API 查詢收支摘要、餘額趨勢與資產分布。
• Notification Service：接收通知事件，再透過 SSE 將訊息推送給前端。

叢集中還有一個 k6-loadtest 在背景持續對 lite-bank 發送壓測流量，模擬平常有人使用系統的狀態。

監控 (Monitoring) 架構

有了微服務主角之後，要給它監控，如果系統沒有完善的監控，那麼注入混沌故障後，人和 AI 根本無法判斷系統的情況。

這次的監控環境使用 Grafana、Prometheus、Grafana Alloy、Tempo 與 Loki，全部都跑在 Rancher 管理的 Kubernetes 叢集。Alloy 負責收集 logs 與 traces，Prometheus 則負責收集各服務公開的 metrics。

1. 全線鏈路追蹤

所有 Spring Boot 微服務都透過 OpenTelemetry (OTel) Java SDK 手動建立 Span，記錄 API 呼叫的追蹤資料。

所有的 API 都會產生 Trace，然後被發送到 Grafana Alloy，最後寫入 Tempo。我們可以在 Grafana 上看出一個轉帳請求在各個微服務之間停頓了多久。

2. Log 收集

Alloy 會持續收集這些 Pod 的 logs，並將帶有 app、container、pod 等標籤的結構化 JSON log 推送給 Loki。因為 log 中帶有 Trace ID，我們可以在 Grafana 上直接從 log 找到對應的 trace。

3. K8s ServiceMonitor 與 Micrometer 指標 (Prometheus)

各微服務透過 Spring Boot Actuator 的 /actuator/prometheus endpoint 公開 Micrometer metrics，Prometheus 再依照 ServiceMonitor 的設定，每 30 秒抓取一次。

4. Span Metrics Connector

我們利用 Grafana Alloy 的 otelcol.connector.spanmetrics 元件，直接從 traces 資料中自動計算出吞吐量、錯誤率、HTTP 延遲（即 RED metrics）指標。

結論

到今天為止，我們終於把後續 AI 實作會使用的主角 lite-bank 介紹完了。

這套環境已經具備基本維運需要的 metrics、logs 與 traces，可以從 Grafana 觀察系統發生什麼事。lite-bank 專用的告警規則目前還沒有設定，所以離完整的維運環境還差這一塊。

不過在讓 AI Agent 正式動手之前，還有一件事要做：我們得先讓它把這個 Repo 的所有架構背景知識給讀懂並記下來。

下一篇，我們就來聊聊當時在社群很紅、能夠幫我們把專案代碼與架構知識整理給 LLM 讀寫的利器：llm-wiki。我們明天見！