在 Intenseye，我们 follow(跟随) trends(趋势) & hype(最被炒作) 的技术，并在使用时应用最佳实践。 我们在用 Scala、Go、Python 等编写的 Kubernetes 上运行了数百个 pod，其中大多数使用 gRPC。
gRPC 是一种现代开源高性能远程过程调用 (RPC) 框架，它使用 HTTP/2 进行传输。HTTP/2 支持通过单个 TCP 连接发出多个请求以减少往返次数。这就是问题出现的地方；负载均衡。建立连接后，所有请求都将固定到单个目标 Pod。 因此，我们不会有平衡的负载。 我们需要一个 L7 感知负载均衡器，而不是 L4。稍后您可以从这里阅读问题的详细信息。
我们正在为另一个问题寻求解决方案；微服务之间的安全传输。我们有数十个组件，总共运行数百个 Pod。 在它们之间一一配置 TLS 令人生畏，而且会很耗时。
我们还需要一个监控系统和来自所有这些组件和微服务的流量指标(traffic metrics)。
我们想观察成功/失败(success/failure)率、Pod 的 RPS、谁与谁交谈的频率等。
我们有这三个问题的单一解决方案：Service Mesh
什么是 Service Mesh？
服务网格是一种工具，通过在平台层而不是应用程序层插入这些功能，为应用程序添加可观察性(observability)、安全性(security)和可靠性(reliability)功能。(servicemesh.es)
服务网格通常作为与应用程序代码一起部署的一组可扩展的网络代理来实现；一种称为边车的模式。这些代理处理微服务之间的通信，并允许控制流量并获得整个系统的洞察力。Service Mesh 提供了很棒的功能，例如流量指标(traffic metrics)、熔断(circuit breaking)、mTLS、流量拆分(traffic split)、重试和超时(retry & timeout)、A/B 路由(routing)等。
source: servicemesh.es
我们开始挖掘服务网格的细节并评估对我们很重要的功能，我们如何从中受益等。由于服务网格会影响延迟和资源消耗，因此也必须衡量这些缺点。由于我们有 500 多个 Pod，因此资源成本将是 500 x sidecar。另外，我们在与时间赛跑，所以延迟应该是最小的。
经过一些研究和 PoC，我们决定在 Istio、Consul 和 Linkerd2 之间使用 Linkerd2。 我必须说，servicemesh.es 帮助我们获得了有关服务网格的知识并比较了它们之间的功能。
除了我们正在寻求的功能之外，与 Istio 和 Consul 相比，我们选择 Linkerd2 有 3 个原因。（L7 LB、mTLS、traffic metrics 等）：
轻量级（低 CPU 和内存消耗）
低延迟
延迟感知 LB
Istio 有很多不错的功能（感谢 Envoy 代理），但我们并不需要所有这些功能。与 Linkerd2 相比，它的 sidecar 代理 CPU 和内存消耗也很高。Consul 使用相同的 sidecar 代理，因此我们也将其删除。这里详细解释了为什么 Linkerd2 使用它自己的代理而不是 Envoy。另外，Linkerd2 非常好用。Istio 的文档实在太多了。
Linkerd和“Cardi B”押韵。
“d”要分开发音，如“Linker-DEE”。()
without mesh / with mesh
正如您在图中所见，有些 pods 像替罪羊，有些像树懒。网格后，一切都很好。