服务网格 2021 年终盘点:实用当先,生态为本

标签: 服务 网格 盘点 | 发表时间:2022-01-11 17:16 | 作者:
出处:https://jimmysong.io/blog/

随着服务网格架构理念的深入人心,它的适用场景也慢慢为众人所了解,社区中也不乏争论,甚至是质疑的声音。笔者以在云原生和服务网格社区中多年的观察,将从亲历者的角度总结服务网格在 2021 年的进展。因为当前在国内 Istio 几乎是服务网格的代名词,本文也将主要从 Istio 的技术和生态层面来解读服务网格在 2021 年的发展。

服务网格:云原生的核心技术之一

作为 CNCF 定义的云原生关键技术之一,服务网格发展至今已经有五个年头了,其发展经历了以下几个时期:

  • 探索阶段:2017 年-2018 年
  • 早期采用者阶段:2019 年-2020 年
  • 大规模落地及生态发展阶段:2021 年至今

如果根据 “跨越鸿沟”理论,服务网格已经跨越了“鸿沟”,处于“早期大众”和“晚期大众”阶段之间。根据 《Istio 大咖说》观众中的反馈来看,用户已不再盲从于新技术,开始辩证的考虑 是否真的需要引入服务网格

跨越鸿沟理论

云原生的发展方兴未艾,虽然不断有新的技术和产品出现,但作为整个云原生技术栈的一部分,服务网格在过去一年里不断夯实了它作为“云原生网络基础设施”的定位。下图展示了云原生技术栈模型,其中每一层有一些代表性的技术来定义标准。作为新时代的中间件,服务网格与其他云原生技术交相辉映,如 Dapr(分布式应用程序运行时)定义云原生中间件的能力模型,OAM 定义云原生应用程序模型等,而服务网格定义的是云原生七层网络模型。

云原生技术栈

图:云原生技术栈

社区焦点

过去一年中,社区的焦点主要集中在以下几个方面:

  • 性能优化:服务网格在大规模应用场景下的性能问题;
  • 协议扩展:让服务网格支持任意七层网络协议;
  • 部署模式:Proxyless vs Node 模式 vs Sidecar 模式;
  • 引入 eBPF:将服务网格的部分能力下沉到内核层;

性能优化

Istio 设计之初的目标就是通过“原协议转发”的方式服务于服务间流量,让服务网格尽可能对应用程序“透明”,从而使用了 IPtables 劫持流量,根据 社区提供的测试结果,对于在 16 个连接上具有 1000 RPS 的网格,Istio 1.2 仅增加了 3 毫秒的基准延迟。但是,因为 IPtables conntrack 模块所固有的问题,随着网格规模的扩大,Istio 的性能问题开始显现。关于 Istio sidecar 的资源占用及网络延迟的性能优化,社区给出了以下解决方案:

  • Sidecar 配置:通过手动或在控制平面增加一个 Operator 的方式来配置服务的依赖项,可以减少向 Sidecar 中下发的服务配置数量,从而降低数据平面的资源占用;为了更加自动和智能地配置 Sidecar,开源项目 SlimeAeraki 都给出了各自的配置懒加载方案;
  • 引入 eBPF:eBPF 可以作为优化服务网格性能的一种可行性方案,有基于 Cilium 的初创公司甚至激进的提出 使用 eBPF/Cilium 完全替换 Sidecar 代理的策略,但事实上 Envoy 代理/xDS 协议已经成为服务网格实现的实际代理,且很好的支持七层协议。eBPF 可用来改善网络性能,但复杂的协议协商、解析和用户扩展在用户侧依然很难实现。

协议扩展

如何扩展 Istio 一直以来就是一个老大难的问题。Istio 的可扩展包含两方面:

  • 协议层面:让 Istio 支持所有七层协议
  • 生态层面:让 Istio 可以运行更多的插件

Istio 使用的是 Envoy 作为数据平面,扩展 Istio 本质上就是对 Envoy 功能的扩展。Istio 官方目前给出的方案是使用 WebAssembly,并在 Istio 1.12 引入 Wasm 插件配置 API 用于扩展 Istio 生态,Istio 的扩展机制使用 Proxy-Wasm 应用二进制接口(ABI)规范,提供了一套代理无关的流媒体 API 和实用功能,可以用任何有合适 SDK 的语言来实现。截至目前,Proxy-Wasm 的 SDK 有 AssemblyScript(类似 TypeScript)、C++、Rust、Zig 和 Go(使用 TinyGo WebAssembly 系统接口)。

目前 WebAssembly 扩展应用还比较少,很多企业选择自定义 CRD,基于 Istio 构建服务网格管理平面。另外,让 Istio 支持异构环境,适用于一切工作负载,如虚拟机、容器,这个对于终端用户来说也有很强的需求,因为这可以让用户很方便的从传统负载迁移应用到服务网格中。最后是多集群、多网格的混合云流量管理,这个属于比较高阶的需求了。

部署模式

在服务网格概念兴起之初就有 Per-node 和 Sidecar 模式之争,他们的代表分别是 Linkerd 和 Istio。后来 eBPF 提出将服务网格下沉的内核,从而演化出了更多的服务网格部署模式,如下图所示。

服务网格的部署模式

图:服务网格的部署模式

下表中详细对比了这四种部署方式,它们各有优劣,具体选择哪种根据实际情况而定。

模式 内存开销 安全性 故障域 运维
Sidecar 代理 因为为每个 pod 都注入一个代理,所以开销最大。 由于 sidecar 必须与工作负载一起部署,工作负载有可能绕过 sidecar。 Pod 级别隔离,如果有代理出现故障,只影响到 Pod 中的工作负载。 可以单独升级某个工作负载的 sidecar 而不影响其他工作负载。
节点共享代理 每个节点上只有一个代理,为该节点上的所有工作负载所共享,开销小。 对加密内容和私钥的管理存在安全隐患。 节点级别隔离,如果共享代理升级时出现版本冲突、配置冲突或扩展不兼容等问题,则可能会影响该节点上的所有工作负载。 不需要考虑注入 Sidecar 的问题。
Service Account/节点共享代理 服务账户/身份下的所有工作负载都使用共享代理,开销小。 工作负载和代理之间的连接的认证及安全性无法保障。 节点和服务账号之间级别隔离,故障同“节点共享代理”。 同“节点共享代理”。
带有微代理的共享远程代理 因为为每个 pod 都注入一个微代理,开销比较大。 微代理专门处理 mTLS,不负责 L7 路由,可以保障安全性。 当需要应用7层策略时,工作负载实例的流量会被重定向到L7代理上,若不需要,则可以直接绕过。该L7代理可以采用共享节点代理、每个服务账户代理,或者远程代理的方式运行。 同“Sidecar 代理”。

表:服务网格的部署模式

生态发展

2021 年,Istio 社区也是精彩纷呈,举办了系列的活动,还发布了系列教程:

此外还有众多与 Istio 服务网格相关的项目开源,如下表所示。

项目名称 开源时间 类别 描述 主导公司 Star 数量 与 Istio 的关系
Envoy 2016年 9 月 网络代理 云原生高性能边缘/中间服务代理 Lyft 18700 默认的数据平面
Istio 2017 年 5 月 服务网格 连接、保护、控制和观察服务。 Google 29100 控制平面
Linkerd2 2017 年 12 月 服务网格 适用于 Kubernetes 的轻量级服务网格。 Buoyant 7900 服务网格的另一种实现
Emissary Gateway 2018 年 2 月 网关 用于微服务的 Kubernetes 原生 API 网关,基于 Envoy 构建 Ambassador 3600 可连接 Istio
APISIX 2019 年 6 月 网关 云原生 API 网关 API7 8100 可作为 Istio 的数据平面运行也可以单独作为网关
MOSN 2019 年 12 月 代理 云原生边缘网关及代理 蚂蚁 3500 可作为 Istio 数据平面
Slime 2021 年 1月 扩展 基于 Istio 的智能服务网格管理器 网易 236 为 Istio 增加一个管理平面
Tetrate Istio Distro 2021 年 2 月 工具 Istio 集成和命令行管理工具 Tetrate 95 第一个 Istio 开源发行版和多版本管理工具
Aeraki 2021 年 3 月 扩展 管理 Istio 的任何七层负载 腾讯 330 扩展多协议支持
Layotto 2021 年 6 月 运行时 云原生应用运行时 蚂蚁 393 可以作为 Istio 的数据平面
Hango Gateway 2021 年 8 月 网关 基于 Envoy 和 Istio 构建的 API 网关 网易 253 可与 Istio 集成

注:数据统计截止到 2022 年 1 月 6 日。

总结

回望 2021 年,我们可以看出用户对服务网格的追求更趋实用,作为云原生网络的基础设施,其地位得到进一步夯实,更重要的是服务网格生态渐起。展望 2022 年,有两个值得关注的技术是 eBPF 和 WebAssembly。我们有理由相信,更多的服务网格实践优秀案例出现,在生态和标准化上更进一步。

参考

相关 [服务 网格 盘点] 推荐:

服务网格 2021 年终盘点:实用当先,生态为本

- - Jimmy Song - 云原生|开源|社区 – 博客
随着服务网格架构理念的深入人心,它的适用场景也慢慢为众人所了解,社区中也不乏争论,甚至是质疑的声音. 笔者以在云原生和服务网格社区中多年的观察,将从亲历者的角度总结服务网格在 2021 年的进展. 因为当前在国内 Istio 几乎是服务网格的代名词,本文也将主要从 Istio 的技术和生态层面来解读服务网格在 2021 年的发展.

手机LBS位置服务盘点

- bluesnail - 月光博客
  位置服务(LBS,Location Based Services)指的是通过移动终端和移动网络的配合,确定移动用户的实际地理位置,从而提供用户与位置相关的服务信息.   在美国,Foursquare为代表的以用户主动签到(check-in)为核心的位置签到服务(Location Check-in Service)重新定义了位置服务的内涵,掀起了新一轮移动互联网产业发展热潮,即以位置签到为核心的垂直型位置签到服务企业快速涌现并迅速发展,国内社交网站和微博服务提供商也纷纷更新移动互联网产品,以下月光博客将对国内外较为知名的位置服务进行一些盘点.

替代 Apache 和 IIS 的轻量级网络服务器盘点

- Shearer - 开源中国社区最新新闻
说起当今的网络服务器,我想大家对Apache和IIS不会陌生,一般对于Windows的操作系统来说用的IIS比较多,而对于Linux来说,Apache 会占有比较大的优势. 但是,出色的网络服务器可并不只有Apache和IIS. 事实上,性能卓越,堪比Apache和IIS的其他网络服务器还有很多. 这 篇文章给大家介绍五款可以替代Apache和IIS的轻量级网络服务器.

4个步骤排查istio服务网格的网络问题

- - DockOne.io
对 istio 用户而言,最常见的场景之一是将 istio 用作 ingress 网关,通过其暴露微服务给外部客户端访问. 一种是只运行业务服务的容器,不携带 sidecar. 另一种是运行携带 sidecar 的 Pod,业务服务和 ingress 网关之间建立 mTLS 双向认证进行通信. 最近,笔者帮一位 istio 用户排查问题:为什么通过 istio ingress 网关暴露的服务不能被 istio 网格外部的 CURL 客户端访问到.

如何利用Rancher和Kong实现服务网格?

- - DockOne.io
服务网格(Service mesh)是当前新兴的架构模式,越来越受到人们的青睐. 与Kubernetes一起,服务网格可以形成一个强大的平台,它可以解决在微服务集群或服务基础设施上发现的高度分布式环境中出现的技术需求. 服务网格是一个专门的基础设施层,用于促进微服务之间的服务到服务通信. 服务网格解决了基于微服务的应用中典型的通信需求,包括加密隧道、健康检查、断路器、负载均衡以及流量许可.

Kong 开源的的服务网格Kuma爬过了K8S这座大山

- -
2019年9月10日,Kong正式宣布开源一款Service Mesh:Kuma. 此消息一出,立即在云原生社区引起反响,各大媒体争相报道. 让我们跟随SDxCentral的总编辑,一起来看看Kong的CTO如何介绍Kuma这款Service Mesh产品以及对于SMI的看法. 关于Kuma的具体功能介绍可以阅读官网博客以及Github.

服务禁语

- tiancaicai - 白板报
前几天在一个公交汽车站拍到了一张规定,里面规定了服务禁语和礼貌用语,看了大乐. 3、乘车高峰车厢内拥挤时,禁语:“快往里走,站在前面又没有钞票检. ”文明语:“请尽量往里走,照顾没有上车的乘客”. 4、车子抛锚,禁语:“车子抛锚没有办法,人都要生毛病的,车子坏了也正常. ”文明语:“对不起,车子出现故障修一下,请大家理解.

服务熔断

- - CSDN博客推荐文章
服务熔断也称服务隔离,来自于Michael Nygard 的《Release It》中的CircuitBreaker应用模式,Martin Fowler在博文 CircuitBreaker中对此设计进行了比较详细说明. 本文认为服务熔断是服务降级的措施. 服务熔断对服务提供了proxy,防止服务不可能时,出现串联故障(cascading failure),导致雪崩效应.

iPhone音乐应用盘点

- hama - 月光博客
  苹果iPhone系列手机强大的功能与时尚的外观早已成为人们关注的焦点,而其最具特色的内置iPod音乐播放器也是很多人选购它的理由之一.   说到iPod音乐播放器相信各位也都非常了解,而其作为iPhone的默认音乐播放工具也还算中规中矩,可以满足大众的基本需求. 然而,对于很多音乐爱好者来说,内置iPod功能过于简单,并不能满足用户对于音乐应用的需求.

2010年年终盘点

- lee - 狂人山庄 | Silence,声仔,吴洪声,奶罩
时间过得太快了,我到现在还活在2010年,每次写日期的时候都写错,时间总不够用. 今年发生很多事情,以至于来不及记录. 不过至少说明我一直在干活,没有闲着. 总体来说今年一年的情况还是不错的. 从去年底到今年初,公司上下都在补课,把前几年快速发展所遗留下来的问题都解决了. 自己开发了高性能的DNS服务器软件,把BIND替换了,还开发了攻击防御模块.