微服務架構 #1, WHY Microservices?

問題與答案 (FAQ)

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

Q1: 什麼是微服務架構（Microservices）？

• A簡: 將大型應用切為小型可獨立部署的服務，透過 API 在執行期協作，降低複雜度並提升彈性。
• A詳: 微服務是一種將大型應用拆分為多個小而自治的服務的架構風格。每個服務專注單一業務能力，擁有獨立的部署、版本與擴展節奏，並以明確的 API 或通訊協定在執行期彼此協作。由於服務間透過介面解耦，實作可使用不同平台與語言。此方式降低單體應用的複雜度與耦合，並讓維運能精確監控、個別升級與故障隔離，提升開發效率與系統韌性。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q3, B-Q1

Q2: 什麼是單體式架構（Monolithic）？

• A簡: 以單一進程部署的大型應用，於開發期組裝元件，運行時作為一個整體執行。
• A詳: 單體式架構指應用內部所有功能以同一語言與平台開發，透過函式庫與元件在開發期組裝，最終以單一可執行體或單一進程運作。其優點是開發與部署初期較簡單，整體一致性高；缺點是規模成長後，複雜度、耦合度與部署風險同步增加，效能瓶頸難以局部修正，擴展常需整體擴張，導致資源使用效率不佳。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3, B-Q2, B-Q11

Q3: 微服務與單體式架構的主要差異是什麼？

• A簡: 微服務以多進程服務協作；單體以單進程整體運作。差異在重用層級、部署單位與維運彈性。
• A詳: 差異包括：1) 重用層級：單體偏向 source/binary 於開發期重用；微服務重用發生於執行期的服務契約。2) 執行模型：單體為單一進程，微服務由多進程服務組成。3) 部署單位：單體一次性部署；微服務獨立部署與升級。4) 技術異質性：微服務允許不同語言/框架。5) 維運：微服務可細粒度監控、故障隔離與精準擴展；單體多為整體操作。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q11, B-Q1

Q4: 為什麼需要微服務架構？

• A簡: 降低大型系統複雜度，提升獨立部署、擴展與維運彈性，支援更快交付與變更。
• A詳: 當應用規模與複雜度成長，單體式架構在部署、升級與效能優化上成本攀升。微服務透過業務能力切分，讓每個服務可獨立開發、測試、部署與擴展，將變更範圍局部化，降低風險。維運可針對特定服務監控與調整資源，提升可靠性與成本效率。再配合容器與自動化流程，能縮短交付時間，支援更快的產品迭代。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, A-Q17, B-Q8

Q5: 微服務的核心價值是什麼？

• A簡: 單一職責、鬆耦合、獨立部署與擴展，強化韌性、可維運性與交付速度。
• A詳: 微服務核心價值包括：1) 單一職責：每個服務專注一種業務能力，易於理解與維護。2) 鬆耦合：以 API 協作，降低跨模組影響。3) 獨立部署：變更與發布對其他服務影響最小。4) 彈性擴展：針對負載熱點服務擴張。5) 韌性與可維運性：細粒度監控與故障隔離。6) 技術多樣性：允許依需求選擇適合的語言與框架，提升解決問題的自由度。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q4, B-Q7

Q6: SOA（服務導向架構）與微服務的關係是什麼？

• A簡: 微服務延續 SOA 精神，但粒度更小、部署更獨立，當代工具使其落地更容易。
• A詳: SOA 提倡以服務為邏輯邊界、以契約協作的理念。微服務承襲此精神，但將服務粒度縮小到可獨立部署與自治的單位，並強調自動化、雲原生與去中心化數據及治理。2000 年代因工具與部署門檻高，SOA 常見於大型企業；容器與現代化工具鏈普及後，微服務將這些理念以更輕量的方式落地到更廣泛的團隊與場景。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, B-Q3, B-Q11

Q7: 為什麼 container 與微服務常被一起提起？

• A簡: 容器將部署單位細化與標準化，剛好補上微服務多實例、頻繁發布的運維需求。
• A詳: 微服務帶來更多服務實例、更多部署與升級事件，傳統手動部署與實體/虛擬機粒度過大，成本高且易錯。容器提供輕量、可移植、可重現的部署單位，使建置、打包與發布標準化，快速啟動與回滾，並易於實作自動化管線與擴展。容器因此成為微服務落地的關鍵配套，兩者相輔相成。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q8, B-Q3, B-Q11

Q8: 什麼是 container？部署單位如何演進？

• A簡: 容器是輕量隔離的運行環境；部署單位自伺服器→虛擬機→容器逐步細化與敏捷。
• A詳: 部署單位歷經三階段：1) 伺服器：最小單位為實體機，成本高且彈性差。2) 虛擬機：以管理程式隔離 OS，提升整合密度但啟動與影像仍較重。3) 容器：共享宿主 OS 核心，提供進程級隔離，打包應用與依賴，啟動快、資源效率高，適合微服務的多實例與頻繁部署。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q11, B-Q3, A-Q7

Q9: 微服務允許使用異質技術堆疊嗎？

• A簡: 允許。服務間以 API 協作，實作可用不同平台、語言與框架，彼此獨立。
• A詳: 微服務間只以明確契約（API/協定）互動，不共享內部實作，因此每個服務可自由選擇最適技術棧，如 .NET、Java 或 Node.js。這提升解題自由度與團隊自主性，並能逐步演進或替換舊技術。然而需嚴格治理契約相容性與跨語言通訊，避免碎片化與運維負擔過重。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, B-Q5, B-Q9

Q10: API 與 protocol 在微服務中的角色是什麼？

• A簡: 它們是跨服務溝通契約，定義資料與行為，確保獨立實作能在執行期協作。
• A詳: API 與通訊協定是服務間協作的公開契約，定義可用的操作、資料格式與錯誤語意。像資料庫以協定與驅動程式提供服務（如 SQL Server/TCP 1433），應用以相容的用戶端存取。良好的契約讓不同技術實作的服務在執行期互通，升級時亦能維持相容性，達到可替換與隱藏實作細節的目標。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q9, A-Q11

Q11: 程式碼重用的三種層級是什麼？

• A簡: Source code、Binary code、Service 三層，分別對應開發期與執行期的重用。
• A詳: 重用層級可分：1) 原始碼重用：需取得源碼，於編譯期整合，更新需重編與測試。2) 二進位重用：以套件/函式庫形式於開發期連結，介面不變時可直接替換。3) 服務重用：以執行期的遠端服務存取（API/協定），應用不需重編即可升級或替換服務。微服務偏向第三種重用，強化鬆耦合與部署彈性。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q12, A-Q13, A-Q14

Q12: Source code 重用的特性與限制？

• A簡: 編譯期整合、須同語言、更新需重編與測試，變更範圍較大。
• A詳: 原始碼重用如程式碼片段、樣板或設計模式，需在同一語言與專案內整合。任何更新都會牽動重新編譯、測試、發行作業，影響面較大。優點是靈活，可深度客製；缺點是變更成本高、耦合強，不利於獨立部署。微服務仍用得到，但建議在單一服務內部採用，避免跨服務共享源碼。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q11, A-Q13, B-Q10

Q13: Binary code 重用的特性與限制？

• A簡: 以套件/函式庫在開發期連結，介面穩定可熱替換，但仍需重新發布應用。
• A詳: 二進位重用以封裝良好的函式庫/元件形式（如 .NET DLL、Java JAR）於開發期納入。若公開介面不變，可僅替換二進位以修補漏洞；但多數情境仍需重建、測試與發布整體應用。它能提升一致性與重用效率，但對部署與運維彈性的幫助有限，與微服務的執行期重用不同。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q11, B-Q10, A-Q14

Q14: Service 重用的特性與優點？

• A簡: 以執行期的遠端服務重用，升級可不動應用，隔離實作並強化彈性。
• A詳: 服務重用透過 API/協定存取外部服務，如資料庫、驗證或業務功能。應用不需內含其實作，升級與維護可在服務端完成，甚至不停機。若契約穩定，可替換不同實作（如 MySQL 改 SQLite）。此模式將重用提升到執行期，帶來解耦與運維彈性，是微服務落地的基石。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q10, B-Q6, B-Q5

Q15: 對開發團隊而言，單體與微服務有何不同？

• A簡: 單體統一技術與發布；微服務按業務切分團隊，獨立開發、測試與發佈。
• A詳: 單體常以單一技術棧協作，發佈節奏一致，跨模組變更影響大。微服務則以業務邊界切分團隊，每隊擁有某服務的全責，技術自選，能獨立開發測試與部署。這減少協調成本並加速交付，但亦要求契約治理、服務邊界設計與跨服務測試策略，避免分散式複雜度失控。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q1, B-Q9, C-Q2

Q16: 對維運團隊而言，兩種架構差異為何？

• A簡: 單體多做整體操作；微服務可細粒度監控、獨立升級、重啟與精準擴展。
• A詳: 單體在維運上多以整體為單位進行監控、重啟、備援與擴展，難以針對局部瓶頸調整。微服務讓維運可對每個服務監控健康、延遲與資源，發生異常時僅重啟或下線該服務，並針對熱點服務擴展。雖然帶來更高的可見度與掌控力，但部署拓撲更複雜，需以容器與自動化工具降低人為成本。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q7, B-Q8, D-Q5

Q17: 為何容器技術降低導入微服務的門檻？

• A簡: 容器讓建置、打包、部署標準化可重現，啟動與擴展快速，易於自動化。
• A詳: 導入微服務需要大量、頻繁且一致的部署作業。容器將應用與依賴打包於一致的映像，從開發到生產維持同一環境，降低「環境不一致」風險。容器啟動快、占用小，適合多實例與水平擴展；其映像與定義檔亦利於自動化與版本治理，顯著降低部署與回滾成本，讓小團隊也能實踐微服務。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q11, C-Q1

Q18: 微服務與 DevOps 有何關聯？

• A簡: 微服務要求更快、更頻繁與自動化的交付；容器驅動了 DevOps 流程普及。
• A詳: 微服務把變更粒度縮小，增加發佈頻率，要求從建置、測試、部署到監控的端到端自動化。容器提供可重現環境與標準化打包，使 CI/CD 與基礎設施即程式成為可能。這促成開發與運維協作（DevOps），以共同的工具鏈與指標驅動快速可靠的交付，縮短從需求到上線的時間。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, C-Q5, D-Q8

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

Q1: 微服務在執行期如何運作與組合成應用？

• A簡: 各服務以獨立進程運行，透過 API/協定協作，於執行期動態組構完整應用。
• A詳: 原理說明：每個服務作為獨立進程，對外暴露 API/協定，彼此以網路通訊協作。關鍵流程：請求到達入口後路由至對應服務；服務間基於契約呼叫；依需要再存取資料庫等外部服務。核心組件：服務自身、API 契約、網路協定（HTTP/TCP 等）、外部服務（DB）。這種執行期組構使部署與擴展更靈活。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q1, A-Q10, B-Q5

Q2: 單體式應用的編譯與執行流程為何？

• A簡: 以單一代碼庫編譯為可執行體/進程，內部元件在開發期靜態連結整合。
• A詳: 原理說明：單體將功能與模組在編譯期以 source/binary 連結，產生單一可部署單位。關鍵流程：撰寫模組→編譯打包→部署→以單一進程啟動。核心組件：語言/框架編譯工具、函式庫、應用主進程。優點是部署簡單；缺點是變更需重建整體，局部故障也可能拖累整體。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q11, B-Q10

Q3: 容器如何簡化部署流程與加速交付？

• A簡: 以映像封裝應用與依賴，環境一致可重現，啟動快，利於自動化與回滾。
• A詳: 原理說明：容器共享宿主 OS 核心，將應用與依賴打包成映像，執行為隔離進程。關鍵流程：撰寫定義檔→建置映像→推送登錄→部署執行。核心組件：容器引擎、映像、登錄、定義檔。這使從開發到生產的環境一致，縮短啟動時間，便於擴展、回滾與自動化，符合微服務頻繁部署的需求。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q7, A-Q17, B-Q11

Q4: Windows Container 在 .NET 場景如何運作？

• A簡: 以 Windows 基底映像承載 .NET 應用，透過容器引擎啟動隔離進程，快速部署。
• A詳: 原理說明：Windows Container 使用 Windows 基底映像（含必要執行元件）來運行 .NET 應用，與宿主共享核心。關鍵流程：撰寫容器定義→建置映像→運行容器→對外曝光埠。核心組件：Windows 基底映像、.NET 執行時、容器引擎、網路與儲存設定。適合希望在 Windows 生態中落地微服務的團隊。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q1, C-Q6, A-Q7

Q5: 服務之間的通訊機制與關鍵組件是什麼？

• A簡: 以 API/協定進行網路呼叫，依賴序列化、連線與錯誤處理，確保契約相容。
• A詳: 原理說明：服務以 HTTP/TCP 等協定傳遞請求與回應，序列化資料並處理狀態碼/錯誤。關鍵流程：用戶端組裝請求→送出→伺服端驗證與處理→回傳結果。核心組件：API 契約、序列化格式、用戶端 SDK 或驅動程式（如 DB provider）、網路設定。良好通訊設計是服務可靠協作的基礎。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, B-Q9, C-Q4

Q6: 服務升級可不停機的原理是什麼？

• A簡: 契約穩定與多實例並行，透過逐步替換舊版服務，維持對外服務連續。
• A詳: 原理說明：以相容的 API 契約為前提，新舊版服務同時運行。關鍵流程：部署新版實例→導流部分流量→監測穩定→逐步替換舊版→下線舊版。核心組件：版本管理、流量切換機制、健康檢查。因應微服務獨立部署特性，可最小化停機並快速回滾，降低發布風險。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: C-Q8, B-Q9, D-Q2

Q7: 微服務的監控與故障隔離機制是什麼？

• A簡: 以服務為單位監測健康與資源，異常時僅重啟/下線該服務，縮小影響範圍。
• A詳: 原理說明：監控針對每個服務收集健康檢查、延遲與資源指標，觸發告警與自動化動作。關鍵流程：指標收集→告警判斷→自動重啟/降級→人工介入。核心組件：健康端點、日誌與度量、告警。細粒度監控使故障隔離與快速修復可行，是微服務可維運性的關鍵。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q7, D-Q5, A-Q16

Q8: 微服務的彈性擴展（scale out）如何設計？

• A簡: 針對高負載服務水平擴展其實例，透過負載分流與資源配置達成彈性。
• A詳: 原理說明：擴展單一服務的多個實例來分攤請求，避免整體擴展浪費。關鍵流程：監測負載→新增實例→更新路由/負載策略→回收空閒實例。核心組件：服務實例、路由與負載分配、資源限制。此設計提升資源效率，符合微服務按需伸縮的原則。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q4, A-Q16, C-Q6

Q9: API 相容性與版本控制在微服務中的機制？

• A簡: 保持向後相容的契約，並以版本並存逐步遷移用戶端，降低升級風險。
• A詳: 原理說明：API 變更採向後相容策略，新增不破壞舊用法；重大變更以新版本發布。關鍵流程：標註版本→並存新舊版→監測用戶端遷移→淘汰舊版。核心組件：版本命名與路由、相容性測試、文件。此機制與獨立部署結合，支援頻繁升級而不破壞生產。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q6, C-Q3, D-Q2

Q10: 二進位重用與連結機制如何影響部署？

• A簡: 開發期連結依賴使部署耦合整體，介面變動需重建發布，影響微服務彈性。
• A詳: 原理說明：二進位依賴在編譯/打包時納入，部署單位與應用捆綁。關鍵流程：更新依賴→重建→測試→整體重新部署。核心組件：套件管理、編譯器、部署系統。這與微服務的執行期重用相對；過度依賴開發期連結會降低部署獨立性，需平衡使用。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q13, A-Q14, B-Q2

Q11: 部署單位從 Server→VM→Container 的技術差異？

• A簡: 實體→虛擬化 OS→進程級隔離，容器最輕量，啟動快且密度高，利微服務。
• A詳: 原理說明：Server 為硬體實體部署；VM 以管理程式虛擬化整個 OS；容器共享宿主核心，以命名空間/限制實現進程隔離。關鍵流程：配置環境→部署→啟動。核心組件：硬體/Hypervisor/容器引擎。容器相較 VM 更輕量與可移植，適合多服務與頻繁發佈的微服務場景。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q8, B-Q3, C-Q1

Q12: 微服務如何改善資源使用效率？

• A簡: 針對熱點服務擴展與調優，避免整體擴張，提升密度與成本效益。
• A詳: 原理說明：服務拆分後可對不同負載特性的服務分別配置 CPU/記憶體，僅擴展瓶頸服務。關鍵流程：監測負載→定位熱點→調整資源或擴展實例。核心組件：監控、資源限制、擴展策略。此細粒度管理避免單體浪費資源，讓硬體效用最大化，降低成本。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q16, B-Q8, D-Q10

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

Q1: 如何將 ASP.NET MVC 應用容器化於 Windows Container？

• A簡: 撰寫容器定義、建置映像、開放埠並運行，確保相依元件與設定隨映像。
• A詳: 步驟：1) 以 Windows 基底映像撰寫定義（包含 .NET 版本）。2) 複製組建成果與設定。3) 設定啟動命令與開放埠（如 80）。4) 建置映像與執行。指令範例：docker build -t myapp:1.0 .、docker run -p 80:80 myapp:1.0。注意：最小化映像、外部化機敏設定、健康檢查端點。最佳實踐：確保可重現建置與日誌標準輸出。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q3, C-Q5

Q2: 如何從單體拆分出第一個微服務？

• A簡: 以單一明確業務能力為邊界，抽出最獨立且高變動/高負載模組為首個服務。
• A詳: 步驟：1) 盤點領域，識別高度內聚且外部依賴少的功能。2) 定義 API 與資料契約。3) 實作服務並替換單體內呼叫。4) 以容器部署並導流。代碼位移：先在單體中建立門面，再切換為遠端呼叫。注意：保持向後相容、監測延遲。最佳實踐：從非核心路徑或高收益模組起手。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q15, B-Q1, B-Q9

Q3: 如何為微服務定義穩定的 API 契約？

• A簡: 明確資源與操作、資料格式與錯誤語意，預留擴展並規範版本管理。
• A詳: 步驟：1) 定義資源/動作與輸入輸出。2) 規範錯誤碼與語意。3) 設計可選欄位以便擴展。4) 制定版本策略（路徑或標頭）。設定：使用一致的序列化格式與欄位命名。注意：避免破壞性變更，廣播變更公告。最佳實踐：契約先行、產生文件與用戶端 SDK、加入相容性測試。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, A-Q10, D-Q2

Q4: 如何設定微服務間的連線與通訊埠？

• A簡: 明確曝光服務埠與協定，配置環境變數/連線字串，避免埠衝突。
• A詳: 步驟：1) 決定協定（HTTP/TCP）。2) 暴露必要埠（如 HTTP 80、DB 1433）。3) 以環境變數注入服務位址。4) 在啟動參數設定對映，如 -p 8080:80。注意：避免硬編 IP，集中管理連線設定。最佳實踐：健康檢查與逾時重試策略，確保通訊可靠。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q5, D-Q7, C-Q1

Q5: 如何為微服務建立最小可行的 DevOps 流水線？

• A簡: 建置→測試→映像→掃描→部署，自動化每步驟並保存版本與紀錄。
• A詳: 步驟：1) CI 觸發建置與單元測試。2) 產生容器映像並標記版本。3) 安全與相依掃描。4) 部署至測試環境進行契約/整合測試。5) 核准後推至生產。設定：以版本號與提交雜湊標註映像。最佳實踐：不可變映像、單一事實來源、滾動發布與回滾。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q18, B-Q3, C-Q8

Q6: 如何在 Windows Container 上水平擴展某個服務？

• A簡: 啟動多實例並設定負載分流，依指標自動擴縮，確保無狀態或妥善管理狀態。
• A詳: 步驟：1) 將服務設計為無狀態。2) 啟動多個容器實例。3) 配置入口的負載分流。4) 監控 CPU/延遲以觸發擴縮。指令：docker run -p 8081:80 ... 多次啟動。注意：會話狀態外部化至資料存放。最佳實踐：健康檢查、漸進導流。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q8, D-Q5, C-Q7

Q7: 如何對微服務實作健康檢查與監控指標？

• A簡: 提供健康端點與關鍵度量，蒐集日誌/指標並設告警，支援自動修復。
• A詳: 步驟：1) 實作 /health 與就緒/存活檢查。2) 暴露指標（延遲、錯誤率、資源）。3) 導出日誌到標準輸出。4) 設定告警門檻。設定：環境變數控制健康檢查間隔。最佳實踐：紅/黃/綠健康狀態、關鍵依賴（DB）健康聯動。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, D-Q9, C-Q6

Q8: 如何規劃微服務的獨立升級與回滾策略？

• A簡: 遵循相容契約，採漸進式導流與藍綠/滾動發布，保留可快速回滾的舊版。
• A詳: 步驟：1) 維持 API 向後相容。2) 併行部署新舊版。3) 逐步導流與監控指標。4) 成功後淘汰舊版；異常即回滾。設定：以標籤標示版本。最佳實踐：不可變映像、回滾自動化、變更審核與公告。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q6, B-Q9, D-Q2

Q9: 如何在容器中連線到既有的資料庫服務（如 SQL Server）？

• A簡: 使用對應驅動與連線字串，開放正確埠（如 1433），以環境變數注入設定。
• A詳: 步驟：1) 於應用採用正確 provider。2) 設定連線字串為環境變數。3) 配置網路與開放埠。4) 啟動前測試連線。設定範例：DB_CONN=Server=db;Port=1433;...。注意：管理憑證與網路 ACL。最佳實踐：重試與逾時設定、只讀/寫入分離視需求。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q10, B-Q5, D-Q1

Q10: 如何在團隊內推進 .NET 開發者採用容器與微服務？

• A簡: 從小範圍試點、建立樣板與工具鏈、訓練與守則，逐步擴展到關鍵服務。
• A詳: 步驟：1) 選一個非關鍵服務試點。2) 建立容器化樣板與 CI/CD。3) 撰寫內部實踐守則（契約與版本策略）。4) 分享成功案例並擴展。注意：同步強化監控與故障處理流程。最佳實踐：以開發者體驗為中心，降低入門摩擦。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q17, A-Q18, C-Q5

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

Q1: 容器啟動後服務無法連線，應如何診斷？

• A簡: 檢查埠對映、網路與健康狀態，驗證連線設定與服務日誌，逐步排除。
• A詳: 症狀：容器啟動但無法存取 API/DB。可能原因：埠未對映或衝突、網路策略阻擋、健康檢查失敗、連線字串錯誤。解決：1) 檢查 -p 對映與占用。2) 驗證容器網路。3) 查看健康端點與日誌。4) 測試 DB 埠（如 1433）。預防：以環境變數管理設定、健康檢查與啟動探針自動化。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: C-Q4, C-Q9, B-Q5

Q2: 升級某服務後其他服務錯誤，如何處理 API 相容性？

• A簡: 回滾、並行保留舊版，採用版本化 API 並修正契約相容性測試與文件。
• A詳: 症狀：升級 A 服務後，B/C 呼叫失敗。原因：破壞性契約變更、版本策略缺失。解決：1) 立即回滾。2) 版本並存，逐步遷移用戶端。3) 增補向後相容路徑。4) 強化契約測試與文件。預防：嚴格版本策略與相容性檢查，發布前進行跨服務驗證。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q6, B-Q9, C-Q3

Q3: 單體式應用效能不足但難以擴展，怎麼辦？

• A簡: 鎖定瓶頸模組，優先抽成獨立服務進行水平擴展與資源優化。
• A詳: 症狀：整體擴展成本高、資源使用不均。原因：單體需整體擴張、無法針對熱點調整。解決：1) 分析熱點。2) 抽離高負載模組為微服務。3) 獨立擴展與調優。4) 建立監測。預防：持續以業務能力劃分，避免回到單體耦合。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: C-Q2, B-Q8, A-Q16

Q4: 微服務部署變複雜導致失敗，如何簡化與預防？

• A簡: 以容器標準化打包、建立自動化流水線與基礎樣板，降低人工差異。
• A詳: 症狀：手動部署錯誤、環境不一致。原因：多服務多環境導致複雜度飆升。解決：1) 容器化與不可變映像。2) CI/CD 自動化。3) 建立服務樣板。4) 基於標籤版本化。預防：IaC、環境一致性檢查、發佈清單與回滾策略。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q3, C-Q5, C-Q8

Q5: 某服務 CPU 爆高影響全站，如何隔離與修復？

• A簡: 先限流與隔離故障服務，擴展實例或回滾，再針對根因調優與測試。
• A詳: 症狀：單一服務過載拖慢整體。原因：流量突增、記憶體/CPU 泄漏或迴圈。解決：1) 下線不健康實例。2) 水平擴展或回滾。3) 分析日誌/指標找根因。4) 修復後逐步導流。預防：資源限制、健康檢查、容量規劃與壓測。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, B-Q8, C-Q7

Q6: 服務彼此相依導致整體不可用，如何降級與隔離？

• A簡: 設計降級策略與超時重試，將非關鍵功能關閉，確保核心路徑可用。
• A詳: 症狀：下游故障連鎖放大。原因：強相依與缺降級。解決：1) 設定逾時/重試。2) 快取或預設回應。3) 關閉非關鍵功能。4) 斷路器隔離。預防：依賴分級、降級設計與演練、契約邊界清晰。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q7, C-Q7, A-Q5

Q7: 在 Windows Container 發現埠衝突，如何解決？

• A簡: 更換主機對映埠或關閉佔用進程，統一管理埠分配並加入啟動檢查。
• A詳: 症狀：bind: address already in use。原因：主機埠已被其他容器/進程佔用。解決：1) 改用不同主機埠 -p 8081:80。2) 釋放佔用埠。3) 檢視埠規劃。預防：集中管理埠配置、啟動前檢查衝突、自動選擇可用埠。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q4, C-Q1, D-Q1

Q8: 建置時間過長影響交付速度，怎麼優化？

• A簡: 分層快取、縮小映像與相依，平行化測試與建置，避免不必要重建。
• A詳: 症狀：CI/CD 排程擁塞。原因：映像過大、層無法快取、測試串行。解決：1) 善用分層與快取。2) 多階段建置縮小映像。3) 平行化測試。4) 只在變更時重建。預防：定期瘦身依賴、模組化與快取策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, C-Q5, A-Q17

Q9: 日誌與監控不足難以定位問題，如何補強？

• A簡: 標準化日誌與指標，建立健康檢查與告警，導入關聯追蹤改善可見度。
• A詳: 症狀：只能靠重現問題。原因：缺乏標準化與集中化觀測。解決：1) 標準輸出結構化日誌。2) 暴露關鍵指標。3) 健康端點與告警。4) 導入追蹤關聯 ID。預防：將可觀測性納入定義完成項，隨服務模板交付。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q7, B-Q7, C-Q5

Q10: 容器化後成本未下降，資源使用仍不佳，原因與解法？

• A簡: 未精準擴展與資源限制、熱點未分離。需細粒度監控與按需擴縮優化。
• A詳: 症狀：成本與單體相近。原因：仍整體擴展、缺資源限制與監控、映像臃腫。解決：1) 針對服務擴縮。2) 設定 CPU/記憶體限制。3) 優化映像大小。4) 以指標驅動容量規劃。預防：以服務為單位的效能目標與週期性審視。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, B-Q8, A-Q16

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是微服務架構（Microservices）？
  • A-Q2: 什麼是單體式架構（Monolithic）？
  • A-Q3: 微服務與單體式架構的主要差異是什麼？
  • A-Q4: 為什麼需要微服務架構？
  • A-Q5: 微服務的核心價值是什麼？
  • A-Q7: 為什麼 container 與微服務常被一起提起？
  • A-Q8: 什麼是 container？部署單位如何演進？
  • A-Q10: API 與 protocol 在微服務中的角色是什麼？
  • A-Q11: 程式碼重用的三種層級是什麼？
  • A-Q12: Source code 重用的特性與限制？
  • A-Q13: Binary code 重用的特性與限制？
  • A-Q14: Service 重用的特性與優點？
  • B-Q1: 微服務在執行期如何運作與組合成應用？
  • B-Q3: 容器如何簡化部署流程與加速交付？
  • B-Q11: 部署單位從 Server→VM→Container 的技術差異？
• 中級者：建議學習哪 20 題
  • A-Q6: SOA（服務導向架構）與微服務的關係是什麼？
  • A-Q9: 微服務允許使用異質技術堆疊嗎？
  • A-Q15: 對開發團隊而言，單體與微服務有何不同？
  • A-Q16: 對維運團隊而言，兩種架構差異為何？
  • A-Q17: 為何容器技術降低導入微服務的門檻？
  • A-Q18: 微服務與 DevOps 有何關聯？
  • B-Q2: 單體式應用的編譯與執行流程為何？
  • B-Q4: Windows Container 在 .NET 場景如何運作？
  • B-Q5: 服務之間的通訊機制與關鍵組件是什麼？
  • B-Q6: 服務升級可不停機的原理是什麼？
  • B-Q7: 微服務的監控與故障隔離機制是什麼？
  • B-Q8: 微服務的彈性擴展（scale out）如何設計？
  • B-Q9: API 相容性與版本控制在微服務中的機制？
  • B-Q12: 微服務如何改善資源使用效率？
  • C-Q1: 如何將 ASP.NET MVC 應用容器化於 Windows Container？
  • C-Q2: 如何從單體拆分出第一個微服務？
  • C-Q3: 如何為微服務定義穩定的 API 契約？
  • C-Q5: 如何為微服務建立最小可行的 DevOps 流水線？
  • C-Q7: 如何對微服務實作健康檢查與監控指標？
  • C-Q9: 如何在容器中連線到既有的資料庫服務（如 SQL Server）？
• 高級者：建議關注哪 15 題
  • B-Q6: 服務升級可不停機的原理是什麼？
  • B-Q8: 微服務的彈性擴展（scale out）如何設計？
  • B-Q9: API 相容性與版本控制在微服務中的機制？
  • C-Q6: 如何在 Windows Container 上水平擴展某個服務？
  • C-Q8: 如何規劃微服務的獨立升級與回滾策略？
  • D-Q2: 升級某服務後其他服務錯誤，如何處理 API 相容性？
  • D-Q5: 某服務 CPU 爆高影響全站，如何隔離與修復？
  • D-Q6: 服務彼此相依導致整體不可用，如何降級與隔離？
  • D-Q8: 建置時間過長影響交付速度，怎麼優化？
  • D-Q9: 日誌與監控不足難以定位問題，如何補強？
  • D-Q10: 容器化後成本未下降，資源使用仍不佳，原因與解法？
  • A-Q9: 微服務允許使用異質技術堆疊嗎？
  • A-Q18: 微服務與 DevOps 有何關聯？
  • B-Q12: 微服務如何改善資源使用效率？
  • C-Q10: 如何在團隊內推進 .NET 開發者採用容器與微服務？