Conduit

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

在过去的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.

山雨欲来风满楼:Service Mesh时代的选边与站队

山雨欲来风满楼 大家好,我是敖小剑,来自数人云。今天给大家带来的专题,相对来说会比较轻松一点。大家前面听到的两位的演讲都是非常有真材实料的,以及在我的下一场,周晶同学会带来一个非常有干货的Service Mesh实战的专题。我的内容会比较轻松一点,也比较好玩,主要是今天的主题比较特殊一点,因为我们选择的是“选边与站队”。OK,我们开始今天的主题。 在2017年,Servicemesh技术在快速成长。我们看到在年中的时候,Istio非常霸气的登场。如果大家有关注Service Mesh这个技术,就会知道大概10天前,Conduit这个产品突然发布了。实际上在这过去的一年当中,Servicemesh历经了非常多的事情。在经过2017年的酝酿过程后,Service Mesh技术接近一个爆发的状态。而2018年很有可能就是Service Mesh全面爆发的一年,它的目标其实就是一个:重新塑造整个微服务市场。 在今年十月份的时候,我在QCon做了一个演讲,叫“Servicemesh——下一代微服务”。这个口号十月份喊出来的时候,还是有蛮多反对的声音。有个挺有意思的事情,我一直当成玩笑来说。当时QCon在转我的演讲实录文章的时候,在我的标题后面,在”Servicemesh:下一代微服务”后面打了一个问号,那个问号是Infoq的编辑加的。我的理解是,小编觉得如果这个标题由他们发出来,可能有Infoq的印号。所以为了避嫌,在后面打了一个问号。 大概是在一个星期前,KubeConf刚刚召开,Servicemesh非常的火,而这个时候Infoq做了一个事情,把之前QCon的视频处理好了发出来。视频的标题是”Servicemesh:下一代微服务”,后面再也没有问号了。这是很小的插曲,非常深刻的表明过去的几个月当中,ServiceMesh技术快速的变化,以及大家对它认知的变化。 我们开始今天的主题,站队和选边。上面有一句话叫”新一轮的江湖厮杀又一次开始了”,有个小问题,为什么要说又字?大家觉得上一轮江湖厮杀是什么内容?我们来问一个问题,在大家的认知当中,IT领域的上一轮厮杀是谁对谁。 (备注: 现场互动,有同学指出,容器,k8s,mesos,swarm) 这场厮杀的结果如何?K8S笑到了最后。那现在开始,我们来看看新一轮的厮杀是什么样的结果。 让我们从 Buoyant 这家小公司开始。 Buoyant是一家名不见经传的小公司,但这家公司是Servicemesh的先驱,是Linkerd的公司,而Linkerd是业界第一个Servicemesh。这家是初创型的小公司,今年七月份刚拿到A轮的一千万美元融资,开发团队不到20人,我在他网站主页数了一下也就17、18个左右的样子。 创始人是两个前Twitter的基础设施工程师,CEO是William Morgan。因为融资的关系,A轮融了1000万美元,最近也在招兵买马,招了一些高手进来。这里我们单独列了一位大牛,如果大家有印象的话,他曾写了一篇文章叫《模式:Servicemesh》,那篇文章基本上是目前介绍Servicemesh最好的最经典的文章之一。大家可以看到,中间这位同学,William,这个人是它的CEO,Servicemesh全球第一个布道师: 他定义了Service Mesh,开始在全球讲Service Mesh。右图这张图是在2016年九月份第一次使用这个词汇。 但是,先驱有个问题:先驱和先烈只差一个字。一个常见的说法是:领先一步是先驱,领先两步,可能就变成先烈了。 就在linkerd和William还在布道的时候,让业界慢慢开始接受Servicemesh这个概念,发现后来,有一堆新人出来了。 新的Service mesh,在2017年,蹭蹭蹭的文莱了。第一个,Envoy,这是业界第二个Servicemesh,在今年九月份的时候,同样加入了CNCF。 Envoy还好,基本上属于同质竞争,就是大家都在一个层次上,至少还有的打。 但很不幸,istio杀出来了——大家可以看到Istio发布的时间点还是很快的,5月,10月,12月,就0.3了。Isito从架构,从功能上,比linkerd和Envoy是上了一个层次。这个就头疼了,属于下一代打这一代。按照《三体》的说法,这属于降维攻击:只要对手完成,基本上就是等死。 我们来看一下整个的时间表:Linkerd加入CNCF是一月,这是一个很关键点的,当时CNCF在类别上写了一个Servicemesh。当时看到这个词时还不知道Service Mesh是什么概念。但它对Linkerd特别重要,因为业界已经接受了Servicemesh的概念,且又被CNCF认可了。 而后Linkerd1.0发布不到一个月,Istio就出来了,紧接着Envoy在九月份杀入CNCF。时间点上可以看到非常近,可谓是“江山代有才人出,各领风骚几个月”。整个2017年,Servicemesh的风头就是以一个月一个月的方式在做变化。现在我们可以看到事情有多残酷:前脚还很悠闲的做先驱,做布道,眼看就要变成先烈了。 Istio缘何这么强?主要是三位创造Istio的大佬,Google、IBM、另外一位Lyft在前面两位这里算是小的。所以对于Linkerd来说会有种一时瑜亮的感叹:Linkerd刚出来很强,跨了一个时代的感觉,但脚还没站稳,就让人给揍了回来。 而Istio这个产品不仅后台过硬,社区支持够强,人也够多,能力也足,最重要的是它还特别努力。Isito在今年2700多个Commits,数量远远超过了Linkerd,可以说在产品上,Istio做的非常努力。而在人手上,整个Linkerd公司才不到20人,Istio的Working Groups的leader就已经23位了,怎么玩?这就有一个很要命的问题:对方不仅强,还很努力。 刚才提到的问题,上一场战斗刚刚打完,硝烟还未散去,尸骨都还没有寒呢。Mesos这里我们写着山河破碎,为啥呢?Mesos之前曾经占据领先的优势,最早的时候大部分江山是mesos的,而且现在都残留着很大的地盘。Swarm大家也看到了,基本上是宣布俯首称臣了。Kuberentes笑而不语,笑到最后。 在这场战争结束之后,这场离得非常近,打的非常激烈,可谓殷鉴不远。 接下来有一个关键的问题:到底怎么办? 现在Google带着Istio出来了,还叫上了一堆IBM,Lyft这样的助手,以及社区。对于Linkerd以及它的Servicemesh类的产品,就要面对一个问题:到底是想跪着生?还是站着死? 如果你有勇气和它对抗,那你站着,但若面对的是这样的竞争对手,胜算在哪里?如果没有勇气直面,接下来该怎么办?出路在哪里?这个问题困扰了我一段时间,因为我也在考虑要不要做一个Servicemesh的产品.这个问题细想起来,真的会很纠结。 我们来看看istio身后的Google。 Google是我个人是最崇拜的公司,没有之一,它做了很多让我感觉是真的在推动人类文明往前走的事情,比如它前段时间发表的论文。 我们回到容器、云的领域,Google非常的强,可以说是“剑在手问天下谁是英雄”。 左边,Kuberentes,屠龙宝刀已成,现在是“号令天下莫敢不从”,整个领域都没人敢说不。 右边,Istio,现在还在磨砺,虽然还未成功,但有勇气跟它竞争的人已经不多了。 这是目前我个人的判断,因为个人原因我比较关注这几个点。 GCP是Google云平台的缩写,下面是四个旗下的产品: 其中Kuberentes很熟悉了,它已经搞定整个容器,而且是Done的状态,基本上已经是事实标准了。 Isito按照我的理解是准备出来搞定下一代微服务的,仍在路上,但等成熟稳定后,基本上很难有强劲的竞争对手。 后面两个可能相对偏门一点,但对我比较特殊,我可能是国内第一批对gRPC进行研究的。如果大家对gRPC这个技术有所了解,可能会知道我的名字。这个东西基本上是搞定下一代的RPC通讯了,大家没有知觉的情况下,下一代的RPC基本上在它那里了。目前这个市场用的不是特别多,仍在培育当中,但也没有强劲的竞争对手。 而HTTP/2现在已经是W3C的标准,搞定了下一代HTTP:大家还停留在HTTP1.1上争夺的时候,google已经偷偷摸摸的直接把HTTP/2搞定了。 这四个产品加在一起的有什么感觉?我的想法是GCP在下一盘很大的棋,若将它们串联在一起,接下来在容器、微服务、通信这个领域,都在Google的范围之内——它已经把路完全铺好了。 底层操作系统,中间的容器,可能有一部分的PaaS系统,类似GCP这种,都是从Kuberentes这边走,已经搞定。服务间各种通讯,通讯机制如HTTP/2以及gRPC,这两个已经是事实标准了,搞定。现在全力以赴做微服务,Istio,准备继续往上做。 大家注意这张图,google现在是从底层一步步向上做,趋势非常明显。我们现在回头看这个布局。现在我不敢确定说Google是否真的在下这么一盘棋,但若真的有人在刻意下棋,只能说明这个棋手的能力太强了。现在要跟Google去争,如何去争?直接帮你将后面的东西全部铺好了。 当然,这里还有一个小小的悬念,如果一两年之内,Istio有能力将微服务这一块完全搞定,那么它的下一个目标会是什么?不出意外的话google会继续往上走,继续往业务上走,但会是什么现在还想不明白。 这里留一个悬念,两年之后大家再来看这个图,就可以知道这个问好是什么。 OK,是不是有种阴谋论的感觉? 回到微服务,在Servicemesh这个领域,Google这一次没有直接自己单干,而是搞了一套Istio,然后这次找了IBM。这里面有一个象征意义的东西,Google其实是标准互联网典型代表,但IBM是传统企业,虽然也一直在往互联网上走,一直往这方面做,但企业形象还是偏重传统。他的目标用户也是偏向传统企业用户,它们的合作象征意义是非常大的。 上面我一直在推一个概念,我们现在这个世界,这个技术潮流,有一个很重要的趋势是:传统企业用户向互联网技术做转型,大家注意到这个趋势,会非常明显。如果你在互联网工作,是没什么感觉的。但是如果看传统企业用户,会发现他们现在的技术完全是往互联网这边走,往微服务、容器、敏捷走,现在基本上他们都开始陆陆续续放弃weblogic、EJB、ESB,这个趋势非常明显。 这样的一个合作很有意思。 Google在Istio之前是有一些项目的,当时做了一个Google Service Control,如果熟悉Envoy,会发现这个功能点和现在istio的功能点非常像。实际上当时的一个重要的事情是这样的,IBM的一个VP在istio出来之后发表的一篇文章,意思是说Google和IBM各自在各自的领域做了一些事情,后来他们彼此间了解之后,发现相互之间是可以互补的,而且方向一致。所以做了很重要的一个决策:各自放弃吧,合起来一起做一个。刚好套上Service mesh的概念,就这样一拍即合,搞定。 可以想象Google和IBM的影响力,一起合作是什么概念?我们可以看到Istio在社区里得到了非常积极的响应。这些东西是在0.1版本的时候就已经开始在响应了,0.1是在今年五月份。 这里面很重要的一个是Oracle。容器:K8S,这不出意外。微服务直接选Istio,这个有点出乎我意料。Serverless是直接收购了一个FN的项目。这里面很明确的是,他们的微服务就是Istio,这是它的战略决策。 Redhat就比较好理解,它一直跟Google和Kubernetes跟的很紧,所以它选择Istio完全可以理解。 反而是最后这一位,Pivotal,它的Cloud foundry非常明确要支持Istio。但是这里面有点古怪的地方是,这家公司本身是好像有点跟Google对着干的感觉。