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

問題與答案 (FAQ)

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

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

• A簡: 由多個小型、自治、可獨立部署的服務，透過 API 或訊息協作，組成整體業務功能的架構風格。
• A詳: 微服務是將大型系統拆分為多個小而專一的服務，每個服務自治、獨立部署與擴展，彼此以 API 或訊息隊列互通，強調單一職責、邊界清晰與團隊自治。它改善單體式在維護、部署、擴展上的瓶頸，但帶來通訊、資料一致性、觀測性與 DevOps 的複雜度，需要成熟的流程與基礎設施支持。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q9, B-Q9

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

• A簡: 單體集中開發部署、變更風險大；微服務獨立部署、邊界清晰，但需處理分散式通訊與運維複雜度。
• A詳: 單體式多為單一程式與資料庫，更新需整體重建部署，失敗影響面大且擴展以整體為主；微服務則拆分為多服務，各自擁有邏輯與資料持久層，獨立部署擴展，局部失敗可隔離。然微服務需解決跨服務通訊、資料一致性、監控追蹤、版本相容與自動化部署挑戰。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, B-Q12, D-Q2

A-Q3: 為什麼不是所有團隊都適合立即導入微服務？

• A簡: 微服務進入門檻高，需成熟 DevOps、監控與團隊能力；規模與投資報酬不足時得不償失。
• A詳: 微服務帶來拆分、通訊、部署與維運複雜度，需具備自動化測試、CI/CD、監控告警、服務治理與資安能力。若系統規模不大或問題不在此，轉型只會增加成本與風險。應以問題導向與 ROI 取向，先 POC 驗證，再逐步重構，而非一刀切重寫。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, A-Q6, B-Q12

A-Q4: 什麼是「一窩蜂驅動開發」？

• A簡: 未評估即追逐熱門技術，過度樂觀與躁進，忽略替代與風險，導致專案進退兩難。
• A詳: 一窩蜂驅動開發指在好奇心、自信與樂觀影響下，聽到新技術就貿然導入，忽略 POC、風險與替代方案。常見後果是無法落地、成本飆升與品質下滑。避免之道：快速小型驗證（Spikes）、以 ROI 優先、擁有能寫出關鍵 POC 的架構師、設定漸進里程碑與回退機制，從重構開始。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, A-Q7, B-Q12

A-Q5: 為何導入微服務前要做 POC/Spikes？

• A簡: 以小成本驗證關鍵技術假設與風險，快速失敗與調整，確保方案可行再擴大投資。
• A詳: POC/Spikes 是在最小範圍內驗證核心疑慮（如 API 相容、部署模式、通訊可靠度）的快速實驗。藉由可執行的原型，發現技術限制與團隊落差，提早暴露風險並校正方向。它讓決策建立在實證上，避免一窩蜂，並為重構與切割順序提供依據，降低轉型風險。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q4, A-Q6, C-Q5

A-Q6: 何謂「重構而非重寫」的轉型策略？

• A簡: 保留可運作的業務邏輯，漸進式重構與切割，持續可出貨、風險最低的轉型方式。
• A詳: 相較砍掉重練，重構保留運作中的邏輯與行為，透過介面隔離、單元測試與模組化，逐步抽離服務邊界。其優勢是品質與回歸風險可控、可持續交付、可隨時回退。搭配 POC 驗證與 CI/CD，能在不影響營運下逐步導入微服務能力，避免長期黑暗期。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q8, B-Q14, D-Q1

A-Q7: 架構師在微服務轉型中的核心職責是什麼？

• A簡: 平衡技術與商業目標，能寫出關鍵 POC，引導切割與基礎設施，確保團隊落地。
• A詳: 架構師需洞悉問題本質，規劃服務邊界、通訊模式與部署策略；能以程式碼快速實作關鍵 POC，與團隊用 Code 溝通；建立測試、監控與部署標準；選用雲服務與第三方元件降低門檻；把關 ROI 與風險，按「Think Big, Start Small」推動漸進式轉型。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q4, B-Q12, B-Q15

A-Q8: 「Think Big, Start Small」對轉型有何意義？

• A簡: 先建立長期藍圖，再以小步快跑落地，每步都可回退，持續累積價值與信心。
• A詳: 先描繪未來目標（服務邊界、混合雲、基礎設施），再選高 ROI 區塊小範圍落地，確保每次變更有驗證、可觀測、可回退。避免大改動造成黑暗期，維持可交付狀態，讓團隊與組織同步學習。此策略也利於與商業節奏對齊，逐步降低技術負債。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q6, B-Q14, C-Q10

A-Q9: 單一職責原則（SRP）如何應用在微服務？

• A簡: 每個服務專注做一件事且做到好，邊界清晰、資料與部署自治，降低耦合與風險。
• A詳: SRP 在微服務層次意味著服務聚焦單一業務能力（如課程發佈與消費），內聚高、與外界介面清晰，擁有自身資料存放與生命週期。好處是變更影響面小、部署獨立、易於擴展與容錯。案例中將純內容分流升級為「課程服務」，就體現了服務層的 SRP。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q1, A-Q14, B-Q2

A-Q10: 什麼是「微服務就緒（miniservice/microservice ready）」？

• A簡: 尚未全面微服務化，但切割與通訊等設計已為日後演進預留空間與相容性。
• A詳: 微服務就緒指在不過度投資的前提下，先完成關鍵重構：抽離邊界、定義 API、非同步通訊、資料與部署可獨立，並建立必要基礎設施（如 MQ、反向代理）。雖仍共用部分資源或統一部署，但不阻礙未來平滑拆分，能以最小代價持續演進。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q6, B-Q14, C-Q10

A-Q11: 為何提升服務細粒度很重要？

• A簡: 細粒度讓變更影響面縮小、部署更靈活、故障可隔離；但過度切割會增加治理成本。
• A詳: 合理的細粒度可讓每個服務對齊明確業務能力，單獨擴展與部署，降低單點失敗風險，並提升團隊自治效率。但切過頭將造成通訊爆炸、協調成本與觀測困難。需從需求、資料邊界與團隊邊界綜合判斷，以演進式重構逐步驗證。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q14, B-Q9, D-Q4

A-Q12: 為何要同時支援混合雲與地端部署？

• A簡: 兼顧私有部署與公有雲 SaaS，因應客戶資安與法規，並利用雲端彈性與成本優勢。
• A詳: 許多企業需地端或私有雲以符合法規與客製化，同時也希望享有公有雲的彈性與代管。混合雲設計讓核心服務可在 Azure 等雲上擴展，私有端保留必要系統與資料；通訊採 HTTP/HTTPS 或 MQ，避免 SMB 類協定限制；部署、設定與監控流程需可移植。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q15, C-Q9, D-Q10

A-Q13: 本案例首要解決的四大問題是哪些？

• A簡: 維護困難、雲端化困難、部署困難，及可靠度不足（模組失效易拖垮整體）。
• A詳: 單體式程式碼耦合高、編譯時間長，CI/CD 受阻；商業邏輯與 Web 混雜，任何模組異常（如 OOM）可能全站掛掉；雲端化受限於內網思維（SMB/DFS 等），不利互聯網與自動化；部署需整體重建、風險大。故以重構為先，逐步切割與改造通訊與存儲。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: D-Q1, D-Q2, B-Q3

A-Q14: 內容服務與課程服務有何差異？

• A簡: 內容服務只做靜態檔案分流；課程服務具發佈、授權、追蹤、加密與 API，能獨立運作。
• A詳: 傳統內容服務類似 CDN/檔案站台，只負責分流與存取；課程服務除了檔案交付，還提供內容發佈 API、使用者認證與 Session、學習紀錄與計時、HLS+AES 加密與金鑰、授權校驗與成績回拋。並擁有獨立資料庫與雲端部署，成為平台級能力。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q2, C-Q3, C-Q8

A-Q15: 為什麼選擇 SVN 取代檔案伺服器（而非 Git）？

• A簡: SVN 集中式更符合教材庫需求：版本差異儲存、HTTP/HTTPS 傳輸、易維運與 .NET 整合。
• A詳: 教材版本常只改少量內容，SVN 的差異儲存與壓縮節省空間；以 HTTP/HTTPS 便於穿越防火牆與自動化，比 SMB/DFS 更安全易控；集中式利於權限與一致性管理；成熟度高、文件齊備，.NET 有 SharpSVN 可整合。Git 雖流行，但分散式不一定貼合此場景。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q7, C-Q1

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

B-Q1: 傳統 ASP.NET + MS-SQL 單體式架構如何運作？瓶頸何在？

• A簡: 單一程式承載 Web 與商業邏輯，集中資料庫；變更需整體部署，擴展與容錯受限。
• A詳: 技術原理說明：Web、業務與資料存取同進程，透過 IIS 處理請求、SQL 共享資料。關鍵步驟或流程：編譯整體、部署至多台 Web 節點、以負載平衡分流。核心組件介紹：IIS、ASP.NET、MS-SQL、檔案伺服器。瓶頸在耦合高、編譯慢、部署重、故障影響面大、無法精細擴展與隔離。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, D-Q1, D-Q2

B-Q2: 課程服務的技術架構如何設計？

• A簡: 以 SRP 聚焦內容發佈與消費，含 API、授權、追蹤、加密與獨立資料庫，雲端部署。
• A詳: 技術原理說明：服務自治，對外提供 REST API 與回拋介面，內部管理授權與紀錄。關鍵步驟：1) 發佈內容與版本；2) 使用者授權交換 Token；3) 播放與追蹤；4) 回拋學習成果。核心組件：Web API、Auth（JWT/OAuth2 類）、HLS+AES、SQL 資料庫、儲存（如 Azure Blob）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q9, A-Q14, C-Q2

B-Q3: 內容發佈 API 的執行流程為何？

• A簡: 主系統上傳教材至教材庫，觸發課程服務建立版本與索引，回傳可用位址與憑證。
• A詳: 技術原理說明：藉由 API 將教材包與中繼資料送入，服務校驗、版本化與上架。關鍵步驟：1) 認證與授權；2) 提交教材與 Metadata；3) 版本比對與差異儲存；4) 建立播放清單/金鑰；5) 回應資源 URI 與權杖。核心組件：Web API、SVN/儲存層、資料庫、加密模組、訊息通知。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q1, C-Q2, C-Q3

B-Q4: 主系統與課程服務的認證授權機制是什麼？

• A簡: 以 Token（如 JWT）承載使用者與授權，透過標頭傳遞，課程服務驗證並控管存取。
• A詳: 技術原理說明：採 OAuth2/JWT 類型，簽章保證完整性。關鍵步驟：1) 主系統頒發短時效 Token；2) 客戶端攜帶 Authorization: Bearer；3) 課程服務驗簽、檢查範圍與過期；4) 建立/對應 Session。核心組件：身份提供者、JWT 簽章金鑰、時鐘同步、授權策略與中介軟體。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q4, D-Q8, A-Q14

B-Q5: HLS + AES 加密串流的原理是什麼？

• A簡: HLS 將媒體切片並以 m3u8 清單指引，片段以 AES 對稱加密，金鑰受控發放與輪替。
• A詳: 技術原理說明：媒體分段（TS/Fragment）+ 索引（m3u8），片段以 AES-128/CTR/CBC 加密。關鍵步驟：1) 轉碼切片；2) 生成 m3u8 指向 Key URI；3) 客戶端請求 Key 時驗證授權；4) 播放時解密片段。核心組件：轉碼器、Key Server、CDN/儲存、授權中介與時間同步。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q3, D-Q7, A-Q14

B-Q6: 以 SVN 作為教材庫的設計原理與流程？

• A簡: SVN 以集中式版本控制保存差異與歷史，透過 HTTP/HTTPS 傳輸，適合自動化與權限控管。
• A詳: 技術原理說明：Repository 儲存樹狀檔案與版本差異（delta），集中管理。關鍵步驟：1) 建立 Repository 與結構；2) Commit 教材與 Metadata；3) Tag/Branch 管理版本；4) 以 Hook 觸發發佈流程。核心組件：svnserve/Apache mod_dav_svn、svnadmin、權限檔、SharpSVN（客戶端）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q1, D-Q6, A-Q15

B-Q7: SharpSVN 與 .NET 如何整合 SVN？

• A簡: 透過 SharpSVN 封裝 libsvn 客戶端 API，.NET 可程式化執行 Commit、Update 與查詢。
• A詳: 技術原理說明：SharpSVN 提供 .NET 托管封裝，呼叫底層 libsvn。關鍵步驟：1) 初始化 SvnClient；2) 認證與連線；3) 執行 Add/Commit/Log；4) 處理錯誤與 Hook。核心組件：SharpSVN 套件、libsvn、連線協定（HTTP/HTTPS/SVN+SSH）、例外處理與重試機制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q1, D-Q6, B-Q6

B-Q8: Message Queue + Worker 的 RPC 機制如何運作？

• A簡: 呼叫方送請求訊息入佇列，Worker 取出處理並回傳回應至回覆佇列，實現非同步呼叫。
• A詳: 技術原理說明：以請求/回覆佇列與關聯 ID 實現 RPC。關鍵步驟：1) Producer 將請求封裝（含 CorrelationId/ReplyTo）；2) Worker 消費與執行；3) 產生回應訊息至 ReplyTo；4) 呼叫方等待對應回應或訂閱事件。核心組件：MSMQ/RabbitMQ、序列化、重試與死信、Idempotency。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, C-Q5, D-Q4

B-Q9: REST 與 MQ 的差異與取捨是什麼？

• A簡: REST 簡單直呼、同步通訊；MQ 支援非同步、緩衝、重試與事件分發，適合長流程與解耦。
• A詳: 技術原理說明：REST 基於 HTTP 請求/回應，適合查詢與即時回應；MQ 以訊息為中心，可靠投遞與多消費者。關鍵步驟：REST 經路由至服務處理；MQ 經佇列緩衝與 Worker 消費。核心組件：API Gateway、Queue、Consumer、死信與監控。取捨依延遲、可靠度、耦合與流量型態決定。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, B-Q8, D-Q3

B-Q10: 非同步通訊如何實現重試、順序與可靠性？

• A簡: 以持久化佇列、可設定重試與死信、序號或分割鍵控制順序，搭配冪等設計確保正確。
• A詳: 技術原理說明：訊息持久化避免丟失，重試策略提高成功率，冪等去重確保一次語義。關鍵步驟：1) 設定投遞持久化；2) 指數退避重試與死信路由；3) 以鍵控序列或單一分區維持順序；4) 以 Idempotency Key 防重。核心組件：Queue、DLQ、重試策略、去重儲存。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q6, D-Q5, B-Q8

B-Q11: 發布/訂閱（Pub/Sub）與事件驅動架構如何運作？

• A簡: 事件源頭發布訊息，多個訂閱者各自處理，鬆耦合擴展新行為，避免點對點綁定。
• A詳: 技術原理說明：Publisher 將事件傳至主題/交換器，Subscribers 各自接收處理。關鍵步驟：1) 定義事件結構；2) 發布至 Topic；3) 各服務建立訂閱與過濾；4) 事件溯源與重播（選用）。核心組件：主題型 MQ、事件契約、事件處理器、監控追蹤（CorrelationId）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, C-Q6, D-Q4

B-Q12: 單體與微服務下的 CI/CD 流程差異是什麼？

• A簡: 單體集中建置與部署風險大；微服務需多管線、自動測試與觀測，支援獨立釋出。
• A詳: 技術原理說明：單體建置時間長、整體回歸重；微服務以服務為單位建置、測試與部署。關鍵步驟：1) 依服務觸發建置；2) 單元/契約/整合測試；3) 版本化與發佈；4) 滾動/灰度釋出與回退。核心組件：CI 伺服器、Artifact 儲存、發布編排、觀測與告警。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q1, C-Q10, A-Q8

B-Q13: 反向代理（Reverse Proxy）在微服務中的角色是什麼？

• A簡: 統一進入點，負載平衡、路由與安全控管，隱藏內部拓樸並簡化客戶端。
• A詳: 技術原理說明：反向代理作為網關處理 TLS、路由、壓縮與快取。關鍵步驟：1) 定義服務路由與版本；2) 設定重試與逾時；3) 實作憑證與存取控制；4) 監控與日誌聚合。核心組件：Nginx/Envoy/IIS ARR、API Gateway、服務登錄與健康檢查。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, D-Q3, C-Q10

B-Q14: 如何判斷服務邊界與細粒度？

• A簡: 以業務能力、資料一致性與團隊邊界為依據，先可切可合，再用實證逐步微調。
• A詳: 技術原理說明：以業務能力（Capability）/事件流為單位；內聚高、跨界低。關鍵步驟：1) 繪製流程與資料流；2) 找到強一致性邊界；3) 對齊團隊擁有權；4) 以 POC 驗證通量與耦合。核心組件：業務流程圖、事件風暴、契約測試、觀測資料（延遲/失敗率）。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q11, A-Q10, B-Q9

B-Q15: 混合雲架構的設計關鍵有哪些？

• A簡: 通訊採 HTTP/HTTPS 或 MQ，配置可移植；資料與身分分層，雲端承載高流量能力。
• A詳: 技術原理說明：以網際網路友善協定與零信任思維連接內外部。關鍵步驟：1) 劃分邊界服務放雲端（如課程服務）；2) 地端保留敏感資料；3) 建立安全通道與快取；4) 失效切換與備援。核心組件：API Gateway、MQ、金鑰與憑證、儲存同步（非 SMB）、監控與日誌集中化。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q12, C-Q9, D-Q10

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

C-Q1: 如何用 SharpSVN 上傳教材並保留版本？

• A簡: 建立 SVN 儲存庫結構，程式化 Add/Commit，利用差異儲存節省空間並以 Tag 管版本。
• A詳: 具體實作步驟：1) 設計 repo 路徑（/courses/{id}/versions）；2) 以 SharpSVN Add/Commit；3) 打 Tag。程式碼片段：

  using (var client=new SvnClient()){
    client.Authentication.DefaultCredentials=new NetworkCredential(u,p);
    client.CheckOut(repoUri, localPath);
    client.Add(localPath, new SvnAddArgs{Force=true});
    client.Commit(localPath, new SvnCommitArgs{LogMessage="Publish v1"});
  }
  

  注意事項與最佳實踐：使用小檔案分割、設定忽略、建立 Hook 觸發發佈，定期備份與驗證。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q7, D-Q6

C-Q2: 如何在 ASP.NET Web API 設計內容發佈接口？

• A簡: 建立受權保護的發佈端點，接收包與中繼資料，呼叫教材庫與索引，回傳資源位置。
• A詳: 具體實作步驟：1) 設計 POST /api/content/publish；2) 驗證 Token；3) 寫入 SVN 與 DB；4) 回傳 URI。程式碼片段：

  [Authorize]
  [HttpPost("api/content/publish")]
  public async Task<IActionResult> Publish([FromForm]IFormFile pkg, [FromBody]Meta m){
    // validate, save to SVN, write DB
    return Ok(new { uri=$"/content/{m.Id}/v{m.Version}" });
  }
  

  注意事項與最佳實踐：限制檔案大小、背景處理重任務、回應追蹤 ID、失敗可重試。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q4, C-Q5

C-Q3: 如何在課程服務中實作 HLS + AES 金鑰服務？

• A簡: 產生對稱金鑰並安全儲存，限已授權請求取用；m3u8 指向受保護的 Key 端點。
• A詳: 具體實作步驟：1) 轉碼切片與加密；2) 生成 Key 與 KeyId；3) 實作 /key/{id} 檢查 Token。程式碼片段：

  [Authorize]
  [HttpGet("key/{id}")]
  public IActionResult GetKey(string id){
    if(!Authorized(User,id)) return Forbid();
    var key = keyStore.Get(id); // 16 bytes
    return File(key,"application/octet-stream");
  }
  

  注意事項與最佳實踐：金鑰輪替、短時效 URL、IP/時鐘校驗、避免金鑰緩存外洩。

• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q5, D-Q7, B-Q4

C-Q4: 如何在兩服務間傳遞與驗證 JWT？

• A簡: 主系統簽發短時效 JWT，課程服務以相同金鑰/公鑰驗簽，檢查範圍與過期。
• A詳: 具體實作步驟：1) 達成金鑰分發；2) 在 Authorization: Bearer 傳遞；3) 在中介驗簽。程式碼片段（.NET）：

  services.AddAuthentication().AddJwtBearer(o=>{
    o.TokenValidationParameters = new TokenValidationParameters{
      ValidateIssuerSigningKey=true, IssuerSigningKey=key,
      ValidateLifetime=true, ClockSkew=TimeSpan.FromMinutes(1)
    };
  });
  

  注意事項與最佳實踐：時鐘同步、最小權限、短時效、滾動金鑰與撤銷策略。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, D-Q8, A-Q14

C-Q5: 如何用 MSMQ 建立非同步作業佇列與 Worker？

• A簡: 定義隊列、發送作業訊息、Worker 消費處理並回送結果，支援重試與死信。
• A詳: 具體實作步驟：1) 建立隊列；2) 送出訊息；3) Worker 取用。程式碼片段（C#）：

  var q = new MessageQueue(@".\Private$\jobs");
  q.Send(new Message{Body=job, Label=job.Id});
  var msg = q.Receive(); var job=(Job)msg.Body; Do(job);
  

  注意事項與最佳實踐：設定持久化、逾時與重試、DLQ、記錄 CorrelationId。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, B-Q10, D-Q4

C-Q6: 如何為訊息處理實作重試與冪等（Idempotency）？

• A簡: 設定指數退避重試與死信，利用 Idempotency Key 和去重儲存避免重複處理。
• A詳: 具體實作步驟：1) 設定最大重試與退避；2) 記錄處理過的 Key；3) 遇失敗推入 DLQ。程式碼片段（概念）：

  if(repo.Exists(msg.Key)) return;
  try{ Handle(msg); repo.Save(msg.Key); }
  catch{ RetryOrToDLQ(msg); }
  

  注意事項與最佳實踐：選可組合的自然鍵、處理部分成功、確保資料庫與隊列一致性。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, D-Q5, B-Q11

C-Q7: 如何為 API 版本化以維持相容性？

• A簡: 路由或標頭攜帶版本，維持舊版行為與契約測試，逐步引導客戶端遷移。
• A詳: 具體實作步驟：1) 設計 v1/v2 路由或 Accept 頭；2) 保留舊版；3) 建契約測試。程式碼片段（路由）：

  [Route("api/v1/content")] class V1Controller:Controller{}
  [Route("api/v2/content")] class V2Controller:Controller{}
  

  注意事項與最佳實踐：語義化版本、終止生命週期公告、變更最小化與文件同步。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, D-Q3, A-Q5

C-Q8: 如何設計內容使用追蹤的資料模型？

• A簡: 記錄使用者、內容、會話、開始與結束時間、進度與計次，支援回拋與稽核。
• A詳: 具體實作步驟：1) 設計資料表與索引；2) 事件化寫入；3) 定期彙總。設定片段（DDL）：

  CREATE TABLE UsageLog(
    Id BIGINT PK, UserId NVARCHAR(64), ContentId NVARCHAR(64),
    SessionId NVARCHAR(64), StartAt DATETIME2, EndAt DATETIME2, Progress INT);
  CREATE INDEX IX_Usage_User ON UsageLog(UserId, ContentId);
  

  注意事項與最佳實踐：確保時區一致、避免熱點、採用批次回拋與重送機制。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q14, B-Q2, D-Q7

C-Q9: 如何部署課程服務至 Azure 並支援地端？

• A簡: 將課程服務雲端化，資料與身分分層；地端以 HTTPS/MQ 溝通，實作設定可移植。
• A詳: 具體實作步驟：1) 封裝設定（連線字串、金鑰）；2) 在 Azure App/VM 佈署；3) 設定儲存/DB；4) 地端與雲端以 HTTPS/MQ 互通。設定片段：使用環境變數載入機密。注意事項與最佳實踐：零信任網路、TLS 與防火牆、健康檢查、限內部端口與審計。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q15, A-Q12, C-Q10

C-Q10: 如何用 CI/CD 滾動釋出單一微服務？

• A簡: 以服務為單位建置測試，採用滾動/藍綠釋出與自動回退，縮小影響面與風險。
• A詳: 具體實作步驟：1) 服務專屬管線；2) 單元/契約測試；3) 部署到新實例（藍綠/滾動）；4) 健康檢查與流量切換；5) 異常回退。設定片段：定義健康檢查端點 /health。注意事項與最佳實踐：小批次變更、可觀測性、版本標籤、配置即程式碼。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, B-Q13, A-Q8

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

D-Q1: CI/CD 因編譯時間過長效益不彰怎麼辦？

• A簡: 拆分服務、增量建置與快取、契約測試取代全回歸，縮短路徑並平行化。
• A詳: 問題症狀描述：建置常數十分鐘以上，管線堵塞。可能原因分析：單體過大、無快取、測試粒度過粗。解決步驟：1) 重構切割服務；2) 啟用增量建置與 Artifact 快取；3) 拆小測試、契約測試先行；4) 只部署改動服務。預防措施：持續治理依賴、標準化模版與快取策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q6, B-Q12, C-Q10

D-Q2: Web 模組 OOM 導致整站掛掉如何避免？

• A簡: 隔離商業邏輯與長任務至獨立服務/Worker，監控記憶體並實施資源限制與回收。
• A詳: 問題症狀描述：IIS 應用池回收、全站 500。可能原因分析：單體共進程、記憶體外洩、長任務占用。解決步驟：1) 抽離長任務到 MQ+Worker；2) 分離關鍵模組到獨立服務；3) 啟用記憶體監控與回收策略；4) 壓力與洩漏檢測。預防措施：程式設計規範、分離部署、容量規劃。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, B-Q9, A-Q13

D-Q3: REST 請求逾時或 502/504 怎麼處理？

• A簡: 將長流程改為非同步，前端回應受理與追蹤 ID，結果以回拋/查詢取得。
• A詳: 問題症狀描述：長請求被 Web 伺服器終止、使用者等待過久。可能原因分析：HTTP 同步限制、流程需長時間。解決步驟：1) 將任務推入佇列；2) 立即回應 202 + TrackingId；3) 完成後通知或讓客戶端查詢結果；4) 設定逾時與重試。預防措施：界定同步/非同步邊界、契約清晰、健康檢查與超時治理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, C-Q5, C-Q7

D-Q4: 引入 MQ 後佇列塞車怎麼辦？

• A簡: 量測吞吐與延遲，橫向擴展消費者、分片佇列、調整重試與死信策略並消峰。
• A詳: 問題症狀描述：待處理訊息暴增、延遲變長。可能原因分析：消費者不足、重試風暴、熱點分佈不均。解決步驟：1) 增加並行消費者；2) 以分片鍵拆佇列；3) 設定退避與死信；4) 尖峰前置緩存/排程。預防措施：容量規劃、壅塞保護、背壓機制與告警閾值。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, B-Q10, C-Q6

D-Q5: 訊息重送造成重複處理如何解？

• A簡: 以冪等鍵去重、資料庫唯一約束與事務，配合 At-least-once 投遞達正確性。
• A詳: 問題症狀描述：重試後造成重複入帳/記錄。可能原因分析：至少一次投遞特性、無去重設計。解決步驟：1) 設計 Idempotency Key；2) 寫入前檢查已處理表；3) DB 唯一索引/條件更新；4) 記錄處理結果。預防措施：訊息設計含鍵、契約測試、端到端冪等等級標準化。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q6, B-Q10, B-Q11

D-Q6: SVN 倉庫 locked/損毀如何修復？

• A簡: 先釋放鎖與清理工作副本，必要時以 svnadmin recover 修復並從備份還原。
• A詳: 問題症狀描述：操作提示 locked 或無法 commit；偶發資料庫錯誤。可能原因分析：非正常中斷、儲存損壞。解決步驟：1) 工作副本 svn cleanup；2) 伺服端解除路徑鎖；3) 停機執行 svnadmin recover；4) 從最近備份還原。預防措施：定期備份、正確停機、使用穩定存儲與監控磁碟健康。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q7, C-Q1

D-Q7: HLS+AES 播放失敗如何診斷？

• A簡: 檢查 m3u8 與分片可達性、金鑰端點授權與 CORS、時鐘偏差與加密參數一致。
• A詳: 問題症狀描述：黑屏、無法解密、頻繁 403/404。可能原因分析：金鑰無法取得、授權失敗、清單錯誤、CORS、時鐘不同步。解決步驟：1) 逐一測試清單與分片 URL；2) 驗證金鑰端點授權/時效；3) 檢查 CORS 與 TLS；4) 比對加密模式與 IV。預防措施：自動化驗證流程、短時效 URL、時鐘同步與監控。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q5, C-Q3, C-Q8

D-Q8: 跨服務 Token 驗證失敗怎麼查？

• A簡: 比對簽章金鑰與演算法、時效與時鐘偏差、Issuer/Audience 與範圍是否一致。
• A詳: 問題症狀描述：401/403、授權拒絕。可能原因分析：金鑰不一致、簽章演算法不同、過期、時鐘不同步、宣告不全。解決步驟：1) 解碼 Token 檢查聲明；2) 比對金鑰指紋與算法；3) 檢查發行者/受眾；4) 校正時鐘與時效。預防措施：金鑰管理流程、短時效與輪替、監控與審計。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, C-Q4, A-Q12

D-Q9: 教材版本混亂導致發佈錯誤如何解決？

• A簡: 以 Tag/Branch 管理，發佈鎖定版本，導入審核流與回滾機制，保持一致性。
• A詳: 問題症狀描述：上線內容非預期、版本交錯。可能原因分析：手動操作失誤、缺乏版本鎖定。解決步驟：1) 以 Tag 固定發佈來源；2) 建立審核/簽核流程；3) 自動化發佈與回滾；4) 差異比對與稽核。預防措施：禁止直接改動主線、權限控管、Hook 驗證與紀錄。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, C-Q2, C-Q1

D-Q10: 混合雲環境防火牆致同步失敗怎麼辦？

• A簡: 改用 HTTPS/MQ 通訊，開放必要出口與端點，設定代理與健康檢查，避免 SMB。
• A詳: 問題症狀描述：內容同步/發佈卡住、連線逾時。可能原因分析：內外網防火牆封鎖、協定不被允許。解決步驟：1) 以 HTTPS/SSH 取代 SMB/DFS；2) 僅開放必要端口；3) 設定企業代理；4) 端到端健康檢查與重試。預防措施：協定白名單、最小權限網路分段、通訊觀測與告警。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q15, A-Q12, C-Q9

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是微服務架構？
  • A-Q2: 單體式架構與微服務架構有何差異？
  • A-Q3: 為什麼不是所有團隊都適合立即導入微服務？
  • A-Q4: 什麼是「一窩蜂驅動開發」？
  • A-Q5: 為何導入微服務前要做 POC/Spikes？
  • A-Q6: 何謂「重構而非重寫」的轉型策略？
  • A-Q8: 「Think Big, Start Small」對轉型有何意義？
  • A-Q13: 本案例首要解決的四大問題是哪些？
  • A-Q14: 內容服務與課程服務有何差異？
  • A-Q15: 為什麼選擇 SVN 取代檔案伺服器（而非 Git）？
  • B-Q1: 傳統 ASP.NET + MS-SQL 單體式架構如何運作？瓶頸何在？
  • B-Q9: REST 與 MQ 的差異與取捨是什麼？
  • B-Q12: 單體與微服務下的 CI/CD 流程差異是什麼？
  • D-Q1: CI/CD 因編譯時間過長效益不彰怎麼辦？
  • D-Q3: REST 請求逾時或 502/504 怎麼處理？
• 中級者：建議學習哪 20 題
  • A-Q7: 架構師在微服務轉型中的核心職責是什麼？
  • A-Q9: 單一職責原則（SRP）如何應用在微服務？
  • A-Q10: 什麼是「微服務就緒（miniservice/microservice ready）」？
  • A-Q11: 為何提升服務細粒度很重要？
  • A-Q12: 為何要同時支援混合雲與地端部署？
  • B-Q2: 課程服務的技術架構如何設計？
  • B-Q3: 內容發佈 API 的執行流程為何？
  • B-Q4: 主系統與課程服務的認證授權機制是什麼？
  • B-Q5: HLS + AES 加密串流的原理是什麼？
  • B-Q6: 以 SVN 作為教材庫的設計原理與流程？
  • B-Q7: SharpSVN 與 .NET 如何整合 SVN？
  • B-Q8: Message Queue + Worker 的 RPC 機制如何運作？
  • B-Q10: 非同步通訊如何實現重試、順序與可靠性？
  • B-Q11: 發布/訂閱（Pub/Sub）與事件驅動架構如何運作？
  • C-Q1: 如何用 SharpSVN 上傳教材並保留版本？
  • C-Q2: 如何在 ASP.NET Web API 設計內容發佈接口？
  • C-Q4: 如何在兩服務間傳遞與驗證 JWT？
  • C-Q5: 如何用 MSMQ 建立非同步作業佇列與 Worker？
  • D-Q2: Web 模組 OOM 導致整站掛掉如何避免？
  • D-Q4: 引入 MQ 後佇列塞車怎麼辦？
• 高級者：建議關注哪 15 題
  • B-Q14: 如何判斷服務邊界與細粒度？
  • B-Q15: 混合雲架構的設計關鍵有哪些？
  • C-Q3: 如何在課程服務中實作 HLS + AES 金鑰服務？
  • C-Q6: 如何為訊息處理實作重試與冪等（Idempotency）？
  • C-Q7: 如何為 API 版本化以維持相容性？
  • C-Q8: 如何設計內容使用追蹤的資料模型？
  • C-Q9: 如何部署課程服務至 Azure 並支援地端？
  • C-Q10: 如何用 CI/CD 滾動釋出單一微服務？
  • D-Q5: 訊息重送造成重複處理如何解？
  • D-Q6: SVN 倉庫 locked/損毀如何修復？
  • D-Q7: HLS+AES 播放失敗如何診斷？
  • D-Q8: 跨服務 Token 驗證失敗怎麼查？
  • D-Q9: 教材版本混亂導致發佈錯誤如何解決？
  • D-Q10: 混合雲環境防火牆致同步失敗怎麼辦？
  • A-Q10: 什麼是「微服務就緒（miniservice/microservice ready）」？