eBPF在服务网格中的应用前景如何？

本文共计2436个文字，预计阅读时间需要10分钟。

服务网架构现状+服务网架构为服务提供复杂的应用层网络管理，如服务发现、流量路由、弹性（超时/重试/断路）等。认证/授权、可观测性（日志/度量/追踪）等。在分布式应用的早期，这种架构

服务网格现状

服务网格为服务提供了复杂的应用层网络管理，如服务发现、流量路由、弹性（超时/重试/断路）、认证/授权、可观察性（日志/度量/追踪）等。

在分布式应用的早期，这些要求是通过直接将所需的逻辑嵌入到应用中来解决的，比如spring cloud等微服务框架。服务网格将这些功能从应用程序中提取出来，作为基础设施的一部分透明的提供给所有应用程序使用，因此不再需要修改每个应用程序。

在早期，服务网格的功能通常是以库的形式实现的，要求网格中的每个应用程序都要链接到以应用程序的语言框架编写的库。类似的事情也发生在互联网的早期：曾几何时，应用程序还需要运行自己的 TCP/IP 协议栈！正如我们将在这篇文章中讨论的那样，服务网格正在发展成为一种内核责任，就像网络堆栈一样。

今天，服务网络通常使用一种叫做sidecar模型的架构实现的，通过在每一个应用pod上添加一个代理sidecar容器，如Envoy或Linkerd，这些代理也被称为服务网格的数据平面。

这种方式优点是支持异构系统的服务治理，如果许多服务是用不同的语言编写部署的，或者如果你正在运行不可变的第三方应用程序，这就很有好处，因为它对服务的治理是无侵入式的。同时治理模块升级对用户应用是透明的。

缺点也是比较明显的：

• 服务治理进程本身占用的系统资源也不可被忽略，20个服务，每个服务5个pod就会有100个代理容器，这种纯粹的重复都会耗费资源。