架構師觀點 - 轉移到微服務架構的經驗分享 (Part 3)

問題與答案 (FAQ)

Q&A 類別 A: 概念理解類

A-Q1: 什麼是微服務架構？

• A簡: 以小型、單一職責服務組成的分散式系統，透過網路協作完成業務。
• A詳: 微服務是將大型應用拆解為多個小而專注的服務，每個服務獨立部署、獨立擴展，透過 API 或訊息進行通訊。它降低單體應用的複雜度，但將整體複雜度轉移到服務間協作與基礎設施。常見配套包含 API Gateway、Service Discovery、訊息系統與集中化日誌。適用於需頻繁演進、可獨立部署的領域，前提是團隊具備自動化、監控與快速交付能力。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q3, A-Q5

A-Q2: 為什麼微服務需要不同的基礎建設？

• A簡: 因複雜度轉到服務間協作，需新能力支撐高數量實例與通訊。
• A詳: 單體應用將複雜度集中在程式內，微服務則把複雜度轉到服務間互動。當同時運行數十至上百服務實例時，需解決尋址、負載、故障、認證、觀測等問題。因此必備基礎設施包含：API Gateway（統一入口）、Service Discovery（註冊/發現）、訊息/事件系統（同步與非同步通訊）、集中化日誌與追蹤。沒有這些能力，微服務的效益無法呈現。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, A-Q9, A-Q16, A-Q18

A-Q3: 導入微服務的先決條件是什麼？

• A簡: 需具備快速配置、部署、監控與DevOps流程的團隊能力。
• A詳: 成功落地的先決條件包括兩面向：團隊流程與系統運作環境。流程上需有CI/CD、自動化測試、基礎設施即程式碼、快速回滾、可觀測性與告警；環境上需提供可用的API Gateway、Service Discovery、訊息基礎設施與集中化日誌。沒有這些能力，服務增多只會放大失序與風險，難以維運並快速迭代。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q18, D-Q10

A-Q4: 為何建議漸進式從單體演進到微服務？

• A簡: 先穩健重構與準備，面臨瓶頸再逐步拆分與擴建基礎設施。
• A詳: 一次到位常超過團隊與架構承受度。較佳作法是從單體出發、持續重構保持清晰邊界，預留拆分點；當成長遇瓶頸（效能、部署耦合、團隊協作）再逐步切分、同步擴建基礎設施。這能降低風險、避免過度設計，也讓團隊在實戰中逐步建立自動化、監控與運維能力。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3, B-Q10, D-Q10

A-Q5: 什麼是 API Gateway？

• A簡: 對外統一入口，負責轉發、聚合、路由、認證與快取等。
• A詳: API Gateway 位於客戶端與內部服務之間，統一處理請求的路由、協定轉換、認證授權、輸出快取、流量控管、日誌紀錄與聚合。它將內部服務拓撲與變化對外隱藏，減少客戶端往返次數並提升效能與安全。進階用法包含集中式認證與跨版本轉譯，常見方案有Kong或雲端API管理服務。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, B-Q1, B-Q2

A-Q6: API Gateway 與 WAF 有何差異？

• A簡: WAF聚焦Web安全；Gateway聚焦API路由、聚合、認證與管理。
• A詳: WAF（Web應用防火牆）重在攔截與防護Web攻擊（如SQLi、XSS）。API Gateway則面向API管理：路由、版本轉譯、認證授權、快取、流量與金鑰管理、聚合、多協定轉換。兩者可並存：WAF在最外層處安全防護，Gateway在API層處理應用與協作細節，形成分層安全與治理。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, A-Q7, B-Q3

A-Q7: 直接呼叫服務與透過 API Gateway 的差異？

• A簡: 直接呼叫效率差難治理；Gateway一次往返、易最佳化與安全。
• A詳: 直接呼叫需多次往返、耦合內部拓撲，難以最佳化與變更；安全資訊易外露。透過Gateway，客戶端一次請求即可獲聚合資料，內部變更對外透明，統一快取與路由提高效率，集中認證與稽核提升安全。適合複雜頁面與行動端，減少網路往返與協作複雜度。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, B-Q1, B-Q3

A-Q8: API Gateway 的核心價值是什麼？

• A簡: 隔離內部複雜度、提升效率與安全、集中治理與觀測。
• A詳: 核心價值包含：對外統一入口（隱藏內部結構）、請求聚合（降低往返）、路由與版本治理（平滑演進）、集中認證與授權（簡化跨服務安全）、快取與流控（效能與保護後端）、日誌與追蹤（可觀測性）。它是微服務對外的門面與治理中樞。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q5, A-Q18, B-Q2

A-Q9: 什麼是 Service Discovery（服務發現）？

• A簡: 讓服務註冊與被查詢的機制，解決服務尋址與狀態。
• A詳: Service Discovery 提供服務註冊、查詢與健康狀態維護。服務啟動時註冊（IP/Port/健康檢查），關閉時註銷；呼叫方或負載均衡器通過它找到可用節點。可整合組態管理，集中維護共用設定。典型組件含Service Registry、Registry Client、健康檢查器與查詢介面。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q6, B-Q7

A-Q10: DNS 能否用作 Service Discovery？

• A簡: 可用，透過DDNS、SRV/TXT紀錄與RR機制支援基本需求。
• A詳: 在基礎需求下，DNS可承擔服務發現：動態註冊/反註冊（DDNS）、SRV紀錄提供服務端點與權重、A/AAAA與Round Robin分散流量、TXT輔助元資料。優點是基礎簡單與通用；限制在健康檢查、即時性與豐富的元資料管理。大型場景仍常配合專用Registry提升能力。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, D-Q8, B-Q7

A-Q11: 什麼是 Service Registry 與 Registry Client？

• A簡: Registry存放服務清單；Client執行註冊、續約與反註冊。
• A詳: Service Registry是集中服務目錄與狀態的系統，保存每個服務實例的位址與健康資訊。Registry Client內建於服務或Sidecar，於啟動註冊、定期心跳或主動健康回報、關閉時反註冊。呼叫方或LB通過Registry查詢可用端點，實現動態路由與彈性擴縮。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q6, D-Q2

A-Q12: 心跳與主動健康檢查有何差異？

• A簡: 心跳是被動回報；主動檢查由Registry或探針主動驗證API。
• A詳: 心跳（heartbeat）由服務定期回報「我還活著」，實作簡單但可能誤判（進程存活但無法服務）。主動健康檢查由外部探針或Registry呼叫健康端點（如/Echo、/Diagnostic），可發現因App Pool或依賴失效導致的「假存活」。兩者搭配能提升偵測準確性與時效性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, D-Q3, C-Q9

A-Q13: 為什麼要讓負載平衡與Service Discovery整合？

• A簡: 由後端控制路由與健康，提升可用性與維運可控性。
• A詳: 由呼叫端決定目標節點會分散治理能力。整合後，LB從Registry拉取可用節點與健康狀態，統一決策路由、熔斷與權重，便於維運在故障時即時隔離或調整流量，對前端透明。不僅提升可用性，也簡化呼叫端邏輯與升級部署流程。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, D-Q2, D-Q8

A-Q14: 什麼是同步與非同步通訊？

• A簡: 同步即時回應；非同步以訊息排隊，呼叫方不必等待完成。
• A詳: 同步通訊（多為HTTP/REST）要求即時回應，適合查詢或短交易；需處理重試、超時與負載。非同步通訊以訊息中介（MQ/Bus）承接請求，接收方離線也不丟失，適合長流程或削峰填谷。兩者可搭配：同步受理單據、非同步完成後續處理與通知。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q16, B-Q9, D-Q5

A-Q15: 什麼是事件驅動（Event-Driven）系統？

• A簡: 以事件發布/訂閱協作，消除直接耦合，提升擴展與彈性。
• A詳: 事件驅動以「發生了什麼」為中心，服務發布事件，對該事件有興趣的服務訂閱並處理。它將N×M的呼叫關係簡化為N+M，降低耦合、利於擴展。適用於跨多服務的流程協同，如訂單成立觸發計費、配送、通知等。需要可靠的訊息基礎設施與清晰的事件定義。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, B-Q10, B-Q11

A-Q16: 什麼是 Message Queue / Message Broker？

• A簡: 中介訊息的系統，提供路由、儲存、轉送與Pub/Sub能力。
• A詳: Message Queue/Message Broker接收生產者訊息，依規則路由至隊列並供消費者取用。它支援發布/訂閱、路由與儲存後轉送，常見用於非同步處理、解耦、削峰與跨服務事件協作。文中提及RabbitMQ、Kafka、MSMQ與Redis皆可用於不同場景與需求。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q8, B-Q9, D-Q5

A-Q17: 為何MQ能降低複雜度並提升可靠度？

• A簡: 將路由與重試外包給中介，支援儲存轉送與水平擴展。
• A詳: MQ將「訊息如何到達誰」的複雜度從應用中抽離。系統只關心發布/處理，路由、緩衝、重試與多消費者並行交給中介。它支援儲存後轉送（接收方離線不丟資料），並行消費與擴縮，避免瞬間尖峰壓垮後端。這同時簡化程式與提升整體韌性與吞吐。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q16, D-Q5, D-Q6

A-Q18: 微服務中的日誌與追蹤（Tracing）為何重要？

• A簡: 跨多服務協作需以追蹤ID匯集日誌，快速還原問題。
• A詳: 一個請求往往穿越多個服務。若僅有分散日誌，故障與性能瓶頸難以定位。以「追蹤號」概念（如Correlation ID）貫穿請求，將各服務相關日誌集中檢索，即可像物流追蹤般還原流程。這對事件驅動與聚合請求尤為重要，能縮短除錯時間並提升可觀測性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q14, C-Q10, D-Q9

Q&A 類別 B: 技術原理類

B-Q1: API Gateway 如何運作？

• A簡: 客戶端單一入口；Gateway路由、聚合、快取與認證後轉發。
• A詳: 原理說明：Gateway接收請求，先做認證授權與速率限制，再依路由規則將請求分發至後端服務，必要時並行呼叫多服務並聚合結果。關鍵流程：進站（驗證/限流）→路由（版本/轉譯）→後端請求（並行/重試）→聚合與快取→回應。核心組件：路由器、認證模組、快取、日誌/追蹤、外掛機制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q5, A-Q7, B-Q3

B-Q2: API Gateway 如何集中處理認證？

• A簡: 統一對接認證服務發Token，再攜帶憑證轉發至內部。
• A詳: 原理說明：Gateway與認證服務整合，驗證用戶憑證（如API Key、Token），生成與驗證存取權杖，統一拒絕未授權請求。流程：客戶端→Gateway（驗證與解析Token）→附帶已驗證的用戶上下文→後端服務。核心組件：認證服務、Token驗證器、憑證傳遞中介（Header/Claims）、稽核日誌。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q8, C-Q3, D-Q1

B-Q3: API Gateway 的快取與路由機制是什麼？

• A簡: 依路由規則分發請求，對可緩資料做輸出快取與版本轉譯。
• A詳: 原理說明：路由以路徑、方法、標頭或版本標記決定目標服務；對靜態或可緩資料套用TTL輸出快取降低後端負載。流程：匹配路由→可選轉譯（v1/v2）→快取命中則回應，否則發送後端取得並寫入快取。核心組件：路由表、快取存儲、多版本轉譯器、策略（TTL/失效）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q1, A-Q7, D-Q4

B-Q4: Service Discovery 的註冊與查詢流程如何運作？

• A簡: 服務啟動註冊/心跳，呼叫方或LB查詢可用端點。
• A詳: 原理說明：Registry保存服務清單與健康狀態。流程：1) 服務啟動→Client註冊（IP/Port/標籤/健康檢查）2) 週期心跳或主動健康回報 3) 呼叫方或LB查詢，獲得可用實例 4) 關閉或失聯→反註冊/過期。核心組件：Service Registry、Registry Client、健康探針、查詢API。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q9, B-Q6, D-Q2

B-Q5: 基於 DNS 的 Service Discovery 如何設計？

• A簡: 以DDNS維護A/SRV/TXT，透過RR與TTL分流與控制快取。
• A詳: 原理說明：用DDNS自動註冊/移除服務；SRV紀錄描述端口與權重；A/AAAA做RR分流；TXT保存輔助屬性。流程：服務變動→更新DNS→客戶端以SRV查詢取得端點→按權重連線。核心組件：權威DNS、動態更新機制、SRV/TXT紀錄、合理TTL管理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, D-Q8, B-Q7

B-Q6: 心跳與主動健康檢查在Registry中如何協作？

• A簡: 心跳提供存活訊號；主動探針實測API，提升準確性。
• A詳: 原理說明：心跳由服務定期上報，用於快速續約；主動檢查由Registry或探針定期呼叫健康端點。流程：心跳間隔內失聯→暫時未知；主動檢查失敗→標記不健康並下線。核心組件：心跳管理、健康端點（/echo,/diagnostic）、探針調度、失效轉移策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, D-Q3, C-Q9

B-Q7: 負載平衡如何與Service Discovery互動？

• A簡: LB從Registry拉取健康實例，據此做動態路由分流。
• A詳: 原理說明：LB作為統一入口，定期拉取或訂閱Registry變更，維護健康後端池。流程：請求到達LB→查詢可用實例→選擇策略（RR/最少連線）→轉發→失敗回報健康管理。核心組件：LB、後端池、健康狀態同步、路由策略與重試/熔斷控制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q13, D-Q2, D-Q4

B-Q8: 在MQ中事件/訊息如何流動（Pub/Sub與路由）？

• A簡: 產生者發到交換器，依規則路由至佇列，消費者訂閱處理。
• A詳: 原理說明：Producer將訊息發布至Exchange；Exchange按規則（直連/主題/廣播）綁定到Queue；Consumer訂閱Queue並處理訊息。流程：發布→路由→入列→消費與確認/重試。核心組件：Producer、Exchange、Binding、Queue、Consumer、確認/重試策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q15, A-Q16, D-Q5

B-Q9: 用MQ實作可靠同步通訊（Request/Response）如何做？

• A簡: 以請求佇列與回覆佇列配合CorrelationId達成。
• A詳: 原理說明：客戶端將請求發至Request Queue，指定ReplyTo與CorrelationId；服務處理後將回覆送至Reply Queue並帶回相同CorrelationId。流程：發送→等待回覆或超時→匹配CorrelationId。核心組件：兩個Queue、CorrelationId、超時/重試與去重策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q14, A-Q16, C-Q8

B-Q10: 事件驅動如何實現跨服務交易一致性（文中案例）？

• A簡: 訂單服務發布事件；對方處理後回覆確認，再更新狀態。
• A詳: 原理說明：Order服務創立交易（狀態NEW）並發布事件；消費方（如計點服務）收到事件記錄收入並回覆確認；Order收到確認後將狀態改為OPEN完成。流程：建立→發布→處理→回覆→確認。核心組件：事件定義、Message Broker、訂閱者、狀態機與超時管理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q11, A-Q15, D-Q7

B-Q11: 什麼是二階段提交（2PC），案例中如何套用？

• A簡: 先徵詢可否（準備階段），全數同意才提交，否則取消。
• A詳: 原理說明：2PC分為準備與提交。準備階段，協調者詢問所有參與者能否執行；若全數在期限內回覆肯定，進入提交階段，否則取消。案例中，Order收到計點方的確認視為準備成功，進而提交（OPEN）；若逾時或拒絕，則標記CANCEL並發布取消事件，確保一致結果。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, D-Q7, A-Q14

B-Q12: RabbitMQ、Kafka、Redis、MSMQ在文中如何定位與差異？

• A簡: RabbitMQ/Kafka為主流；Redis可輕量佇列；MSMQ重可靠但老舊。
• A詳: 原理說明：RabbitMQ提供豐富路由與Pub/Sub，適用通用整合；Kafka偏事件串流與高吞吐；Redis可實作輕量任務佇列；MSMQ具端點儲存轉送與回覆佇列，高可靠但部署依賴AD、Pub/Sub較不靈活。選擇依需求：可靠度、吞吐、運維環境與開發便利性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q16, D-Q5, D-Q6

B-Q13: 組態管理如何與Service Discovery整合？

• A簡: 啟動時註冊並拉取共用配置，集中治理、動態下發。
• A詳: 原理說明：將共用組態集中於Registry或配套系統，服務啟動時僅持有連線與憑證的最小配置，註冊同時拉取其餘設定；變更時由中心下發。流程：啟動→註冊→拉取配置→運行→配置變更通知。核心組件：配置中心、Registry Client、版本/灰度機制、回滾策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q9, C-Q4, D-Q10

B-Q14: 日誌關聯與Correlation ID的基本機制是什麼？

• A簡: 以唯一ID貫穿請求，跨服務傳遞並集中檢索關聯。
• A詳: 原理說明：入口（Gateway）產生Correlation ID，透過Header傳遞至後端；各服務寫入日誌時附帶該ID。流程：進站產生/接收ID→傳遞→每次呼叫保留ID→集中式查詢按ID聚合。核心組件：ID產生器、Header傳遞、日誌標準格式、集中檢索（含索引與保留策略）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q18, C-Q10, D-Q9

Q&A 類別 C: 實作應用類（10題）

C-Q1: 如何用NGINX建立基本API Gateway？

• A簡: 設置反向代理與路由規則，啟用快取與日誌即可起步。
• A詳: 步驟：1) 安裝Nginx 2) 在server{}內配置location路由到後端upstream 3) 啟用proxy_cache與日誌 4) 測試與監控。設定片段：upstream api_v1 { server svc1:8080; server svc2:8080; }；location /v1/ { proxy_pass http://api_v1; }。注意：設定合理超時與重試；區分可緩與不可緩資源；加上X-Correlation-ID傳遞。最佳實踐：以變更管理與自動化部署維護配置。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q1, B-Q3, C-Q10

C-Q2: 如何用Kong快速架設API Gateway並啟用認證？

• A簡: 啟動Kong，宣告服務與路由，安裝認證外掛驗證Token。
• A詳: 步驟：1) 啟動Kong與Postgres 2) 宣告Service：POST /services 3) 宣告Route：POST /routes 4) 啟用認證外掛（如key-auth或JWT）5) 測試請求。設定示例：POST /services {name:svc,url:http://svc:8080}；POST /routes {paths:[“/api”]}；POST /plugins {name:”jwt”}. 注意：妥善管理金鑰與憑證、配置速率限制與日誌。最佳實踐：把宣告寫成版本化的宣告式配置。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q2, B-Q3, D-Q1

C-Q3: 如何在.NET微服務加上API Token並透過Gateway轉傳？

• A簡: 中介軟體驗證Token，將用戶Claims寫入Header傳遞。
• A詳: 步驟：1) 在Gateway驗證Token 2) 內部服務信任Gateway傳入的Header（如X-User-Id, X-Roles）3) 在ASP.NET加入Middleware讀取與驗證Header，再建立ClaimsPrincipal。程式片段：app.Use(async (ctx,next)=>{ var uid=ctx.Request.Headers[“X-User-Id”]; if(string.IsNullOrEmpty(uid)) return ctx.Response.StatusCode=401; ctx.User=new ClaimsPrincipal(…); await next(); }); 注意：內網信任邊界、避免客戶端偽造Header。最佳實踐：僅Gateway對外，內部僅接受內網流量。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q2, D-Q1, C-Q10

C-Q4: 如何用Consul建置Service Discovery並註冊服務？

• A簡: 部署Consul Agent，提供service定義與健康檢查端點。
• A詳: 步驟：1) 啟動consul agent -server（叢集至少3）2) 每個服務節點啟動client agent 3) 提供service定義JSON（包含ID, address, port, checks）4) 實作/health端點供HTTP檢查 5) 用DNS或HTTP查詢。示例：{ “service”:{ “name”:”order”,”port”:8080,”check”:{“http”:”http://localhost:8080/health”,”interval”:”10s”}}}. 注意：設定deregister_critical_service_after避免僵屍節點。最佳實踐：宣告式註冊、自動化部署。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q6, D-Q2

C-Q5: 如何用DNS SRV設計簡易Service Discovery？

• A簡: 建立SRV/TXT紀錄，服務啟停時以DDNS更新與合理TTL。
• A詳: 步驟：1) 在DNS建立服務域名（_svc._tcp.domain）2) 為每節點建立SRV（priority/weight/port/target）與必要TXT 3) 服務啟停時以nsupdate動態更新 4) 客戶端使用SRV查詢，按權重選擇。示例：_order._tcp.example 10 50 8080 host1。注意：TTL過大導致切換不即時；需搭配健康監測外掛或縮短TTL。最佳實踐：小規模或過渡期可用。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, D-Q8, B-Q7

C-Q6: 如何把負載平衡與Registry整合成動態後端？

• A簡: 以模板渲染upstream（如consul-template），熱更新LB池。
• A詳: 步驟：1) LB（如NGINX）定義upstream模板 2) 部署consul-template或同類工具訂閱Registry變更 3) 變更時渲染新配置並平滑reload 4) 啟用主動/被動健康檢查。設定片段：upstream order { server {{range service “order”}}{{.Address}}:{{.Port}}{{end}}; }. 注意：確保無中斷reload；限縮重載頻率。最佳實踐：加上熔斷與重試策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, D-Q2, D-Q4

C-Q7: 如何以RabbitMQ實作訂單處理的事件流？

• A簡: 定義交換器/佇列，發布order.created，服務訂閱處理。
• A詳: 步驟：1) 建立topic exchange：orders 2) 建立queue：billing.q、inventory.q並綁定routing key order.created 3) 新訂單時發布消息 4) 各服務消費處理並回覆確認事件。程式片段（概念）：channel.ExchangeDeclare(“orders”,”topic”); channel.BasicPublish(“orders”,”order.created”,body). 注意：設定持久化、重試與死信佇列。最佳實踐：事件結構版控與冪等處理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, B-Q10, D-Q6

C-Q8: 如何以MQ實作同步Request/Response？

• A簡: 使用replyTo與CorrelationId，超時與重試保護。
• A詳: 步驟：1) 客戶端建立臨時回覆佇列 2) 發送請求時設置BasicProperties.ReplyTo與CorrelationId 3) 服務處理後回傳到ReplyTo並帶相同CorrelationId 4) 客戶端等待匹配ID或超時。程式片段：props.ReplyTo=replyQName; props.CorrelationId=Guid.NewGuid().ToString(); 注意：設置合理超時；避免阻塞；保護重入與去重。最佳實踐：將同步窗口縮短到必要最小。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, D-Q5, D-Q6

C-Q9: 如何設計健康檢查API（Echo/Diagnostic）？

• A簡: 提供輕量/eho與深入/diagnostic端點，反映依賴狀態。
• A詳: 步驟：1) /echo：回200與基本資訊（版本/時間）供快檢 2) /diagnostic：檢查依賴（DB/MQ/外部服務）彙總狀態 3) 於Registry配置HTTP檢查 4) 權限限制避免外部濫用。範例：GET /echo→200 OK；GET /diagnostic→{db:”ok”,mq:”ok”}. 注意：/echo快速且穩定；/diagnostic可能昂貴，降低頻率。最佳實踐：標準化回傳格式。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q6, D-Q3, C-Q4

C-Q10: 如何設計跨服務Log追蹤（Correlation ID）？

• A簡: 入口產生ID，透過Header傳遞，各服務落盤並集中檢索。
• A詳: 步驟：1) Gateway產生X-Correlation-ID（或沿用來自客戶端）2) 每次轉發附帶該Header 3) 服務讀取後放入日誌欄位 4) 集中式日誌（如ELK）按ID聚合。程式片段：若無ID則Guid.NewGuid()；logger.With(“cid”,cid).Log(…). 注意：保持ID不變；避免覆寫；在非同步事件中也帶上。最佳實踐：用中介軟體統一路徑。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q14, A-Q18, D-Q9

Q&A 類別 D: 問題解決類（10題）

D-Q1: API Gateway後端變更導致APP失效怎麼辦？

• A簡: 問題：耦合內部拓撲。解法：版本路由與轉譯、集中認證。
• A詳: 症狀：APP頻繁更新才能適配後端變更、認證不一致。原因：客戶端直連多服務、無版本治理。解法：導入Gateway集中路由與版本轉譯，聚合多次呼叫；統一認證於Gateway後轉傳Claims。預防：對外API契約版控、棄用政策、API測試與灰度發布。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, B-Q2, C-Q2

D-Q2: Service Discovery出現僵屍節點如何處理？

• A簡: 問題：未反註冊仍可被發現。解法：主動檢查與自動摘除。
• A詳: 症狀：流量導向已離線節點。原因：僅靠心跳或關機異常未反註冊。解法：啟用主動健康檢查，設置失敗閾值與deregister_critical_service_after；LB按健康狀態路由。預防：優雅關閉流程、縮短TTL、監控註冊漂移與差異報表。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, C-Q4, C-Q6

D-Q3: 心跳正常但服務實際已掛掉怎麼偵測？

• A簡: 問題：假存活。解法：以真正API健康檢查驗證。
• A詳: 症狀：心跳持續回報，但實際API 500或超時。原因：僅檢查進程未檢查應用或依賴。解法：提供/echo與/diagnostic端點，Registry與LB執行主動HTTP檢查，以結果決定上下線。預防：心跳搭配主動檢查、檢查涵蓋關鍵依賴、異常通報。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q6, C-Q9, A-Q12

D-Q4: 經API Gateway延遲過高如何診斷與改善？

• A簡: 症狀：P95高。解法：快取、並行聚合、連線池與路由優化。
• A詳: 症狀：尖峰延遲高、後端飽和。原因：串行聚合、多次往返、無快取、DNS/LB不當。解法：啟用輸出快取與頁面聚合並行呼叫；連線池與HTTP/2；縮短不必要轉譯；LB/Registry健康同步；壓測驗證。預防：APM與追蹤、容量規劃、限流與熔斷。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q1, B-Q3, C-Q6

D-Q5: MQ出現訊息堆積或延遲怎麼辦？

• A簡: 症狀：佇列積壓。解法：擴增消費者、調整預取與分區。
• A詳: 症狀：處理延遲、逾時、重試風暴。原因：消費能力不足、單點隊列、重試策略不當。解法：水平擴展消費者、提高預取/並行、分佈隊列或增加分區；實施死信佇列與回退。預防：容量監控與警戒、背壓與動態擴縮、事件模型壓測。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, C-Q7, C-Q8

D-Q6: 重複訊息導致重覆扣款如何避免？

• A簡: 問題：至少一次投遞。解法：設計冪等與去重鍵。
• A詳: 症狀：資金或庫存重覆變動。原因：重試或消費超時造成重投。解法：以業務唯一鍵或CorrelationId做去重；操作冪等（檢查狀態再更新）；使用外部事務表記錄處理過的消息。預防：清晰的投遞語義與重試策略、消費超時合理化。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, C-Q7, C-Q8

D-Q7: 事件驅動交易部分失敗如何回復？

• A簡: 問題：跨服務一致性。解法：2PC準備/取消與補償。
• A詳: 症狀：一方成功另一方失敗導致不一致。原因：跨庫無本地交易。解法：使用2PC：準備階段全數確認才提交；若逾時或拒絕則發布取消並恢復原狀。對取消訊息採重送直到確認。預防：定義明確狀態機、超時與重試、對等錯誤處理與告警。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, B-Q11, C-Q7

D-Q8: DNS快取造成服務切換不即時怎麼辦？

• A簡: 問題：TTL過長。解法：縮TTL或改用Registry/LB整合。
• A詳: 症狀：節點下線仍被解析到、流量導向失效節點。原因：本地與中間DNS快取。解法：降低TTL、重要服務使用SRV並縮TTL；對關鍵流量改採Registry+LB模式，即時同步健康狀態。預防：監測解析結果、在變更期間短TTL與觀察期。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q7, C-Q6

D-Q9: 日誌無法串起跨服務呼叫如何補救？

• A簡: 問題：缺關聯。解法：導入Correlation ID與集中檢索。
• A詳: 症狀：故障難定位、需人工比對多服務日誌。原因：缺乏統一追蹤ID與格式。解法：由入口產生或沿用Correlation ID，透過Header傳遞，所有服務記錄；集中日誌系統以ID聚合查詢。預防：在開發框架中內建中介、契約要求合作方回傳ID。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q14, C-Q10, A-Q18

D-Q10: 遷移微服務後團隊維運失靈如何修正？

• A簡: 問題：缺流程能力。解法：補齊CI/CD、監控與自動化。
• A詳: 症狀：部署慢、回滾難、故障定位久。原因：未建立DevOps能力與基礎設施。解法：導入CI/CD、自動化基礎設施、標準化日誌與追蹤、建立SLO與告警；逐步拆分，與基礎設施建設同步推進。預防：以漸進式方法、明確邊界與資源配比迭代前進。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3, A-Q4, B-Q13

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是微服務架構？
  • A-Q2: 為什麼微服務需要不同的基礎建設？
  • A-Q3: 導入微服務的先決條件是什麼？
  • A-Q4: 為何建議漸進式從單體演進到微服務？
  • A-Q5: 什麼是 API Gateway？
  • A-Q6: API Gateway 與 WAF 有何差異？
  • A-Q7: 直接呼叫服務與透過 API Gateway 的差異？
  • A-Q9: 什麼是 Service Discovery（服務發現）？
  • A-Q14: 什麼是同步與非同步通訊？
  • A-Q16: 什麼是 Message Queue / Message Broker？
  • A-Q18: 微服務中的日誌與追蹤（Tracing）為何重要？
  • B-Q1: API Gateway 如何運作？
  • B-Q4: Service Discovery 的註冊與查詢流程如何運作？
  • C-Q1: 如何用NGINX建立基本API Gateway？
  • D-Q9: 日誌無法串起跨服務呼叫如何補救？
• 中級者：建議學習哪 20 題
  • A-Q8: API Gateway 的核心價值是什麼？
  • A-Q10: DNS 能否用作 Service Discovery？
  • A-Q11: 什麼是 Service Registry 與 Registry Client？
  • A-Q12: 心跳與主動健康檢查有何差異？
  • A-Q13: 為什麼要讓負載平衡與Service Discovery整合？
  • A-Q15: 什麼是事件驅動（Event-Driven）系統？
  • A-Q17: 為何MQ能降低複雜度並提升可靠度？
  • B-Q2: API Gateway 如何集中處理認證？
  • B-Q3: API Gateway 的快取與路由機制是什麼？
  • B-Q5: 基於 DNS 的 Service Discovery 如何設計？
  • B-Q6: 心跳與主動健康檢查在Registry中如何協作？
  • B-Q7: 負載平衡如何與Service Discovery互動？
  • B-Q8: 在MQ中事件/訊息如何流動（Pub/Sub與路由）？
  • B-Q9: 用MQ實作可靠同步通訊（Request/Response）如何做？
  • B-Q14: 日誌關聯與Correlation ID的基本機制是什麼？
  • C-Q2: 如何用Kong快速架設API Gateway並啟用認證？
  • C-Q4: 如何用Consul建置Service Discovery並註冊服務？
  • C-Q7: 如何以RabbitMQ實作訂單處理的事件流？
  • D-Q2: Service Discovery出現僵屍節點如何處理？
  • D-Q4: 經API Gateway延遲過高如何診斷與改善？
• 高級者：建議關注哪 15 題
  • B-Q10: 事件驅動如何實現跨服務交易一致性（文中案例）？
  • B-Q11: 什麼是二階段提交（2PC），案例中如何套用？
  • B-Q12: RabbitMQ、Kafka、Redis、MSMQ在文中如何定位與差異？
  • B-Q13: 組態管理如何與Service Discovery整合？
  • C-Q3: 如何在.NET微服務加上API Token並透過Gateway轉傳？
  • C-Q5: 如何用DNS SRV設計簡易Service Discovery？
  • C-Q6: 如何把負載平衡與Registry整合成動態後端？
  • C-Q8: 如何以MQ實作同步Request/Response？
  • C-Q9: 如何設計健康檢查API（Echo/Diagnostic）？
  • C-Q10: 如何設計跨服務Log追蹤（Correlation ID）？
  • D-Q5: MQ出現訊息堆積或延遲怎麼辦？
  • D-Q6: 重複訊息導致重覆扣款如何避免？
  • D-Q7: 事件驅動交易部分失敗如何回復？
  • D-Q8: DNS快取造成服務切換不即時怎麼辦？
  • D-Q10: 遷移微服務後團隊維運失靈如何修正？