Menu

  • Home
  • Work
    • Cloud
      • Virtualization
      • IaaS
      • PaaS
    • Java
    • Go
    • C
    • C++
    • JavaScript
    • PHP
    • Python
    • Architecture
    • Others
      • Assembly
      • Ruby
      • Perl
      • Lua
      • Rust
      • XML
      • Network
      • IoT
      • GIS
      • Algorithm
      • AI
      • Math
      • RE
      • Graphic
    • OS
      • Linux
      • Windows
      • Mac OS X
    • BigData
    • Database
      • MySQL
      • Oracle
    • Mobile
      • Android
      • IOS
    • Web
      • HTML
      • CSS
  • Life
    • Cooking
    • Travel
    • Gardening
  • Gallery
  • Video
  • Music
  • Essay
  • Home
  • Work
    • Cloud
      • Virtualization
      • IaaS
      • PaaS
    • Java
    • Go
    • C
    • C++
    • JavaScript
    • PHP
    • Python
    • Architecture
    • Others
      • Assembly
      • Ruby
      • Perl
      • Lua
      • Rust
      • XML
      • Network
      • IoT
      • GIS
      • Algorithm
      • AI
      • Math
      • RE
      • Graphic
    • OS
      • Linux
      • Windows
      • Mac OS X
    • BigData
    • Database
      • MySQL
      • Oracle
    • Mobile
      • Android
      • IOS
    • Web
      • HTML
      • CSS
  • Life
    • Cooking
    • Travel
    • Gardening
  • Gallery
  • Video
  • Music
  • Essay

服务网格的现状和未来

13
Apr
2020

服务网格的现状和未来

By Alex
/ in PaaS
/ tags ServiceMesh
0 Comments
引言

服务网格(Service Mesh)是一种微服务治理基础设施,用于控制、监测微服务之间的东西向流量。它通常由控制平面、数据平面两部分组成。其中数据平面就是伴随着业务应用部署的网络代理,控制平面则是一组独立的组件,和数据平面交互,发送控制网络流量的规则,接收各类监测指标。业务应用的开发人员对服务网格的存在并无感知,这是服务网格最关键的优势。

服务网格的概念出现于2010年代早期,2017年前后开始风行。从ServiceMesher社区在2020年2月发起的终端用户调研结果来看,在生产环境下使用该技术的公司占比不到15%,大部分公司仍然在观望:

service-mesh-usage

是什么原因阻碍了服务网格的大面积应用,它的未来会如何?本文将从主要从技术角度来细化分析。

现状和问题
社区发展情况

Kubernetes早已成为容器编排领域的事实标准,主流服务网格框架都选择构筑在Kubernetes之上。Kubernetes和服务网格是相辅相成的,尽管功能上有些许重叠。Kubernetes主要专注于应用的部署,服务网格更关注应用的运行时管理。

目前占据着领导地位的服务网格框架是Istio + Envoy的组合。早期的Linkerd运行在JVM之上,资源消耗较高,已经被Linkerd 2所取代。Linkerd 2的进展不尽如人意,支持的特性比Istio要少很多。国内的参与者,包括阿里的SOFAMesh、华为的ASM等,这些框架一部分没有开源,另一部分更新较为缓慢,SOFAMesh的代码库2020年尚未有新代码合并到主干。

从ServiceMesher社区在2020年2月发起的终端用户调研结果来看,Istio和Envoy是用户关注度最高的服务网格开源项目:

focused-service-mesh-tech

要打造自研服务网格产品,理性的方案是以一种成熟的社区技术为基础,这是因为服务网格牵涉到的技术面很广,从零开发的成本非常高。目前来看,Istio + Envoy是较好的选择,包括AWS App Mesh、F5 Aspen Mesh等商业方案都是在Istio / Envoy的基础上进行深入定制实现的。

标准化问题

2019年5月,微软联合一系列厂商发布了一个服务网格规范(Service Mesh Interface,SMI),它是一个基于Kubernetes的服务网格接口标准,致力于实现不同服务网格框架的互操作性。

巨头们早已看到了服务网格的价值,并且纷纷出手,支持或参与开源项目,推出自己的商业产品。百花齐放的服务网格产品,接口不一致,必然会导致供应商锁定问题,一旦选择了某个厂商的服务网格产品,你将很难切换到另一家。SMI需要解决的就是供应商锁定问题,微软、Vmware、HashiCorp、F5等都加入了SMI阵营。遗憾的是,社区的领头羊,Istio阵营的Google、IBM等却对SMI不感兴趣,个中利益纷争耐人寻味。

标准化的分歧,的确会导致技术选型相关的风险,因为我们难以准确判断中长期的技术方向。为了规避这类风险,自研服务网格产品应该面向上层应用暴露技术中立的API,避免在API上和某种服务网格实现耦合。

遗留技术

我已经在多个团队中目睹推行服务网格甚至是Kubernetes时遇到强大的阻力,原因是这些团队已经在使用“等位”技术,而且工作的不错。

这种阻力在以Java为单一技术栈的公司/团队中尤为明显。Java生态圈一直非常繁荣,自成体系。特别是Spring Cloud项目提供了服务发现、负载均衡、内容感知路由等特性,这些正和Kubernetes、Istio存在功能重叠,导致技术迁移的动力不足。

在决定引入服务网格技术之前,首先要确信自己的团队的确需要它。对于规模很小的公司/团队,答案往往是否。答案反转的一个重要的契机是,你提供的服务需要被别的团队所消费,且这个团队和你使用不一样的技术栈,例如使用Go而非Java。

另外需要注意一点,Spring Cloud和Kubernetes并非水火不容,它不但可以容器化部署在Kubernetes上,改用Kubernetes作为服务发现机制也非常简单。 事实上,Spring背后的VMware是云原生领域的重要参与者,Spring Cloud对Kubernetes的集成能力也在不断提高。服务网格属于PaaS层而非应用级的解决方案,它和Spring Cloud这类框架可以长期共同存在,平滑迁移。

服务网格的边缘代理,则又和API网关存在功能上的重叠。前些年在Kubernetes尚未普遍应用的时候,很多互联网开发团队就在自研API网关产品。我的建议是,现有的API网关产品可以继续使用,如果团队已经全面转向云原生,则不要新造轮子,可以基于Envoy构建API网关。

性能问题

Istio的架构,在1.0版本之后已经经过多次重大调整,以平衡架构的优雅性和性能。1.1版本进一步微服务化,分离了 Pilot 的配置下发功能到新的 Galley 组件中,将 Mixer 组件中原本进程内插件改为进程外插件,这一版本加剧了性能问题。随后的版本又开始180度转弯,放弃架构之美,追求性能和实用。到1.5版本为止,Mixer已经废弃,遥测功能下沉到Envoy代理中,控制平面变成一个单体的istiod:

istiod-archeture

即使是在禁用Mixer,仅仅启用最基础的流量管理功能的情况下,Envoy引入的性能开销仍然需要关注。对于规模很大的命名空间,Envoy占用的内存会比较可观,甚至大于被代理的微服务本身。使用Istio提供的Sidecar CRD,可以对代理进行细粒度配置,很大程度上降低内存消耗。

在服务网格内部,每个请求都要经由一个客户端代理、一个服务端代理。在Istio 1.5版本的默认配置下的基准测试中,客户端代理的P99延迟大约为2.8ms,服务端代理的P99延迟大约为2.7ms,也就是一次微服务调用会可能会引入5.5ms的延迟。如果调用链比较复杂,引入的总延迟可能达到数十毫秒。大部分场景下,这样的延迟不是问题,但对于一些本身响应时间很短的HTTP服务,影响就难以忽略了。

Istio数据平面引入的延迟,主要有三个来源:

  1. 代理本身的逻辑:L7代理逻辑较为复杂,执行这些逻辑需要CPU时间。如果扩展了自定义的过滤器,这些过滤器的性能很关键
  2. 流量重定向:Istio使用iptables重定向拦截Pod的全部流量给Enovy处理,这种重定向需要多次遍历TCP/IP栈,单次拦截可能引入0.3ms左右的延迟。基于Socket感知的BPF程序,例如Cilium CNI,可以消除这一延迟,但是对内核版本有要求
  3. 网络传输:不管是否引入代理,网络传输导致的延迟都存在。但是代理给我们带来了降低延迟的契机。QUIC可以代替TCP作为HTTP的底层协议,它具有更好的拥塞控制、多路复用、前向纠错、链接迁移特性,在网格的边缘这些特性具有显著的优势。Envoy已经逐步加入对QUIC的支持,当实现了QUIC Termination后,就能透明的将业务应用流量的底层传输协议更换为QUIC,提升性能
可扩展性

Envoy基于C++开发,扩展它需要编写自定义的过滤器。2019年12月进入W3C推荐标准的WebAssembly(Wasm)改变了这一状况。Wasm是一套可移植的字节码格式,你可以将任何主流语言编写的代码编译为Wasm字节码。Envoy现在已经能够支持Wasm Filter,这意味着扩展Envoy,和团队现有的系统进行集成,不会再遇到编程语言上的障碍,也不需要重新部署新版本的Enovy二进制文件。

尽管尚未合并到主干,Istio 1.5版本附带的Envoy,已经包含了Alpha版本的Wasm Filter支持。

Istio的开发语言是Go,经典的扩展方式是Mixer插件,如今这种方式已经被废弃。 Mixer的两大功能,Check和Report,将分别由Proxy-Wasm plugins和Telemetry V2代替。Proxy-Wasm是一套ABI规范,规定了Envoy这样的L4/L7代理软件如何和它们的Wasm扩展进行交互。Istio 1.6将提供Proxy-Wasm plugins的统一配置API。 

可观察性

服务网格的可观察性有三个方面的内容:日志收集、分布式追踪、指标收集。

日志收集仍然是基于EFK/ELK这样的集中化日志解决方案。Envoy代理可以提供完善的访问日志,收集这些日志后,可以在ElasticSearch中检索和分析。

指标收集,粒度可以细致到微服务级别,这个从设计上来说是刻意的,因为服务网格中的服务,就是指微服务。遗憾的是,很多业务应用并没有按照微服务的理念进行设计,单个服务提供了太多的职责。这样的服务出现了问题,在网格拓扑图上只能进行模糊的定位。另一方面,Envoy支持的协议仍然很少,HTTP、WebSocket、gRPC被支持的很好,Redis、MySQL、ZooKeeper、Dubbo、Kafka目前获得了一定的支持,其它的协议目前Enovy都不能理解,只能看作是原始的L4流量。无法理解协议,也就不能收集有价值的指标,并展现在网格拓扑图上。

应用层协议过于繁多,每种协议还可能有多个版本,要支持这么多协议的确是个苦差。但是在自研服务网格的产品时,我们只需要关注团队经常用到的协议,针对它们进行解析就足够了。

对于分布式追踪,Istio能够自动添加必要的请求头,以便在微服务之间传递Trace ID、Span ID、Parent ID,并且,Istio会将这些信息上报给分布式追踪系统。 但是,Istio能做的也仅仅是这些了,对于单个微服务来说,还得依靠开发人员把入站请求中的Trace ID传递给出站请求。

通用的、零入侵的自动传递调用链上下文的解决方案,在技术上是不可能实现的。因为各种编程语言具有不同的线程模型、运行时架构,无法单纯的从网络流量中分析出足够的信息。某些语言,可以几乎没有入侵的自动传递调用链上下文,例如Java,可以通过Java Instrumentation来穷举式的拦截各种流行的客户端库,自动传递调用链信息。另外一些语言,则只能编写代码传递。 

未来之路

经过上文的分析,我们了解到服务网格技术仍然存在一定的不足。在标准化方面,云厂商巨头们竞争激烈,这为我们带来了技术选型的风险。由于功能类似的遗留技术的存在,导致服务网格技术推广起来遇到阻力。此外,在性能、可扩展性、可观察性等非功能因素方面,现有主流服务网格开源项目存在不尽如人意的地方。

不过,我们应当看到社区的繁荣发展,开源项目的不断进步,以及服务网格具有的,不可替代的技术优势。

以Istio为例,它的性能自发布以来已经有了长足的进步,代理的P99延迟从数十ms降为10ms,进一步降低到5ms级别,已经能满足绝大部分场景的需求。如果需要进一步降低延迟,可以考虑BPF和QUIC等技术。

零入侵是服务网格不可替代的技术优势,这种优势在大型企业中更加明显。大型企业会有很多开发团队,使用不同的技术栈,Spring Cloud这种入侵式、绑定到JVM语言的解决方案显然是不可取的。微服务甚至是无服务是可预见的趋势,相对笨重的JVM并不十分适合这种应用场景,将企业的技术栈锁死在JVM甚至是Spring Cloud不是明智的选择。

服务网格领域仍然有大量的事情等待人们去做,比如各种中间件协议的解析、提升边缘节点性能的QUIC Termination、智能化的灰度发布平台,等等。自研服务网格产品,对内提升服务治理水平,对外输出社区影响力,现在就是很好的契机。

← 如何在Pod中执行宿主机上的命令
从镜像中抽取文件 →

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Related Posts

  • Istio Mixer与Envoy的交互机制解读
  • Istio学习笔记
  • Istio Pilot与Envoy的交互机制解读
  • 扩展Envoy
  • 通过WebAssembly扩展Envoy

Recent Posts

  • Investigating and Solving the Issue of Failed Certificate Request with ZeroSSL and Cert-Manager
  • A Comprehensive Study of Kotlin for Java Developers
  • 背诵营笔记
  • 利用LangChain和语言模型交互
  • 享学营笔记
ABOUT ME

汪震 | Alex Wong

江苏淮安人,现居北京。目前供职于腾讯云,专注容器方向。

GitHub:gmemcc

Git:git.gmem.cc

Email:gmemjunk@gmem.cc@me.com

ABOUT GMEM

绿色记忆是我的个人网站,域名gmem.cc中G是Green的简写,MEM是Memory的简写,CC则是我的小天使彩彩名字的简写。

我在这里记录自己的工作与生活,同时和大家分享一些编程方面的知识。

GMEM HISTORY
v2.00:微风
v1.03:单车旅行
v1.02:夏日版
v1.01:未完成
v0.10:彩虹天堂
v0.01:阳光海岸
MIRROR INFO
Meta
  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org
Recent Posts
  • Investigating and Solving the Issue of Failed Certificate Request with ZeroSSL and Cert-Manager
    In this blog post, I will walk ...
  • A Comprehensive Study of Kotlin for Java Developers
    Introduction Purpose of the Study Understanding the Mo ...
  • 背诵营笔记
    Day 1 Find Your Greatness 原文 Greatness. It’s just ...
  • 利用LangChain和语言模型交互
    LangChain是什么 从名字上可以看出来,LangChain可以用来构建自然语言处理能力的链条。它是一个库 ...
  • 享学营笔记
    Unit 1 At home Lesson 1 In the ...
  • K8S集群跨云迁移
    要将K8S集群从一个云服务商迁移到另外一个,需要解决以下问题: 各种K8S资源的迁移 工作负载所挂载的数 ...
  • Terraform快速参考
    简介 Terraform用于实现基础设施即代码(infrastructure as code)—— 通过代码( ...
  • 草缸2021
    经过四个多月的努力,我的小小荷兰景到达极致了状态。

  • 编写Kubernetes风格的APIServer
    背景 前段时间接到一个需求做一个工具,工具将在K8S中运行。需求很适合用控制器模式实现,很自然的就基于kube ...
  • 记录一次KeyDB缓慢的定位过程
    环境说明 运行环境 这个问题出现在一套搭建在虚拟机上的Kubernetes 1.18集群上。集群有三个节点: ...
  • eBPF学习笔记
    简介 BPF,即Berkeley Packet Filter,是一个古老的网络封包过滤机制。它允许从用户空间注 ...
  • IPVS模式下ClusterIP泄露宿主机端口的问题
    问题 在一个启用了IPVS模式kube-proxy的K8S集群中,运行着一个Docker Registry服务 ...
  • 念爷爷
      今天是爷爷的头七,十二月七日、阴历十月廿三中午,老人家与世长辞。   九月初,回家看望刚动完手术的爸爸,发

  • 6 杨梅坑

  • liuhuashan
    深圳人才公园的网红景点 —— 流花山

  • 1 2020年10月拈花湾

  • 内核缺陷触发的NodePort服务63秒延迟问题
    现象 我们有一个新创建的TKE 1.3.0集群,使用基于Galaxy + Flannel(VXLAN模式)的容 ...
  • Galaxy学习笔记
    简介 Galaxy是TKEStack的一个网络组件,支持为TKE集群提供Overlay/Underlay容器网 ...
TOPLINKS
  • Zitahli's blue 91 people like this
  • 梦中的婚礼 64 people like this
  • 汪静好 61 people like this
  • 那年我一岁 36 people like this
  • 为了爱 28 people like this
  • 小绿彩 26 people like this
  • 彩虹姐姐的笑脸 24 people like this
  • 杨梅坑 6 people like this
  • 亚龙湾之旅 1 people like this
  • 汪昌博 people like this
  • 2013年11月香山 10 people like this
  • 2013年7月秦皇岛 6 people like this
  • 2013年6月蓟县盘山 5 people like this
  • 2013年2月梅花山 2 people like this
  • 2013年淮阴自贡迎春灯会 3 people like this
  • 2012年镇江金山游 1 people like this
  • 2012年徽杭古道 9 people like this
  • 2011年清明节后扬州行 1 people like this
  • 2008年十一云龙公园 5 people like this
  • 2008年之秋忆 7 people like this
  • 老照片 13 people like this
  • 火一样的六月 16 people like this
  • 发黄的相片 3 people like this
  • Cesium学习笔记 90 people like this
  • IntelliJ IDEA知识集锦 59 people like this
  • 基于Kurento搭建WebRTC服务器 38 people like this
  • Bazel学习笔记 37 people like this
  • PhoneGap学习笔记 32 people like this
  • NaCl学习笔记 32 people like this
  • 使用Oracle Java Mission Control监控JVM运行状态 29 people like this
  • Ceph学习笔记 27 people like this
  • 基于Calico的CNI 27 people like this
Tag Cloud
ActiveMQ AspectJ CDT Ceph Chrome CNI Command Cordova Coroutine CXF Cygwin DNS Docker eBPF Eclipse ExtJS F7 FAQ Groovy Hibernate HTTP IntelliJ IO编程 IPVS JacksonJSON JMS JSON JVM K8S kernel LB libvirt Linux知识 Linux编程 LOG Maven MinGW Mock Monitoring Multimedia MVC MySQL netfs Netty Nginx NIO Node.js NoSQL Oracle PDT PHP Redis RPC Scheduler ServiceMesh SNMP Spring SSL svn Tomcat TSDB Ubuntu WebGL WebRTC WebService WebSocket wxWidgets XDebug XML XPath XRM ZooKeeper 亚龙湾 单元测试 学习笔记 实时处理 并发编程 彩姐 性能剖析 性能调优 文本处理 新特性 架构模式 系统编程 网络编程 视频监控 设计模式 远程调试 配置文件 齐塔莉
Recent Comments
  • qg on Istio中的透明代理问题
  • heao on 基于本地gRPC的Go插件系统
  • 黄豆豆 on Ginkgo学习笔记
  • cloud on OpenStack学习笔记
  • 5dragoncon on Cilium学习笔记
  • Archeb on 重温iptables
  • C/C++编程:WebSocketpp(Linux + Clion + boostAsio) – 源码巴士 on 基于C/C++的WebSocket库
  • jerbin on eBPF学习笔记
  • point on Istio中的透明代理问题
  • G on Istio中的透明代理问题
  • 绿色记忆:Go语言单元测试和仿冒 on Ginkgo学习笔记
  • point on Istio中的透明代理问题
  • 【Maven】maven插件开发实战 – IT汇 on Maven插件开发
  • chenlx on eBPF学习笔记
  • Alex on eBPF学习笔记
  • CFC4N on eBPF学习笔记
  • 李运田 on 念爷爷
  • yongman on 记录一次KeyDB缓慢的定位过程
  • Alex on Istio中的透明代理问题
  • will on Istio中的透明代理问题
  • will on Istio中的透明代理问题
  • haolipeng on 基于本地gRPC的Go插件系统
  • 吴杰 on 基于C/C++的WebSocket库
©2005-2025 Gmem.cc | Powered by WordPress | 京ICP备18007345号-2