微服務架構 #1, WHY Microservices?
摘要提示
- 背景與動機: 以 .NET + Windows Container 分享微服務導入經驗，強調從「目的」切入技術價值。
- SOA 與容器演進: 從 SOA 起源談起，容器降低部署成本，使 microservices 成為顯學。
- DevOps 影響: 容器的快速部署特性推動流程轉變與 DevOps 普及。
- 文章定位: 鎖定有經驗的 .NET 開發者，補齊微服務與容器的實務落差。
- 系列架構: 規劃三篇—微服務概念、容器化部署、實務案例（大型人資系統）。
- Monolithic 定義: 以相同技術堆疊成單一大型可執行體，開發期組裝，執行為單一 process。
- Microservices 定義: 切分為多個獨立服務，以 API/協定在執行期組合，語言平台可異質。
- 程式碼重用層級: 分為 source、binary、service 三層，微服務重用發生於 runtime。
- 維運觀點差異: 單體式升降級、監控與擴展粗粒度；微服務可細粒度監控、擴縮、降級與維護。
- 容器價值: 容器大幅簡化微服務複雜部署，與微服務相輔相成。
全文重點
作者以參與 Microsoft Community Open Camp 的分享為起點，主張技術應回到解決問題的目的，因此將容器與微服務合併談，凸顯兩者互補的價值。回顧 SOA 在早期因開發與部署門檻高而難以普及，如今容器技術將部署成本從伺服器、虛擬機進一步降到容器等最小單位，帶來快速且一致的部署能力，也促成 DevOps 實踐。受限於 40 分鐘的議程，作者規劃以系列文補充，對象鎖定具 .NET 經驗但對微服務與容器仍陌生的開發者，並規劃三篇：微服務架構、容器化部署（Windows Container 範例）與大型人資系統案例。
核心比較聚焦於 Monolithic 與 Microservices 的組成與重用策略。單體式應用在開發期以相同語言/框架將 library、component 組裝，執行時為單一大型 process；微服務則在設計時控制複雜度，切分多個小型獨立服務，透過 API/協定在執行期組合，服務之間可用異質技術堆疊。作者進一步以「重用層級」剖析兩者差異：source code（需重編譯、侷限同語言）、binary（以封裝介面替換、仍屬開發期整合）、service（以協定/API 在執行期重用，如資料庫），微服務的重用重點即發生於 runtime 的 service 層級。
從維運角度，單體式應用的監控、異常處理與擴展多半是整體性的：掛掉就整個重啟、缺效能就整體擴充與負載平衡，難以充分利用資源。相對地，微服務讓維運能以細粒度監控、個別升級、熱修復或暫停局部功能，並針對負載瓶頸服務做選擇性水平擴充，因而更精準且具成本效益。然而，微服務的部署與組態管理明顯更複雜，這正是容器能發揮價值的場景：以一致化的打包與快速、可預測的部署流程，顯著降低微服務落地的操作成本。因此作者主張容器與微服務須聯合思考，下一篇將延續此主軸展開容器化部署的細節與實作。
段落重點
前言與系列規劃
作者分享於 Microsoft 的 Community Open Camp 所做的「微服務架構導入經驗」議程。強調不要將容器視為單一技術，而應從其解決部署與運維痛點的目的出發，與微服務結合看待。回顧 SOA 因工具與部署門檻高而未普及，如今容器讓最小部署單位縮至 container，成本與速度優勢使微服務成為主流；同時也促成 DevOps。由於實體議程時間有限，作者決定以系列文補充更多細節與實作，並以 .NET 開發者為主要讀者。系列規劃三篇：微服務架構概念、Windows Container 部署示範，以及大型人資系統（WebForm）案例，並提供投影片、錄影與程式碼資源鏈接作延伸閱讀。
微服務架構(Microservices) v.s. 單體式架構(Monolithic)
兩種架構的差異在於「重用與組合的時機」。單體式以相同技術堆疊，在開發期借助工具/編譯器將 library、component 組合成一個大型應用，最終執行為單一 process。微服務則將巨大應用切分為多個小型、可獨立部署的服務，透過明確定義的 API/協定在執行期組合，服務間可異質化（語言、平台、框架不必一致）。結果是：Monolith 複雜度集中在單一部署單元；Microservices 將複雜度分散到服務間通訊與協調，但換得獨立演進、獨立部署與彈性擴縮。作者以圖示與幽默素材輔助對比，強調觀念須從巨觀來理解：本質是不同層次與時機的重用與組合策略。
Develop Team: Reuse of Codes
作者將重用分為三層：1) source code：需取得原始碼、同語言、需重編譯與完整流程（測試/發行）才能套用；2) binary code：以封裝的元件/套件形式在開發期組合，若不破壞對外介面可直接替換，降低相依影響；3) service：以 API/協定在執行期重用，例如資料庫服務，應用程式只需遵循協定與驅動程式即可使用，升級時可不動應用、甚至不中斷服務。單體式開發多在 source/binary 層完成系內模組化；微服務則先在 service 層解構業務域，之後各服務內部再選擇 source/binary 的實作方式。此差異影響團隊分工、邊界劃分與版本治理的思維模式。
Operating Team: Application Maintainess
維運觀點下，單體式應用對 OP 幾乎是「黑盒」：問題處理與資源調整多以整體為單位（整個重啟、整體擴展、整體備援），造成監控粗粒度與資源利用效率不佳。微服務則提供細粒度運維能力：可針對單一服務監控、個別升級、個別重啟、區域性關閉功能、分區維修，並依負載僅對瓶頸服務做水平擴充，提升可靠度與成本效率。然而，微服務的部署鏈條更長、組件更多、相依更複雜，傳統方式很難應付。容器技術正好補位：以一致的打包、快速可重現的部署與隔離機制，顯著降低落地難度，促進微服務普及。作者預告後續將深入容器化部署的實務與工具鏈，延續「容器 x 微服務」的整體解決方案。
資訊整理
知識架構圖
- 前置知識：學習本主題前需要掌握什麼？
- 基本軟體架構觀念：Monolithic 與 SOA 的差異、API/協定的概念
- 基本網路與部署知識：TCP/Port、Load Balancer、備援與擴縮
- 開發基礎：.NET/ASP.NET（或任一主語言與框架）、Library/Package 使用
- 版本控管與建置：CI/CD、測試與發行流程的基本概念
- 容器基礎：Container 與 VM 的差異、鏡像/容器生命週期
- 核心概念：本文的 3-5 個核心概念及其關係
- 架構分野：Monolithic vs Microservices（從「開發重用方式」與「維運控制粒度」兩面向比較）
- 重用層級：Source/Binary/Service 三種 reuse 方式對應到 compile-time vs runtime
- 維運能力：監控、獨立升級/重啟、分區維修、針對性擴縮（微服務帶來的彈性與複雜度）
- 容器角色：降低部署門檻、促成 DevOps、與微服務相輔相成
- 技術演進脈絡：從 SOA 到 Microservices，容器成熟使中小團隊可負擔
關係：SOA 提出服務化理念 → 容器技術成熟 → 以服務為單位的重用（runtime）可行 → 微服務架構在開發與維運上成形；DevOps 隨之被推動。
- 技術依賴：相關技術之間的依賴關係
- 微服務依賴清晰的 API/協定定義（REST/gRPC/消息佇列等）
- 服務化落地依賴容器化與自動化部署（Image、Registry、Orchestrator）
- DevOps 流程依賴 CI/CD、監控/告警、日誌/追蹤（Observability）
- 多語言/多框架共存依賴平台無關的部署單位（容器）與標準化的通訊協定
- 彈性擴縮與高可用依賴編排與平台能力（Kubernetes/Service Fabric 等）
- 應用場景：適用於哪些實際場景？
- 大型/複雜應用，需要針對性擴縮與高可用
- 功能模組清晰、介面可明確定義的系統（例如 HR、訂單、帳務等子域）
- 多技術棧共存、需快速試錯與獨立部署的團隊
- 維運需精細監控、分區維修、零停機升級的場景
- 從既有 Monolithic 漸進式拆分的轉型計畫
學習路徑建議
- 入門者路徑：零基礎如何開始？
- 了解 Monolithic、SOA、Microservices 的差異與演進
- 熟悉 API 基礎（REST、HTTP、狀態碼）與簡單服務切分案例
- 學習容器基礎：建立 Dockerfile、建置/執行/推送鏡像
- 部署一個最小可用的 .NET Web API 到容器中，練習本機多容器組合（Web + DB）
- 進階者路徑：已有基礎如何深化？
- 練習服務邊界與資料擁有權（每服務擁有其資料）
- 導入觀測性：集中式日誌、Metrics、Tracing
- 練習零停機部署與版本管理（藍綠/金絲雀）
- 深入 DevOps：自動化測試、CI/CD 流水線、秘密管理
- 探索多語言服務與通訊（gRPC/Message Queue）互通
- 實戰路徑：如何應用到實際專案？
- 以現有 Monolithic 為基礎，選定低風險子域做第一個服務化切割
- 建立標準化容器鏡像與部署範本，落地監控/告警基線
- 設計 API 契約與相容策略（版本化、向後相容、錯誤處理）
- 導入編排平台（例如 Kubernetes 或 Windows Container 相關解決方案）
- 建立故障演練與回滾機制，實做擴縮與分區維修流程
關鍵要點清單
- Monolithic vs Microservices 本質差異: 前者在開發期組裝（compile-time reuse），後者在執行期組裝（runtime via API）(優先級: 高)
- 重用層級三分法: Source/Binary/Service，不同層級對應不同的耦合與變更成本 (優先級: 高)
- 服務邊界與 API 設計: 清晰邊界與協定是微服務成功的前提 (優先級: 高)
- 維運粒度提升: 微服務允許獨立監控、升級、重啟、備援與分區維修 (優先級: 高)
- 針對性擴縮: 依服務負載差異做精準 scale out，而非整體擴張 (優先級: 高)
- 容器化價值: 降低部署成本與環境差異，成為微服務落地載體 (優先級: 高)
- DevOps 推動: 容器與自動化部署促成開發/維運流程整合 (優先級: 中)
- 異質技術並存: 微服務允許不同語言/框架/平台共存，以 API 解耦 (優先級: 中)
- SOA 與微服務關係: 微服務延續 SOA 思想，以更輕量與工程化實踐 (優先級: 中)
- 觀測性與可視化: 日誌、指標、追蹤是維運微服務的基礎能力 (優先級: 高)
- 部署複雜度提升: 服務拆分帶來網路、設定、依賴與安全的額外複雜度 (優先級: 高)
- 相容與版本控制: API 版本化與向後相容策略避免聯鎖升級 (優先級: 高)
- 故障隔離與回復: 以服務為單位的回滾、熔斷/重試等韌性設計 (優先級: 中)
- 資料擁有權與一致性: 每服務擁有其資料，跨服務一致性採事件/最終一致 (優先級: 中)
- 漸進式拆分策略: 從現有 Monolithic 擇低風險子域試點，逐步演進 (優先級: 中)
