编译器|伊森规划|YunZhaoSidecars的概念在容器和微服务领域变得如此普遍，以至于很容易将Sidecars视为云原生技术堆栈中自然、健康的一部分。但退一步想想，Sidecar也未必这么优雅。当微服务的规模变得臃肿时，Sidecar模型也需要创新。就像现在的摩托车很少有边车一样。毕竟，它之所以被称为边车，是因为如果你需要携带一些本身放不下的东西，你可以把它放在摩托车的边车上。然而，边车解决了摩托车容量有限的问题，但同时大大减慢了行驶速度，使机动变得更加困难。服务网格的Sidecar模式服务网格是技术堆栈中的一个层，可帮助连接、保护和监视分布式应用程序的各个组件。通常，单体应用程序不会使用服务网格，因为它作为单个进程运行，没有复杂的依赖网络和进程间通信。但是，在将单体应用迁移到微服务架构时，会遇到三大问题：第一，必须应对离散微服务之间互通的挑战；其次，你需要确保微服务交易是安全的；第三，需要有一种有效的方法来从每个微服务收集可观察性数据。管理微服务的成本是巨大的，如果直接在微服务本身的代码中检测并处理这些问题，开发人员将花费大量时间在每个微服务中繁琐地编写和维护自定义代码，以处理连接性、安全性和可观察性。服务网格通过提供集中管理的服务解决了这个问题。从本质上讲，服务网格允许开发人员将管理微服务连接性、安全性和可观察性所需的大部分工作“外包”给专用的基础设施层，而不必在微服务本身内部处理这些工作。任务。通过这种方式，服务网格有助于简化和标准化微服务的管理方式。当然，服务网格不能直接与微服务对话或集成，这就是“sidecar模式”的用武之地。Sidecar成为服务网格与微服务对话的方式。在sidecar模式下，需要在承载各个微服务业务逻辑的主应用容器之外部署一个特殊的sidecar容器。Sidecar托管管理微服务的服务网格代理。如果边车容器和主容器运行在同一个Pod中，两者都可以执行服务网格中定义的治理规则。Sidecar模式对于管理部署为容器并使用Kubernetes编排的分布式应用程序中的微服务很有意义。在没有更好的技术将服务网格连接到单个应用程序容器的情况下，将边车容器与实际微服务一起部署是将服务网格编排到微服务架构中的一种简单直接的方法。Istio很火是有原因的。今天有许多服务网格，如Linkerd和Traefik。但可能最流行的解决方案是Istio，这是一种为以Kubernetes为中心的堆栈设计的开源服务网格。来源：istio.ioIstio通过提供两个主要组件来实现服务网格：1.一个数据平面，它依赖于运行Envoy代理的边车容器与各个微服务进行交互。2.控制平面，作为集中式进程运行以提供服务发现、强制配置和保护流量。Istio的开源特性和Kubernetes友好的设计使该工具成为迄今为止数以千计的云原生托管堆栈的核心部分。依赖Sidecar的问题Istio和其他依赖Sidecar模型的服务网格确实解决了很多实际问题，但同时也埋下了很多问题的种子。Sidecar并不是一个完美的解决方案。面对分布式应用连接、保护和观察的大规模管理需求，像Istio这样的服务网格存在两个关键问题：高资源消耗和低性能。1.资源开销在分布式托管环境中，每个微服务都需要运行一个Sidecar容器，使运行的容器总数增加一倍。这也意味着应用程序最终会消耗更多资源。除了sidecar容器本身消耗的资源外，编排器也增加了管理sidecar的负担。同时，开发者在部署和更新Sidecar时会消耗更多的网络带宽。也就是说，在运行sidecar时，会占用相当一部分资源，实际应用可用的资源会减少，可能导致需求高峰期的性能体验较低。当然，随着最终需要更多节点（或具有更高资源分配的昂贵节点）来处理工作负载，托管成本也会攀升。2.性能和延迟除了托管Sidecar的成本外，Sidecar容器需要在网络流量流入和流出每个微服务时进行干预，这将不可避免地拖累性能。在应用程序可以接收和响应请求之前，每个数据包都必须通过边车，这会增加延迟并可能对用户体验产生负面影响。Sidecar模式下的Istio性能Sidecar容器的性能开销到底是多少？我们来看看Istio自己记录的相关数据。Istio的数据显示，每个Envoy代理每1000个请求将消耗0.35个vCPU和40MB内存。当然，性能开销会根据配置Istio的确切目的而有所不同（您使用的功能越多，开销就越高）。因此，如果您有10个微服务并为每个微服务部署一个EnvoySidecar，则您需要额外的3.5个vCPU和400MB内存来托管它们。这可以很容易地转化为相当于一个额外的VM实例来运行sidecar。（根据Istio的说法，它甚至需要额外的1个vCPU和1.5GB的控制平面。）另请注意，Istio表示每个代理容器平均增加2.65毫秒到第90个百分位数的延迟。这意味着当你使用Sidecar时，响应速度也会有所延迟。2.65毫秒可能看起来很短，但在每一毫秒都很重要的网络世界中，它也可能极具破坏性，尤其是对于需要真正实时执行的应用程序。通过eBPF实现“SidelessCars”开发人员和IT团队经常将Sidecar容器带来的性能和延迟成本视为不可避免的罪恶。使用带有sidecar模式的服务网格比不使用服务网格要容易得多，并且必须在每个微服务中进行管理，因此他们很乐意为托管支付更多费用和/或接受性能损失以便能够使用其中，集中式微服务管理服务网格。然而，今天，一个更美好的世界是可能的——多亏了eBPF，可以直接在Linux内核中运行超高效、超安全的动态代码，而无需处理内核模块或修改内核源代码。对于需要服务网格的工程师来说，这意味着借助eBPF，传统上使用sidecar容器实现的微服务治理可以通过eBPF程序在内核中进行处理。由于eBPF程序可以在Kubernetes集群中的每个（基于Linux的）节点上运行，它们可以直接在内核中管理微服务连接、安全性和可观察性，而不是作为单独的sidecars运行。与Istio等传统服务网格相比，这种方法具有很大的优势：性能：由于eBPF程序消耗的资源最少，因此与使用Sidecar架构相比，它们将显着降低运行服务网格的开销。简单性：基于eBPF的服务网格将消除部署和管理一组边车容器的需要。可见性和控制：通过直接在内核中运行，eBPF程序在可以从容器中访问哪些数据以及可以对其施加哪些控制方面几乎具有无限的范围。在这方面，基于eBPF的网格将比那些依赖sidecar容器的网格更强大。利用eBPF来解决传统服务网格的缺点是一个相对较新的想法。目前，开发者越来越关注这一策略，Cilium已经实现了这一策略。Cilium：基于eBPF加速节点代理模式的eBPF前景广阔eBPF作为服务网格解决方案的“潜力股”，正在成为开发者应对分布式应用安全、可观察和管理的“后起之秀”。将开发人员从Sidecar模型中解放出来，并允许将现有的代理技术集成到现有的内核命名空间概念中，提供原生且高效的服务网格实现范例。此外，还可以更轻松地收集丰富的数据以实现可观察性，并为数据流动提供必要的安全性在容器内和容器之间，eBPF还可以用于服务网络中的“内核级”创新，能够卸载越来越多当前由代理执行的功能，以更简单、更高效、更少的方式管理微服务之间的交互资源密集型方式，Sidecar会消失吗？不得不说，连一直使用“sidecars”的Istio都承认es它的局限性。9月7日，Istio公布了新的数据平面模型AmbientMesh，突出取消了以Sidecar为中心的架构，取而代之的是Sidecar-less方式，同时保留了Istio的零信任安全、遥测和流量管理等核心功能.正如Istio官方所说：“自诞生以来，Istio架构的一个关键特性就是使用了Sidecar，但Sidecar模型并没有提供应用程序与Istio数据平面之间的完美隔离，这导致了高入侵和资源利用率不足、流量中断等，用户需要有一个侵入性更小、更易于使用的选项。”当然，这并不是说Istio或依赖“sidecar模型”的服务网格将退出舞台。我们可以想象一个Istio控制平面仍然存在的世界，但数据平面由eBPF程序驱动，而不是运行在边车容器中的Envoy代理。Istio已经开发了许多用于服务发现和配置管理的强大技术，这些技术将在基于eBPF的服务网格中具有持久的吸引力。可以预见，“边车模式”在未来几年内会慢慢过时——就像摩托车上的边车一样。优先考虑速度和效率的企业和开发者将再次拥抱eBPF，摆脱Sidecar的限制。参考链接https://www.groundcover.com/blog/istio-service-meshhttps://isovalent.com/blog/post/2021-12-08-ebpf-servicemeshhttps://istio.io/latest/blog/2022/引入环境网格/
