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

問題與答案 (FAQ)

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

A-Q1: 什麼是微服務（Microservices）？

• A簡: 將單體式系統拆成小型、自治、可獨立部署的服務，以標準 API 溝通的架構風格。
• A詳: 微服務是一種架構風格，將原本高度耦合的單體式系統（Monolith）拆解為多個小而專注的服務。各服務各自擁有資料與邏輯，透過 API（常見如 REST）彼此協作。優點包含自治開發與部署、可獨立擴展、容許技術異質性；缺點是分散式的複雜度上升，如網路不可靠、資料一致性挑戰、跨服務除錯與觀測困難。它是解決特定問題的方法，不是目的本身。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q4, B-Q1

A-Q2: 微服務為什麼不應成為目標，而是手段？

• A簡: 微服務是解決特定問題的手段；未釐清問題即導入，成本高、風險大。
• A詳: 架構存在的目的在於解決問題。若未釐清當前瓶頸與目標，只因趨勢而改寫成微服務，常付出巨大成本（切割、部署、治理、觀測），卻收不到對等效益。正確做法是先確認：是否有擴展、異質技術、團隊協作、部署頻率等痛點，再評估微服務是否能有效解決；否則可能本末倒置。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q20, B-Q20

A-Q3: 微服務的核心原則是什麼？

• A簡: 小巧、專注、自主；高內聚低耦合；以 API 協作，獨立部署與擴展。
• A詳: 微服務強調單一職責（小巧）、明確邊界（專注）、獨立生命周期（自主）。服務內部高內聚，服務之間低耦合，藉 API 溝通。團隊可各自選擇最適技術與資料儲存。這些原則使團隊能更快迭代、更易擴展，代價是必須具備分散式系統能力（可靠通訊、觀測、版本相容）。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, B-Q1, B-Q6

A-Q4: 微服務與單體式架構有何差異？

• A簡: 單體集中、簡易但擴展困難；微服務分散、自治可擴，但治理複雜。
• A詳: 單體式將功能集中於一個部署單元，初期開發快、除錯簡單，但規模增長後，變更風險與維護成本呈指數上升。微服務分拆為多服務，各自部署與伸縮，降低單點修改衝擊與提升異質技術採用彈性，但需要解決分散式的網路、資料一致性、跨服務追蹤、版本控制與自動化運維等挑戰。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q6, B-Q14

A-Q5: 為什麼近年微服務流行？

• A簡: 面對複雜度與規模成長，以拆分降低維護成本，並支援異質技術。
• A詳: 當系統規模擴大，單體式維護成本可能呈 N^2 成長。微服務將系統拆為 N 個服務，使維護成本更接近線性成長。此外，服務邊界清晰讓團隊自治、部署頻率提升，並能為不同子域採用各自最適技術（例如 .NET 服務配合 Linux 上的 Redis/Elastic），均促使微服務成為主流選項。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q15, B-Q12, B-Q20

A-Q6: 分散式系統的主要挑戰是什麼？

• A簡: 網路不可靠、延遲與失敗；資料一致性；跨服務除錯與觀測困難。
• A詳: 微服務是分散式系統，必須面對：非可靠網路造成重試與逾時；序列化與跨網延遲；資料一致性的困難與事件驅動的最終一致性；跨服務請求追蹤、集中日誌、指標告警的需求；版本相容與灰度釋出；多服務部署與回滾的協調。這些都需以工程化能力補足。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q13, B-Q14, D-Q2

A-Q7: 什麼是服務邊界？如何判斷切點？

• A簡: 以高內聚低耦合為原則，沿業務流程與依賴邊界切分服務。
• A詳: 服務邊界描述某服務的職責範圍。典型判斷方法：觀察模組間相依圖，辨識高內聚區塊與鬆散耦合區；用 Use Case 或領域模型比對，讓服務貼近實際流程；同時考量組織分工（康威定律）。切在自然的交互邊界上，能降低跨服務呼叫、資料共享與協調成本。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q9, B-Q2, B-Q18

A-Q8: 為何過度切割會適得其反？

• A簡: 切太細將激增跨網呼叫、部署治理成本，效益不成正比。
• A詳: 「能拆就拆」忽視了分散式成本。過度切割會放大網路延遲、可靠性風險、版本協調與觀測負擔，導致整體交付速度反而下降。實務上宜「切到剛好」，以業務邏輯自然邊界為主，確保每個服務具備足夠的內聚度與變更頻率，並保留後續再切的空間。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, D-Q7, A-Q7

A-Q9: 什麼是康威定律？與微服務有何關係？

• A簡: 系統架構反映組織溝通結構；團隊邊界會形塑服務邊界。
• A詳: 康威定律指出，系統設計會鏡像組織的溝通結構。若組織以跨職能小隊負責明確子域，微服務邊界更易與之對齊；反之則產生大量跨團隊協調成本。導入微服務前應盤點組織邊界與責任劃分，必要時以組織調整配合架構變更，讓服務與業務運作相契合。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q19, A-Q7, D-Q9

A-Q10: 物件導向（OOP）概念如何啟發微服務切分？

• A簡: 從「模擬世界、加以處理」擴展，將類物件思維提升為服務邏輯。
• A詳: OOP 強調以現實概念建模，提高對變更的適應性。類比到微服務，將物件與類的邊界提升為服務邊界，讓服務關係對應真實流程。若 Use Case 與服務拓撲能互相對照，多數需求變更會沿著自然邊界發生，降低耦合、易於迭代與維護。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q18, A-Q7, A-Q11

A-Q11: 為何建議用 Use Case 對照微服務架構圖？

• A簡: 讓服務互動貼近業務流程，驗證邊界合理與依賴方向正確。
• A詳: Use Case 描述使用者目標與系統互動，對照微服務架構可檢驗：關鍵流程是否需不必要的跨服務跳轉、資料流向是否合理、責任是否落在合適服務。若兩者能對應，代表切分貼近現實流程；若落差大，應優先重構而非盲目切割。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, B-Q18, B-Q2

A-Q12: 為何 API 版本相容性重要？

• A簡: 確保服務可獨立升級與回滾，避免牽一髮動全身的連鎖變更。
• A詳: 微服務期望單一服務可獨立部署。若 API 不向後相容，升級一個服務將迫使「一起升級」而造成群體風險。透過清晰契約、版本標記（路徑/標頭）、棄用策略與相容機制，可讓新舊服務共存、灰度釋出與快速回滾，維持整體穩定。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, D-Q3, B-Q16

A-Q13: 為什麼容器技術對微服務關鍵？

• A簡: 容器提供一致、輕量、可移植的執行環境，簡化部署與擴展。
• A詳: 容器以映像檔封裝應用與依賴，啟動快、效能接近原生，支援高密度部署。相較 VM，容器建置與分發更簡單（Dockerfile、Registry），利於自動化 CI/CD 與彈性伸縮。對微服務而言，容器使多服務、大量實例與異質技術的部署難度大幅下降。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, B-Q10, C-Q4

A-Q14: 容器與虛擬機（VM）差異是什麼？

• A簡: 容器共用主機核心、啟動快、映像輕；VM 隔離更強但較重。
• A詳: VM 模擬硬體、含完整 OS，隔離強但資源開銷大、啟動慢；容器共享主機核心，以 Namespace/Cgroups 隔離，映像層次化輕量、部署快速。容器更適合微服務的頻繁部署與高密度運行；VM 仍適合需強隔離或不同核心版本的場景。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, B-Q11, C-Q4

A-Q15: 對 .NET 團隊，Windows Container 有何意義？

• A簡: 讓 .NET 服務也能容器化，降低異質架構與自動化部署門檻。
• A詳: 過去容器多在 Linux 生態。.NET 團隊受限較多。Windows Container 使 ASP.NET/.NET Framework/.NET 可用容器封裝與部署，與 Linux 生態共同運作，利於導入 API Gateway、Registry、CI/CD 與異質組合（例如 Redis、Elastic 在 Linux，Web 在 Windows）。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q11, C-Q4, A-Q13

A-Q16: 什麼是技術異質性？為何重要？

• A簡: 於同一系統採用多語言/多平台，選每個子域最適解。
• A詳: 技術異質性指同一產品線中，不同服務可用不同語言與平台（如 .NET Web、Linux 上 Redis/Elastic）。前提是能管理部署與運維複雜度。微服務加容器降低門檻，讓架構以業務需求為先，採用最成熟解法，而非被單一技術棧綁定。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, C-Q6, A-Q13

A-Q17: 什麼是 Glue Code？何時使用？

• A簡: 為過渡期撰寫的臨時轉接程式，通常不公開、不長期維護。
• A詳: 在單體轉微服務的過程，新舊系統需互通。Glue Code 是連接新服務與既有模組/資料的臨時程式，重點在快速打通、風險可控，而非對外契約品質。待新架構穩定後，應計畫移除或以正式 API 取代，避免技術債累積。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q3, B-Q7, C-Q3

A-Q18: 導入微服務的入門門檻有哪些？

• A簡: 分散式架構能力、工程流程（CI/CD/測試）、營運部署能力。
• A詳: 三大門檻：1) 架構面：分散式除錯、追蹤、可靠通訊、資料一致性；2) 開發面：契約管理、相容性、套件與 API 版本治理、自動化測試與 CI/CD；3) 營運面：大量服務與實例的部署、監控、告警、回滾與容量管理。未跨過門檻，導入將非常痛苦。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q16, B-Q13, D-Q5

A-Q19: 為何 DevOps 對微服務至關重要？

• A簡: 沒有自動化與觀測，微服務的多服務部署與營運將不可維持。
• A詳: 微服務數量多、更新頻繁，若無自動化建置、測試、部署與回滾，營運成本會暴增。DevOps 流水線與基礎建設即程式（IaC）確保一致性；集中觀測（日誌、指標、追蹤）提升診斷效率；灰度釋出與回滾降低變更風險。這些是微服務得以規模化運作的基礎。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q16, D-Q5, B-Q13

A-Q20: 什麼情況不建議使用微服務？

• A簡: 問題可由單一應用解決、團隊未備妥、變更頻率低時不宜導入。
• A詳: 若系統規模小、變更少、瓶頸可透過單體重構或橫向擴展解決；或團隊缺乏分散式、CI/CD 與容器能力；或主要問題是需求不確定性而非技術擴展性，導入微服務多半只增加成本與風險。應以問題導向，選最低足夠複雜度的架構。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, B-Q20, D-Q7

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

B-Q1: 微服務整體如何運作？

• A簡: 多個自治服務以 API 協作，獨立部署與伸縮，透過路由統一入口。
• A詳: 原理：將系統切為多服務，各自擁有資料與邏輯；以 API（REST 等）通訊。流程：客戶端→入口（反向代理/API Gateway）→對應服務→跨服務協作→回應。核心組件：服務本體、服務間通訊、入口路由、集中觀測（Log/Metric/Trace）、自動化部署與註冊/發現（若採用）。此模式提升自治與擴展性，代價是治理複雜度。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q3, B-Q4

B-Q2: 如何辨識適合的切割點（技術面）？

• A簡: 以依賴圖找高內聚區，避開強循環依賴，沿低耦合邊界切分。
• A詳: 原理：依賴分析揭示模組耦合度。流程：1) 視覺化依賴（調用/資料流）；2) 找出高內聚團塊；3) 檢視跨團塊呼叫頻率與粒度；4) 與業務流程比對；5) 擇低耦合邊界切割。核心組件：依賴圖、Use Case、耦合/內聚指標。避免切在頻繁同步互動處，降低跨服務成本。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, B-Q18, A-Q8

B-Q3: 重構策略一「停止擴大單體」的流程是什麼？

• A簡: 新功能改走新服務，前端以路由轉發；舊功能留在單體。
• A詳: 原理：以路由隔離變更。流程：1) 新需求建立獨立服務；2) 前端加反向代理/API Gateway，將新功能路徑導到新服務；3) 舊功能仍由單體處理；4) 必要時以 Glue Code 與舊系統交會。核心組件：新服務、路由器（NGINX/HAProxy/API Gateway）、Glue Code。先止血，再逐步拆分。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q1, A-Q17, B-Q4

B-Q4: 反向代理與 API Gateway 的機制與差異？

• A簡: 皆做轉發；Gateway 還管驗證、節流、版本、聚合等高階能力。
• A詳: 原理：以 L7 代理轉發請求。流程：1) 比對路徑/主機/標頭；2) 轉發至目標服務；3) 回寫回應。核心組件：路由規則、健康檢查、重試/逾時。API Gateway 除路由外，還含認證授權、流量管制、版本控制、請求/回應轉換與聚合。反向代理偏輕量、Gateway 偏完整治理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q1, C-Q6, A-Q12

B-Q5: 重構策略二「前後端切開」如何執行？

• A簡: 定義後端 API；前端改以 API 呼叫；後端承載既有邏輯。
• A詳: 原理：以 API 為清晰契約拆分。流程：1) 選定切點；2) 定義後端 API 契約（資源、方法、錯誤）；3) 將單體複製為前/後兩份；4) 前端改呼叫後端 API；5) 後端實作 API 封裝原邏輯；6) 漸進清理重複碼。核心組件：契約、前端 Client、後端 API、相容性測試。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q2, A-Q12, B-Q6

B-Q6: API 契約與版本治理的流程？

• A簡: 明確契約、標示版本、保障相容；以棄用策略平滑遷移。
• A詳: 原理：穩定契約支撐獨立部署。流程：1) 定義資源與結構；2) 決定版本位址（路徑/標頭）；3) 加入回傳碼與錯誤模型；4) 建立相容性測試；5) 制定棄用公告與時程；6) 灰度釋出與回滾。核心組件：Schema、版本策略、契約測試、發布策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, C-Q7, D-Q3

B-Q7: 重構策略三「抽取內部元件」如何落地？

• A簡: 複製架構、以 REST 轉接替代內部呼叫，逐步清理冗餘。
• A詳: 原理：把內部模組升級為服務。流程：1) 鎖定欲抽取之模組；2) 複製系統成新舊兩側；3) 以 REST Client/Server 取代原本local呼叫；4) 雙向需要者皆加轉接；5) 過渡期允許重複碼；6) 後續持續優化與合併。核心組件：REST API、Client、路由與觀測。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: C-Q9, A-Q8, D-Q1

B-Q8: 為什麼遠端呼叫效能顯著下降？

• A簡: 跨網需序列化、傳輸、排隊與重試；延遲放大、吞吐降低。
• A詳: 原理：Local 呼叫是記憶體堆疊跳轉；遠端需序列化/反序列化、TCP/HTTP 往返、佇列排隊、可能重試。流程：1) 構建請求；2) 網路往返；3) 解析回應。核心組件：序列化器、傳輸協定、逾時/重試策略。建議粗粒度 API、批次與快取，減少交互次數。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q1, A-Q6, C-Q6

B-Q9: Dockerfile 建置映像的原理？

• A簡: 以層（Layer）疊加基底映像與指令，產生可重用的映像。
• A詳: 原理：宣告式 Dockerfile 定義基底（FROM）、檔案加入（COPY）、依賴安裝（RUN）、啟動命令（CMD/ENTRYPOINT）。流程：1) 解析 Dockerfile；2) 逐層建置快取；3) 產生映像。核心組件：基底映像、分層快取、Build Context、Registry。層可重用，建置與分發高效。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q4, B-Q10, A-Q13

B-Q10: 容器映像 Registry 如何分發映像？

• A簡: 以分層存儲與雜湊索引，推送/拉取只傳缺失層，節省頻寬。
• A詳: 原理：映像分層與內容可尋址（Digest）。流程：1) Push 時上傳新層與清單；2) Pull 時比對本地層，僅下載缺少層；3) 利用快取加速。核心組件：Registry 伺服器、Manifest、Layer、Digest。使大規模部署與回滾更高效。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q5, B-Q9, A-Q13

B-Q11: Windows 與 Linux 容器如何協作（Hyper-V 容器）？

• A簡: 以虛擬化隔離執行 Linux 容器，讓 Windows 環境能跑異質工作負載。
• A詳: 原理：在 Windows 透過虛擬化（如 Hyper-V 型）提供 Linux 內核環境，承載 Linux 容器。流程：1) 啟用對應容器執行時；2) 以平台旗標選定目標；3) 一致化使用 docker 命令。核心組件：Windows 容器執行時、虛擬化層、Linux 容器執行時。讓異質組合更容易落地。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q15, C-Q6, A-Q13

B-Q12: 微服務如何支持技術異質性？

• A簡: 邊界清晰與標準協定，使不同語言/平台以 API 安全互通。
• A詳: 原理：以協定（HTTP/gRPC）取代語言/Runtime 相依。流程：1) 定義清晰契約；2) 服務內選用最適棧；3) 以容器封裝；4) 透過路由統一入口；5) 観測與部署統一化。核心組件：API 契約、容器、路由、觀測、CI/CD。使 .NET、Java、Linux 服務共存互補。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q16, C-Q6, B-Q4

B-Q13: 分散式日誌與追蹤如何運作？

• A簡: 用關聯 ID 串起跨服務請求，集中收集與檢索日誌/指標/追蹤。
• A詳: 原理：以 Correlation/Trace ID 在請求鏈路中傳遞。流程：1) 入口生成 ID；2) 注入標頭向下傳遞；3) 各服務記錄同一 ID 的日誌/指標；4) 集中平台檢索與視覺化。核心組件：日誌收集器、度量系統、分散式追蹤、儀表板。可快速定位跨服務問題。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q8, D-Q4, A-Q6

B-Q14: 遠端穩定性機制有哪些（逾時、重試、斷路器）？

• A簡: 設逾時、防雪崩的重試與熔斷，隔離失敗並快速恢復。
• A詳: 原理：失敗不可避免，以保護性策略控制影響面。流程：1) 為呼叫設定逾時；2) 針對可恢復錯誤重試（退避抖動）；3) 累積錯誤啟動熔斷，快速失敗並恢復探測；4) 快取/降級應對。核心組件：逾時/重試器、熔斷器、回退策略。確保服務韌性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q6, B-Q8, A-Q6

B-Q15: 直呼 vs 經由 API Gateway：何時選用？

• A簡: 少量服務可直呼；多服務治理需 Gateway 提供統一能力。
• A詳: 原理：治理需求決定入口模式。流程：1) 評估服務規模與跨域需求；2) 若僅數個內部服務、簡單流量，直呼較輕；3) 若需驗證、節流、版本、觀測、灰度與聚合，採 Gateway。核心組件：服務間通訊、Gateway 能力、政策管理。逐步演進即可。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, C-Q6, A-Q12

B-Q16: 微服務的 CI/CD 流水線怎麼設計？

• A簡: 針對每服務獨立建置、測試、製像、掃描、部署與回滾。
• A詳: 原理：單一服務獨立生命周期。流程：1) 觸發建置；2) 單元/契約/整合測試；3) 產生映像並簽章；4) 安全掃描；5) 推送 Registry；6) 漸進部署（灰度/藍綠）；7) 自動回滾。核心組件：CI 伺服器、測試框架、容器建置、Registry、部署控制器、觀測。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q10, A-Q19, D-Q5

B-Q17: 路徑或網域導向的請求路由如何工作？

• A簡: 依請求屬性匹配規則，轉發至目標服務，支援健康檢查與重試。
• A詳: 原理：第七層代理根據 Host/Path/Header 決策。流程：1) 載入規則；2) 解析請求；3) 選擇上游；4) 轉發並處理失敗機制；5) 回應。核心組件：路由規則、上游池、健康檢測、重試/逾時。可用於新功能導流與灰度。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q1, B-Q4, C-Q6

B-Q18: 如何將 Use Case 映射到服務互動？

• A簡: 以使用者目標拆分步驟，對齊服務職責與交互順序。
• A詳: 原理：讓服務協作貼近流程。流程：1) 梳理 Use Case 與主/替代流程；2) 對應至服務職責；3) 檢查跨邊界次數與資料流；4) 調整服務粒度；5) 驗證異常處理路徑。核心組件：Use Case、服務互動圖、序列圖。確保切分合理與可演進。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, A-Q10, B-Q2

B-Q19: 如何讓架構與組織對齊（康威反射）？

• A簡: 以跨職能團隊負責子域，服務邊界對應團隊責任。
• A詳: 原理：組織邊界塑造系統邊界。流程：1) 以業務域分團隊；2) 每隊負責一組服務的全生命周期；3) 明確介面契約與協作模式；4) 減少跨隊依賴；5) 以觀測與回饋循環改進。核心組件：團隊拓撲、契約、平台能力。可降低協調成本，提高交付速度。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q9, D-Q9, B-Q16

B-Q20: 導入微服務的評估機制？

• A簡: 以痛點清單與能力盤點，搭配小範圍試點驗證可行。
• A詳: 原理：問題導向與漸進式風險控管。流程：1) 明確現狀痛點（擴展、部署、異質等）；2) 盤點團隊能力（分散式、容器、CI/CD）；3) 設計試點範圍與成功指標；4) 建立最小可行平台（路由、觀測、流水線）；5) 回顧結果決定擴張或調整。核心組件：評估清單、試點、平台基座。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q2, A-Q18, C-Q10

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

C-Q1: 如何以反向代理將新功能導到新服務（停止擴大單體）？

• A簡: 新功能獨立成服務，前端設路由轉發，新舊並行運作。
• A詳: 步驟：1) 為新功能建立新服務與容器映像；2) 於前端加入反向代理（如 NGINX/HAProxy）；3) 設定路徑規則將 /new-feature 導到新服務；4) 保留舊功能走單體。設定片段（NGINX）：location /new-feature/ { proxy_pass http://new-svc:8080; } 注意健康檢查、逾時/重試、日誌關聯 ID，並以小流量驗證再放量。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q3, B-Q4, B-Q17

C-Q2: 如何將單體切為前後端兩個服務？

• A簡: 定義後端 API，前端改為 API Client，逐步清理重複碼。
• A詳: 步驟：1) 選切點（如控制器與業務層）；2) 設計後端 REST API（資源/方法）；3) 前端改以 HTTP 呼叫，如 GET /api/orders；4) 後端以原邏輯實作 API；5) 補上驗證與錯誤模型；6) 自動化契約測試。範例（cURL）：curl GET http://api/orders/123 注意版本路徑（/api/v1）、向後相容、逾時與重試。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q6, A-Q12

C-Q3: 如何撰寫 Glue Code 銜接新舊系統？

• A簡: 以最小可行轉接打通流程，待穩定後以正式 API 取代。
• A詳: 步驟：1) 明確過渡期資料/流程缺口；2) 在新服務加入轉接層，直接存取舊 DB/模組；3) 包裝為內部介面，不對外暴露；4) 加上監控與告警；5) 設定移除時程。示意：var legacy = new LegacyDb(); var dto = legacy.Query(…); return Map(dto); 注意權限、交易一致性與退場計畫，避免技術債永久化。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q17, B-Q3, D-Q8

C-Q4: 如何容器化 .NET 應用（Windows Container）？

• A簡: 以合適基底映像撰寫 Dockerfile，建置推送並以相同命令啟動。
• A詳: 步驟：1) 選基底映像（例：mcr.microsoft.com/dotnet/aspnet:適用版本-適用Windows基底）；2) Dockerfile：FROM COPY . /app WORKDIR /app EXPOSE 80 ENTRYPOINT [“dotnet”,”App.dll”]; 3) docker build -t myapp:1.0 .；4) docker run -p 8080:80 myapp:1.0；5) 推送 Registry。注意：鎖定 .NET 與 OS 版本相容、最小權限、健康檢查與資源限制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, B-Q10, A-Q15

C-Q5: 如何快速建立私有映像倉庫（Registry）？

• A簡: 啟動官方 registry 容器，設定認證與儲存，安全地推拉映像。
• A詳: 步驟：1) docker run -d -p 5000:5000 –name registry registry:2；2) 設置認證/TLS（正式環境）；3) docker tag myapp:1.0 localhost:5000/myapp:1.0；4) docker push localhost:5000/myapp:1.0；5) 節點配置為可信倉庫。注意：儲存持久化、Access Control、網路帶寬與快取策略。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q10, C-Q4, B-Q16

C-Q6: 如何導入 API Gateway 串接單體與新服務？

• A簡: 設路由與策略於 Gateway，集中驗證與版本，統一路口。
• A詳: 步驟：1) 部署 Gateway；2) 為 /api/v1/orders 指向單體，/api/v1/new-feature 指向新服務；3) 啟用驗證、流控、逾時/重試；4) 設定版本轉送與棄用策略；5) 接入集中觀測。設定示例（概念）：route /api/v1/new-feature -> svc-new；policies: auth, rate-limit。注意：小步導入、先路由後政策、監控延遲與失敗率。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q17, A-Q12

C-Q7: 如何實作 API 版本管理？

• A簡: 以路徑/標頭標示版本，維持相容並制訂棄用時程。
• A詳: 步驟：1) 選擇版本策略（/api/v1 或 Accept: version=1）；2) 路由對應至不同版本服務；3) 於文件標註變更與棄用期；4) 契約測試確保相容；5) 灰度導向新版本。路由示例：/api/v1/orders -> svc-v1；/api/v2/orders -> svc-v2。注意：避免破壞性變更、提供轉換層、明確期限公告。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, D-Q3, C-Q6

C-Q8: 如何建立跨服務日誌與關聯 ID？

• A簡: 入口生成關聯 ID，沿鏈路傳遞並集中蒐集分析。
• A詳: 步驟：1) 入口中介軟體產生 X-Correlation-ID；2) 下游呼叫傳遞該標頭；3) 各服務日誌皆包含該 ID；4) 收集到集中平台（ELK/等）；5) 儀表板串查請求。範例（偽碼）：id=req.header(“X-Correlation-ID”)??uuid(); log.with(id).info(…); 注意：標準化欄位、時區/時間戳、結構化日誌。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q13, D-Q4, A-Q6

C-Q9: 如何按策略三抽取模組為服務？

• A簡: 以 REST 取代內部呼叫，雙向轉接，逐步移除重複與相依。
• A詳: 步驟：1) 鎖定模組 Z；2) 定義 Z 的公開 API；3) 新增 Z 服務與容器；4) X→Z 改為 REST Client；5) Z 若需 X 也以 API 回呼；6) 保留重複碼過渡；7) 加入觀測與壓測；8) 穩定後移除重複與 Glue。注意：粒度調整、批次/快取、失敗處理與回滾預案。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q7, B-Q8, D-Q1

C-Q10: 如何以試點專案驗證微服務可行性？

• A簡: 小範圍選題，最小平台基座，明確指標，驗證後再擴大。
• A詳: 步驟：1) 選擇邊界清晰、風險可控的子域；2) 建最小平台：路由、容器、Registry、觀測、基本 CI/CD；3) 設定成功指標（部署頻率、回復時間、失敗率、Lead Time）；4) 小量流量灰度；5) 回顧與知識沉澱。注意：避免大爆改、保持可回滾、優先建立可觀測性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q20, A-Q19, D-Q5

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

D-Q1: 切出服務後效能驟降怎麼辦？

• A簡: 減少跨服務往返、改粗粒度、批次/快取，並優化逾時重試。
• A詳: 症狀：P99 延遲升高、TPS 下滑。原因：序列化耗時、跨網延遲、頻繁細粒度呼叫。解法：1) 調整 API 粒度與路徑，減往返次數；2) 批次與快取；3) 非即時改為異步；4) 設合理逾時與重試；5) 壓測與容量規劃。預防：切分前先模擬依賴圖，避開高頻交互的切點。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, C-Q9, A-Q8

D-Q2: 分散式資料一致性問題如何處理？

• A簡: 採事件驅動與最終一致性，設計冪等與補償，避免跨服務交易。
• A詳: 症狀：跨服務更新出現不一致。原因：網路失敗、部分成功、併發競爭。解法：1) 事件驅動、最終一致；2) 冪等操作與唯一鍵；3) 補償流程；4) 邏輯分片避免分散式交易；5) 對齊一致性需求層級。預防：在設計階段避開跨服務強一致路徑，將強一致留在單一服務內。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q6, B-Q14, A-Q7

D-Q3: 升級單一服務導致相依服務壞掉怎麼辦？

• A簡: 維持向後相容、版本並存、契約測試與灰度釋出。
• A詳: 症狀：升級後出現 400/500 或資料結構不符。原因：破壞性更動、未公告棄用。解法：1) 新舊版本並存；2) 消費者驅動契約測試；3) 灰度釋出與快速回滾；4) 明確棄用期與遷移指引。預防：版本策略落地、API 變更審核流程。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, C-Q7, A-Q12

D-Q4: 跨服務除錯困難如何診斷？

• A簡: 建立關聯 ID、集中日誌/追蹤/指標，配合儀表板與告警。
• A詳: 症狀：不易重現或定位問題服務。原因：鏈路跨多服務，缺乏統一觀測。解法：1) 強制 Correlation ID；2) 結構化日誌集中收集；3) 分散式追蹤串線；4) 服務級指標與告警；5) 錯誤分級。預防：在試點即導入觀測，將其納入完成定義（DoD）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q13, C-Q8, A-Q6

D-Q5: 部署與維運複雜度爆炸怎麼辦？

• A簡: 容器化、建立 CI/CD 與標準化平台，實作灰度與回滾。
• A詳: 症狀：手動部署易錯、環境不一致。原因：多服務、多版本缺少自動化。解法：1) 容器與映像管理；2) 服務級流水線；3) 標準化環境（IaC）；4) 灰度釋出與回滾；5) 監控與容量管理。預防：平台基座先行，服務再擴張。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q16, C-Q10, A-Q19

D-Q6: 網路逾時與不可靠導致錯誤怎麼辦？

• A簡: 設逾時、重試與熔斷；降級與快取，監控失敗率。
• A詳: 症狀：頻繁 5xx/逾時。原因：瞬時抖動、背壓、串聯失敗。解法：1) 逾時保護；2) 指數退避重試；3) 熔斷快速失敗；4) 快取與降級；5) 背壓與佇列異步化。預防：壓測、容量預算與 SLO 制定。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q14, B-Q8, D-Q1

D-Q7: 如何判斷已過度切割並修正？

• A簡: 指標為過多跨服務呼叫與低變更耦合度；合併或調整邊界。
• A詳: 症狀：改一功能需動多服務、延遲高、營運負擔大。原因：切在頻繁交互處、粒度太細。解法：1) 觀測跨呼叫密度與變更耦合；2) 合併高度耦合服務；3) 提升 API 粗粒度；4) 重繪邊界。預防：以 Use Case 驗證切點，先「剛好」再演進。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q8, B-Q2, B-Q18

D-Q8: Glue Code 變成長期技術債怎麼辦？

• A簡: 設定退場計畫與里程碑，用正式 API 逐步取代。
• A詳: 症狀：轉接層擴張、難維護。原因：過渡期無終止設計。解法：1) 列出依賴清單；2) 拆分轉換為公開 API；3) 設定每段功能下線節點；4) 觀測確保無流量後移除。預防：建立過渡期準則與稽核機制。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q17, C-Q3, B-Q5

D-Q9: 組織與架構不對齊引發協作瓶頸怎麼辦？

• A簡: 調整團隊拓撲對齊子域，明確契約、減少跨隊依賴。
• A詳: 症狀：跨團隊協調成本高、交付慢。原因：服務邊界與團隊責任不一致。解法：1) 以子域重劃團隊；2) 團隊端到端負責；3) 建立契約與變更流程；4) 觀測與回饋循環。預防：導入前先做組織盤點與試點。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q9, B-Q19, B-Q20

D-Q10: Windows Container 常見問題與解法？

• A簡: 基底過大、相容性與版本對齊；採精簡映像與版本鎖定。
• A詳: 症狀：映像龐大、建置慢、執行相容性問題。原因：不合適基底、.NET/OS 版本不匹配。解法：1) 選最小可行基底；2) 多階段建置減少體積；3) 鎖定 .NET 與 OS 版本；4) 健康檢查與資源限額；5) 本地與 CI 環境一致。預防：規範映像選型與版本管理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q4, B-Q9, A-Q15

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是微服務（Microservices）？
  • A-Q2: 微服務為什麼不應成為目標，而是手段？
  • A-Q3: 微服務的核心原則是什麼？
  • A-Q4: 微服務與單體式架構有何差異？
  • A-Q5: 為什麼近年微服務流行？
  • A-Q13: 為什麼容器技術對微服務關鍵？
  • A-Q14: 容器與虛擬機（VM）差異是什麼？
  • A-Q15: 對 .NET 團隊，Windows Container 有何意義？
  • B-Q1: 微服務整體如何運作？
  • B-Q3: 重構策略一「停止擴大單體」的流程是什麼？
  • B-Q4: 反向代理與 API Gateway 的機制與差異？
  • C-Q1: 如何以反向代理將新功能導到新服務？
  • C-Q4: 如何容器化 .NET 應用（Windows Container）？
  • C-Q5: 如何快速建立私有映像倉庫（Registry）？
  • D-Q5: 部署與維運複雜度爆炸怎麼辦？
• 中級者：建議學習哪 20 題
  • A-Q6: 分散式系統的主要挑戰是什麼？
  • A-Q7: 什麼是服務邊界？如何判斷切點？
  • A-Q8: 為何過度切割會適得其反？
  • A-Q9: 什麼是康威定律？與微服務有何關係？
  • A-Q12: 為何 API 版本相容性重要？
  • A-Q16: 什麼是技術異質性？為何重要？
  • B-Q2: 如何辨識適合的切割點（技術面）？
  • B-Q5: 重構策略二「前後端切開」如何執行？
  • B-Q6: API 契約與版本治理的流程？
  • B-Q8: 為什麼遠端呼叫效能顯著下降？
  • B-Q9: Dockerfile 建置映像的原理？
  • B-Q10: 容器映像 Registry 如何分發映像？
  • B-Q12: 微服務如何支持技術異質性？
  • B-Q13: 分散式日誌與追蹤如何運作？
  • B-Q14: 遠端穩定性機制有哪些（逾時、重試、斷路器）？
  • B-Q16: 微服務的 CI/CD 流水線怎麼設計？
  • B-Q17: 路徑或網域導向的請求路由如何工作？
  • C-Q2: 如何將單體切為前後端兩個服務？
  • C-Q6: 如何導入 API Gateway 串接單體與新服務？
  • C-Q7: 如何實作 API 版本管理？
• 高級者：建議關注哪 15 題
  • A-Q10: 物件導向（OOP）概念如何啟發微服務切分？
  • A-Q11: 為何建議用 Use Case 對照微服務架構圖？
  • A-Q18: 導入微服務的入門門檻有哪些？
  • B-Q7: 重構策略三「抽取內部元件」如何落地？
  • B-Q11: Windows 與 Linux 容器如何協作（Hyper-V 容器）？
  • B-Q18: 如何將 Use Case 映射到服務互動？
  • B-Q19: 如何讓架構與組織對齊（康威反射）？
  • B-Q20: 導入微服務的評估機制？
  • C-Q8: 如何建立跨服務日誌與關聯 ID？
  • C-Q9: 如何按策略三抽取模組為服務？
  • C-Q10: 如何以試點專案驗證微服務可行性？
  • D-Q1: 切出服務後效能驟降怎麼辦？
  • D-Q2: 分散式資料一致性問題如何處理？
  • D-Q7: 如何判斷已過度切割並修正？
  • D-Q9: 組織與架構不對齊引發協作瓶頸怎麼辦？