哈囉大家好，歡迎來到我們系列文的第四階段！

在過去幾天，我們已經成功地建構了一條完整的 CI/CD 自動化生產線。現在，我們能夠快速地將我們的微服務（例如 ota-backend, ota-frontend）部署到 Kubernetes 叢集中。

但隨著專案規模擴大，叢集中的微服務數量可能會從個位數，增長到數十個、甚至數百個。這時挑戰又出現了：這些服務之間的網路通訊，變得極度複雜且難以管理。

今天，我們就要來認識一個專為解決此問題而生的架構模式 — 服務網格 (Service Mesh)，以及它的業界標準實現 Istio。

Part 1：問題的根源：微服務通訊的混沌

在一個微服務架構中，所有功能都被拆分成獨立的服務，而這些服務之間是透過網路來互相溝通的。這帶來了許多重複且棘手的問題，開發者在撰寫商業邏輯時，還必須分心處理大量的網路通訊議題：

1. 流量管理 (Traffic Management)：
   • 如果 Service A 呼叫 Service B 失敗了，我應該如何實作自動重試 (Retry) 機制？
   • 如果 Service B 回應太慢，我該如何設定超時 (Timeout) 來避免連鎖反應？
   • 我想發布新版本的 Service B，該如何只將 10% 的流量先導到新版本上，進行金絲雀發布 (Canary Release)？
2. 安全性 (Security)：
   • 如何確保 Service A 到 Service B 之間的所有網路流量，都是加密的 (mTLS)？
   • 我該如何設定存取策略，只允許 Service A 存取 Service B，而拒絕 Service C 的存取？
3. 可觀測性 (Observability)：
   • 我該如何收集到每一筆服務之間呼叫的詳細指標（Metrics），例如請求延遲、成功率、請求量？
   • 當一個完整的用戶請求，流經了五個不同的微服務後才失敗，我該如何追蹤 (Tracing) 出問題到底發生在哪一個環節？

傳統的作法是，將這些通訊邏輯，以函式庫 (Library) 的形式，直接寫進每一個微服務的程式碼中。但這種方式有著致命的缺陷：高度重複、與特定程式語言綁定、難以統一升級與管理。

Part 2：解決方案：服務網格 (Service Mesh)

為了解決上述混沌，服務網格 (Service Mesh) 的概念應運而生。

服務網格是一個專門用來處理服務之間通訊的、獨立的基礎設施層。

它的核心思想，是將所有關於網路通訊的複雜邏輯，從我們的應用程式碼中抽離出來，下沉到一個由平台管理的「代理層 (Proxy Layer)」中。

這樣一來，開發者就可以完全專注於商業邏輯的開發，而所有關於重試、加密、路由、監控等網路問題，都交由服務網格來統一處理。

Part 3：Istio 的架構：控制平面與資料平面

Istio 是目前最受歡迎、功能也最完整的開源服務網格實現。它的架構分成兩個部分：

1. 資料平面 (Data Plane)

資料平面是由一系列輕量的網路代理 (Proxy) 組成，它才是實際處理、轉發所有服務之間流量的部分。Istio 實現資料平面的方式，是透過一種稱為 Sidecar (邊車) 的模式：

• 當你將一個 Namespace 加入 Istio 網格後，Istio 會自動在該 Namespace 中建立的每一個 Pod 裡面，都注入一個額外的容器。
• 這個被注入的容器，就是一個高效能的 Envoy 代理。
• 最關鍵的是，Istio 會巧妙地修改 Pod 的網路設定，讓應用程式容器的所有網路流量（無論是傳入還是傳出），都必須先經過這個 Sidecar Proxy。

從此以後，應用程式容器本身不再直接與外界通訊，所有的溝通都由它身旁的這位「代理」來處理。而你的應用程式，對此完全無感。

2. 控制平面 (Control Plane)

控制平面是 Istio 的大腦與指揮中心。它不直接接觸任何服務之間的實際流量。

它的唯一職責，就是集中管理與設定資料平面中所有的 Sidecar Proxies。

在現代的 Istio 版本中，所有的控制平面功能，都被整合到了一個名為 istiod 的核心元件中。istiod 會做以下幾件事：

1. 接收規則：它從我們（管理者）這裡，接收用 K8s YAML 檔案定義的、高層次的流量規則（例如 VirtualService）和安全策略（例如 AuthorizationPolicy）。
2. 轉譯設定：它將這些高層次的規則，「翻譯」成 Envoy Proxy 能看懂的、詳細的低層次設定。
3. 分發設定：它將這些設定，動態地分發給叢集中每一個 Sidecar Proxy。

這張圖要展示 Istio 的運作模式：管理者（我們）只與控制平面 (istiod) 對話，提交我們的期望規則。istiod 負責將規則轉譯並下發給資料平面的所有 Sidecar Proxies。而服務之間實際的流量，則完全在資料平面中，由這些 Sidecar Proxies 互相溝通來完成。

有了這個清晰的架構理解，我們就準備好來實際操作了。在明天的文章中，我們就要來學習如何使用 Istio 最核心的流量管理工具 — Gateway 與 VirtualService，來取代我們之前使用的 Ingress，並實現更強大、更靈活的路由控制！明天見！