Common Proxies in Service Mesh Implementations

背景

前一篇我們介紹了 Service Proxy & Edge Proxy 這兩類雖然都是代理，但是依照其工作模式和部署類型分別在 Kubernetes 上各自所扮演的角色。今天這篇將在更介紹常見的代理應用於 Service Mesh 中，以及為何這些代理適合當作 Service Proxy。

何謂 Service Mesh ?

首先瞭解一下 Service Mesh 可以先參考我們之前一篇介紹 Service Mesh 一文，Service Mesh 是一種專用的網路功能基礎層被添加進服務與服務之間，在這系統之上，可以提供的功能包含四大種類: 1. 可觀測性 (Observability) 2. 流量轉移 (Traffic shifting) 3. 彈性功能 (Resiliency features) 4. 自動化 mTLS (Automatic mutual TLS)，並且在引用之後對商業邏輯的源碼無侵入性換句話說不需要對業務邏輯的源碼進行修改適配（造成源碼更加複雜）就能提供上述4大功能。

無侵入性

理論上將以上四大類的功能實作進每一個微服務中，就能達到 Service Mesh 所帶來的好處，我們為什麼一定要使用 Service Mesh呢？

由於微服務應用非常多，應用實作所用的語言也非常多，插入這些片段的非業務邏輯源碼，會造成應用難以維護及同步更新，故我們看到的 Service Mesh 產品，在引入這些功能後，都還具備有對源碼無侵入性，也就是能在提供上述4大功能的同時又與業務邏輯完美解耦 (Decoupling) 而這些非業務邏輯的處理工作又被稱作 Cross Cutting Concerns ，完美的 Service Mesh 產品會將 Cross Cutting Concerns 放到 Service Proxy (Data Plane) 來做，透過其提供的 Control Plane 來進行更進一步的統一操控及監控。

常見的 Service Mesh 實作比較

以下將介紹目前幾款常見的 Service Mesh 選項，目前常見的 Service Mesh有7種，這裡將依照社群的活躍度及科技公司採用程度做2大類分群（按字母排序），除此之外排除在這2大類之外的為特殊解決方案屬於雲供應商綁定（閉源）的 Service Mesh

第一類：Consul Connect, Istio, Linkerd2

第一類可以視為主流的 Service Mesh 產品，從客觀的一些評論上可以找到的資料包含

1. Linkerd2 的 data plane/control plane 性能優於 Istio (第三方效能評測)。Ingress Controller 沒有限定可任意搭配
2. Istio 的 service mesh 的功能較 Linkerd2 豐富 (ex: Resilience 特性少了熔斷及延遲注入) 。Ingress Controller 限定使用 Ingress Gateway (Envoy) 方案。支持網格擴展至 Cluster 環境外 (Mesh Expansion)
3. Consul Connect 需搭配 Consul 一起使用，內建 L4 代理作為 Service proxy 開發測試用，生產環境官方建議使用 Envoy 可抽換代理。Ingress Controller 限定使用 Envoy 或 Ambassdor

第二類 ：Kuma, Open Service Mesh, Traefik Mesh

第二類可以作為次要的 Service Mesh 產品，不會建議讀者上生產環境使用，但可以持續關注，總結以下幾個要點：

1. Open Service Mesh 微軟所推出，官方明確表示目前還在重度開發中，不適合生產。Ingress Controller 限定搭配 Nginx, Azure Application Gateway Ingress Controller, Gloo API Gateway。
2. Traefik Mesh 不支援 mTLS 且使用的 service proxy 為自家的 Traefik proxy 效能待考驗。Ingress Controller 沒有限定可任意搭配。
3. Kuma 為 Kong 官方所出的 Mesh 項目，是非常晚期才出的專案，專案成熟度不足。Ingress Controller 沒有限定可任意搭配。

第三類：AWS App Mesh

第三類為 AWS 所推出的雲供應商綁定 mesh 服務屬於閉源的產品，除非團隊高度依賴AWS 並願意付出相當的諮詢費在於遷移自家微服務上 AWS App Mesh，否則應該是少數人會使用，Ingress Controller 搭配尚未發現，研判很大機會使用 AWS 自家 LB

以下附上三大類的比較圖表

論代理應用於 Service Mesh 的 Service Proxy 之中

由上面的比較圖表，歸納有三種代理作為 Service Proxy

1. Envoy: C++實作，除被 Edge Ingress 積極採用之外 Mesh 實作也採用，屬於通用性非常高的代理。
2. linkerd2-proxy: Rust 實作，為 linkerd 所專用代理，單一性特別強，整合度高，性能高於 Envoy。
3. Traefik: Go 實作，自家 Traefik Ingress Controller 使用作為 Edge/Service Proxy，效能估計沒有前二者高。

我們可以看出 Envoy 獲得最高 Service Mesh 實作所採用作為其 Data Plane，而由第三方效能分析報告可看出 linkerd2-proxy 獲得較高的性能評比（可以推測因專一性高，控制平面整合性強）

而之所以 Envoy 之所以會被那麼多 Service Mesh 及 Ingress Controller 項目所採用作為 Data Plane (Service Proxy / Edge Proxy) 的原因就是其向上提供了 xDS 接口介面，開發者可以透過程式去控制代理的行為（撰寫 Control plane）具有 Programmable Edge 的稱號

結論

由本篇 分析的面向概覽可以作為讀者選用 Service Mesh 的參考方向之一，其中代理的比較可以做為參考之一，但絕對不會是唯一指標。個人主觀對於 Envoy 及 linkerd2-proxy 兩者的評價是：

Envoy 比 linkerd2-proxy 更適合做通用代理，而 linkerd2-proxy 比 Envoy 更適合做 mesh 代理 (service proxy)

依照筆者過去在團隊中引入的經驗，Proxy 性能高低不會是選用 Service Mesh 的主要考量，而是以易用性以及維運層面成本去選用適當的 Service Mesh 解決方案。