Linkerd 2：5 分种厘清 Service Mesh 相关术语

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 通常只验证服务器的身份，而不是客户端。）

https://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 可用于通过将重试和超时等技术

应用于跨服务调用、以智能方式进行负载平衡、

在出现错误时转移流量等来提高可靠性。

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 响应被认为是不成功的——应用程序未能响应请求）。

高成功率表明应用程序运行正常。