微服務基礎建設 - Service Discovery

問題與答案 (FAQ)

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

Q1: 什麼是 Service Discovery？

• A簡: 在微服務中定位服務節點位置與狀態的機制，含註冊、查詢、健康檢查，維持即時可用端點清單。
• A詳: Service Discovery 是分散式系統中，為了在高度動態環境下準確找到可用服務而設計的機制。其核心由三部分構成：註冊（服務啟動時將自身端點與描述資料註冊到中心目錄）、查詢（呼叫方依服務名或屬性查詢可用端點）、健康檢查（持續檢測與剔除不健康實例）。透過這三者維持一份最新、可信的服務清單，讓服務間的呼叫不需硬編碼 IP/Port，並能在服務彈性伸縮時保持穩定性與可靠性。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q4, B-Q1

Q2: 為什麼微服務需要 Service Discovery？

• A簡: 微服務節點數量多且動態變化，需自動定位可用端點與狀態，避免人工配置失效與錯誤。
• A詳: 微服務把單體應用拆成許多小服務，實例數可能瞬間擴展或收縮，手動維護位址與狀態不可行。Service Discovery 自動維持服務清單與健康狀態，讓呼叫方不必知道具體位址即可找到可用節點，並透過健康檢查避免把流量送往故障節點。它也支援依負載或屬性選擇端點，確保在高彈性與高變動環境中仍能穩定提供服務。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q6, B-Q2

Q3: 微服務與單體式應用在節點規模上的差異？

• A簡: 單體多為少量實例，微服務會擴至數百上千實例，需自動化發現與調度機制。
• A詳: 單體式應用通常同時運行的實例數量有限，管理與配置相對簡單；微服務則由多個服務組成，每個服務又可被水平擴展至大量實例，總體節點數級數成長。這種規模使得人工配置 IP/Port、手動更新設定檔不可行。Service Discovery 成為關鍵基礎設施，提供自動註冊、查詢與健康檢查，確保在規模擴大與頻繁部署下仍能可靠連線。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q4, B-Q25

Q4: 註冊、查詢、健康檢查三者的定義與關係？

• A簡: 註冊登記端點與屬性；查詢取得可用端點；健康檢查維持清單正確性與可用性。
• A詳: 註冊是服務啟動時將自身 IP/Port、名稱、標籤等資訊登錄於註冊中心。查詢是呼叫方依服務名或條件向註冊中心取回符合且健康的端點清單。健康檢查則持續驗證服務實例狀態，常見方式有心跳回報或第三方主動探測，並自動下架故障節點。三者相輔相成：沒有註冊無法查詢，沒有健康檢查清單會汙染，查詢依賴健康資訊提升可靠性。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q1, B-Q2, B-Q3

Q5: DHCP + DNS 如何幫助理解 Service Discovery？

• A簡: DHCP 動態配發 IP，DNS 依名稱解析 IP，搭配 ping 類健康檢查，類比現代服務發現。
• A詳: 將 PC 接上網路時，DHCP 分配 IP 並可代為註冊 DNS 記錄，相當於服務「註冊」。他人透過 DNS 以主機名查詢 IP，即為「查詢」。在連線前以 ping 測試端點是否通暢，可視為基本「健康檢查」。此組合是最早期的服務發現原型，雖然在現代微服務場景不足以滿足動態、精準與豐富的服務描述需求，但能幫助初學者快速建立概念框架。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q6, B-Q6, B-Q15

Q6: 為何僅靠 DNS 無法支撐微服務的需求？

• A簡: DNS TTL 粗、無健康檢查、無負載感知、僅客戶端選擇端點，難應對劇烈動態。
• A詳: 微服務環境中的實例會頻繁彈性伸縮，DNS 的 TTL 通常以分鐘至小時計，導致清單過期；它缺乏標準健康檢查，無法自動剔除故障節點；輪詢解析不感知負載；且 DNS 僅提供名稱解析，實際路由仍由客戶端自行決策。要達成即時、健康、負載感知與轉送能力，需引入專用的 Service Discovery 與反向代理或客戶端庫。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q6, B-Q5, A-Q4

Q7: 什麼是服務註冊中心（Service Registry）？

• A簡: 儲存服務端點、狀態與中繼資料的目錄系統，提供註冊與查詢介面。
• A詳: 註冊中心是 Service Discovery 的核心組件，負責維護可用服務的權威清單。服務啟動時登錄自身位址、連線埠、版本、標籤等；註冊中心根據健康檢查結果維護狀態，向查詢者回應可用端點。它可能提供 HTTP 與 DNS 介面，並支援 Watch 或長輪詢以推播變更。可靠與一致的註冊中心能顯著提升跨服務通訊的正確性與韌性。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q1, B-Q2, A-Q18

Q8: 什麼是健康檢查（Health Check）？為何不只靠心跳？

• A簡: 健康檢查驗證服務可用性；心跳易誤判，需外部主動探測提升準確性。
• A詳: 健康檢查用以持續驗證服務是否可對外提供功能。心跳由服務向註冊中心回報存活，但可能出現服務內部故障仍發心跳、或只對內可達等誤判。為提升準確性，常搭配第三方主動檢測（HTTP 探測端點、TCP 端口、腳本檢查），從外部路徑模擬真實流量。綜合心跳與外部檢測可及時下架故障節點，避免將流量導向「僵死」服務。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, A-Q10, D-Q4

Q9: 什麼是自我註冊（Self-Registration）模式？

• A簡: 由服務自行向註冊中心登錄與續約，並可回報心跳，直接管理自身生命週期。
• A詳: 自我註冊是最直接的註冊模式。服務啟動後主動向註冊中心登錄端點與中繼資料，運行期間以心跳或租約續約維持可用狀態，關閉時可主動撤銷。其優點是簡單、低耦合第三方元件、可就地實作特化邏輯；缺點是程式侵入性高、需修改並重新部署，且心跳易因局部故障造成誤判。常與第三方探測搭配以提升精確性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, B-Q1, B-Q23

Q10: 什麼是第三方註冊（Third-Party Registration）模式？

• A簡: 由外部代理或平台替服務註冊與檢查健康，降低應用侵入與誤判風險。
• A詳: 第三方註冊指由外部代理、Sidecar 或平台（如容器編排系統）負責發現新服務並為其登錄，並以外部路徑持續檢測健康狀態。此法對應用非侵入，更新註冊邏輯集中管理，且更接近真實可達性。代價是需部署額外基礎設施，並確保其高可用。常見於容器平台、Service Mesh 或註冊代理與監測服務的組合。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q9, B-Q3, B-Q5

Q11: 自我註冊與第三方註冊的差異與取捨？

• A簡: 自我註冊簡單但侵入；第三方非侵入且更準確，但需額外基礎設施與維運。
• A詳: 自我註冊易上手、效能最佳，適合早期導入與語言/框架支援完善的場景；但它將註冊與續約邏輯綁入程式，更新困難且心跳誤判風險較高。第三方註冊將責任外移，能以外部探測提高精準度、集中更新策略，亦利於多語言環境，但需部署與維護代理/平台。選擇時需權衡團隊成熟度、異質技術棧與營運成本。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q1, B-Q3, B-Q25

Q12: 什麼是 Client-Side Discovery 模式？

• A簡: 客戶端先向註冊中心查詢可用端點，再自行選擇並直連服務，常含客戶端負載均衡。
• A詳: 在 Client-Side Discovery 下，呼叫方使用「認得註冊中心」的客戶端庫，先查詢服務可用端點清單，依演算法（如輪詢、加權）選定一個並直連呼叫。優點是去中心化、效能佳、可實作細緻路由與特化負載策略；缺點是程式侵入性高、升級與一致性管理困難，且易與特定註冊中心耦合。常見實作有 Netflix Ribbon + Eureka。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q15, A-Q19, B-Q4

Q13: 什麼是 Server-Side Discovery 模式？

• A簡: 由註冊感知的反向代理/負載均衡器代為轉送請求到健康端點，對應用透明。
• A詳: Server-Side Discovery 把服務選擇與轉送放在中間層（如負載均衡器、反向代理）。該層與註冊中心整合，持續更新可用端點並將請求轉發給最合適的實例。優點是對應用非侵入、集中管理策略、易於異質技術棧；缺點是增加一次跳轉延遲、形成潛在瓶頸與故障點。雲端 LB、Nginx 配合動態後端即屬此類。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, A-Q20, A-Q21

Q14: Client-Side 與 Server-Side Discovery 的差異？

• A簡: 前者去中心化、效能佳但侵入；後者非侵入、集中管理但增延遲與瓶頸風險。
• A詳: Client-Side 由客戶端查詢並選端點，直連呼叫，路由彈性大且易避開集中瓶頸，但需在程式內置入庫並統一升級。Server-Side 將路由集中於代理/LB，對應用透明、跨語言一致，但增加一次網路轉送且可能成為單點或需擴展。選擇取決於團隊治理能力、性能要求、異質環境與維運偏好。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, A-Q13, B-Q25

Q15: 什麼是 Registry-aware HTTP Client？

• A簡: 能與註冊中心整合的客戶端庫，支援查詢端點、健康感知與負載均衡。
• A詳: Registry-aware HTTP Client 內建存取註冊中心的邏輯，呼叫時先取得可用端點，選路並發送請求。通常提供多種負載策略、容錯重試與快取，並可讀取端點標籤以做環境或版本路由。它讓 Client-Side Discovery 易於落地，但同時帶來語言/框架耦合與升級一致性挑戰，需良好的版本管理與發布流程。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, B-Q4, D-Q6

Q16: 負載均衡在 Service Discovery 中扮演什麼角色？

• A簡: 在多實例間分配請求，避免過載並提升可用性，可在客戶端或代理端實作。
• A詳: 負載均衡根據端點健康與策略，將流量在多實例間合理分配，使資源使用均衡並降低因個別過載導致的失效風險。Client-Side 於客戶端選路，效能佳且可細化；Server-Side 則由代理/LB 轉送，集中管理易於異質環境。策略可基於輪詢、加權、最少連線或基於延遲度量的選擇，與健康檢查緊密結合。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q5, B-Q7

Q17: 什麼是服務中繼資料與標籤（Metadata/Tags）？

• A簡: 描述服務的附加資訊，如版本、環境、能力，用於篩選與路由決策。
• A詳: 除 IP/Port 外，服務常附帶中繼資料與標籤，如版本號（v1/v2）、部署環境（dev/stage/prod）、可用區、功能標誌等。這些訊息可用於精準查詢與路由，例如藍綠/灰度發布、同城就近或合規性隔離。註冊中心保存並暴露此資訊，客戶端或代理據此選擇端點，提升彈性與治理能力。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q17, C-Q9, C-Q10

Q18: 什麼是 Consul？核心價值為何？

• A簡: Consul 是整合註冊、健康檢查、DNS/HTTP 介面與 KV 儲存的服務發現方案。
• A詳: Consul 提供完整的 Service Discovery：服務可透過 HTTP 註冊、DNS/HTTP 查詢；健康檢查支援 HTTP、TCP 與自訂腳本；並內建 KV Store 供動態設定、特性旗標與協調用途。它還支援多資料中心與長輪詢通知變更。整合度高、部署簡單、可兼容舊系統（以 DNS 方式）是其核心價值，適合漸進式導入。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, B-Q9, C-Q1

Q19: 什麼是 Netflix Eureka 與 Ribbon？

• A簡: Eureka 是註冊中心，Ribbon 是客戶端 IPC 庫，提供發現、負載均衡與容錯。
• A詳: Eureka 提供基於 REST 的註冊與查詢，是 Netflix OSS 生態中的註冊中心；Ribbon 則是 Client-Side 的 IPC 客戶端，支援多協議、負載均衡、容錯與快取/批次等。兩者結合實現 Client-Side Discovery 的典型方案，讓應用在呼叫前查詢可用端點並自行選路，適合高效能、去中心化的雲端場景。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, B-Q12, C-Q9

Q20: 雲端負載均衡（ALB/NLB）與 Service Discovery 的關係？

• A簡: 雲端 LB 與平台註冊整合，依可用實例清單將外部流量轉發至健康端點。
• A詳: 公有雲提供的負載均衡器（如 AWS ELB、Azure LB）與其內部資源登錄機制整合，當虛擬機或容器端點註冊或變更時，LB 會更新後端池與健康狀態，並將來自 Internet 的請求分散到健康節點。它屬於 Server-Side Discovery 的實踐，對應用透明，但需考量延遲、瓶頸與高可用部署。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q13, B-Q5, D-Q3

Q21: Docker 內建 DNS 如何支援服務發現？

• A簡: 容器啟動時自動註冊服務名與 IP，容器內以服務名解析到對應端點。
• A詳: Docker 在自訂網路中提供內建 DNS（預設 127.0.0.11）。每個服務或容器啟動時會將名稱與分配 IP 註冊到 DNS，其他容器可透過服務名解析到對應 IP，形成輕量的服務發現。搭配反向代理（如 Nginx）即可做動態後端路由。此法簡單有效，適合單機或小規模，用於容器間通訊與與外部入口整合。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q13, C-Q5, D-Q7

Q22: 什麼是 Routing Mesh（Docker Swarm）？

• A簡: Swarm 將服務對外發布的連接埠映射至叢集，請求自動路由至健康任務。
• A詳: 在 Swarm 中，發布服務時會建立 Ingress/Routing Mesh，叢集任一節點接收指定連接埠的請求後，會路由到對應服務的健康任務。這提供了 Server-Side Discovery 式的入口，簡化服務暴露與流量分配。需正確配置網路與防火牆，理解其對 UDP/TCP 的支持與限制，以避免連線問題。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q14, C-Q6, D-Q8

Q23: 什麼是侵入式與非侵入式解決方案？

• A簡: 侵入式需改程式嵌入庫；非侵入式靠外部代理/LB，部署與更新更集中。
• A詳: 侵入式方案如 Client-Side 庫，將註冊、查詢、選路注入應用程式中，效能佳且彈性高，但升級需重建重佈，且語言依賴顯著。非侵入式方案如 Server-Side 代理/LB，對應用透明，集中部署易更新，也利於多語言整合，但增加一次轉送與瓶頸/單點風險。選擇應依團隊治理能力與性能需求取捨。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, A-Q13, B-Q25

Q24: Service Discovery 如何提升可靠性（SLA）？

• A簡: 以健康檢查排除故障節點，只在剩餘健康實例間分流，顯著降低故障機率。
• A詳: 未妥善管理時，任一實例故障都可能拖垮整體，故障率近似 1-(1-p)^n。若透過 Service Discovery 持續剔除故障端點，僅所有實例同時失效才會中斷，故障率趨近 p^n。雖然此模型簡化，但清楚顯示健康感知路由與即時清單對提升整體 SLA 的價值，尤其在實例數量巨大的微服務環境中更為關鍵。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q22, D-Q1, D-Q2

Q25: 什麼是 Service Mesh（高階概念）？

• A簡: 以 Sidecar 代理建立服務間網狀通訊與治理層，非侵入地實作發現與路由。
• A詳: Service Mesh 透過每個服務旁的 Sidecar 代理組成資料平面，集中控制平面下發策略，實現服務發現、健康感知路由、重試、熔斷、金絲雀等功能。它屬於非侵入方式，擴展了 Server-Side 思路至每節點，減少集中瓶頸，同時保留集中治理優勢。本文聚焦基礎概念，Mesh 為進階主題。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q13, B-Q25, D-Q3

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

Q1: 服務註冊的運作流程是什麼？

• A簡: 服務啟動→上報端點與標籤→續約或心跳→狀態更新→終止時撤銷。
• A詳: 原理說明：服務於啟動階段向註冊中心提交自身位址、連接埠、名稱與標籤。流程步驟：1) 啟動並組裝註冊資料；2) 呼叫註冊 API 或由代理代辦；3) 週期性續約或心跳；4) 註冊中心依健康檢查更新狀態；5) 終止時撤銷或由 TTL 自動過期。核心組件：服務實例、註冊中心（Catalog）、健康檢查器與可選的註冊代理。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q4, A-Q9, C-Q1

Q2: 服務查詢（解析）如何運作？

• A簡: 呼叫方向註冊中心以名稱/條件查詢，取得健康端點清單再發起請求。
• A詳: 原理說明：將服務位址抽象為邏輯名稱並以註冊中心解析。流程：1) 呼叫方以服務名或標籤提出查詢；2) 註冊中心過濾僅健康端點並按策略排序；3) 回應清單與中繼資料；4) 呼叫方選擇端點或交由代理轉送。核心組件：查詢 API（HTTP/DNS）、健康狀態源、選路策略模組與可選快取/觀察者。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q4, B-Q5, C-Q3

Q3: 健康檢查的機制與類型有哪些？

• A簡: 被動心跳與主動探測並用，支援 HTTP/TCP/腳本，精準反映對外可用。
• A詳: 原理說明：結合被動與主動以準確掌握健康。流程：1) 服務回報心跳或續約；2) 檢查器以 HTTP/TCP/自訂腳本從外部探測；3) 註冊中心聚合結果並更新狀態；4) 觸發事件通知或移除端點。核心組件：健康檢查器、探測端點（/health）、時間窗與判定策略、事件系統與狀態儲存。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q8, C-Q2, D-Q4

Q4: Client-Side Discovery 的執行流程如何設計？

• A簡: 查詢端點→套用策略選路→直連呼叫→失敗重試/切換→定期刷新清單。
• A詳: 原理說明：由客戶端掌握路由。流程：1) 啟動時載入註冊中心位置；2) 查詢目標服務端點清單；3) 依策略（RR/加權/最少延遲）選路；4) 直連呼叫；5) 失敗時重試或切換端點；6) 週期刷新清單或訂閱變更。核心組件：註冊中心客戶端、選路策略、容錯模組（重試/熔斷）與度量上報。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, A-Q15, C-Q9

Q5: Server-Side Discovery 的技術架構如何？

• A簡: 由代理/LB 訂閱註冊中心，維護後端池並動態轉送請求至健康實例。
• A詳: 原理說明：將路由責任集中。流程：1) 代理/LB 與註冊中心同步端點與健康；2) 建立/更新後端池；3) 接收前端請求；4) 按策略選擇實例並轉送；5) 監測失敗並熔斷或摘除。核心組件：註冊中心、反向代理/LB、健康檢查整合、選路與熔斷模組、可觀測性（指標/日誌）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q13, A-Q20, C-Q4

Q6: DNS TTL 與快取如何影響動態服務解析？

• A簡: TTL 過長會返回過期端點，需降低 TTL、控制快取或採更即時機制。
• A詳: 原理說明：DNS 回應可被客戶端/系統快取至 TTL 期間。動態環境中，長 TTL 導致過期端點不斷被使用。流程建議：1) 降低服務域名的 TTL；2) 在代理側定期刷新解析；3) 對需即時性的內部通訊採 HTTP API 查詢或 Watch。核心組件：DNS 伺服器、客戶端解析器、代理的 resolver 與快取策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q6, C-Q4, D-Q2

Q7: 客戶端負載均衡策略如何選擇與實作？

• A簡: 常見有輪詢、加權、最少連線與延遲感知，需結合健康與重試策略。
• A詳: 原理說明：策略影響延遲與穩定性。流程：1) 取得端點與健康/度量；2) 挑選策略（RR 簡單、加權匹配容量、最少連線衡量負載、基於延遲/錯誤率動態調整）；3) 失敗重試與退避；4) 熱點保護與熔斷。核心組件：度量收集、選路器、失敗處理模組、配置熱更新機制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q16, C-Q9, D-Q3

Q8: Consul 如何同時提供 HTTP 與 DNS 的發現介面？

• A簡: 註冊資料存於目錄，透過 HTTP API 查詢或以內建 DNS 解析服務名。
• A詳: 原理說明：Consul 將服務資訊存於 Catalog，對外提供兩套介面。流程：1) 服務用 HTTP 註冊；2) 查詢方可呼叫 HTTP API 取得端點與健康；或 3) 透過 Consul DNS 使用服務名查詢 A/SRV/TXT 記錄。核心組件：Catalog、Health、DNS 子系統、ACL 與 Watch/長輪詢支援。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q18, C-Q1, C-Q3

Q9: Consul 的健康檢查與告警流程如何設計？

• A簡: 支援 HTTP/TCP/腳本檢查，狀態變更即更新 Catalog，並可觸發事件。
• A詳: 原理說明：多來源健康資訊匯總。流程：1) 註冊時定義檢查類型與頻率；2) 代理按計畫執行檢查；3) 將結果回報 Health；4) 狀態影響查詢回傳；5) 可透過 Watch 或長輪詢通知外部。核心組件：Health 檢查器、Agent、Catalog、事件/Watch 機制與 UI/指標輸出。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q2, D-Q4, A-Q8

Q10: Consul KV Store 的原理與用途？

• A簡: 以鍵值存設定與旗標，支援長輪詢監聽變更，實現集中配置與動態開關。
• A詳: 原理說明：KV 提供弱結構化的共享儲存。流程：1) 服務讀取配置鍵值；2) 變更透過寫入更新；3) 客戶端以長輪詢 Watch 實時獲知並套用；4) 可用於特性開關、協調與選主。核心組件：KV 儲存、HTTP API、ACL、長輪詢（Index/Wait）機制，以及客戶端的回調/重載能力。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q8, D-Q10, A-Q18

Q11: Consul 的多資料中心查詢如何運作（概念）？

• A簡: 支援跨 DC 查詢與路由，可選擇本地優先或跨 DC 存取。
• A詳: 原理說明：Consul 允許多 DC 之間同步必要的服務資訊。流程：1) 在查詢時指定目標 DC；2) 若未指定可配置偏好本地；3) 根據網路拓撲評估延遲與可達性。核心組件：多 DC 連線、目錄同步策略、跨 DC 查詢參數與 ACL 控制。實務建議以本地優先，跨 DC 作為回退。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: D-Q5, A-Q18, B-Q25

Q12: Eureka 與 Ribbon 如何整合實作發現與負載均衡？

• A簡: 客戶端向 Eureka 查端點，Ribbon 依策略選路並直連呼叫。
• A詳: 原理說明：典型 Client-Side 組合。流程：1) 服務向 Eureka 註冊；2) 呼叫方啟動時載入 Eureka 位址；3) 每次呼叫前或週期性向 Eureka 取回目標端點；4) Ribbon 根據策略選路（RR/加權等）；5) 失敗時重試或切換。核心組件：Eureka Server/Client、Ribbon、健康狀態同步與重試熔斷模組。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q19, C-Q9, D-Q6

Q13: Docker Compose 的服務名解析原理？

• A簡: 服務加入自訂網路即被內建 DNS 註冊，互相可用服務名解析至容器 IP。
• A詳: 原理說明：Docker 在自訂網路提供 DNS。流程：1) Compose 建立網路；2) 服務容器啟動並註冊名稱/IP；3) 同網路容器以服務名解析；4) 多副本時 DNS 返回多個 IP。核心組件：Docker Engine、內建 DNS（127.0.0.11）、自訂網路與服務命名規則。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q21, C-Q5, D-Q7

Q14: Docker Swarm 的 Routing Mesh 原理？

• A簡: 對外公布埠映射到叢集入口，請求在節點間轉送到健康任務。
• A詳: 原理說明：以叢集層提供入口路由。流程：1) 發布服務並指定對外埠；2) 節點建立 Ingress；3) 接收請求的任何節點將流量路由至目標服務健康副本；4) 健康狀態影響路由。核心組件：Swarm 管控、Ingress 網路、服務任務、健康監測與轉送層。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q22, C-Q6, D-Q8

Q15: Nginx 如何與註冊中心或 DNS 整合實現動態路由？

• A簡: 透過 resolver 動態解析上游域名，配合 SRV/TXT 或 API 生成上游。
• A詳: 原理說明：Nginx 可依 DNS 解析結果更新上游後端。流程：1) upstream 使用域名；2) 設定 resolver 與 TTL；3) Nginx 週期性重解；4) 依健康狀態與策略分流。若與註冊中心整合，常由外部模板渲染或 API 推送變更。核心組件：resolver、upstream、健康檢查/熔斷模組與自動重載機制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q4, D-Q9, A-Q13

Q16: 以共享儲存為基礎的發現（Etcd/ZooKeeper）與 Consul 的關係？

• A簡: 均提供一致性儲存供登錄/查詢；Consul另整合 DNS/健康檢查/KV。
• A詳: 原理說明：多數發現方案底層依賴一致性鍵值儲存。ZooKeeper/Etcd 提供原 primitives 供自建註冊/監看；Consul 在此之上整合服務註冊、健康檢查與 DNS/HTTP 介面，降低上手成本。核心組件：一致性存儲、Watch/事件、API 與高階的服務語義支持。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q18, B-Q10, C-Q1

Q17: 如何以標籤/中繼資料做精準路由？

• A簡: 在註冊時標記版本/區域，查詢或代理依條件篩選目標端點。
• A詳: 原理說明：把路由條件化。流程：1) 服務註冊附加 tags/metadata（如 version=canary, zone=a）；2) 查詢 API 以條件過濾；或 3) 代理根據標籤選後端；4) 配合灰度/藍綠策略逐步放量。核心組件：註冊中心的標籤索引、查詢語義、代理路由規則與變更發布流程。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q17, C-Q9, D-Q3

Q18: 如何設計抽象層以避免耦合特定註冊中心？

• A簡: 以介面封裝發現操作，實作多個提供者，透過設定選擇後端。
• A詳: 原理說明：以依賴反轉降低耦合。流程：1) 定義 IDiscovery（註冊/查詢/監看）；2) 提供 Consul/Eureka/DNS 等實作；3) 以工廠或 DI 根據設定選用；4) 將策略與重試置於抽象層。核心組件：抽象介面、提供者實作、DI/工廠、配置管理與測試替身。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: C-Q10, D-Q6, A-Q23

Q19: 如何整合舊系統至 Consul（以 DNS 介面）？

• A簡: 將應用 DNS 指向 Consul，服務以名稱解析至註冊端點，免改應用程式。
• A詳: 原理說明：利用 Consul DNS 兼容舊系統。流程：1) 設置系統/網段 DNS 指向 Consul；2) 將服務註冊於 Consul，定義 A/SRV/TXT；3) 舊系統以原生 DNS 查詢即可取得端點；4) 逐步引入 HTTP API 做更細緻控制。核心組件：Consul DNS、系統 DNS 配置、服務註冊與健康資料。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q3, D-Q2, A-Q18

Q20: Service Discovery 與 API Gateway 的邊界與重疊？

• A簡: 皆可路由請求；Gateway 聚焦跨切面（認證、限流），發現聚焦端點選擇。
• A詳: 原理說明：兩者分工不同但互補。API Gateway 面向客戶端入口，處理認證、限流、聚合與協議轉換，並可使用發現結果決定後端。Service Discovery 提供健康端點清單與路由依據。架構上常由 Gateway 消費發現資料，避免重複建設多套代理與策略，並確保各層職責清晰。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q13, B-Q5, D-Q3

Q21: 如何透過發現實作故障隔離（去中心化）？

• A簡: 以健康感知與去中心化路由，避免單點，將故障侷限於局部服務。
• A詳: 原理說明：路由去中心化降低單點風險。流程：1) Client-Side 直連健康端點，避免集中代理失效；2) 以標籤/區域做就近與隔離；3) 故障時重試/切換同服務其他副本。核心組件：健康檢查、選路策略、分區/區域標籤與容錯模組。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q12, B-Q7, D-Q3

Q22: 可靠性計算如何反映發現機制的效益？

• A簡: 未管理時故障率近 1-(1-p)^n；健康感知下近 p^n，差異呈指數級。
• A詳: 原理說明：以簡化模型量化影響。若任何實例失效都致整體不穩，故障率 1-(1-p)^n；若能剔除故障端點，只在健康實例間分流，需全部失效才中斷，近 p^n。雖忽略性能與相依，但顯示健康感知路由對 SLA 的乘數效益。核心組件：健康檢查準確性、動態路由與快速下架機制。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q24, D-Q1, D-Q2

Q23: 網路分割或局部故障為何導致心跳誤判？

• A簡: 服務可回報心跳但對外路徑中斷，需外部探測驗證真實可達性。
• A詳: 原理說明：心跳僅證明服務與註冊中心可通。若對外路徑故障，仍可能收到心跳而誤認健康。解法流程：1) 加入第三方外部探測；2) 用多來源判定（心跳+外部）；3) 以失敗閾值與滑動窗口濾除偶發；4) 斷路保護下游。核心組件：外部健康檢查、判定策略、熔斷與回退。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, D-Q1, D-Q4

Q24: 如何擴展 Server-Side 代理避免瓶頸與單點？

• A簡: 以多副本、水平擴展、就近入口與健康同步，並分層分域設計。
• A詳: 原理說明：消除集中瓶頸。流程：1) 部署多個代理節點並設置前端對等分流；2) 按域/服務拆分代理群；3) 就近入口與區域化路由；4) 快速同步註冊資訊；5) 度量驅動擴容。核心組件：前端均衡器、代理叢集、同步/快取、分域配置與監控告警。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q13, D-Q3, B-Q5

Q25: 何時選擇 Client-Side 或 Server-Side Discovery？

• A簡: 強調效能與去中心化選 Client-Side；重視非侵入與集中治理選 Server-Side。
• A詳: 原理說明：取決於團隊能力與場景。若語言統一、能管控庫版本、需精細路由與最低延遲，可選 Client-Side。若多語言、需快速導入、重視運維集中與對舊系統透明，選 Server-Side。也可混合：入口採代理，服務間採客戶端直連，逐步演進至 Mesh。核心組件：治理能力、技術棧、性能與風險偏好。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q14, B-Q21, A-Q25

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

Q1: 如何用 Consul HTTP API 註冊服務？

• A簡: 發送含名稱、位址、埠與檢查的 JSON 至 /v1/agent/service/register 完成註冊。
• A詳: 步驟：1) 啟動 Consul Agent；2) 準備 JSON 含 Name、Address、Port、Tags、Check；3) 以 PUT 呼叫 /v1/agent/service/register；4) 驗證服務已在 Catalog。程式碼片段：curl -X PUT –data ‘{“Name”:”web”,”Address”:”10.0.0.5”,”Port”:8080,”Check”:{“HTTP”:”http://10.0.0.5:8080/health”,”Interval”:”10s”}}’ http://127.0.0.1:8500/v1/agent/service/register 注意：Address/Port 必須對檢查來源可達；建議提供健康檢查；撤銷可呼叫 /v1/agent/service/deregister/{id}。最佳實踐：標記版本與環境標籤，便於路由。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q1, B-Q8, C-Q2

Q2: 如何在 Consul 定義健康檢查（HTTP/TCP/腳本）？

• A簡: 在註冊時於 Check 指定 HTTP/TCP 或 Script 與 Interval/Timeout 等參數。
• A詳: 步驟：1) 選擇檢查類型：HTTP 用於 Web 健康端點；TCP 檢查開放埠；Script 執行自訂邏輯；2) 在服務註冊 JSON 的 Check 填入對應欄位；3) 設定 Interval/Timeout；4) 於 UI/ API 檢視狀態。範例： “Check”:{“TCP”:”10.0.0.5:6379”,”Interval”:”10s”,”Timeout”:”1s”} 或 “Check”:{“Args”:[“/usr/local/bin/check.sh”],”Interval”:”15s”} 注意：腳本需以 0/非 0 回傳碼表示健康；避免過於頻繁影響性能。最佳實踐：檢查從外部路徑模擬真實可達性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, D-Q4, A-Q8

Q3: 如何以 Consul 查詢服務（DNS 與 HTTP）？

• A簡: DNS 查 A/SRV 記錄；HTTP 呼叫 /v1/health/service/{name} 取得健康端點清單。
• A詳: 步驟：1) DNS：dig @127.0.0.1 -p 8600 web.service.consul SRV 取得端點與埠；2) HTTP：GET http://127.0.0.1:8500/v1/health/service/web?passing=true 回傳健康節點；3) 解析 JSON 並選路。設定：系統或程式 DNS 指向 Consul；HTTP 客戶端處理逾時與重試。最佳實踐：使用 passing=true 僅取健康；搭配 tags/filters 精準篩選；重要流量避免依賴長 TTL 的 DNS 快取。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q2, B-Q8, D-Q2

Q4: 如何用 Nginx 結合 Docker 內建 DNS 做動態反向代理？

• A簡: 上游使用服務名並設定 resolver 127.0.0.1/127.0.0.11，Nginx 依 DNS 動態更新。
• A詳: 步驟：1) 確保 Nginx 與目標服務在同一 Docker 網路；2) 設定 upstream 指向服務名；3) 指定 resolver 指向 Docker DNS（多為 127.0.0.11）；4) 配置 proxy_pass。範例： resolver 127.0.0.11 valid=5s; upstream api { server api:8080 resolve; } server { location / { proxy_pass http://api; } } 注意：加入 resolve 以啟用動態解析；設定 valid 控制 TTL。最佳實踐：健康檢查與失敗重試，確保在容器滾動時平滑。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q15, A-Q21, D-Q9

Q5: Docker Compose 如何正確設定服務名與網路以啟用解析？

• A簡: 建立自訂網路，服務加入同網路即能互以服務名解析，避免使用預設 bridge。
• A詳: 步驟：1) docker-compose.yml 定義 networks: appnet；2) 各服務加入 appnet；3) 使用 services 下的名稱作為主機名呼叫；4) 多副本時配合 LB。範例： networks: { appnet: {} } services: api: { image:…, networks: [appnet] } web: { depends_on: [api], networks: [appnet] } 注意：不同網路間無法解析；避免硬編碼容器 IP。最佳實踐：按邏輯分域建立網路，最小化廣播域與權限。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q13, D-Q7, A-Q21

Q6: 如何在 Docker Swarm 發布服務並啟用 Routing Mesh？

• A簡: 使用 docker service create/publish，叢集節點對外埠自動路由至健康任務。
• A詳: 步驟：1) 初始化 Swarm；2) docker service create –name web –publish 80:80 –replicas 3 nginx；3) 驗證任一節點:80 可達；4) 檢視任務健康狀態。注意：開放節點防火牆的 ingress 連線；UDP 需特別指定；跨主機需正確的 overlay 網路。最佳實踐：監控路由延遲與失敗率，合理設置健康檢查與重試策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q14, D-Q8, A-Q22

Q7: ASP.NET Core 如何提供健康檢查端點？

• A簡: 安裝健康檢查套件，於 Program/Startup 註冊與 MapHealthChecks 暴露 /health。
• A詳: 步驟：1) dotnet add package Microsoft.Extensions.Diagnostics.HealthChecks；2) 在 builder.Services.AddHealthChecks() 註冊檢查；3) app.MapHealthChecks(“/health”); 片段： builder.Services.AddHealthChecks().AddCheck(“self”, () => HealthCheckResult.Healthy()); app.MapHealthChecks(“/health”); 注意：端點應回傳 200/503 表示健康/不健康；避免含機敏資訊。最佳實踐：區分活性/就緒檢查，匹配外部探測語義。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q3, C-Q2, D-Q4

Q8: .NET 應用如何從 Consul KV 讀取集中設定？

• A簡: 使用 HTTP API 讀取鍵值，或引用 SDK，並以長輪詢監聽變更熱更新。
• A詳: 步驟：1) 建立配置鍵：curl –request PUT –data ‘conn=…’ http://127.0.0.1:8500/v1/kv/app/db; 2) 程式讀取：HttpClient GET /v1/kv/app/db?raw；3) 解析並套用；4) 啟用長輪詢監看變更並重新載入。C# 片段： var val=await http.GetStringAsync(“http://127.0.0.1:8500/v1/kv/app/db?raw”); 注意：加入快取與失敗回退；敏感資訊加密。最佳實踐：以前綴分層鍵，版本化設定，避免巨大 payload。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, D-Q10, A-Q18

Q9: 如何在 .NET 實作簡單的 Client-Side Discovery 與均衡？

• A簡: 從註冊中心取端點，輪詢選路並用 HttpClient 直連，失敗重試切換。
• A詳: 步驟：1) 以 HTTP 調 Consul /health/service/{name}?passing=true；2) 解析端點清單；3) 使用簡單輪詢或加權選路；4) 用 HttpClient 發送；5) 失敗重試切換端點。C# 片段： var eps=await GetEndpoints(); var ep=PickNext(eps); var resp=await client.GetAsync($”http://{ep.Address}:{ep.Port}/api”); 注意：加入逾時、退避與熔斷；定期刷新清單。最佳實踐：抽象發現介面，避免耦合單一註冊中心。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, A-Q17, C-Q10

Q10: 如何以抽象介面降低對特定註冊中心的耦合？

• A簡: 定義 IDiscovery/ILoadBalancer 介面，多個 Provider 實作，配置選擇後端。
• A詳: 步驟：1) 定義 IDiscovery.Find(service, filters) 與 Watch；2) 實作 Consul/Eureka/DNS Providers；3) 定義 ILoadBalancer.Strategy；4) 以 DI 注入實作；5) 測試用 MemoryProvider。C# 片段： public interface IDiscovery{ Task<IList> FindAsync(string svc);} 注意：封裝重試與容錯在抽象層；避免在業務程式出現特定 SDK 類型。最佳實踐：以設定切換 Provider，支持漸進遷移。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q18, D-Q6, A-Q23

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

Q1: 註冊中心清單不準確導致導流至故障節點怎麼辦？

• A簡: 可能僅靠心跳誤判，加入外部探測、縮短 TTL、快速下架故障端點。
• A詳: 症狀：請求偶發超時或集中超時。原因：僅憑心跳，服務對註冊中心可達但對外不可達；狀態滯後。解法：1) 增設 HTTP/TCP 外部健康檢查；2) 縮短檢查間隔與過期時間；3) 啟用 passing=true 查詢；4) 避免長 TTL 的快取。預防：建立多來源健康判定，監控失敗率並自動摘除。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, A-Q8, B-Q23

Q2: DNS 解析返回過期位址導致連線失敗，如何處理？

• A簡: 降低 TTL、控制快取、在代理側動態解析，或改用 API 查詢即時端點。
• A詳: 症狀：滾動發布後仍連到下線節點。原因：DNS TTL 過長、系統快取未更新。解法：1) 降低內部域名 TTL；2) 在 Nginx 設定 resolver 與短 valid；3) 客戶端禁用過度快取；4) 改用註冊中心 HTTP 查詢。預防：規範內部服務域名的 TTL 與快取策略，監控解析命中率與錯誤。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, C-Q4, B-Q8

Q3: 負載均衡層成為瓶頸或單點時怎麼辦？

• A簡: 多副本水平擴展、分層分域、就近入口與健康同步，或引入 Mesh。
• A詳: 症狀：延遲升高、吞吐受限、LB 異常引發全站影響。原因：集中式代理超負荷或部署單點。解法：1) 橫向擴容與前端均衡；2) 按服務/域拆分；3) 區域化入口與就近路由；4) 觀測驅動擴容；5) 規劃向 Service Mesh 演進。預防：容量壓測、紅藍部署、熔斷與限流策略。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q24, A-Q25, B-Q20

Q4: Consul 顯示服務為 Critical，如何診斷與修復？

• A簡: 檢查檢查類型、端點可達性與腳本回傳碼，校正間隔與逾時設定。
• A詳: 症狀：UI/Health API 標示 critical，流量被摘除。原因：HTTP/TCP 不可達、腳本退出碼非 0、逾時過短。解法：1) 直接訪問 /health 端點；2) 測試 TCP 連線；3) 檢查腳本權限與返回碼；4) 放寬 Timeout/Interval；5) 檢視 Agent 日誌。預防：在預備環境驗證檢查；提供輕量健康端點與就緒/存活分離。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, C-Q2, C-Q7

Q5: 跨資料中心查詢延遲大或不一致，怎麼優化？

• A簡: 以本地優先，僅必要時跨 DC；快取結果並設置容錯回退策略。
• A詳: 症狀：偶發高延遲、查詢結果不一致。原因：跨 DC 網路延遲/同步延時。解法：1) 預設本地 DC 查詢；2) 僅當本地無可用再跨 DC；3) 快取短期有效結果；4) 監控跨 DC 健康並告警。預防：拓撲優化、容量預留本地冗餘、SLA 區分本地與跨區。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q11, B-Q25, A-Q18

Q6: 客戶端庫版本不一致導致行為差異，如何治理？

• A簡: 制定版本矩陣與升級策略，或改以非侵入代理集中化路由邏輯。
• A詳: 症狀：不同服務路由/重試策略不一，導致不穩。原因：Client-Side 庫多版本並存。解法：1) 建立中央依賴管理與強制升級窗口；2) 提供共用抽象與測試；3) 過渡到 Server-Side/Sidecar 集中策略。預防：CI 檢查版本、發布計畫、灰度驗證與回退機制。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q15, C-Q10, B-Q18

Q7: Docker 服務名解析失敗（Unknown host）如何排查？

• A簡: 確認容器在同自訂網路、服務名正確、DNS 指向 127.0.0.11。
• A詳: 症狀：容器內 ping/連線服務名失敗。原因：不在同一網路、拼寫錯誤、使用預設 bridge。解法：1) docker network inspect 確認；2) 修正 compose 服務名與 networks；3) 檢查 resolv.conf。預防：制定命名規範、按域劃分網路，避免跨網路隱性依賴。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q13, C-Q5, A-Q21

Q8: 發布 Swarm 服務後對外連線不通，該怎麼辦？

• A簡: 檢查 publish 設定、防火牆與 Ingress 網路，確保節點可互通。
• A詳: 症狀：叢集外無法連線到服務埠。原因：未發布埠、防火牆阻擋、ingress/overlay 配置錯誤。解法：1) 驗證 service 構型：docker service inspect；2) 開放節點防火牆；3) 檢查 overlay 網路；4) 驗證任務健康。預防：發布前檢查清單、基礎網路驗證、監控入口錯誤率。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q14, C-Q6, A-Q22

Q9: Nginx 未能分流至多個容器，如何修正？

• A簡: 啟用動態解析（resolve）、設定 resolver、降低 TTL，檢查 upstream 配置。
• A詳: 症狀：Nginx 只連到單一 IP 或連到已下線容器。原因：未啟用動態解析、DNS 快取過長。解法：1) upstream server 加 resolve；2) 設置 resolver 127.0.0.11 valid=5s；3) 減少 keepalive 連線；4) 檢查健康檢查插件。預防：發佈流程中驗證解析與分流，度量後端連線分佈。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q4, B-Q6, A-Q13

Q10: KV 設定更新後服務未生效，如何確保動態套用？

• A簡: 實作長輪詢/Watch 與回調，加入快取與回退，並記錄版本與時間戳。
• A詳: 症狀：KV 變更，但服務仍使用舊設定。原因：未監看變更或熱更新失敗。解法：1) 用 ?index&wait 長輪詢；2) 實作回調套用並驗證；3) 設快取失效；4) 失敗回退到上版。預防：配置版本化、灰度發布設定、強制重載指令與觀測變更延遲指標。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, C-Q8, B-Q2

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是 Service Discovery？
  • A-Q2: 為什麼微服務需要 Service Discovery？
  • A-Q3: 微服務與單體式應用在節點規模上的差異？
  • A-Q4: 註冊、查詢、健康檢查三者的定義與關係？
  • A-Q5: DHCP + DNS 如何幫助理解 Service Discovery？
  • A-Q6: 為何僅靠 DNS 無法支撐微服務的需求？
  • A-Q7: 什麼是服務註冊中心（Service Registry）？
  • A-Q16: 負載均衡在 Service Discovery 中扮演什麼角色？
  • A-Q18: 什麼是 Consul？核心價值為何？
  • A-Q19: 什麼是 Netflix Eureka 與 Ribbon？
  • A-Q20: 雲端負載均衡與 Service Discovery 的關係？
  • A-Q21: Docker 內建 DNS 如何支援服務發現？
  • B-Q1: 服務註冊的運作流程是什麼？
  • B-Q2: 服務查詢（解析）如何運作？
  • C-Q3: 如何以 Consul 查詢服務（DNS 與 HTTP）？
• 中級者：建議學習哪 20 題
  • A-Q8: 什麼是健康檢查？為何不只靠心跳？
  • A-Q9: 什麼是自我註冊（Self-Registration）模式？
  • A-Q10: 什麼是第三方註冊（Third-Party Registration）模式？
  • A-Q12: 什麼是 Client-Side Discovery 模式？
  • A-Q13: 什麼是 Server-Side Discovery 模式？
  • A-Q14: Client-Side 與 Server-Side Discovery 的差異？
  • B-Q3: 健康檢查的機制與類型有哪些？
  • B-Q4: Client-Side Discovery 的執行流程如何設計？
  • B-Q5: Server-Side Discovery 的技術架構如何？
  • B-Q6: DNS TTL 與快取如何影響動態服務解析？
  • B-Q8: Consul 如何同時提供 HTTP 與 DNS 的發現介面？
  • B-Q9: Consul 的健康檢查與告警流程如何設計？
  • B-Q10: Consul KV Store 的原理與用途？
  • C-Q1: 如何用 Consul HTTP API 註冊服務？
  • C-Q2: 如何在 Consul 定義健康檢查？
  • C-Q4: 如何用 Nginx 結合 Docker DNS 做反向代理？
  • C-Q5: Docker Compose 如何設定服務名與網路？
  • C-Q7: ASP.NET Core 如何提供健康檢查端點？
  • D-Q1: 註冊中心清單不準確怎麼辦？
  • D-Q2: DNS 解析返回過期位址如何處理？
• 高級者：建議關注哪 15 題
  • A-Q23: 什麼是侵入式與非侵入式解決方案？
  • A-Q25: 什麼是 Service Mesh（高階概念）？
  • B-Q11: Consul 的多資料中心查詢如何運作（概念）？
  • B-Q16: 共享儲存型發現與 Consul 的關係？
  • B-Q17: 如何以標籤/中繼資料做精準路由？
  • B-Q18: 如何設計抽象層避免耦合註冊中心？
  • B-Q20: Service Discovery 與 API Gateway 的邊界與重疊？
  • B-Q21: 如何透過發現實作故障隔離？
  • B-Q24: 如何擴展 Server-Side 代理避免瓶頸？
  • B-Q25: 何時選擇 Client-Side 或 Server-Side？
  • C-Q6: 如何在 Docker Swarm 啟用 Routing Mesh？
  • C-Q8: .NET 應用如何從 Consul KV 讀取集中設定？
  • C-Q9: 如何在 .NET 實作 Client-Side Discovery？
  • C-Q10: 如何以抽象介面降低耦合？
  • D-Q3: 負載均衡層成為瓶頸或單點時怎麼辦？