對於剛接觸微服務架構的工程師來說，Service Mesh（服務網格）聽起來像是一個很複雜的基礎設施層。簡單來說，它的作用是在每個微服務旁邊放一個小助手（稱為 Sidecar Proxy），負責處理所有服務之間的通訊，包含加密、流量調度與監控，讓開發者不需要在每個應用程式碼裡重複寫這些邏輯。
Linkerd 作為 CNCF 畢業的開源碼專案，一直以輕量化著稱。在最新的 2.20 版本中，它針對實際生產環境中的痛點，推出了三個核心改進：流量調度的智能化、控制平面的資源極小化，以及可觀測性的強化。
理解 Rate-limit-aware Load Balancing 的重要性
在傳統的負載平衡（Load Balancing）邏輯中，Proxy 通常根據延遲（Latency）或端點是否存活（Availability）來決定要把請求發給誰。但現實中的 API 服務往往不會直接崩潰，而是會透過 HTTP 狀態碼告訴你：我現在太忙了，請稍後再試（即 Rate Limit 速率限制）。
過去的 Service Mesh 在面對這種情況時，可能會將其視為一般的回應，繼續將流量發往該過載的節點，導致請求不斷被拒絕，甚至引發連鎖反應導致整個系統崩潰（Cascading Failures）。
Linkerd 2.20 引入了 Rate-limit-aware Load Balancing（感知速率限制的負載平衡）。這意味著 Proxy 現在能識別出速率限制的訊號，並自動將流量暫時導向其他健康的實例。這種機制能有效維持系統整體的吞吐量，對於高度依賴第三方 API 或具有動態限流機制的微服務體系尤其重要。
控制平面的資源消耗優化
對於維運工程師而言，基礎設施本身不應該搶走太多應用程式的資源。Linkerd 的控制平面（Control Plane）負責管理所有 Proxy 的配置與狀態。在 Kubernetes 環境中，當 Pod 頻繁地被建立或刪除（Pod Churn）時，控制平面的記憶體壓力會劇增。
Linkerd 2.20 對 Destination Controller（目標控制器）進行了深度優化，在 Pod 高頻變動的情況下，記憶體消耗最高可降低 85%。這對於資源受限的叢集或是超大規模的生產環境非常有感，讓團隊能將更多記憶體配給給真正的業務邏輯，而非浪費在基礎設施的維護上。這也體現了 Linkerd 使用 Rust 語言編寫 Proxy 的初衷：追求極高的效能與極低的資源佔用。
強化 Inbound 流量的可觀測性
可觀測性（Observability）是指我們能透過外部輸出（如指標、日誌）來推斷系統內部狀態的能力。Linkerd 2.20 提升了 Inbound Request Metrics（入站請求指標）的精確度。
對於平台工程師來說，準確的入站流量數據能幫助他們快速定位瓶頸：是請求在進入服務前就卡住了，還是服務內部處理太慢？配合 OpenTelemetry 等標準化遙測協議，這讓故障排除（Troubleshooting）變得更加直觀，減少了在事故發生時盲目猜測的時間。
設計哲學：簡單勝過複雜
目前的 Service Mesh 市場分為兩種路線。一種是以 Istio 為代表的全功能生態系，提供極其強大的策略控制與安全性設定，但相對地，學習曲線陡峭且維運複雜。另一種則是 Linkerd 堅持的路線：只提供最核心、最必要的服務網格能力，並將運作簡單化、資源輕量化。
隨著 Kubernetes Gateway API 與 eBPF 技術的成熟，網路層的許多功能已經內建化。Linkerd 2.20 的更新方向顯示，現代的 Service Mesh 不應盲目追求功能堆砌，而應專注於如何讓運維更輕鬆、讓資源利用率更高。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。