[[432332]]

API Gateway(API 網關)

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

Cluster(集群)

在云原生環(huán)境中，cluster 是一組物理或虛擬機器，它們構成了容器(container)編排器(如 Kubernetes)可以運行的硬件池。集群中的每臺機器通常被稱為一個 node，cluster 的 node 通常是統(tǒng)一的、可互換的和互連的。

Container(容器)

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

在 service mesh 環(huán)境中，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 用來配置、監(jiān)控和操作 mesh 的 UI 和 API。

Data Plane(數(shù)據平面)

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

Distributed tracing(分布式追蹤)

在基于微服務的系統(tǒng)中，來自客戶端的單個請求通常會觸發(fā)跨多個服務的一系列請求。 Distributed tracing 是一種 tracing 的實踐，當這些請求在分布式系統(tǒng)中移動時， 出于性能監(jiān)視或調試的原因，跟蹤這些請求。它通常是通過修改服務以發(fā)出跟蹤信息或“跨度(span)”，并將它們聚合到中央存儲中來實現(xiàn)的。

Egress(出口)

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

Enterprise Service Bus(ESB 企業(yè)服務總線)

ESB 是一種工具和架構模式，它在很大程度上早于現(xiàn)代微服務架構。 ESB 用于管理面向服務架構 (SOA) 中的通信， 處理從應用程序間通信、數(shù)據轉換、消息路由和消息隊列功能的所有內容。在現(xiàn)代微服務應用程序中，像 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 容器的典型用例包括重寫網絡規(guī)則;為應用程序收集 secrets;并從網絡位置復制文件。例如，Linkerd 的 init 容器更新網絡規(guī)則以通過 Linkerd proxy container 引導 pod 的所有 TCP 流量。 init 容器在應用程序容器啟動之前終止。

Latency(延遲)

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

Linkerd

Linkerd 是第一個 service mesh 和定義術語 “service mesh” 本身的項目。 Linkerd 于 2016 年首次發(fā)布，旨在成為 Kubernetes 生態(tài)中最快的、最輕量級的服務網格。 Linkerd 是一個云原生計算基金會 (CNCF) 畢業(yè)項目。

Load balancing(負載均衡)

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

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

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

mTLS(雙向 TLS)

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

https://linkerd.io/2/features/automatic-mtls/

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

Multi-cluster(多集群)

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

Observability(可觀測性)

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

Reliability(可靠性)

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

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

Service mesh(服務網格)

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

Sidecar Proxy(邊車代理)

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

Success rate(成功率)

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