Service Mesh年度总结:群雄逐鹿烽烟起

Abstract

2017年的Service Mesh 历程,在平淡中开始,如戏剧般结束,留给我们一个充满想象和憧憬的 2018。让我们一起来回顾这堪称精彩的一年。

Publication
InfoQ2017年度总结系列文章
Date

在过去的2016年和2017年,微服务技术得以迅猛普及,和容器技术一起成为这两年中最吸引眼球的技术热点。而以Spring Cloud为代表的传统侵入式开发框架,占据着微服务市场的主流地位,它甚至一度成为微服务的代名词。

直到2017年底,当非侵入式的Service Mesh技术终于从萌芽到走向了成熟,当Istio/Conduit横空出世,人们才惊觉:微服务并非只有侵入式一种玩法,更不是Spring Cloud的独角戏!

这一次的新生力量,完全不按照常理出牌,出场就霸道地掀翻桌子,直接摆出新的玩法:Service Mesh,下一代微服务!这一场大战,在 2017 年的最后一个月,终于上演到白热化,被摆上了台面,受到越来越多人关注。往日霸主 Spring Cloud,此时只能沦为看客。

2017年的Service Mesh历程,在平淡中开始,如戏剧般结束,留给我们一个充满想象和憧憬的2018。让我们一起来回顾这堪称精彩的一年。

Service Mesh的萌芽期

在我们正式开始2017年回顾之前,我们将时间稍微放前一点,回到2016年:有些故事背景需要预交交代一下。

虽然直到2017年底,Service Mesh才开始较大规模被世人了解,这场微服务市场之争也才显现,但是其实Service Mesh这股微服务的新势力,早在 2016年初就开始萌芽:

  • 2016年1月15日,离开twitter的基础设施工程师William Morgan和Oliver Gould,在github上发布了linkerd 0.0.7版本,他们同时组建了一个创业小公司Buoyant,业界第一个Service Mesh项目诞生。
  • 2016年,Matt Klein在Lyft默默的进行Envoy的开发。Envoy诞生的时间其实要比Linkerd更早一些,只是在Lyft内部不为人所知。

在2016年初,service mesh还只是Buoyant公司的内部词汇,而之后,它开始逐步走向社区:

  • 2016年9月29日在SF Microservices上,“Service Mesh”这个词汇第一次在公开场合被使用。这标志着“Service Mesh”这个词,从Buoyant公司走向社区。
  • 2016年10月,Alex Leong开始在buoyant公司的官方Blog中开始”A Service Mesh for Kubernetes”系列博客的连载。随着”The services must mesh”口号的喊出,buoyant和Linkerd开始service mesh概念的布道。

在这一年中,第一代的Service Mesh产品在稳步推进:

  • 2016年9月13日,Matt Klein宣布Envoy在github开源,直接发布1.0.0版本
  • 2016年下半年,Linkerd陆续发布了0.8和0.9版本,开始支持HTTP/2 和gRPC,1.0发布在即;同时,借助Service Mesh在社区的认可度,Linkerd在年底开始申请加入CNCF。

而在这个世界的另外一个角落,Google和IBM两位巨人,握手开始合作,他们联合Lyft,启动了Istio项目。这样,在第一代Service Mesh还未走向市场主流时,以Istio为代表的第二代Service Mesh就迫不及待地上路。

现在我们可以进入主题,开始2017年Service Mesh发展历程的回顾。

急转而下的Linkerd

2017年,Linkerd迎来了一个梦幻般的开局,喜讯连连:

  • 2017年1月23日,Linkerd加入CNCF
  • 2017年3月7日,Linkerd宣布完成千亿次产品请求
  • 2017年4月25日,Linkerd 1.0版本发布

可谓各条战线都进展顺利:产品完成1.0 release,达成最重要的里程碑;被客户接受并在生产线上成功大规模应用,这代表着市场的认可;进入CNCF更是意义重大,是对Linkerd的极大认可,也使得Linkerd声名大噪。一时风光无量,可谓”春风得意马蹄疾,一日看尽长安花”。

需要特别指出的是,Linkerd加入CNCF,对于Service Mesh技术是一个非常重要的历史事件:这代表着社区对Service Mesh理念的认同和赞赏,Service Mesh也因此得到社区更大范围的关注。

趁热打铁,就在Linkerd 1.0版本发布的同一天,创作者继续Service Mesh的布道:

  • 2017年4月25日,William Morgan发布博文”What’s a service mesh? And why do I need one?“。正式给Service Mesh做了一个权威定义。

然而现实总是那么残酷,这个美好的开局,未能延续多久就被击碎:

  • 2017年5月24日,Istio 0.1 release版本发布,google和IBM高调宣讲,社区反响热烈,很多公司在这时就纷纷站队表示支持Istio。

Linkerd的风光瞬间被盖过,从意气风发的少年一夜之间变成过气网红。当然,从产品成熟度上来说,linkerd作为业界仅有的两个生产级Service Mesh实现之一,暂时还可以在Istio成熟前继续保持市场。但是,随着Istio的稳步推进和日益成熟,外加第二代Service Mesh的天然优势,Istio取代第一代的Linkerd只是个时间问题。

面对google和IBM加持的Istio,linkerd实在难有胜算:

  • Istio作为第二代Service Mesh,通过控制平面带来了前所未有的控制力,远超linkerd。
  • Istio通过收编和linkerd同为第一代Service Mesh的envoy,直接拥有了一个功能和稳定性与linkerd在一个水准的数据平面(也就是作为 sidecar 模式部署的 proxy)。
  • 基于c++的envoy在性能和资源消耗上本来就强过基于Scala/Jvm的Linkerd
  • Google和IBM组合在人力,资源和社区影响力方面远非Buoyant公司这样的小公司可以比拟

Linkerd的发展态势顿时急转而下,未来陷入一片黑暗。出路在哪里?

在一个多月后,Linkerd给出一个答案:和Istio集成,成为Istio的数据面板。

  • 2017年7月11日,Linkerd发布版本1.1.1,宣布和Istio项目集成。Buoyant发表博文”Linkerd and Istio: like peanut butter and jelly”。

这个方案在意料之中,毕竟面对Google和IBM的联手威胁,选择低头和妥协是可以理解的。只是存在两个疑问:

  1. 和Envoy相比,Linkerd并没有特别优势。考虑编程语言的天生劣势,Linkerd想替代Envoy难度非常之大。
  2. 即使替代成功,在Istio的架构下,只是作为一个数据平面存在的Linkerd,可以发挥的空间有限。这种境地的Linkerd,是远远无法承载起Buoyant的未来的。

Linkerd的这个谜团,直到2017年即将结束的12月,在Conduit发布之后才被解开。

波澜不惊的Envoy

自从在2016年决定委身于Istio之后,envoy就开始了一条波澜不惊的平稳发展之路,和Linkerd的跌宕起伏完全不同。

在功能方面,由于定位在数据平面,因此Envoy无需考虑太多,很多工作在Istio的控制平面完成就好,Envoy从此专心于将数据平面做好,完善各种细节。在市场方面,Envoy和Linkerd性质不同,不存在生存和发展的战略选择,也没有正面对抗生死大敌的巨大压力。Envoy在2017年有条不紊地陆续发布了1.2、1.3、1.4和1.5版本,稳步地完善自身,表现非常稳健。

稳打稳扎的Envoy在2017年一方面继续收获独立客户,一方面伴随Istio一起成长。作为业界仅有的两个生产级Service Mesh实现之一,Envoy随后收获了属于它的殊荣:

  • 2017年9月14日,Envoy加入CNCF,成为CNCF的第二个Service Mesh项目

可谓名至实归,水到渠成。作为一个无需承载一家公司未来的开源项目,Envoy在2017年的表现,无可挑剔。

背负使命的Istio

从Google和IBM联手决定推出Istio开始,Istio就注定永远处于风头浪尖,无论成败。

Istio背负了太多的使命:

  • 建立Google和IBM在微服务市场的统治地位
  • 为Google和IBM的公有云打造杀手锏级特性
  • 在k8s的基础上,延续Google的战略布局

Google在企业市场的战略布局,是从底层开始,一步一步向上,一步一步靠近应用。刚刚大获全胜的K8s为Istio准备了一个非常好的基石,而Istio的历史使命,就是继k8s拿下容器之后,更进一步,拿下微服务

2017年,Istio稳步向前,先后发布四个版本:

  • 2017年5月24日,Istio 0.1 release版本发布
  • 2017年10月4日,Istio 0.2 release版本发布
  • 2017年11月30日,Istio 0.3 release版本发布
  • 2017年12月15日,Istio 0.4 release版本发布

在社区方面,Istio借助Google和IBM的大旗,外加自身过硬的实力、先进的理念,很快获得了社区的积极响应和广泛支持。包括Oracle和Red Hat在内的业界大佬都明确表示对支持Istio。

在平台支持方面,Istio的初期版本只支持k8s平台,从0.3版本开始提供对非k8s平台的支持。从策略上说,Istio借助了k8s,但是没有强行绑定在k8s上。

Istio面世之后,赞誉不断,尤其是Service Mesh技术的爱好者,可以说是为之一振:以新一代Service Mesh之名横空出世的Istio,对比Linkerd,优势明显。同时产品路线图上有一大堆令人眼花缭乱的功能。假以时日,如果Istio能顺利地完成开发,稳定可靠,那么这会是一个非常美好、值得憧憬的大事件,它的意义重大:

  • 重新定义微服务开发方式,让Service Mesh成为主流技术
  • 大幅降低微服务开发的入门门槛,让更多的企业和开发人员可以落地微服务
  • 统一微服务的开发流程,标准化开发/运维方式

奈何,事情的发展总是不会这么简单地如人所愿。Istio发布之后,试用中就被发现问题较多,0.1版本时还比较容易被接受,但是接下来的0.2、0.3和0.4,Istio在可用性上并没有明显的改观,导致迄今在全球范围内都几乎没有听到Istio上生产的案例,各家公司都将其停留在简单试用阶段。

此时再看Istio琳琅满目的各种功能,不禁让人疑惑Istio的产品策略:为什么一开场就将摊子铺的如此之大?以至于开发时间长达一年 (注意,虽然开源才半年多,但是开源前已经在开发),却无法得到一个稳定可用的版本。

这有悖于互联网产品的开发理念。下边这个经典图片相信大家并不陌生:

从目前情景看,Istio已经在图上“不应该”的产品迭代路径上走了一年。从5月份0.1版本发布开始,我们就满心期待,却陷入“过尽千帆皆不是”的尴尬境地:每一次新版本试用后的结果,都不理想。

身处局外,无法了解Istio项目开发的背景和真实情况,也自然无法得知为何会如此,我们只能由衷地希望,Istio能在2018年尽快完成计划中的产品开发,实现生产可用。个人意见:哪怕推迟某些特性的实现,也希望能做到主体部分尽快完善。

2018年Service Mesh的整体走势,很大程度取决于Istio:如果Istio能在2018年上半年实现生产可用,哪怕是牺牲部分高级特性,也足以推动整个Service Mesh向前大步迈进。反之如果进展不顺,市场会呈现观望和等待的态势,也会给竞争对手机会,比如说,下面将要出场的Conduit。

背水一战的Conduit

2017年底的KubeConf,在Service Mesh成为大会热点、Istio备受瞩目时,Buoyant公司出人意料地给了踌躇满志又稍显拖沓的Istio重重一击:

  • 2017年12月5日,Conduit 0.1.0版本发布,Istio的强力竞争对手亮相KubeConf。

Conduit的整体架构和Istio一致,借鉴了Istio数据平面+控制平面的设计,同时别出心裁地选择了Rust编程语言来实现数据平面,以达成Conduit 宣称的更轻、更快和超低资源占用。

继Isito之后,业界第二款第二代Service Mesh产品就此诞生。话说得有些拗口,但是一场大战就此浮出水面。Buoyant在Linkerd不敌Istio的恶劣情况下,绝地反击,祭出全新设计的Conduit作为对抗Istio的武器。

需要额外指出的是,作为一家初创型企业,在第一款主力产品Linkerd被Istio强力阻击之后,Buoyant已经身陷绝境,到了生死存亡之秋,作为背负公司期望,担负和Istio正面抗衡职责的Conduit,可谓压力巨大。

从目前得到的信息分析,Conduit明显是有备而来,针对Istio当前状况,针锋相对的:

  • 编程语言:为了达成更轻、更快和更低资源消耗的目标,考虑到Istio的数据面板用的是基于C++语言的Envoy,Conduit跳过了Golang,直接选择了Rust,颇有些剑走偏锋的意味。不过,单纯以编程语言而言,在能够完全掌握的前提下,Rust的确是做proxy的最佳选择。考虑到Envoy在性能方面的良好表现,Conduit要想更进一步,选择Rust也是可以理解。
  • 架构设计:在借鉴Istio整体架构的同时,Conduit做了一些改进。首先Conduit控制平面的各个组件是以服务的方式提供功能的,极富弹性。另外,控制平面特意为定制化需求进行了可扩展设计,可以通过编写gPRC插件来扩展Conduit的功能而无需直接修改Conduit,这对于有定制化需求的客户是非常便利的。
  • 产品演进:这是最重要的一点!Conduit完全吸取了Istio的教训,因此它的产品迭代路径会是我们最期待的方式。在本文撰写期间,笔者特意和 Conduit的CEO William深入探讨过这个话题,得到了一个非常令人欣慰的答复:++Minimal feature set,prod ready as quickly as possible++。

然而,要抗衡Istio和其身后的Google与IBM,谈何容易。Conduit2018年的发展道路,注定是充满挑战的,艰难险阻可想而知。但是,不得不佩服Buoyant公司,以及以CEO William为首的那支充满挑战精神的团队,有理想、有追求、有魄力、有勇气!期待他们在2018年的表现。

让我们回到Istio和Conduit的竞争格局。从目前局面看,Istio先天优势明显,但是产品策略上的选择给了Conduit一个难得的机会。接下来的2018年,在Conduit的威胁和刺激下,希望Istio能打起精神,给出一份令大家满意的答卷。期待Istio和Conduit能在2018年形成良性竞争,共同引领Service Mesh的大潮。

就在本文撰写之时,在2017年的最后几天,大名鼎鼎的F5 Networks公司突然放出了他们的Service Mesh类产品“Aspen Mesh”,基于Istio构建,目标“企业服务网格”。需要特别强调的是,F5在Service Mesh上的坚定决心:砍掉原有传统产品思路的项目,以内部孵化项目的方式组建独立自治团队,并在新方向上重新开始。而且在Istio才0.1版本的时候F5就做好战略决策,之后默默耕耘,其决策者的胆识令人敬佩。F5在Service Mesh这个新兴技术领域表现出积极进取的姿态,立足Istio完善企业级特性,这也是一条值得探索的路线,期待2018年Aspen Mesh的进展。

低调的参与者

2017年的Service Mesh,除了业界先驱Linkerd/Envoy,和后起之秀Istio/Conduit,还有一些其它的竞争者进入这个市场,只是它们都非常低调。

首先是nginmesh,来自大名鼎鼎的Nginx:

  • 2017年9月,在美国波特兰举行的nginx.conf大会上,nginx宣布了nginmesh。随即在github上发布了0.1.6版本。
  • 2017年12月6日,nginmesh 0.2.12版本发布
  • 2017年12月25日,nginmesh 0.3.0版本发布

nginmesh的定位是作为Istio的服务代理,也就是替代Envoy,思路和Linkerd之前和Istio集成很相似。Nginmesh在发布后的两个多月,github上提交非常少,直到最近突然发力,先后发布了0.2和0.3版本。不过Nginmesh极度低调,github上的star也只有不到100。

然后是Kong,但是这个比默默无闻的nginmesh还要更加低调,只是曾经有传闻kong有意service mesh,但是后来又没有下文。不过kong的github项目介绍里面,悄悄的加上了Service Mesh的字样:”Kong is a ××× Microservice Abstraction Layer (also known as an API Gateway, API Middleware or in some cases Service Mesh).”

在2017年,这些低调的参与者,几乎没有引起外界任何的注意,也无法预期他们在2018年会如何表现。从社区的角度,还是希望有更多的参与者进Service Mesh市场,以推动整个市场的健康发展。

快速升温的国内

2017年,随着Servic Mesh的发展,国内技术社区也开始通过新闻报道/技术文章等开始接触Service Mesh,但是传播范围和影响力都非常有限。直到年底才剧烈升温,开始被国内技术社区关注:

  • 2017年10月16日,在2017 QCon上海大会上,我做了一个”Service Mesh:下一代微服务”的演讲,成为Service Mesh技术在国内大型技术峰会上的第一次亮相。
  • 2017年11月,国内第一个Service Mesh的技术社区“Service Mesh中文网” 成立。
  • 2017年12月,在全球架构师峰会(ArchSummit)2017北京站上,来自华为的田晓亮做了名为”Service Mesh在华为云的实践”的分享。
  • 2017年12月16日,来自新浪微博的周晶做了名为”微博Service Mesh实践”的演讲,分享了Service Mesh在微博的落地情况。

此外,作为Servic Mesh国内最早的开发和实践者的华为和新浪微博,都积极参与开源。其中新浪微博Service Mesh的核心实现,跨语言通信和服务治理已经在Motan系列项目中提供,而华为也将稍后开源他们基于Golang的Service Mesh代码实现。

特别要指出的是,华为目前已经在公有云上将Service Mesh作为公共服务提供,这在国内公有云中是第一家。预计随着Service Mesh的落地和普及,公有云提供生产级别的Service Mesh服务将成为标配。在国外Google/IBM/Amazon等公有云都有提供Service Mesh的计划,相信国内公有云也会陆续跟进。

展望2018

2017年的Service Mesh市场,从Linkerd的风光无限开始,到Istio的横空出世,最后止于Conduit的绝地反击,可谓一波三折;产品也经历从第一代的Linkerd/Envoy,跨越性的演化出第二代的Istio/Conduit;同时,技术社区的态度也从年初的逐步接受发展到年底的热烈追捧,下面这张KubeConf上的图片非常有代表性地展示了社区的热切期望:

然而Service Mesh终究是一个新兴的技术,尤其作为未来主流的Istio/Conduit迄今还没有实现产品级别可用,因此2018年对Service Mesh而言,必然不是一帆风顺,必然是充满荆棘和坎坷的。如何实现从技术理念到产品落地,如何实实在在地解决实践中遇到的各种问题,将会是这一年中至关重要的事情。

衷心祝愿Istio和Conduit(也许还有其他的产品)可以在2018年快速成长,实现社区期待的功能和可用性,可以真正地实现降低微服务门槛的目标,让Service Mesh成为名副其实的下一代微服务。

2018年的Service Mesh,值得期望!

转发与赞赏

如果喜欢本文,欢迎转发,媒体转载注明出处即可。

如果特别喜欢,可以赞赏作者,请使用微信扫描: