Istio

Mixer Cache: Istio的阿克琉斯之踵?微信讨论实录

在Service Mesh技术社区的微信群中,针对Istio Mixer Cache设计中缓存存放和逻辑分离的潜在分险,进行了深入探讨,截屏实录,原汁原味。

Istio Mixer Cache工作原理与源码分析(4)-签名

签名是Mixer Check Cache的核心操作,涉及到最重要的缓存查找,还有性能,但是,其实在理解了引用属性和absent key的概念后,也非常简单。

Istio Mixer Cache工作原理与源码分析(3)-主流程

Mixer Check Cache的主流程代码解析。

Istio Mixer Cache工作原理与源码分析(2)-工作原理

Mixer check Cache设计时,由于受限于无法得知mixer adaper会使用哪些属性,因此不得不引入两层缓存的设计,而absence key的使用也增加了代码阅读上的困难。在展开代码阅读和讲解之前,我们先在本文中概括讲述mixer check cache的工作原理。

Istio Mixer Cache工作原理与源码分析(1)-基本概念

为了保证性能,避免每次请求都远程访问Mixer,Istio在Envoy中精心设计了一套Mixer Cache机制。在Mixer这个精美的花瓶下面,垫上了一块厚实的板砖。

Mixer Cache: Istio的阿克琉斯之踵?

为了架构的优雅,Istio设计了Mixer,将大量的功能从Sidecar中搬了出来。为了减少Mixer远程调用带来的性能,又精心设计了一套复杂的缓存。只是,这个Mixer Cache,有一个地方需要探讨……

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测试,金丝雀发布,限流,访问控制和端到端认证。 开发人员和运维人员在单体应用程序向分布式微服务架构的转型中, 不得不面临上述挑战。