从Istio在CNCF毕业，看服务网格的架构变迁
近日（美国东部时间7月12日），CNCF通过官网宣布，Istio正式成为毕业项目，理由是作为一个快速增长的服务网格产品，为该领域增添了更多的终端用户、产品特性和维护者，达到了基金会的最高成熟度。
这距离Istio加入CNCF也仅仅过去1年的时间。
如果将Istio诞生的2017年看作服务网格元年，那么到今天为止，它已经走过了6个年头。
作为该领域的典型代表，Istio的发展历程可以看做是服务网格的浓缩史。历经多年的演进和迭代，Istio也从萌新转向成熟，它在流量控制、安全和可观测方面的能力也被越来越多的人所了解。
而服务网格领域的开发者们依然在探索着各种新的可能性。本文会基于服务网格的架构演化来阐述目前有哪些新的产品形态和技术方向值得我们关注。
网络形态的演化
主流的服务网格产品包括控制平面和数据平面两部分。其中数据平面的构建形态体现了服务网格的主要特征。这是因为所谓网格，指的是由服务间通信链路组成的网络拓扑，以及负责流量控制的代理而组成。业界也主要基于提供核心流控能力的代理组件进行优化和调整。下面我们逐一对目前所出现的各种架构模式进行分析，并探讨它们的优劣和适用场景。
Sidecar 模式
一般来说，典型的服务网格都在使用Sidecar作为数据平面，但Sidecar模式并不是服务网格所特有的。
Kubernetes的Pod提供了多容器支持，所有伴随应用容器部署的其他容器都可以被称为Sidecar，如日志收集、追踪代理等。
服务网格将具有流控能力的代理以Sidecar部署，从而组成了网格数据平面的基本形态。
相对于传统服务治理方案（本质上是以SDK方式提供能力）来说，云原生环境下，借助于Kubernetes的能力，以Sidecar模式实现流控和治理是非常直接的一种实现思路，在某种程度上解决了传统方案的弊端，因此也成为了标准的服务网格实现方式。SDK类库或框架具有如下的缺点：
代码侵入：SDK作为应用的依赖包，必然要以某种方式被应用代码引入，如配置、标注、接口实现等。当然，我们也可以说Sidecar也需要侵入到应用所在的Pod，但相比SDK代码层面的侵入来说要轻量的多。
语言绑定：SDK是基于单一语言构建的，针对不同语言要实现同样的功能，就需要提供多语言的SDK包。对于一些功能丰富、实现复杂的框架来说，实现多语言版本几乎不可能。因此，这类框架即便功能强大，也只能作为限定于某种语言的特定产品。
维护成本：作为应用的依赖包，想要完成维护和升级都需要依赖方的配合。因工期、人力资源等问题会导致SDK的升级延迟或搁浅，造成版本的不一致，从而导致要花费大量精力在维护层面上。
对于异构系统来说，SDK很难提供一个统一的、跨语言、跨系统的服务治理解决方案。Sidecar借机杀入服务治理战场，逐渐成为企业落地时重点考量的选项。到今天为止，绝大多数服务网格产品都以Sidecar模式作为数据平面的标准。随着落地实践的普及，Sidecar的缺点也逐渐被人所熟知：
请求中断：原本服务间直接访问的方式，因为Sidecar的引入被切分为了三段，且因为进程外调用的增加，出现网络故障的几率也会增加。其副作用就是增加了调试的难度，开发者在故障发生时需要找到到底是在哪一步链路出现了问题。
延迟：请求从一跳变三跳最明显的问题就是会增加延迟，这也是最被开发者诟病的一点。尽管从一些产品的benchmark结果来看，Sidecar的引入只会增加毫秒级（个位数）延迟，足以应对绝大多数场景。但对性能有极高要求的业务场景（如实时广告展示）来说，延迟损耗成为了放弃服务网格的最主要原因。
资源占用：Sidecar作为一个独立的容器必然会占用一定的系统资源，多数产品的Sidecar代理都尽可能设计的轻量化，仅依靠极少的资源即可启动运行。但对于超大规模集群（如数万个Pod）来说，巨大的基数也使得资源总量变成了不小的数目。同时，这类集群的网络通信拓扑也更加复杂，配置下发的规模也会让Sidecar的内存出现剧烈的增长。
维护成本：和SDK一样，Sidecar同样需要维护的成本。尽管像Istio这样的网格产品都提供了自动注入机制，开发者无需手动编写和维护Sidecar模版信息，但想要合理使用它还是需要做相应的配置调整。在版本升级时，Sidecar可以解决SDK手动升级的侵入性问题，但依然需要通过Pod的重建完成升级，对流量敏感的业务可能会受到影响。
也正因为如此，社区的开发者开始重新思考是否应该将服务网格和Sidecar划上等号，同时继续探索产品形态其他的可能性。
Proxyless 模式
Sidecar本质上是一个服务代理（如Envoy），通过劫持发送到应用容器的流量从而实现对流量的控制。解决代理模式缺点的方案之一就是Proxyless，即无代理模式。其核心理念是：服务间总是要选择一种协议进行通信，就必然要依赖于该协议的类库（SDK）进行编解码工作。既然如此，那么将协议的类库扩展，使其具有流量控制的能力，不就能代替Sidecar代理了吗？且SDK和应用同属于同一进程，必然有更优秀的性能表现，Sidecar最为诟病的延迟问题也会迎刃而解。
2021年Istio官方博客发表了一篇基于gRPC实现Proxyless的文章，详细阐述了其工作原理以及如何在Istio中使用它。如下图所示，在这种模式中，核心的流控能力被集成在gRPC库中，不再使用代理进行数据面通信。但它仍然需要一个Agent进行初始化并与控制平面交互，负责告知gRPC库如何连接到istiod，如何获取证书，并作为xDS代理，代表应用与istiod进行连接和认证。
相比通过进程外通信的Sidecar代理来说，Proxyless具有如下明显的优势：
性能：Proxyless模式是进程内、点对点的直接通信，网络延迟比代理要小得多。
稳定性：SDK类库与应用共享单一进程，拓扑结构简单，调试方便，消除了跨进程的调用，稳定性更高。
框架集成：对于传统的基于SDK实现的服务治理框架，如果集成了Proxyless模式，即能够复用框架现有的能力。
资源消耗低：无独立的Sidecar容器，内置类库资源消耗低。
从官方博客给出的数据来看，gRPC Proxyless模式下的延迟情况接近基准测试，资源消耗也相对较低。
读者可能已经发现，所谓Proxyless其实和传统的SDK并无二致，只是将流控能力内嵌到负责通信协议的类库中，因此它具有和传统SDK服务框架相同的缺点：
语言绑定：需要开发多种语言的SDK
侵入性：进程内类库，需编译到应用程序及侵入代码。
也正因为如此，业内很多人认为Proxyless本质上是一种倒退，是回归到传统的方式去解决服务通信的问题。笔者认为，软件设计的主要活动就是取舍，不存在一种完美的方案能解决所有问题。但不管怎样，服务网格领域的开发者们仍旧在探索和推动产品的演进，这才是我们最希望看到的结果。
Sidecarless 模式
如果说Sidecar是主流的服务网格架构形态的集大成者，围绕着Sidecar的夺位之争也在持续上演。既然有了去代理模式，那又何妨多个去边车模式？这就是所谓的Sidecarless，也叫Sidecar-free。2022年Cilium基于ebpf技术发布了具有服务网格能力的产品。Cilium的服务网格产品提供了两种模式，对于L3/L4层的能力直接由ebpf支持，L7层能力由一个公共的代理负责，以DaemonSet方式部署。
Cilium认为，内核加上共享型代理的引入可以极大的减少代理的数量，从而降低资源消耗和维护成本。而在内核层面进行通信管理也提高了性能。
但同样，软件领域没有银弹，Sidecarless也是取舍后的结果。ebpf并不是万能钥匙，也存在内核版本要求、编写难度大、安全等方面的问题。Linkerd创始人William Morgan还总结了共享型代理存在的一些缺点：
资源管理不可评估：取决于集群中Node数量
隔离性：所有应用共用同一个代理，应用的稳定性可能会受到影响
爆炸半径变大：会影响整个Node节点的Pod
安全问题更复杂：比如代理会保存整个Node节点的秘钥。
依笔者愚见，基于ebpf的服务网格在设计思路上其实和Proxyless如出一辙，即找到一个非Sidecar的地方去实现流量控制能力。它们一个是基于通信协议类库，一个是基于内核的扩展性。ebpf通过内核层面提供的可扩展能力，在流量经过内核时实现了控制、安全和观察的能力，从而构建出一种新形态的服务网格。
Ambient Mesh
2022年9月Istio发布了一个名为“Ambient Mesh”的无边车数据平面模型，宣称用户可以弃用Sidecar，以Ambient Mesh模式使用Istio的特性。Ambient Mesh将Istio的功能分为两层，安全覆盖层用来处理L4层的路由和安全。如果需要，用户可以启用L7处理层从而使用更全面的功能特性。在这一点上它和Cilium的做法类似。
下图中ztunnel即为安全覆盖层，以DaemonSet部署，本质上是一个处理L4层场景的共享代理。图中的Waypoint代理以Pod形态部署于集群中，可使用Istio处理L7网络的完整能力。
我们可以将Ambient Mesh也看做是一种Sidecarless模式，但笔者更愿意将其称之为中心化代理模式，因为其核心思路是通过共享的、中心化的代理实现流量控制，从而代替应用容器旁的Sidecar代理。不过用户依然可以根据需要同时启用Ambient Mesh和Sidecar，因为它们的关系是互补而不是互斥的。
从官方的博客来看，Istio在过去的半年中一直在推进Ambient Mesh的开发，并于2023年2月将其合并到了Istio的主代码分支。这也从一定程度上说明Istio未来的发展方向之一就是持续的对Ambient Mesh改进并探索多种数据平面的可能性。
未来的主角
经过6年多的发展，服务网格已经迈进了早期主流（early majority）技术的行列。借助于新技术和新思路的不断涌现，架构形态也从最初的Sidecar模式变的更加多样化。我们现在很难定论谁会成为最终的胜利者，毕竟各个模式都存在优劣点，都有自己更适合的应用场景。也许服务网格也和程序设计语言一样，并不会出现统一的局面，而是在不断的自我完善中提供给用户更多的选择。
欢迎阅读《Istio最佳实战》一书了解更多相关内容。
发布：刘恩惠
审核：陈歆懿