服务网格

Service Mesh:重塑微服务市场

大家好,我是敖小剑,今天给大家带来的这个主题叫做 “Service Mesh:重塑微服务市场”。 刚才主持人张亮提到说,过去一年Service Mesh成为一个热词。基本上,在国内的话,我差不多是Service Mesh最早的布道师。可能如果大家之前有看相关的资料的话,应该会看到一些我的资料。我先后做过几场的演讲,做过一些技术的分享,也写过很多文章。但在此之前,这些内容可能更多的都是集中在技术领域。那今天我们会特殊一点,我们今天不谈详细的技术,不谈具体的架构,我们也不谈具体的产品。后面的这些名词,Istio/Conduit/Envoy/Linkerd/Nginmesh,这些词可能听过,可能没听过,但没问题,今天这些我们统统都不讲。我们今天要讲另外一个东西:我们会聊一聊在未来一两年之内,Service Mesh技术会在微服务相关的市场带来什么样的变化? 主要内容会是三大块:首先我们会看一下目前微服务的市场的一些现状,然后接下来我们会探讨一下它的商业模式,在第三块,我们会重点讲一下Service Mesh对PaaS的意义。 OK,第一块,微服务的现状。 我们快速过一下。 目前微服务的背景是这样,首先目前在市场上是有这么一个潮流:传统企业会慢慢向互联网技术转型,其中微服务和容器是这个技术转型的核心。这个市场比较大,大家也都看好这样一个方向,这是大的时代背景。 简单回顾一下,微服务在国内,基本上是在2015年开始兴起。2016/2017这两年在国内的基本上就是大热了。我们能看到的是,未来这一两年之内,这个热潮应该继续延续。主要还是因为微服务这个技术是用于解决实际问题的,另外它也同样适用于各种企业。这样的大背景之下,我们来看现在使用微服务的客户现状。 实际上,我们之前在谈到Service Mesh技术为什么演进的时候,我们有提到,在Service Mesh之前,第一代的侵入式微服务框架,它的门槛相对稍微高一点,典型的代表的是Dubbo,Spring Cloud。对于传统企业来说,传统企业其实缺乏一些互联网的技术基因,这些包括技术,人才,经验,还有开发流程。在实际的市场当中,我们可以看到,大多数企业,虽然他们试图在微服务方面有一些转变,但实际上,在落地的时候还是会遇到一些问题。目前第二代的Service Mesh技术其实主要是冲着解决这个问题来的。他的思路在于要想办法用Service Mesh这样一个技术来降低微服务落地的门槛,最后帮助传统企业完成整个技术转型。这是目前大的背景和现状,我们下面来详细聊一下在这个背景当中一些具体的东西。 微服务的一个痛点:落地很难。 在这个地方我放了一个冰山图,左边的有一个坐标,就是说要实现好一个微服务,技术要求大概是一个什么样子,我这边简单的画了一下。 实际上我们可以看到,就是说如果以60分为及格线的话,那很遗憾的是,虽然这个冰山我们看它的体积非常的巨大,这个市场规模是非常大的,但实际上到目前真正能够落地的,能够浮在水面上的,其实并不多。这个问题在哪里? 因为它落地太难了。 落地难的原因是门槛比较高。我们简单的罗列了一下,比如说典型的Spring Cloud,他的技术栈,我们看到的这些特性的列表。大家可以看到非常多的东西,左边这个地方Spring Cloud的各个组件。大家如果用过Spring Cloud的都会比较熟悉。当然两边并不是严格对称,这只是一个示意。 实际上在这样的一个巨大的特性列表和组件列表当中,比较头疼的是:如果你是一个新人的话,你要第一时间掌握的东西其实是非常多的。Hello Would都很简单,但是你真的要掌握,这些东西是要一个一个吃透的。 为什么这个门槛会这么高?在这里面要指出一点,就是说:解决问题的思路有点不太对。 我们先看左边这个图,我们现在如果是想要一辆汽车,那OK,可以像左边这个图一样。我们看到一辆汽车分解之后是会有多少个零件?我们现在通过类库的方式,实际去组装辆汽车,我可以给你不同的组件,不同的类库,然后告诉你这个是发动机,这个是轮胎,这个是刹车……这确实会比自己从头到尾,从每一个螺丝钉开始制造,去组装整车要轻松的多,比如说至少有个成熟的发动机,至少方向盘可以不用自己做了。但是实际上,对用户而言,必须要对整体有非常深的认识:你知道每个组件能做什么,选择合适的组件,并把他们并拢起来。这样对一个系统的了解是需要比较深的。 我们再看看右边:你组装出来的东西是什么样子?最上面这个跑车可能是所有人的梦想,对吧?但实际当中,不同的用户,他的能力是不一样的,他的投入也不一样。那他最终得到产出品,很有可能不是上面的这个让大家心动的跑车。很可能只是一个普通的大众,只能只一个QQ,甚至,其实最后一张图非常凄惨:不知道出来的会是什么,很可能是接近无法使用的产品。 在下一代的Service Mesh当中,会用其他的方式来完成这个事情。 首先通过智能代理的方式,屏蔽掉大家对底层各个组件的认知。Service Mesh会通过直接使用Sidecar的方式来完成这些功能。 从思路上说,在这个时候,最大的事情是调整战略。 我们回到需求:客户用这些东西的需求是什么?它的目标是把这个车造出来,但造出这个车的下一步,是开着它上路,去该去的地方。造车,并不是他的最终的目标,对吧?我们回到现实的例子,大家学习Spring Cloud的目标是仅仅掌握Spring Cloud吗?我们说到,做微服务的实现,是把我们体系架构在微服务之上,然后让整个体系可以更快更好的运转。所以呢,客户真正的需求是用微服务做开发,做应用开发,应用是它的核心价值。这种情况下,对于微服务系统本身的掌握,要求其实不应该那么高。 比如说我随便举个例子,我相信在座的各位,很多同学开过车对吧?你可能开车的驾驶技术很高,但是如果我们现在,举个例子说:我给你一堆组件给你组,你能不能组装成一辆车?我相信在坐的同学应该没有几个能办得到。 所以,在这个地方,在Service Mesh里面,最重要的是:我们会做一个思路的转变。我们不再以组件的方式给客户提供服务,而且直接给客户成品,而且是精心打磨的成品。这个大家梦想中的跑车,开箱即用,直接呈现在客户面前。它非常的方便,可以非常快速地使用它。他的品质是经过打磨好之后的,然后客户只需要知道该怎么驾驶就好了。 这是整个Mesh的思路。 在这个思路背后,代表了一个重要的核心理念。我们会看到,第一代的微服务将当时微服务开发的门槛降低了,在第一代微服务之前,你需要一切从零开始,你需要从每一行代码开始。换句话说,在你造整车的时候,你需要从每个螺丝钉开始,这必然是很难的。 第一代微服务至少提供了一些成熟的组件,比如说发动机OK啦,这个门槛它降低了一部分。第二代微服务,我们是希望在这个基础上,将门槛进一步降低。60分不再是及格线,我们希望将它降成30分。这个目标如果能够达成,对于期望用微服务来做技术革新的企业来说,他这个时候可以更容易地落地。大家可以想象,一场考试,及格线是60分和及格线是30分,这个时候及格率会发生质的变化,这个时候能释放出来的市场规模也会远远大于前者。 OK,这个第一阶段我们讲好。 嗯,在这个地方,我想问大家一个问题:在座的各位,有没有哪一位所在的企业是真正的将微服务落地在一线生产上的?张亮兄?OK,你这个没问题。还有没有哪一位?OK?好,这个属于冰山水面上的部分。后面还有没有其他同学?有没有同学做过尝试的?就是在你们的实际的生产当中,实际落地微服务的架构,OK,这边有些同学。 好,实际上调查的和我们预期的还是有点像的。真正的大家能够把微服务落地的,就是冰山上面露出来的一小部分。 OK,我们进行第二个探讨:Service Mesh和微服务市场模式的探讨。 我先抛出一个问题:假设现在有一个公司,他要推微服务,但它确实之前没有这样的经验,它可能也缺乏这样的人才,所以在技术能力上它会有些欠缺。那这个时候怎么办? 哪位同学能给我想一个办法?或者说如果现在你的领导和你说:我们要上微服务了,有什么办法?这个很现实的,领导明天就你定方案,然后你发现你的团队好像大家都没玩过,也都不会。请你告诉我怎么办?有没有哪个同学给我一个想法? 注:现场互动,有同学回答说,需要领导重视。 嗯,非常重视,我们明天就上! 注:现场互动,有同学继续说,招人,外包。 恩,招人和外包,还有别的吗?OK,好,这位同学至少已经找到了明天早上开始推行微服务的一些方案了。 OK,我们简单过一下,刚才这个同学这里有一个比较有意思的地方:招人。这个有个比较有意思的东西给大家轻松一下。 这个是我个人的玩笑,用于区分互联网企业的一个简单方式:当发现有些事情自己不会做,也没有合适的人手,没能力的时候怎么办?一般互联网公司的习惯都是:挖!没人是吧,看一下业界谁会,挖!挖不过来是吧,薪水乘2?OK,互联网公司一般习惯这么干。但是传统企业一般不喜欢这么干,这里还包括伪装成互联网,大家应该懂这个意思吧?嗯,他的业务有可能是互联网业务,但他的工作方式,整个运作可能是传统企业的方式。但它的业务模式可能是互联网产品。这种企业的通常情况下它的习惯是买!拿钱去买,但他能买到什么? 当然这是个玩笑,但是有时候还是挺准确的,大家可以私底下去验证一下。 那我们现在说说,能买什么? 在这个市场,能为微服务的开发提供什么样的产品,什么样的服务吗?刚才同学说了一个:外包。是的,这个很正常。确实有非常之多的外包,但还有两个,一个是咨询,教你怎么做;一个是培训,包括出书也是一种培训,现场培训是另一种。还有一种就是卖产品,微服务相关的各种产品。整个市场会提供这些产品,但我们会注意到:前三者是不一样的。咨询、培训、外包本质上是要提升客户的能力,就是让你的能力更强。如果大家记得前面的那条线的话,现在就是在你考试的时候,让你的考试能力更强。产品是帮你稍微降低一下门槛。比如我告诉你,第五道题的答案是B,你填上就好了。最终达到大家及格的目标,至少起码及格。 整个市场提供的产品,大概是这个样子。 我们聊另外一个话题,可能更有意思:为什么大家想用微服务?尤其在参加技术大会之后。平时大家苦日子过习惯了,后来某人参加了某个技术大会之后,回来就觉得:平时这苦日子过得有点惨。旁边的这个是麦粒,不知道大家有没有吃过?晒干之后脱皮直接煮着可以吃的,甚至也可以生吃。然后是非常难吃的,很难下咽,但古代,我们的祖先原来就是这么吃下来的。后来发现参加了一场大会之后,发现这个受不了,为什么呢?发现别人吃的是右边的东西。 这个叫什么?不患贫而患不均,对吧?左边这个其实也不是过不下去,但是当你看到右边之后,通常一般人都受不了了。别人告诉你说要去皮,你要磨成粉,之后你要和面,发酵,蒸,然后就有这个吃了。大家一看,开完大会之后就发现,对啊,左边这个麦粒确实没必要这么吃,对不对? 我们现在回到刚才的这个话题:咨询、培训、外包的本质是什么?

Dream Mesh

Dream Mesh,梦想中的Service Mesh.

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对着干的感觉。

Service Mesh:下一代微服务

敖小剑:首先感谢这么多朋友来听我的演讲,今天我们分享的是Service Mesh,下一代微服务.我是敖小剑,来自数人云的资深架构师。 简单回顾一下过去三年微服务的发展历程。在过去三年当中,微服务成为我们的业界技术热点,我们看到大量的互联网公司都在做微服务架构的落地。也有很多传统企业在做互联网技术转型,基本上还是以微服务和容器为核心。 在这个技术转型中,我们发现有一个大的趋势,伴随着微服务的大潮,Spring Cloud微服务开发框架非常普及。而今天讲的内容在Spring Cloud之外,我们发现最近新一代的微服务开发技术正在悄然兴起,就是今天要给大家带来的Service Mesh/服务网格。 我做一个小小的现场调查,今天在座的各位,有没有之前了解过服务网格的,请举手。(备注:调查结果,现场数百人仅有3个人举手) 既然大家都不了解,那我来给大家介绍。首先,什么是Service Mesh?然后给大家讲一下Service Mesh的演进历程,以及为什么选择Service Mesh以及为什么我将它称之为下一代的微服务,这是我们今天的内容。 我们首先说一下Service Mesh这个词,这确实是一个非常非常新的名词,像刚才调查的,大部分的同学都没听过。 这个词最早使用由开发Linkerd的Buoyant公司提出,并在内部使用。2016年9月29日第一次公开使用这个术语。2017年的时候随着Linkerd的传入,Service Mesh进入国内技术社区的视野。最早翻译为“服务啮合层”,这个词比较拗口。用了几个月之后改成了服务网格。后面我会给大家介绍为什么叫网格。 先看一下Service Mesh的定义,这个定义是由Linkerd的CEO William给出来的。Linkerd是业界第一个Service Mesh,也是他们创造了Service Mesh这个词汇的,所以这个定义比较官方和权威。 我们看一下中文翻译,首先服务网格是一个基础设施层,功能在于处理服务间通信,职责是负责实现请求的可靠传递。在实践中,服务网格通常实现为轻量级网络代理,通常与应用程序部署在一起,但是对应用程序透明。 这个定义直接看文字大家可能会觉得比较空洞,不太容易理解到底是什么。我们来看点具体的东西。 Service Mesh的部署模型,先看单个的,对于一个简单请求,作为请求发起者的客户端应用实例,会首先用简单方式将请求发送到本地的Service Mesh实例。这是两个独立进程,他们之间是远程调用。 Service Mesh会完成完整的服务间调用流程,如服务发现负载均衡,最后将请求发送给目标服务。这表现为Sidecar。 Sidecar这个词中文翻译为边车,或者车斗,也有一个乡土气息浓重的翻译叫做边三轮。Sidecar这个东西出现的时间挺长的,它在原有的客户端和服务端之间加多了一个代理。 多个服务调用的情况,在这个图上我们可以看到Service Mesh在所有的服务的下面,这一层被称之为服务间通讯专用基础设施层。Service Mesh会接管整个网络,把所有的请求在服务之间做转发。在这种情况下,我们会看到上面的服务不再负责传递请求的具体逻辑,只负责完成业务处理。服务间通讯的环节就从应用里面剥离出来,呈现出一个抽象层。 如果有大量的服务,就会表现出来网格。图中左边绿色方格是应用,右边蓝色的方框是Service Mesh,蓝色之间的线条是表示服务之间的调用关系。Sidecar之间的连接就会形成一个网络,这个就是服务网格名字的由来。这个时候代理体现出来的就和前面的sidecar不一样了,形成网状。 再来回顾前面给出的定义,大家回头看这四个关键词。首先第一个,服务网格是抽象的,实际上是抽象出了一个基础设施层,在应用之外。其次,功能是实现请求的可靠传递。部署上体现为轻量级的网络代理。最后一个关键词是,对应用程序透明。 大家注意看,上面的图中,网络在这种情况下,可能不是特别明显。但是如果把左边的应用程序去掉,现在只呈现出来Service Mesh和他们之间的调用,这个时候关系就会特别清晰,就是一个完整的网络。这是Service Mesh定义当中一个非常重要的关键点,和Sidecar不相同的地方:不再将代理视为单独的组件,而是强调由这些代理连接而形成的网络。在Service Mesh里面非常强调代理连接组成的网络,而不像sidecar那样看待个体。 现在我们基本上把Service Mesh的定义介绍清楚了,大家应该可以大概了解什么是Service Mesh了。 第二个部分和大家追溯一下Service Mesh的演进历程。要注意,虽然Service Mesh这个词汇直到2016年9才有,但是它表述的东西很早以前就出现了。 首先看“远古时代”,第一代网络计算机系统,最早的时候开发人员需要在自己的代码里处理网络通讯的细节问题,比如说数据包顺序、流量控制等等,导致网络逻辑和业务逻辑混杂在一起,这样是不行的。接下来出现了TCP/IP技术,解决了流量控制问题,从右边的图上可以看到,功能其实没发生变化:所有的功能都在,代码还是要写。但是,最重要的事情,流程控制,已经从应用程序里面抽出来了。对比左右两边的图,抽出来之后被做成了操作系统网络层的一部分,这就是TCP/IP,这样的话应用的结构就简单了。 现在写应有,就不用考虑网卡到底怎么发。在TCP/IP之后,这是完全不需要考虑的。上面说的是非常遥远的事情,大概发生在五十年前。 微服务时代也面临着类似的一些东西,比如说我们在做微服务的时候要处理一系列的比较基础的事情,比如说常见的服务注册、服务发现,在得到服务器实例之后做负载均衡,为了保护服务器要熔断/重试等等。这些功能所有的微服务都跑不掉,那怎么办呢?只能写代码,把所有的功能写进来。我们发现最早的微服务又和刚才一样,应用程序里面又加上了大量的非功能性的代码。为了简化开发,我们开始使用类库,比如说典型的Netflix OSS套件。在把这些事情做好以后,开发人员的编码问题就解决了:只需要写少量代码,就可以把这些功能实现。因为这个原因,最近这些年大家看到Java社区Spring Cloud的普及程度非常快,几乎成为了微服务的代名词。 到了这个地步之后,完美了吗?当然,如果真的完美了,那我今天就不会站在这里了:) 我们看这几个被称之为痛点的东西:内容比较多,门槛比较高。调查一下,大家学Spring Cloud,到你能熟练掌握,并且在产品当中应用,可以解决出现的问题,需要多长时间?一个星期够不够?大部分人一个星期是不够的,大部分人需要三到六个月。因为你在真实落地时会遇到各种问题,要能自己解决的话,需要的时间是比较长的。这里是Spring Cloud的常见子项目,只列出了最常见的部分,其中spring cloud netflix下还有netflix OSS套件的很多内容。要真正吃透Spring Cloud,需要把这些东西全部吃透,否则遇到问题时还会非常难受。 这么多东西,在座的各位相对来说学习能力比较强一点,可能一个月就搞定了,但是问题是你的开发团队,尤其是业务开发团队需要多久,这是一个很要命的事情:业务团队往往有很多比较初级的同事。 然后事情并不止这么简单,所谓雪上加霜,我们还不得不面对一堆现实。 比如说,我们的业务开发团队的强项是什么?最强的会是技术吗?不,通常来说我们的业务开发团队最强的是对业务的理解,是对整个业务体系的熟悉程度。 第二个事情,业务应用的核心价值是什么?我们辛辛苦苦写了这么多的微服务,难道是为了实现微服务吗?微服务只是我们的手段,我们最终需要实现的是业务,这是我们真正的目标。 第三个事情是,就微服务这个手段而言,有比学习微服务框架更艰巨的挑战。在做微服务的真正落地时,会有更深刻的理解。比如微服务的拆分,比如要设计一个良好的API,要保持稳定并且易于扩展,还有如果涉及到跨多个服务的数据一致性,大部分团队都会头疼。最后是康威定律,但凡做服务的同学最终都会遇到这个终极问题,而大多数情况下是欲哭无泪。 但是这些还没完,比你写一个新的微服务系统更痛苦的事情,是你要对旧有的系统进行微服务改造。 所有这些加在一起,还不够,还要再加一条,这条更要命:业务开发团队往往业务压力非常大,时间人力永远不足。说下月上线就是下月上线,说双十一促销就不会推到双十二。老板是不会管你有没有时间学习spring cloud的,也不会管你的业务团队能否搞得定微服务的方方面面。业务永远看的是结果。 第二个痛点,功能不够,这里列出了服务治理的常见功能。而Spring Cloud的治理功能是不够强大的,如果把这些功能一一应对做好,靠Spring Cloud直接提供的功能是远远不够的。很多功能都需要你在Spring Cloud的基础上自己解决。

服务网格新生代-Istio

服务网格新生代-Istio 大家晚上好,欢迎参与直播,我是今天的讲师,来自数人云的资深架构师,敖小剑。 相信大家进来前都有看到这次分享的介绍,今天的主角名叫 istio,我估计很多同学在此之前可能完全没有听过这个名字。请不必介意,没听过很正常,因为istio的确是一个非常新的东西,出世也才四个月而已。 今天的内容将会分成三个部分: 介绍: 让大家了解istio是什么,以及有什么好处,以及istio背后的开发团队 架构: 介绍istio的整体架构和四个主要功能模块的具体功能,这块内容会比较偏技术 展望: 介绍istio的后续开发计划,探讨未来的发展预期 介绍 istio是什么 istio是Google/IBM/Lyft联合开发的开源项目,2017年5月发布第一个release 0.1.0, 官方定义为: Istio:一个连接,管理和保护微服务的开放平台。 按照isito文档中给出的定义: Istio提供一种简单的方式来建立已部署的服务的网络,具备负载均衡,服务到服务认证,监控等等功能,而不需要改动任何服务代码。 简单的说,有了istio,你的服务就不再需要任何微服务开发框架(典型如spring cloud,dubbo),也不再需要自己动手实现各种复杂的服务治理的功能(很多是spring cloud和dubbo也不能提供的,需要自己动手)。只要服务的客户端和服务器可以进行简单的直接网络访问,就可以通过将网络层委托给istio,从而获得一系列的完备功能。 可以近似的理解为: istio = 微服务框架 + 服务治理 名字和图标 Istio来自希腊语,英文意思是”sail”, 翻译为中文是“启航”。它的图标如下: 可以类比google的另外一个相关产品,Kubernetes,名字也是同样起源于古希腊,是船长或者驾驶员的意思。下图是Kubernetes的图标: 后面我们会看到, istio和kubernetes的关系,就像他们的名字和图标一样, 可谓”一脉相传”. 主要特性 Istio的关键功能: HTTP/1.1,HTTP/2,gRPC和TCP流量的自动区域感知负载平衡和故障切换。 通过丰富的路由规则,容错和故障注入,对流行为的细粒度控制。 支持访问控制,速率限制和配额的可插拔策略层和配置API。 集群内所有流量的自动量度,日志和跟踪,包括集群入口和出口。 安全的服务到服务身份验证,在集群中的服务之间具有强大的身份标识。 这些特性我们在稍后的架构章节时会有介绍. 为什么要使用Istio? 在深入istio细节之前,我们先来看看,为什么要使用Istio?它可以帮我们解决什么问题? 微服务的两面性 最近两三年来微服务方兴未艾, 我们可以看到越来越多的公司和开发人员陆陆续续投身到微服务架构, 我们也看到一个一个的微服务项目落地. 但是, 在这一片叫好的喧闹中, 我们还是发觉一些问题,普遍存在的问题: 虽然微服务对开发进行了简化,通过将复杂系统切分为若干个微服务来分解和降低复杂度,使得这些微服务易于被小型的开发团队所理解和维护。但是, 复杂度并非从此消失. 微服务拆分之后, 单个微服务的复杂度大幅降低, 但是由于系统被从一个单体拆分为几十甚至更多的微服务, 就带来了另外一个复杂度: 微服务的连接、管理和监控。 试想, 对于一个大型系统, 需要对多达上百个甚至上千个微服务的管理、部署、版本控制、安全、故障转移、策略执行、遥测和监控等,谈何容易。更不要说更复杂的运维需求,例如A/B测试,金丝雀发布,限流,访问控制和端到端认证。 开发人员和运维人员在单体应用程序向分布式微服务架构的转型中, 不得不面临上述挑战。