Linkerd 2：5 分種釐清 Service Mesh 相關術語

• 2021 年 11 月 1 日
• 筆記

API Gateway(API 網關)

API gateway 位於應用程式的前面，旨在解決身份驗證和授權、速率限制以及為外部消費者提供公共訪問點等業務問題。
相比之下，service mesh 專註於提供應用程式組件之間的操作（而非業務）邏輯。

Cluster(集群)

在雲原生環境中，cluster 是一組物理或虛擬機器，它們構成了容器(container)編排器（如 Kubernetes）可以運行的硬體池。
集群中的每台機器通常被稱為一個 node，cluster 的 node 通常是統一的、可互換的和互連的。

Container(容器)

Container 是應用程式及其依賴項的輕量級包裝，旨在由主機作業系統 (OS) 以隔離方式運行，並嚴格限制資源消耗和對作業系統的訪問。
從這個意義上說，容器是一個原子可執行「單元」，可以由作業系統運行，無需特定於應用程式的設置或配置。

在 service mesh 環境中，container 被 Docker 推廣為虛擬機 (VM) 的輕量級替代品，
虛擬機 (VM) 具有相似的特徵，但重量要大得多。反過來，container 的興起又催生了 Kubernetes 等 container 編排器，
它允許應用程式在打包為 container 時自動跨機器池（稱為 cluster）進行調度。
Kubernetes 的興起催生了 sidecar 部署模型，
它允許像 Linkerd 這樣的 service mesh 以與應用程式解耦的方式提供其功能，
並且不會給運營商帶來嚴重的運營成本。

Control Plane(控制平面)

Service Mesh 的 control plane 提供 data plane 運行所需的命令和控制訊號。
control plane 控制 data plane 並提供 operator 用來配置、監控和操作 mesh 的 UI 和 API。

Data Plane(數據平面)

Service Mesh 的 data plane 包括其 sidecar proxy 的部署，
這些代理攔截 mesh 內的應用程式流量。data plane 負責收集指標、觀測流量和應用策略。

Distributed tracing(分散式追蹤)

在基於微服務的系統中，來自客戶端的單個請求通常會觸發跨多個服務的一系列請求。
Distributed tracing 是一種 tracing 的實踐，當這些請求在分散式系統中移動時，
出於性能監視或調試的原因，跟蹤這些請求。
它通常是通過修改服務以發出跟蹤資訊或「跨度(span)」，並將它們聚合到中央存儲中來實現的。

Egress(出口)

在 Kubernetes 集群的上下文中，egress 是指離開集群的流量。
與 ingress 流量不同，沒有明確的 Kubernetes 出口資源，默認情況下，egress 流量只是退出集群。
當需要控制和監控 Kubernetes egress 流量時，它通常在 networking / CNI 層實現，
或者通過添加顯式 egress proxy 來實現。

Enterprise Service Bus(ESB 企業服務匯流排)

ESB 是一種工具和架構模式，它在很大程度上早於現代微服務架構。
ESB 用於管理面向服務架構 (SOA) 中的通訊，
處理從應用程式間通訊、數據轉換、消息路由和消息隊列功能的所有內容。
在現代微服務應用程式中，像 Linkerd 這樣的 service mesh 取代了對 ESB 的大部分需求，
並提供了改進的關注點分離和減少 SPOF。

Golden Metrics(黃金指標)

Golden metrics 或 Golden signals 是應用程式運行狀況的核心指標。
黃金指標集通常定義為延遲(latency)、流量(traffic volume)、
錯誤率(error rate)和飽和度(saturation)。Linkerd 的黃金指標忽略了飽和度。

Ingress(入口)

Ingress 是在 Kubernetes cluster 中運行並處理從集群外源進入集群的流量的特定應用程式。
此流量稱為入口（或偶爾為「北/南」流量）。與通常由 service mesh 中介的集群內流量相比，
ingress 流量具有一組特定的關注點，因為它通常來自客戶、第三方或其他非應用程式來源。API gateway 通常用作入口。

Init Container(初始化容器)

Init Container 是在 pod 生命周期開始時運行的容器，在應用程式容器啟動之前。
init 容器的典型用例包括重寫網路規則；為應用程式收集 secrets；並從網路位置複製文件。
例如，Linkerd 的 init 容器更新網路規則以通過 Linkerd proxy container 引導 pod 的所有 TCP 流量。
init 容器在應用程式容器啟動之前終止。

Latency(延遲)

Latency 是指應用程式做某事所花費的時間(例如，處理請求、填充數據等)。
在 service mesh 術語中，這是在響應級別上度量的，即通過對應用程式響應請求所花費的時間進行計時。
Latency 的典型特徵是由分布的幾個百分比來表示，
通常包括 p50(或中位數)、p95(或第 95 個百分比)、p99(或第 99 個百分比)，等等。

Linkerd

Linkerd 是第一個 service mesh 和定義術語 「service mesh」 本身的項目。
Linkerd 於 2016 年首次發布，旨在成為 Kubernetes 生態中最快的、最輕量級的服務網格。
Linkerd 是一個雲原生計算基金會 (CNCF) 畢業項目。

Load balancing(負載均衡)

Load balancing 是在多個等效端點之間分配工作的行為。與許多系統一樣，Kubernetes 在連接級別提供負載平衡。
像 Linkerd 這樣的 service mesh 通過在請求級別執行負載平衡來改進這一點，這使得它可以考慮各個端點的性能等因素。

請求級別的負載均衡還允許 Linkerd 有效地為使用 gRPC（以及更普遍的 HTTP/2）的系統負載均衡請求，
這些系統通過單個連接多路復用請求—Kubernetes 本身無法有效地對這些系統進行負載均衡，因為通常只有一個曾經建立的連接。

Load balancing 演算法決定哪個端點將為給定的請求提供服務。
最常見的是 「round-robin(循環)」，它只是在所有端點上進行迭代。
更高級的平衡演算法包括 「least loaded(最少負載)」，它根據每個端點的未完成請求數分配負載。
Linkerd 本身使用稱為 EWMA(exponentially-weighted moving average 指數加權移動平均)
的複雜延遲感知負載平衡演算法，根據端點延遲分配負載，同時響應各個端點延遲配置文件的快速變化。

mTLS(雙向 TLS)

Mutual TLS (mTLS) 是一種對兩個端點之間的連接進行身份驗證和加密的方法。
Mutual TLS 只是標準的傳輸層安全 (TLS) 協議，附加限制是必須驗證連接雙方的身份。
（例如，在 Web 瀏覽器中使用 TLS 通常只驗證伺服器的身份，而不是客戶端。）

• //linkerd.io/2/features/automatic-mtls/

在 service mesh 上下文中，mTLS 是驗證連接任一端的服務身份並保持通訊機密的基本機制。
這種身份驗證是策略實施的基礎。

Multi-cluster(多集群)

在 Kubernetes 的上下文中，multi-cluster 通常是指 「跨」 多個 Kubernetes 集群運行應用程式。
Linkerd 的 multi-cluster 支援提供跨集群的無縫和安全通訊，
以一種即使在公共 Internet 上也是安全的方式，並且對應用程式本身完全透明。

Observability(可觀測性)

Observability 是從系統生成的數據中了解系統運行狀況和性能的能力。
在 service mesh 的上下文中，可觀測性通常是指 service mesh 可以報告的有關係統的數據。
這包括 "黃金指標"、依賴關係的服務拓撲圖、流量取樣等。

Reliability(可靠性)

Reliability 是衡量系統對故障的響應程度的系統屬性。
系統越可靠，它就越能更好地處理出現故障或降級的單個組件。
對於多服務或微服務應用程式，service mesh 可用於通過將重試和超時等技術
應用於跨服務調用、以智慧方式進行負載平衡、
在出現錯誤時轉移流量等來提高可靠性。

• //linkerd.io/2/features/retries-and-timeouts
• //linkerd.io/2/features/load-balancing
• //linkerd.io/2/features/traffic-split

Service mesh(服務網格)

Service mesh 是一種工具，通過在平台層而不是應用程式層插入這些功能，
為應用程式添加可觀測性、安全性和可靠性功能。
Service mesh 是通過添加 sidecar 代理來實現的，這些代理可以攔截應用程式之間的所有流量。
生成的代理集構成了服務網格數據平面，並由服務網格控制平面進行管理。
代理彙集了服務之間的所有通訊，並且是引入 service mesh 功能的載體。

Sidecar Proxy(邊車代理)

Sidecar Proxy 是與 mesh 中的應用程式一起部署的代理。
（在 Kubernetes 中，作為應用程式 pod 中的容器。）sidecar proxy 攔截進出應用程式的網路調用，
並負責實現任何控制平面的邏輯或規則。sidecar proxy 共同構成了服務網格的數據平面。
Linkerd 使用一個名為 Linkerd2-proxy 的基於 Rust 的 micro-proxy，該代理專為 service mesh 用例而設計。
Linkerd2-proxy 比 Envoy 或 NGINX 等通用代理更輕巧且更易於操作。

Success rate(成功率)

Success rate 是指我們的應用程式成功響應請求的百分比。
例如，對於 HTTP 流量，這被衡量為 2xx 或 4xx 響應佔總響應的比例。
（請注意，在這種情況下，4xx 被認為是成功的響應—應用程式執行了它的工作—而 5xx 響應被認為是不成功的——應用程式未能響應請求）。
高成功率表明應用程式運行正常。