[[432332]]

API Gateway(API 網(wǎng)關(guān))

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

Cluster(集群)

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

Container(容器)

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

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

Control Plane(控制平面)

Service Mesh 的 control plane 提供 data plane 運行所需的命令和控制信號。 control plane 控制 data plane 并提供 operator 用來配置、監(jiān)控和操作 mesh 的 UI 和 API。

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

Service Mesh 的 data plane 包括其 sidecar proxy 的部署， 這些代理攔截 mesh 內(nèi)的應(yīng)用程序流量。data plane 負(fù)責(zé)收集指標(biāo)、觀測流量和應(yīng)用策略。

Distributed tracing(分布式追蹤)

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

Egress(出口)

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

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

ESB 是一種工具和架構(gòu)模式，它在很大程度上早于現(xiàn)代微服務(wù)架構(gòu)。 ESB 用于管理面向服務(wù)架構(gòu) (SOA) 中的通信， 處理從應(yīng)用程序間通信、數(shù)據(jù)轉(zhuǎn)換、消息路由和消息隊列功能的所有內(nèi)容。在現(xiàn)代微服務(wù)應(yīng)用程序中，像 Linkerd 這樣的 service mesh 取代了對 ESB 的大部分需求， 并提供了改進的關(guān)注點分離和減少 SPOF。

Golden Metrics(黃金指標(biāo))

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

Ingress(入口)

Ingress 是在 Kubernetes cluster 中運行并處理從集群外源進入集群的流量的特定應(yīng)用程序。此流量稱為入口(或偶爾為“北/南”流量)。與通常由 service mesh 中介的集群內(nèi)流量相比， ingress 流量具有一組特定的關(guān)注點，因為它通常來自客戶、第三方或其他非應(yīng)用程序來源。API gateway 通常用作入口。

Init Container(初始化容器)

Init Container 是在 pod 生命周期開始時運行的容器，在應(yīng)用程序容器啟動之前。 init 容器的典型用例包括重寫網(wǎng)絡(luò)規(guī)則;為應(yīng)用程序收集 secrets;并從網(wǎng)絡(luò)位置復(fù)制文件。例如，Linkerd 的 init 容器更新網(wǎng)絡(luò)規(guī)則以通過 Linkerd proxy container 引導(dǎo) pod 的所有 TCP 流量。 init 容器在應(yīng)用程序容器啟動之前終止。

Latency(延遲)

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

Linkerd

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

Load balancing(負(fù)載均衡)

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

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

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

mTLS(雙向 TLS)

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

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

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

Multi-cluster(多集群)

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

Observability(可觀測性)

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

Reliability(可靠性)

Reliability 是衡量系統(tǒng)對故障的響應(yīng)程度的系統(tǒng)屬性。系統(tǒng)越可靠，它就越能更好地處理出現(xiàn)故障或降級的單個組件。對于多服務(wù)或微服務(wù)應(yīng)用程序，service mesh 可用于通過將重試和超時等技術(shù) 應(yīng)用于跨服務(wù)調(diào)用、以智能方式進行負(fù)載平衡、 在出現(xiàn)錯誤時轉(zhuǎ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(服務(wù)網(wǎng)格)

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

Sidecar Proxy(邊車代理)

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

Success rate(成功率)

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