01:13
线上的伙伴们,大家周二晚上好,欢迎来到于原生正发声直播间,我是今天的主持人朱丽叶,于原生正发声,于原生技术爱好者共同学习成长。那云原生正发声呢是腾讯云主办的首个云原生百科知识节目,主要是围绕云原生领域覆盖实时的云原生技术实践、性能优化、前沿趋势、案例分享等等内容来和大家进行交流。那我们的节目呢是在每周二的晚上七点半会准时开播,那通过这样的一个直播节目呢?我们是希望能够帮助云原生技术使用者和爱好者加深对云原生技术的理解,同时也推动云原生在与企业it的融合。助力企业上云更简单,那今天是我们节目的第32期,我们邀请到了来自腾讯T腾讯I资深云原生架构师陈继杰老师来给大家分享服务网格在腾讯I的落地实践。
02:17
那陈老师呢,会以腾讯业务为背景来介绍服务网格对于典型的大型企业应用的关键价值落地模式,以及对服务网格能力的增强探索。那我们今天的节目分享流程呢,前面是呃,前面的30~45分钟呢,我们的陈老师会给大家分享啊整体的一个内容,然后呢,在分享结束之后呢,我们会有15分钟的一个互动问答的时间,大家可以扫描我们屏幕左侧的二维码,进入到我们的提问专区进行提问,同时呢,扫描我们右侧的二维码,进入到我们的技术交流群里面。那在我们老师分享结束之后呢,会选取部分大家的问题来给大家去进行答疑,如果大家有提问的话,那我们同时呢也准备了精美的呃鹅厂的虎年公仔会送给到大家,给到提问的同学,所以欢迎大家多多线上参与互动啊,并且我们在直播间呢,还会有不定时的抽奖红包,奖品也是我们精美可爱的虎年公仔,欢迎大家多多关注哦。
03:24
好了,那接下来我们有请陈老师来开始给大家分享吧。好的,谢谢朱丽。那么我们今天的分享的话呢,就是包含这样的四个部分呢,呃,首先呢,我们会简单介绍一下我们的就是腾讯it的一些业务特点。呃,接着呢,就是我们会介绍一下服务网格对于腾讯it的一些关键价值,以及这后面的话我们会谈一谈啊,我们在腾讯it是怎样去落地这个辅网格的,最后我们也会简单聊一下,在实际落地过程当中,我们有些场景可能原生的辅网格不能支持的,那我们做了一些怎样的一个探索,怎样的一个一些一个增强,因为。
04:09
这个大家都有疫情的,所以我今天的话有一点不好意思,是家里人有不舒服的,所以需要去需要带个口罩跟大家做一些分享啊,那么我们首先进入第一个部分,简单介绍一下腾讯it的业务特点。呃,其实腾讯it的话,可能跟很多大型的企业都差不多,呃,都是用于支持我们公司内部运作的一个啊专业的it团队,基本上呃,每一位每一位在各个企业里面去呃上班的朋友们都会非常清楚的能够接触到,呃各种各类的企业应用,包括我们在公司内部的一些订餐呐,一些打车呀,一些公司之内的一些HR数据啊,一些HR应用啊,你入职啊,然后你的一个发这样的一系统,实际上大量的系统我们都是在支持这类系统。
05:07
呃,另外呢,我们作为一个公司,同时作为公司的一个基础团队的话,我们也提供一些在公司范围内提供给各类其他的,呃,这样的一些内部网站提供的一些基础服务。啊,这类的技术服务,包括比如说我们员工登录啊等等一些相关的系统。同时呢,我们为了支持公司的运营的话,我们还会从外部采购一些。呃,用于支持我们日常运作的一些系统,这样的一些系统可能标准化程度比较高,所以我们也会有一些外采的系统,那么这些系统其实都是有他们不同的特点的。呃,比如说像刚才我提到的这种办公形式类的应用的话,呃,对应来说他们有时候呢,有的会比较可能会复杂一点,但是大部分业务可能相对没有那么复杂啊,我们会可能相对来说不会有那么多人就是去关注到同一个业务,相对应来说就可能是由一个人负责多个项目,同时我们也会邀请很多合作伙伴参与到我们的这个研发中来。
06:07
对于基础服务来说,他们因为是面向全公司的基础服务,所以我们会对它的稳定性以及安全性的要求是非常高的,那么同时呃,因为有了这样的一些要求,所以我们在实际运营过程当中需要做到非常精细的一些呃,一些治理。然后一些流量的管控,所以对服务来说,对于这个它的运营需求是非常丰富多样的。那么对于外采系统来说的话呢,他们其实有一些是可能因为受限于这个厂商的一些情况,所以它系统原生的这个程度并不完全一样。部署方法也会可能会有差别。啊,但是呢,他们也有对应它的一些优势,就是说它这个系统会相对比较稳定,部署周期啊,这些工作流的比较明确啊,这是我们,呃,基本上我们的业务形态会分成这几个这几种类型。呃,然后从技术上讲的话呢,其实我们的技术也可以说是非常丰富多样的,从这里也简单的分成了我们日常平常所关注的这种业务应用的三层,呃,不管是界面也好,后台技术,还是我们数据存储,其实都经过了大家所熟知的这样的一个技术发展的一个历程。
07:22
我们20202010年以前的话,也是使用一些比较传统的技术,以及后续的话,我们逐步给它换成了一些包括上云,包括换成我们现在一些比较呃更加开源的一些技术等等,所以其实经过了这样的一个漫长的这样的一个发展。呃,实际上我们现在构成了一个比较可以说比较复杂的场,呃,场景吧,因为其实并不是所有的系统都完成了,呃,刚才我们讲的这样的一个历程,因为有一些系统他们相对来说,呃,可能功能已经比较稳定了,那么我们不一定会对它进行大范围的一个重构或者重写,所以可能我们会继续沿用这些相对比较旧的一些技术。
08:04
呃,但是呢,新的系统可能会使用新的,尽量使用新的技术去构建。而旧的应用,我们为了支持业务的运营,我们又必须支持,所以其实最终我们会形成一个呃,比较复杂的一个状态啊,具体来讲的话,我们把它。归结为三个类别。第一个话就是业务,总体来讲的话,业务我们,呃,因为是it类的应用,所以我们的数据相对是非常敏感的,对稳定性也要求很高,在人员方面的话,我们毕竟也是一个其实算算是一个比较小的部门,在公司之内,那么为了支持我们比较多的一个,呃应用体系的话,那么它其实是一种少数专家来支持大量业务的一个状态。在技术上面,刚才我也谈到就是其实它是一个比较丰富的一个技术站,同时这些技术,这些产品本身之间存在着大量的这种相互集成的需求,那这些需需求他们相互又有很多的一些约束,呃,这里有一个简单的例子,我们有不少的这种系统,它是采用比如说IP地址白名单的方式来做健全,那么这样的一些比较传统的方式,实际上是给我们啊在做云原生的改造过程当中带来了不小的挑战。
09:14
所以这是我们,呃,目前来看,我们能够总结的这样的几种业务特点。那么针对这些业务特点的话,其实属网格在这个当中能够给我提供比较好的一些,呃,匹配的价值。那我们来看一下,呃,简单我们来聊一聊网格是一个什么样的概念,其实可能很多人在社区里面已经有所了解了,那我们这里简单的聊一聊。呃,现在我们看到的是一个我们比较传统的一个虚机服务的一个呃状态,那它其实就是在一个虚拟机上,我部了我三个,呃三个服务,一个是我的数据库,另外就是我的这个后台应用,另外是我的这个前台应用,基本上我们能够啊能够。通过这样的一个简单的部署,就可以让一个业务就能运营起来,那么如果我们要对他们做一个容器化的改造的话,那么刚才讲的这三个服务的话,可能会,呃,可能会。
10:12
提取为更多的微服务,而这些更多的微服务都是运行在容器集群上的不同的这种虚拟节点上,那么在这种情况下的话呢,它就势存在这个服务之间的这种调用的一些一些。需求,那我们以前可能更多的,因为你单机的模式下的话,实际上你都是。呃,直接调用本机就可以了,我们知道其实在你做微服务改造之前,如果说你作为一个单体应用,实际上只需要在进程内调用,即使你是在单个的虚机上,你去调用本机也是相当稳定的。但是呢,如果你要把这种调用进一步拆解为作为一个容器集群里面的相互调用,甚至作为容器集群的相互调用,那么其实你这个这样的一个。
11:01
相互调用,未服务调用就可能会出现,可能会出现一些不太稳定的情况,需要我们去格外关注它的一些治理能力。具体来说的话,微服务的治理其实包含很多个方面,那么我们其实在社区里面,大家应该也是在这方面有所了解。本本身的话,从如果只是从服务调用这块的话,那可能主要是在这个图上的,呃,左边这一服务发现自啊啊熔断呀这些,但是除了除了这个微服务,除了左侧这边的话,还有它的右侧这部分。因为他以前更多的比如说我一个虚机,可能我一个系统就在一个虚机上,那么我对这个虚机里面的若干进程做了监控之后,基本上我这个运维保障工作也就搞定了,但是呢,现在你把它变成一个集群之后,把它这个微服务又有服务的这个实力。呃,它进行它发生了一个成倍的增长之后,其实我们会发现在这个右侧的这部分的运维工作实际上是有成倍的增长的。
12:03
那么我们来简单的看一下呃服网格,在这个过程当中,我们辅网格是怎样发展出来的,以及它是怎样去帮助我们解决这个服务治理的一些能力的。其实最早的时候,当我们把服务都拆成都拆成一个一个的进程,以及把它分到不同的机器上之后呢,人们会发现它逐步开始有了这种就是呃一些微服务治理的需求,那么最最早的时候,可能我们比较简单的就直接在以前可能你是调用一个同一进程内的函数,直接把那个函数呢改成一个面向远程的调用,那如果发现是需要去做出发现以及重市等等这些处理的话,就直接在那个相应的。呃,业务逻辑单元去做相关的处理就可以了,那么后续的话,我们当然大家会发现这个服务治理相关的需求,我可以在进程里面把它,呃,专门抽象出来,形成一个微服务框架,这也是很多像呃,Spring cloud,对吧,像这样的一些微服框架啊,实际上在做的事情。
13:11
那么后面的话,人们会发现,既然我可以把它作为一个服微服务的框架放在同一个进程里面,我可不可以把它进一步提取出来,变成一个,呃。基础设施的一个标准能力呢,直接供给我们部署在平台上的这个。各种微服务的,实际上也是服务网格的一个思路。那么这样一来的话呢,实际上服务网格就可以服务各种不同的技术,因为它是在进程之外,所以它其实对于服务进程本身的一些呃技术要求不是很多,那只要你是正常的,你去呃做HTPPPC这样的一些调用,那基本上它这个网格都是可以去做治理的,所以这样就可以很好的去适配各种不同的技术。的一个治理。
14:00
呃,那么其实在社区里面用的比较多的这个服务治理软件,现在主要就是那我们腾讯云的服务网格里面,TM其实是对这个九做了一些呃托管的封装,提供了一套标准化的这种呃服务网格的能力,在腾讯云的t ke里面提供跟这个社区版的呃几乎是完全一致的各种呃各类的功能啊,在的网站上我们可以看到呢,呃。列出了它的几种比较关键的功能,首先是互联互通,互联互通它指的就是说我需要去把这个服务之间的这种访问能力,我可以把它管理起来。那么访问能力就意思就是说我某一个服务,我应该从哪一个节点。去出去从哪一个节点进来,那么它是可以对你这个流量的一些通路去做一些这个处理的啊安全安全保护的话,就是说既然我可以对你的流量进行限制对吧,那么我当然我既然可以看到你的流量,我可以对你的流量进行一个转发和处理,那么我当然也可以对你进行一些拦截或者放通知操作对吧,等等,以及呃,他也可以基于呃这样的一些能力去。
15:12
施加一些策略,然后去完成我们相关的这种呃,硬性的要求,要求一个呃,你的这个。你的这个资源是怎么分配的等等,你的流量在这个版本之间是怎么分配的,观测的话呢,同样它是基于这个互联互通,既然说它能够整体知道你的网络通路在哪里,那么他也就可以清晰的知道你的这个。微服务的流量从哪里来的,以及到到哪里去的,你的访问的时间是多少,你的成功失败这些情况都是可以拿到的,所以呢,呃,TCM以及九都提供了这几类的功能。它之所以能够之所以能够提供这些功能的话,其实得益于在这个网格里面,它对流量进行的一些呃这样的一些分类,那么首先呢,就是我们平常我们刚才其实谈到的这个微服务之间的流量的调用呢,就是在辅网格里面把它称之为这个东西向的流量,就是说我的微服务的不同的微服务之间的调用,那么东西向流量这一类的东西向流量呢,是可以去根据它的一些策略来来做一些这个来做一些刚才讲的比例分流啊重啊这些。
16:25
那么从外头来的这个集群之外来的流量的话啊,称之为北向流量,从从这个图上,如果说上北下南的话,其实也很好理解,那么这个北上流量主要我们会关注它的,比如说呃,外部的这个请求的一些特征,然后域名的匹配,以及呃,TS卸载等等这样的一些需求。那么同时如果我们的当前这个业务流量,我们这个业务它是需要去跟外部的一些服务做集成的话,那么我们可以在网格里面选择让他直接去调用,也可以让他通过我们的一个统一的出口网关去调用。
17:03
那么呃,刚才我也举了一个例子,比如说我们有一些业务,它是需要使用这种固定IP的IP地址的这样的一个健全,那么我们通过对这个出口网关进行一个启动固定IP的功能,那么我们就可以,然后再把这些流量从出口网关出去的话,我们就可以。当前这个业务出去的流量都是拥有这个固定IP地址的。那么固定IP地址其实也是腾讯T里面提供的一个比较在我看来是比较好的一个功能吧,因为它是可以在你的容器里面,容器里面的po,本来呢,它的那个IP地址可能只是在容器里面能看到的,那么呃,在腾讯云的这个VC,以及它有一些EI这样的一些IP这的能力,启用了相关的能力之后的话,我们就可以在普通的pod上去启用一个,呃,像是外面的这个。
18:01
容器节点一样的,同一个级别的一个IP地址,这样的话呢,在外面其他的业务就可以看到我们这个出口网关的一个地址。这样子的话,相当于它的出去的流量是不会做nat的。嗯。那么有了这样的一个流量分类啊,我们来简单看一个辅网格里面的一个流量治理的场景吧,这里呢有一个简单的事例,其实是我们也是一个典型的这种。呃,浏览器一个一个前端页面的一个模式啊,我们可以看到左边浏览器,右边是服务器,首先我们通过呃浏览器会加载HTML相关的静态资源,然后服务器返回,接着呢,就是说呃浏览器会根据这个前端的应用,就是类似于react view这些应用。然后去调用相关的API,再由后台API服务去返回相关的数据,其实这是一个非常常见的一个一个形态,那我们来看一下,呃,我们来研究一下这个前端这个场景,前端在更新的这个场景。
19:06
我们现在要,假如我们现在场景是我们要去把这个前端从V1版更新成V2版,那我们第一个请求我们到达了这个V1版上面,然后呢,接着我们成功的返回了这个内容,然后我们第二个请求,根据前面的这个。这个SL里面内容去加载的JS的时候,很不到了V版本,而这时候V里面很有可能没有这个GS,然后就会对不对,那他就会呃,页面上看来就会得到一个很多的资源误这样的类似于这样的一个页面,那为什么会出现这种情况呢?但是因为我们现在啊,很多呃,我们的开发框架,我们前端的一些开发模式,大家都使用类似于PA这样的一些打包工具,然后每一次他在打包的时候,他的这个javascript CSS这样的一些资源呢,他都会去呃生成一个。
20:03
不同的一个哈希值,它的资源上面都会生成一个不同的哈希值,从而避免浏览器去缓存这样的一些文件,因为你一旦缓存,可能页面的这个程序也加载也是执行不正确的,所以呢,他会去做这样的一个处理,就是会有一个不同的哈希值,那么在不同的哈希值里面的话。在我刚才讲的这个场景里面,如果我们是使用容器原生的这种更新能力的话,就可能会出现这样的错误。有人会说我曾经用过,我我自己也用过这个容器啊,对不对,我好像没有遇到过这种问题啊。啊,那是因为,那是因为什么呢?是因为我们可能可能我们比如说你的集群的这个条件都比较好啊,然后你整个更新非常顺利的,那其实呢,有一种情况是这样子的,我们来看一下这样的一个,就是普通集群上的一个自动滚动更新,实际上在呃。K8S或者T这个这样的一些容器集群里面,如果你去更新一个,你去更新一个呃这种呃无状态的应用的话,那么它其实会帮助我们去做一个自动的一个滚动更新,那么这个滚动更新里面其实会新版的这个pod的话,它会自动起来,然后同时呃旧版的pod它会同步在销毁,那么我刚才讲这种情况呢。
21:24
可能会出现前面三个步骤里面。就是说就是说我们的一个请求来了之后的话,我们根本没有办法知道他到底去的是第一个版本还是第二个版本,我们没有办法确定这一点,而且有时候呢,你可能会出现,当你的集群资源突然呃,一下子没有办法启动第二个新版本的时候,那么可能你会持续的卡在这个位置。卡到这个位置,所以这时候的话,那么可能你就会持续的出现刚才讲的这个脚本错误。那这个实际上是很多业务是不希望看到这样的一个情况的。
22:02
这是我们普通集群里面呃发生的情况,那么网格是怎么做的呢?我们接助服网格的能力的话就可以。可以在它旧版本完全不销毁的情况下,我们直接去生成和维护一个新版本。那么这个新版本它一开始是没有任何流量的。知道我们可以使用一些流量的规则,把一些特征的流量可以转到这个。新的版本上啊,当然这个规则你可以也可以写,写的非常的宽泛,就是说我可以一把切过去都可以,但是不管怎么样,那个时候实际上我们是能够对这样的一个变更的过程有一个非常好的掌控。那么这就是服务网格的一个流量治理能力的一个体现。他就可以非常好的解决刚才我讲的这个变更过程当中这样的一个流量错乱的问题。好,那么后面一个网格里面的能力,也可以说在我们企业,我们这个腾讯这边也是非常关心的一个能力,就是它的安全功能,实际上以前的话呢,我们在呃,单个虚机,或者甚至你是在最早的时候是进程内部,那我们通常不太需要关心你不同模块的这个安全问题,尤其是单个虚范围内,我们也认为,因为那个同一个虚都是我们同一个业务的,那么我们一般来说是会默认它是可以安全。
23:29
可以信任的。那么但是放到我们容器集群里面,其实是这一点就变得不成立了,呃,容器集群的pod与pod之间默认是互通的,而且如果它又是不同的业务的话,那么可能这就存在一些安全隐患了。呃,当然有同学说可能呃的集上是不是可以用一些network policy这样的一些工具啊,但是万一你的集群没有提前安装network policy呢,对不对?所以其实是一个很麻烦的事情,而且network policy其实对性能,对整个集群的性能是有一定的影响的。
24:02
而服务网格里面提供的一个非常好的安全机制,它可以把这个po pod之间的这种流量的话呢,来做一个MTS的打包,打包了之后它实际上是一个加密流量,而且在这个处理过程当中的话,支持对这个从MMTS里面提取的一些信息来做一些授权,那么晚一点我们会呃来讲一下。呃,当然辅网格的可观测能力也是很多同学会关注的,以前可能我们呃不知道自己的维护到底在系统里面长成什么样子,他们相关的调用是什么样子的,那网格其实给我们提供了不同的力度的一个呃测能力,最细的当然就是日志,呃日志然后链路这个跟踪你的请求的这个链路跟踪的情况,以及你的系统的一些指标,这个网格都是在帮我们生成这些数据,从从从而的话,我们就可以为系统啊,可以说提供更丰富的一些指标数据。
25:02
呃,那么刚才我们其实简要的介绍了一下这个网格的一些能力,那么它对于我们来讲,为什么说是一个合适的工具呢?其实主要是我们刚才最早的时候谈到我们的三类的这种业务特点,那么针对这三类业务特点的话,我们会发现其实服务网格都可以有一个很好的满足,首先的话,在业务方面,它其实提供了很好的一个安全特性,同时又能够帮助我们去解决这个稳定,呃,这个发布发布流程的问题,呃,有一个非常稳定可控的一个流程化的一个能力。那么人员这方面的话,因为我们这个可能是跟我们的业务特点有关系的,我们目前的话,我们需要一个比较可能这个社区版的和我们开源版的这个,呃,网格的话不具备,我们可能需要有一个比较自己去研发一个低门槛一点的一个工具。啊,然后最后就是在技术方面的话呢,因为我们技术站比较丰富,然后历史包袱也是挺多的啊,这个可能跟不同的企业,其实大大家各类的it企业都都差不多,呃,各类的企业it的技术可能在这方面都差不多,那所以呢,网格其实在这方面也是具有普适性的。
26:17
那么接下来我们简单来看一下网格在我们呃,腾讯的一些落地的过程。呃,当然呢,这个因为我们呃整个网格的话是呃,部署在腾讯云的容器集群里面,然后我们也用到腾讯云相关的服网和技术这块的话,接下来介绍的内容其实也都可以在这个腾讯的腾讯云相关的产品里面是可以去体验的。首先我们简单来看一下,如果是我自己在可能我自己的一个集群上面去搭建,呃,相关的一些开源工具会是什么样子,那一般来说我们可能要去用这个服网格的话,首先我们会想到说我们的一些策略怎么下,然后我的应用怎么去管理,对吧?以及我相关的指标啊,刚才提到这些观测这样的一些东西,我怎么样去看到,所以通常的话,呃,如果你自己去安装一个,会发现里面其实呃会有很多的内置的一些组件,你是可以相当于开箱即用的,那么这就是其中的几个特点。
27:21
但是这些工具的话呢,它呃,实际上你是需要做很多的定制,要做很多的增强,才能够真正去用起来啊,除非呢,除非你所有人都是专家对吧,所有人都是专家,那么这些工具对你来说就是一个非常简单的,就是要可视化的工具而已。那么这样子的话,可能你能就是一个大的部门,也许能用起来,但是我们的情况显然是不允许这样子的,我们其实是只有少量的少量的人员在这方面比较专业,而大部分的人员,我们希望他能够以一个低门槛的方式去使用。呃,所以呢,其实这个开源的一些工具的话,对于我们来说还是会有一些,呃,会有一些挑战。
28:05
我相信这个其实也是对于大部分的企业,可能差不多如果想去用网格的话,在这方面都会有类似的一个感受。呃,同时本身对于容器集群来讲的话,也是有类似的问题。那我们会发现,如果你要去。把一个微服务从以前的虚机部署给他,现在放到这个容器集部署,那么你会发现要涉及到大量的这个容器集群里面对象的一个维护。啊,具体可能最终体现在代码里面,体现在你的这个,呃,日常的工作里面,就是一堆这个研工具啊,研某文件,所以现在社区里面也流行一种说法,说这个容器相关的研发都是工程师。这个可以说也是一定程度上也是不无道理的吧。呃,但是呢,其实我们在日常的这个工作当中啊,啊,除了去写这些之外的话,还是有很多其他的事情要做的,也就是说如果一个企业要去做好它的云原生相关的东西,实际上除了刚才讲那些之外,还有许多的东西要去关注。
29:13
那么比如说你的容器资源,你怎么去管理,你容器资源,容器的命名空间,它跟业务怎么管理,对吧?然后怎么去申请一个业务,怎么样去接入这些资源,以及你怎么样去维护,刚才讲这个,然后你跟流水线,跟你的CD流程又怎么去结合,后面这个运行发布的时候,你怎么样去做审批,你怎么样去跟这个容器镜像。还有你相关的这个配置系统做集成对吧,以及你后续的这个运维相关的事情,其实它整个这个云原生相关的体系的话,不光是呃一个简单的说,我写好刚才讲的容器那些压就可以。可以搞定的。它实际上是一个,呃,可以说比较全方位的一个工作,是需去注的。
30:04
所以呢,其实我们的落地服网格相当于是把网格作为部门的这个我们呃作为呃,腾讯it的一个云原生的整体战略的一部分来做的。那么在刚才提到的这些业务流程里面,我们着重去强调这个服务网格的相关的工作流程,我们可以看到从上角我们去申请资源,这个是需要跟相关的,呃,业务管理和人员的系统去做集成。还有项目管理的这些东西做集成,那么后续的话,我们要去创建这个容器部署环境,然后去拿到相关的,以及呢,我们去,呃,我们需要有,因为我们有不同的集群啊,不同的集群可能他的情况又不一样,所以我们是需要去跟这个不同的群去做对接啊,以及后面我们把整个这个把一个一个业务我们按PA去管理的话,那你这个的一些初始化的工作需要把它完成,后续的话,中间的绿色部分其实是我们服务网格提出,呃,提供的一个关键能力所在,就是说我们的这个服务的一些治理的一些能力,呃,包括你的流量规则,包括你的观测能力等等啊,那么。
31:14
同时的话呢,既然我们希望能够集成化的去利用这个版本发布这样的这样的一个流程,那么我们一定是需要把这个版本发布的工作要跟呃,要跟服务网格的这个相关的规则要能够集成起来。那么来看一个例子。在我们的这个相关的,呃,刚才我们提到我们会开发一个低门槛的一个呃实施工具啊,我们提供给我们同事去使用,所以呢,在这个工具里面我们会,呃,像现在我看到这个图是我们去部署一个新版本,那么部署一个新版本的时候,我们可以去支持直接从他原来的一个呃现有的版本去复制,去复制这样的话可以快速的去形成一个新的版本,形成了之后的话,它,那么我们马上会去从容器集群同步它当前的一个运行状态,同时的话,我们看到它当前不是主版本,不是主版本的意思就是说。
32:10
现在当前这个版本它还在空跑,它没有任何的流量,那同时也意味着说它不会对现在网的这个服务的流量造成任何的影响,对吧,那么接下来的话,我们就可以采用一些由服务网格提供的能力。那么具体来讲的话,就是说我们在里面让用户去选择,他要切换到。新版的这个流量的一些特征,就好比,比如说我在里面去选择一个这个API路径,对吧,我这个API路径可能是需要去关注的,那我把这个API路径给它先访问新版。或者呢,我可以把一些这个员工的名字,或者所在的部门这样的一些特征。然后选中了之后,那么可能我们就只有那一部分的员工在访问这个网站的时候,他就会使用新版本,这样的话我们就可以去做到,就是说在一个业务他正在发布的时候,他就可以做到,让我们比如说他自己一开始先让他自己这个正在发布的这个工程师。
33:12
先访问新版本,那么接着呢,他再一次把这个范围扩大到他的一个小组,对不对,后面再扩大到部门,那么这样就是一个逐步去调整这个发布范围这样的一个过程,所其实也就是社区里面大家经常讲的这个金丝雀发布,所以实际上在利用网格能力要去做这样的一些,呃,发布能力是可以说是比较简单的。好,我们来简单来看一下一个安全机制,刚才我们谈到是实际在使用的一个呃,流量治理的场景,那么现在我们简单来看一下,在安全机制上面,我们利用了它这个MTS之后,我们怎么样去在工具里面体现出来的?那我们的这个工具,既然希望它是呃低门槛的,那我们就希望整个这个使用流程也是变得非常的清晰和简单,具体来讲的话,我们这个case里面,我们就希望他,呃。
34:09
我们因为目前呢,我们针对所有的流量都是。每一个name space我们是以作为一个业务单元的,所以在我们的场景里面,我们只要控制好不同的name space的流量的一个访问能力就可以了,那么在这里的话,我们可以看到利用刚才讲的这个MTMTS的这样的一个能力,我们就可以做到说,呃,让原本让原本这个集群上name space之间没有隔离的流量,通过这个MTS的技术来实现这个的隔离,最终呢,在页面上其实只是一个非常简单的一个开关而已。用户只需要在。用户只需要在页面上去开启这个开关,那么他就可以在让他的这个流量。无法被其他的来访问,所以这样的话,那基本上我们也就实现了,我们就是说。
35:06
这个刚才讲的这种安全的一个一个基本的安全机制,呃,当然从辅网格的能力上来讲,它甚至可以做到。你同一个name范围内的,或者当然也可以是不同范围内啊,就是你服务级别的控制,它都是可以做到的,你它可以控制你允许你啊来自哪个的,来自哪个哪个服务可以访问我当前这个服务,这个是呃,服务网格其实有非常细致的一个安全管控能力。同时呢,这个其实这个MTS这个技术,另外有一个,呃,在我个人看来,其实非常好的一个特性,就是说既然它是TS,那我们知道它里面是有证书的,那么证书的话呢,以前我们会觉得说我搞一个长效的证书,似乎也不是很安全啊,这个证书太时间有效期太短了的话,我也老去更新这个证书,对吧?其实呢,在辅网格里面,呃,149网格里面,其实内置的一个P,也就是说它自己是可以去,呃自动的去。
36:06
颁发和这个更新这个证书的,它默认更这个提供的一个workload,就是pod级别的一个,呃,一个证书的有效期是24小时。这是它的安全机制。那么简单的聊一聊,我们其实实现了刚才这样的一些东西的一些技术原理吧。其实呢,从整个体系上来讲的话呢,这个整个这个产品它是呃,我们我们想做一个低门槛的一个产品的话呢,肯定还是希望能够结合我们相关的一个体系的啊,所以呢,在最底层是我们的相关的项目啊,运营啊这样的一些系统,那么他会关注我们的资源使用情况,然后去呃,去支持我们的一些配额和结算。呃,那么中间就是我们关键的核心能力了。
37:03
呃,在这个左侧的话,是我们在容器应用需要去使用到的一些其他的pass资源的支持,呃,中间的话,蓝色部分其实正好就是我们的这个t ke所提的能力,那么上面这个,呃,这个绿色的部分其实是。可以说是我基于这个服务网格,然后我们去封装的一些能力。所以最终的话,呃,左侧的两个能力,呃,两个部分最终的话合起来会变成我们相关的这个业务数据,它其实是这样的一个关系。那这个里面其实关键的一些场景呢,就是刚才我们达到的,我们提到的这种关键场景,其实主要是这些绿色的这个部分,那么这些部分对应到集群上,其实呃,如果有朋友能够比较熟悉服网格或者容器集群的话,可能会比较清晰的能够知道它相关对应的这些场景里面都具体包含的内容,我们来简单看一下,其实呢,对接集成配置的话,主要关注的是我们怎么样去跟这个容器集群,跟我们的服务网格去做一些做一些对接,然后中间部署发布,我们希望能够去关注它的这个呃容这个容器应用的一些发版的情况,还有你日常的一些维护,包括重启啊这样的一些操作,还有你去看日志这样的一些需求,那么后面就是提到我们流量治理,流量治理刚才有提到,呃,合作发布的一些能力啊,然后你的这个熔断限流啊,这样的一些规则的维护,那么最后就是诊断和观测。
38:35
那么这些功能的话呢,它都是其实都是对应到我们容器集群和服务网格上面的一些规则,这个我们应该很多同学都是比较清楚的,如果对这个网格有一些经验的话啊,举一个例子啊,这里提到我们在。界面上可能会让用户去配置他的访问方式,所谓访问方式就是说你的网站,呃,别人要怎么样去访问你这个网站,就好比说别人输输入什么域名,别人那不要。
39:05
要不要给他提供这个HTPS的能力等等,那么这些东西我们会知道,其实它对应的是网格上G这样的资源。再举一例,就是刚才我提到的这个逐步的去做流量切换的这样的一个灰度发布的能力,那么这个灰度发布的能力主要其实用到的是我们的这个service,其实要配合destination这样的一些规则来来提供啊,所以呢,其实它我们你可以理解为有点像是一个规则生成器了。那么顺便聊一下,刚才我提到了说我们是以namespace级别去做一个隔离的,那顺便聊一下我们这样的一个机制是怎么样去实现的。呃,其实在我们目前的这个网格的一个部署拓里面的话,其实我们没有把这个多个容器集群的网格给它,呃,给它集成起来,实际上TM是支持的,就是说我们在给多个群。
40:05
直接去用把它,把它做成同一个网格啊,然后我们其实没有这么用,因为目前我们暂时还没有这个跨集群调度的一个需求啊,未来可能会把它,呃,这个按照需要也有可能往这个方面去探索,那么我们目前的呃这个场景的话,主要还是将这个每一个业务。限制在他一个name范围内。那么每一个业务范围内的话,就可以去部署它的多个微服务,大概是这样,然后每一个业务呢,会有它的入口网关,这个可能跟社区版的这个呃list的部署会有一些差别,那么社区版的里面一般它是呃会有我们使用它默认的一个有呃放在那个system里面的运营空间了,那那个里面的way,那我们呢,其实希望不同的业务之间的流量是需要隔离的。有的业务流量大,有的业务流量小,那我们希望他使用不同的这个ateway,同时的话呢,Ateway再对接到外面的这个腾讯云CLB,这样子的话,CLB其实是note balance啊,就是负载均衡,那么我们就可以在这些里面把这个流量呢,就是有一个非常清晰的一个,呃,透谱了,我们可以看一下右边这个图,右边这个图呢,绿色和紫色的这个图分别是不同业务的两个不同业务的流量。
41:27
那么对于这个绿绿色的这个就是业务二这个业务来讲,如果他需要去调用这个业务,那么理论上他们是只能通过这个外面的CB来调用的,而不能通过呃这样的方式来调用,这是我们呃做的这样的一个规范,相当于。那么基于这样的一个规范的话,我们刚才讲的这些空间隔离啊,这样的一些能力,其实就可以去实施了。既然既然我们要定义这样的一种业务隔离单元,我们其实就需要去做,其实需要去做很多的。
42:07
具体在服务网格上的一个一个处理啊,因为实际上这个社区版的E,其实它是一个把自己定位成一个集群级别的一个服务治理的工具,呃,他通常首先他就会整个集群的这个所有的资源,以及呢,以及他也会去。天然它就允许你不同的space啊,不同的这个ateway是可以去引用其他里面的服务的。所以这是它的一个,呃,它社区版的一个天然的特性,那对于我们的场景来说,我们希望能够防止这些东西,所以呢,我们也是需要去在集群里面做一些对应的配合,包括一些web来对这个做一些检查。确保确保不会出现这个跨的一个调用。对应的,其实除了刚才讲的这些这个隔离,呃,除了刚才讲那个流量隔离之外,其实还有一些其他方面的隔离啊,比如说你的这个KS或者说t ke上面的这些这些资源的隔离,那么就是天然的本来集群就是有带的这些版本,呃,这些这个权限的一个隔离,所以集群上有比较好的一个这个RBAC的一个权限模型,所以这个我们是可以通过控制它的用户的权限来使得你可以跨ne去操作。
43:28
这是第一个部分,第二个部分是服务发现,那么既然我们的English getateway其实根本就不会去引用到另外一个里面的资源的话,那我们就干脆让他。就直接不能发现另外一个name space的服务了,所以呢,我们可以在呃T里面去做一个这样的开关啊,然后把同时可去控制这个资源,通过这个资源这个规则来控制它的这个单个的pod的服务发现的一个范围,这样子可以极大的去。三个里面拉取到的这个,呃,相关的呃的配置的规模,呃,我们在。
44:06
没有做这个隔离之前的话,你单个name可能会拉取到的配置有数十兆,可能四五十兆,但是做了这个隔离之后的话啊,我们基本上每个拿到的配置可能不到一兆,大的有一兆,小的只有4500KB,所以其实是一个相当巨大的数量级的一个提升。效率的提升,刚才有提到这个流量规则的隔离,那我们是希望去通过一些B来控呃,它的集群的行为,跨space的一个引用。呃,流量链路,流量链路刚才有比较详细的介绍,就是CV这样的一些啊,一个入口,以及就是在出口上面,我们也是给每个去配备它的这个。好,那简单的聊了一下,我们刚才提到的这个,我们是怎么样去使用服务网格的,那么其实我们也在某些场景里面遇到了一些其实原生的服务网格还不能满足我们的需求的地方,呃,简单聊几个场景。
45:07
第一个场景的话,我们希望做到的是消除这个南北向、东西向规则的一个相互影响,其实这是什么意思呢?我们会发现在我刚才讲的这个,我现在要针对不同的这个人群,比如说是我当前这一个人,接着是我的一个小组,接着是我的一个部门,然后逐步去做灰度发布的过程当中,那么我一定要生这个相关的service规则。那么在water service里面我们去写啊,写匹配,然后接着去匹配,完了之后呢,我要去写我的目标,我转发目标是哪里,所以我的服务和他服务的版本是什么等等,这样就是我要去生成的一个规则的一个完整内容啊,这个可以体现为上面的这个图,就是说我需要先有匹配条件,再有路由选择,最后呢,我还可以加一个附加处置,所谓附加处置就是说我可以啊对这个请求加一些,或者是做个拦截啊,或者做一个重等等,这个是它的一个流量模型的一个流量模型,但它这个流量模型有一个缺陷呢,就是啊,你会发现。
46:19
你针对这个,你针对这个上过来的流量与针对这个你的。Pod与pod之间的流量。你的规则其实。要分开写。如果你写在一个里面的话,你就会发现刚才我讲的那些匹配条件,你对于外来的流量,你每个每个就是你都需要把刚才讲的那些业务的规则要加到他的这个转发规则里面去。那么这个就很尴尬了,呃,因为呢,我们的业务的规则,比如说我要到要具体到某一个API的一个,把某一个API转到这个V版本,但是呢,其实针对外部的流量的一个规则,其实他希望是只要一个简单的一个A了。
47:06
然后API底下的所有的子径都沿用这个API规则。而刚才讲的这个。这个业务的这种逐步发布的这个规则又需要往里面加,所以就导致很麻烦。你对于?同一个规则,你希望同时让它生效到这个南北向与东西向的时候,这个流量的时候就很麻烦,因为你南北向的。这个转发也是用到了service,东西向的这种转发也是用到了service,但是这二者对于一个请求来说,只有一个能生效。所以你。你就必须把们不同的这个位置,刚才讲个规则都写进去,这样就会导致你这个整个这个water service实非常的混乱的,难以维护的。呃,那么我们希望在这个里面,我们就使用的其实,呃,在其实就是使用的一个这个很简单的一个脚本,也就是说我们把把这个外部的这个流量的一个转化规则呢,我们就不用water service了,那我们把这个water service这样的一个匹配呢,就留给啊,留给这个东西向这个规则。
48:20
然后同时在里面把gateway也写上way。那就可以了,所以实际上就可以做到就是。可以做到一个规则。能够同时作用于南北向流量、东西向流量。这个是啊,我们的其实第一个场景,这个场景其实不算很复杂。但也是一个使用的技巧。呃,另外一个呢,就是关于这个范域名动态转发的,其实我们在使用这个辅网格的过程当中,我会发现它虽然已经很灵活了,但是它目前提供的相关的规则里面,我们需要使用的,我们需要填的都是非常固定的值。那比如说左边我们现在如果希望把这个A点点com转到site a服务,同时B set.com转到B服务的话,那我们就要分别为他写一个规则。
49:10
那么如果说我们现在正在做的是一个多租户的软件,我们希望针对每一个不同的域名自动起一个微,起完了之后,我们还希望能够。自动的去,呃,根据它的域名能够转发到对应的服务的话,那么后面这一个转发的功能的话,对于原生的这个呃网格来讲,可能就是有一些吃力的,那我们也是使用刚才讲的这种啊网编程的方法啊,我们会发现在辅网格里面,你启用了这个相关的脚本是非常容易做到这一点呢,你可以对这整个请求里面的各种开来做一些呃简单的一些匹配,然后去把它作为一个作为一个呃,把你路由的结果作为一个它的这个head,然后接着呢,我们再在这个route里面去把刚才讲的这个head给它作为一个值啊,取值作为一个取值,然后作为它的。
50:04
这个路由的一个,呃,根据所以呢,这样一来的话,我们就可以轻松的实现一个泛域名转发,在我们场景里面,除了刚才讲的这种多租户的应用之外,我们还有一个场景就是说。我们在测试环境,希望由这个就测试同学,希望由他们能够不需要去,不需要去为每一个服务都把它暴露出来。我们我们的场景里面测试同学希望说我只要。直接指定一个微服务服务的名字及它的端口和name,我就可以直接访问到这个集群里面的各个微服务,对吧?那么呃,那么因为实际上呢。最终在业的上线的过程当中,其实并不会有这样的访问的需求,所以我们也不希望把这个呃测试需求。强行的加到这个业务的这个访问方式里面去,作为一个声明,于是呢,我们就直接把它做成一个集群级别的一个能力,然后那么相关的这个测试同学就可以直接用这种约定俗成的方式去访问集群上的各种服务了。
51:11
这个是范玉民动态转发,最后再简单介绍一个场景,就是说呃,我们其实在有些场景里面,希望他能够。只染色不处理,什么叫染色不处理的?在这里有一个场景啊,就是说。我们来的请求会先到达服务A上面,那么服务A上面收到了名字叫张服务。就已经它的程序代码可能不会转发这个,所以呢,其实在D这里就看不到了,同样E也看不到,所以我们会发现,如果你希望。一次发布里面涉及到多个微服务,而这些微服务它要都要匹配一个条件的时候,我们就会发现。这个除非些微服务都转发了这些的,不然的话其实我们很难去做到这个。
52:05
同一个按照同一个特征来做这个灰度发布的。那么呃染色呢,其实就是微服务治理里面的一个呃一个术语,就是说他把这个流量呢打一个标记,然后这个标记的话就可以啊,穿透到各个服务里面,我们就跟这个各个服务研发的团队去做一个约定,请他们能够去把这个染色的这个标做一个转化就可以了,所以在这个请求源头的地方,我们就是去对它做一个这样的染色。然后呢啊,然后在这个各个各个地方,就是比如说刚才我们提到的ADE这三个服务,那么只要在A这里做了染色的话,做了这个标记的话,那么B在做的转发,这个B做转发,那实际上他后续就是根据这样的一个标记去做的一个匹配,然后去做的一个微服务的一个。啊的一个。
53:00
跨版本的一个调用。那么在这个过程当中,我们会发现我们需要一种能力,就是在A里面。我们希望它具备一种能力,就是它只染色,它对这个请求不要处理,但是对于原生的服务网格里面的话,其实是不具备这个能力的,就是说你啊,你做了一个match之后的话,你肯定是需要对它做一个转发的,一定要有一个路由的,那么转由完了之后,你可以去做一个处理,比如给他加一个handle,那当然呃,有同学说呢,我能不能把它原来原本要转发到的那个位置写写下来,作为。你的那个的地址呢。啊,其实也是可以的,但是那样子会导致还是会导致,刚才讲那个流量基本上是非常流量规则,是非常难以维护的一个情况。嗯,是因为你刚才我讲这是其中一条规则,因为你如果。这种规则很多的话,你会导致你的这个water service会非常难以维护的,这就是我们其实是实现了这样的一个,就是说它只需要去我们对于一个请求,他只支他可以支持只染色不处理,这样子的话,我们其实可以支持多个这样的一个呃规则,然后同时去息的多个服务,并且对它的流量,我们可以选择对它的流量有特征啊,有这个影响或者没有影响都是OK的,这个是我们在产品里面把它提供出来,以一个可视化的界面去提供出来,然后啊,让用户去一开始可以先去啊,去设计它的一个度的计划,然后。
54:36
然后逐步的去对这个计划进行一个实施。呃,今天我的分享的话,主要内容就是这些了,然后接下来如果有朋有这个相关的疑问和交流,可以一起聊一聊。是的,感谢陈老师的精彩分享,那线上的观众朋友呢,可以扫描我们直播屏幕左边的二维码,进入我们的今天晚上的互动问答直播专区提问。
55:08
然后写下问题的时候,记得要同时留下你的姓名跟微信号,呃,如果就是因为我们会选取前三名提问者,然后会送出我们今天晚上的奖品,就是腾讯的。虎年公仔。好的,我看到这边那呃。问提问专区已经有线上的朋友正在填写问题,老师这边也可以关注一下。好的。
56:07
我前面已经有提了两个问题了,我先把前面那个尝试呃,聊一聊哈,第一个就是如何做好一个全站服务网格的链路规划。呃,那么这个其实我的理解如果没有问题的话,其实我觉得主要还是要关注业务了,就是说服务网格的链路规划呢,它本身,呃,只是一个就是集群的级别的一个服务治理工具,就是说它是一个服务于我们的业务的,那么服务业务的一个工具,所以呢,还是要根据你业务的需求来做这个链路的一个规划,所以那像刚才我提到的我们的场景就是说。会希望以这个namespace作为一个范围啊,去规划它的链路,但同时其实我也看到在公司之内也有一些其他部门,他们会把这个。集群作为一个单位去去规划它的流量的,那么在那些有一些比较大型一些的业务的话,那它一个集群可能就是一个业务的环境,那这种情况下可能它就需要呃跨的这种调用,然后同时对于呃不同之间的调用,相对来说就不需要有那么非常。
57:18
非常敏感的一个关注的。所以还是要根据业务形态来来关注。第二个问题是说,服务网格跟KS有哪些本质区别?呃,这个其实。可以这么理解吧,就是K8S,它我做一个比喻吧,其实K8S更多的是呃用来做调度容器的,也就是说它其实调用的是就是容的一个运行资源,它有点像我,所以我说做一个比喻,就是说它有点像我们的呃虚机的管理工具,如果像我们以前在操作虚机的时候,它有点像我们虚机的管理工具,它帮助我们对容器的去管理容器的一些起的动作,然后呃帮助我们去关心这个容器的的一些事件,以及你这个容器就是pod啊容pod的一个网络的一些这个通讯能力,基本的网络通讯能力。
58:22
所以这是K8S提供的。所以它你可以理解为它有点像是我们以前这个虚模式下的有点像open对不对,所以它是可以帮助我们去把这个容器让它运行起来。而服务网格的话,它关心的是容器之间的这种调用关系,你的你的流量行为,所以对于K来说,它其实对于你的这个容器与容器之间的网络行为。他认为你就是一个标准网的通信,所以他不会关注到你的这个,呃,你具体的我们我们平常经常会谈这个网络的所谓七层,那么其实服务网主要关注的是网络里面的从第四层,也就是呃,TCP这样的一些这样的一些应用协议,然后到我们的呃第七层。
59:07
第七层就是我们的一一些实际的应用协议,比如说你的啊HTTPGPC这样的一些服务,这样的一些通协议,所以其实KS它更多的是关注容器本身的一个运行,以及呢,它保障容器本身的个基础网络的通信能力,所以它K8S主要关注,如果从网络这个角度来讲的话,它主要关注的是网络的这个从其实它没有一层啊,主要是二到三层的通能力。那么换言之就是K其实不去尝试理解你这个流量里面的一些一些特征的,就比如说你的HT里面的呀,你的GPC里面的这个函数呢,它其实不去理解这些东西,服网格就是可以更加细度的去关注到流量里面的这些内容。第三个提到了服务网格在安全方面的应用网格,这个我不是特别理解这个问题的具的指向性,我简单的谈一谈,就是说呃,安全方面呢,其实现在有一个最近呢,社区里面其实有很多人在关注这个安全服网格的安全方面的一些特性,呃,我个人其实也也很看好服网格,实际上它已经慢慢的可以成为一个,呃类似于应用层的一个有点像防火墙一样的东西,所以它有点像可以可有点像我们呃以前呃,可能更底层的一些防火墙,包括你去使用IP table啊,或者使用云上的安全组啊这样的一些方法去实现的防火墙,那其实服网格里面可以实现更细力度的一个安全功能,比如说你可以让他去,刚才刚才我有讲到,就是可以去去针对这个,针对这个去做流量隔离,其实这个还只是非常小的一部分,它里面还。
60:56
可以实现你针对比如说HTTP的某个ul,然后你去做一个什么样的一个处理,比如说你要求他登录对不对,可以对接一个GWT的一个provide的,呃,那其实是非常简单的,以及呢,你在这个流量这一块的话,它也是可以有更细力度的,可以到这个七层的一些特征。
61:18
就好比你HTTP的这个呀,然后。像这个呃,Ul啊,或者是你的域名呢,其实都是可以根据这些方面来去做这种安全限制的。呃,当然当然,其实你要去实现这些方面的能力的话,都会需要关注它的这个规则的一个可维护性。啊,因为目前如果我们没有把它做成一种比较,就是比较。持续可持续的一种维护机制的话,那么很有可能你的规则容易容易相互混乱,容易相互的就是干扰,这个也是一个值得需要去关注的问题。第四个问题问到服务网格中应用间的访问是通过service吗?事实上服网格里面的应用间的访问,它是根据service去发地址,然后你信实际上是直接去访问po,所以呢,我们网格里面也是可以去设置一些这个负载均衡的策略的。
62:21
那么比如说你去做一些保持啊,这些都是可以的,那么它其实比这个KS原生的这个session affinity要好一些。网格的注册中心用的是K8SERVICE,还有其他的注册中心。呃,其实在现在我们平常关注的这个服网格就是九用的比较多嘛,它里面其实是默认使用s service,但同时也是可以去配置其他的一些这个服务注册中心的,包括啊这样的一些,呃,然后还有它里面提供了一个呃,服务网格的一个。
63:01
呃,协议一个配置协议,通过实现这个配置协议的话。很多其他的包括卡这样的一些,呃,传统的注册中心其实都可以接入网格的。像在我们腾讯里面的话,因为啊,我们除了一些团队在用网格之外,还有很多团队在用另外一个技术叫北极星,那么我们其实也把这个网格跟北极星做了一个集成,也是我们在北极星也是腾讯在开源的一个项目,嗯,大家可以关注一下那个里面有相关的网格的一个集成的实现。呃,问题五提到如何从传统的这个微服务接口调用转化为服务网格,其实这个转化是非常简单的,因为我们传统的微服务的话,主要是我们提到了有很多的这个。像因为有自己的一些服务注册机制嘛,所以主要还是把传统的这个服务注册机制,把它接入到服务网格里面来,那么后面的工作基本上就是跟呃,服务网格里面的标准的功能是没有什么差别了,所以你直接去使用就可。
64:13
问题六说服务网格在service前面做一个代理,如果服务没有service,是不是也可以做灰度发布?呃,服务没有service,指的就是普通的,对不对,就是可以做灰度发布,没有做没有普通的。没有普通的这个没有service的这种普通的po,我好像没有试过,我想。应该是不行的,那至少呢,还是要至少要做一个head service,就是你可以没有IP,至少做一个空壳的service,如果连service都没有的。那么你访问域名是什么呢?就是内部的这种,呃,相互访问的这种子域名也是要有一个,也是要有一个方法的,所以还是要有一个service的,但是在这里注意的就是说在service之前做一个代理,其实这个也可以这么说吧,他大家会关注到他的,所以他这个呢,这个东西反而是跟service其实没什么关系,它是内置在这个里面的。
65:12
所以它是跟service没什么关系,但是呢,你要想能够在一个里面去相互访问的话,你还是要有一个service。问题七说的是服务网格怎么去做熔断,比如某一个服务调用第三方出现问题,会导致整个集群崩溃,最明显的是外部CLB超时。这个的话呢,就是我们输网格里面其实可以配一个destination rule里面,你可以去配它的这个,呃,一个错误的一个情况,然后你可以去配置它这个超时的一些判断的方法,比如说超时或者是五叉叉的这些错误连续发生了几次,你就认为它是有问题的,然后同时它还可以配置你熔断的时间长度啊,以及你熔断的流量的比例等等。
66:03
这样的一些配置参数其实还是非常好的一个特征,但是服网格里面熔断的话,也可以说也有一个小问题,就是说它的力度不够细,它主要还是以实力为力度,所以如果想做到接口级别的话,可能需要自己做一点事情。问题八说的是,如果是做级别隔离,对于一些通用的微服务,这些服务各种业务都会用到,怎么部署?每个都部署一套吗?啊,这类的服务的话呢,其实它也可以把它的这个流量入口接入到外面的这balance上面去,就是C上面去,然后再由其他。其他的这个业务的话呢,再通过这个CB的IP地址,或者是配了一个域名去访问会比较好,这样子的话,我们不管是业务的调用方,还是业务的自己,就是业务负责业务的自己这一方就会明确的知道当前这个访问方式它是对外的。
67:03
不然的话,如果大家直接调用的话,可能就你如果日后需要做一些做一些迁移啊,做一些重构啊,那么就可能会影响到别人调用你的业务。而如果说你现在把流量都让他从外部的CB进来的话,那么你CB上有哪一个域名,它的路径是怎么转化进来的,其实我们都会相当于是有一个契约了,你你让别人知道你这个。域名这个地址就是你会持续维护的,同时你自己要知道这一点,别人可能会通过那个外面的那个域名会访问到你,所以你需要我们自己作为这个通用服务的一个运维方,我们要知道这个东西,我们需要很好的去维护他的这个可能力。有没有遇到JWT认证要做到。多租户的一个支持,类似于这样的一种动态的一个格式。
68:06
呃,我大概理解啊,老实说我觉得现在这个在这方面都做的比较做的比较差,因为其实刚才也提到了这个类似于。比如说域名这种动态解析嘛,嗯,也是做不到的,那么他他原做不到,那么对于对于这个朋友提的这个问题的话,我的其实我没有这样去对接过,但是呃,根据我对这个149这个软件的一个了解的话,他应该也是不会提供这样的能力的,就是说你。通过某一个标签动态的拿到一个值,然后把它绑定到,然后把它呃填写到你的这个这个呃集成地址里面去,我的理解应该也做不到,那这种的话呢,一般就需要使用filter来做,因为filter是。的相当于执行策略的那个最终的那个程序嘛,所以这个可能需要需要研究一下,应该也是可以做到的,就是最终效果可以做到,但是本身没提供部分。
69:09
相比于传统微服框架,比如spring cloud,微服服务网格有没有什么劣势?这个是个很好的问题啊,因为我们很多人去关注一些所谓的比较新的技术的时候。就好像它是一个非常完美的东西,没有什么问题一样,那网格其实有没有什么问题,当然其实是很多的一些。我觉得不一定是劣势,但是是需要考虑的一些点。比如说呢,比如说微服务网服务的框架这些。实际上是开发同学是比较熟悉的,日常在这个他的开发环境是很容易。呈现的,因为他他他就在代码里面。所以其实开发同学是非常容易熟悉的,但是服务网格因为它在集群里面,所以通常在本地是不太好启动起来的。那么就会导致说。
70:00
其实它在本地的这个运行的过程,跟跟在网格上面运行的效果可能会有些差异。所以这样其实。呃,有时候会带来一些莫名其妙的问题。呃,我们曾经遇到一个情况,就是说他两个程序他们相互做HTP调用的时候。那么开发同学写这个。写这个http method的时候呢,它写成了一个大写的,第一个字母大写后面就是小写,这样它两个构成直接去调用的时候是没有问题的。但是它部署到网格之后就会有问题。因为辅网格收到请求之后的话,他会先尝试去解析这个请求。然后发现第一个字母是大写的这种的话。他不认识。啊,它必须要求这个所有字母都是大写。所以所以这个劣势就很明显了,就是说。你毕竟还是跟这个代码是有一定距离的,那么实际上有一些东西是没有办法做到完全一致的,这是第一个,第二个的话,其实呃,对于像spring cloud里面有一个,像一个组件ne里面的一个,那这个工具的话,其实用来做熔断,以及它熔断其实非常好用的。
71:14
但是在刚才我提到的这个服网格里面的话,它的熔断其实是比较呃,力度比较粗,它是做到一个做到一个实力级别的,那么这样子的话,你其实呃,这个Netflix也可以做到。呃,方法级别的一个API级别的一个垄断是可以做的非常好的,所以这些方面其实服务网格的默认提供能力还是还是一些。呃,主要是因为他就是他的他们提供的这个熔断能力,跟我们就是传统上我们期望的一些熔断能力,会有一些理解上有一些不一致吧。当然我们自己也是可以基于这个去去做一些拓展的。然后让他支持呃,传统微框架的一些能力。
72:01
呃。服务的网络日志分析监控指标是怎么做的?呃,服网络日志分析其实是很容易的,就是说我们。呃,因为对于服务网格来说,它本身默认是会去生成这个访问日志的,所以你直接把这个访问日志就采集到你的一个集中的一个地方,比如说这个腾讯云的这个日志服务,或者呢,就是采集到你的的这个相关的工具里面都是可以的。然后他也提供了包括以及以及Jason的不同的格式,所以分析起来也比较容易。呃,监控指标是怎么做的,监控指标的话呢,因为在。我们的里面其实它生成了很多的这个指标,所以可能我们,呃,大部分的应用来说,大部分的应用来说,一般只关注其中的一部分这个指标,所以主要还是要对他这个生成的指标要做一些优化,不是所有的指标以及所有的标签我们都要拿,因为你如果。
73:12
整体存储的话会非常的耗费的。呃,所以我们的实现的话呢,还是去,呃,基于他原先的这个普米修斯的格式的指标,我们会把这个指标做一个转发,转发到我们集中的这个指标平台。然后去做这个后续的这个监控告警的一些能力。呃,问题13A强化。呃,N的话,其实我更多的了解它主要是在做这个网关,它在内部的话,这个微之间的这种管理能力,我还没有太多的了解,所以不好判断它是不是可以替代。
74:07
呃,当然同时除了刚才讲的这种服务与服务之间的这种流量的管理之外,还具备一个集群的一个啊,流量的这种故障转移,以及集群的这个。呃。像一些一些这个做负载均衡这都是可以的,所以其实能力可以说它的相关的能力还是可想象空间很大吧。呃,其中有一些其他的问题,我可能因为不是感觉好像不是特别清晰啊,所以就不回答了,然后呃,那我们今天时间是不是差不多了。
75:05
啊是的,对,感谢沈老师今晚的分享,然后刚刚也给大家解答了很多问题,大家提提问也非常的热烈啊,那刚刚老师也说了,就是我,呃老师呢,会主要聚焦大家提的就是问题要比较清晰,然后呢,老师这边就是他能够回答都尽量帮大家回答,如果大家还有其他疑问或者相关的希望有更多的探索的话,可以加我们技术交流群,那啊我们可能会有其他的专家,如果对相关有了解的,后续可以交流也可以,大概就是啊通过网上的一些资料查询啊,再去进行一个解答,嗯,那今天我们的分享呢,就大概到现在,呃到啊到此结束了,感谢老师今晚的分享,也感谢啊,全程在线,一直守着观看跟提问的啊朋友,然后来不及观看和错过观看的朋友,那也不用遗憾,我们每一次的直播呢,第二天都是可以观看回放的,那同样的直播观看链接,包括我们的那个腾讯原生视频号,大家进去都。
76:05
可以再观看回放的,好的,那我们今天的呃,节目就到此结束啦,那我们下一期原深圳发直播,再见,感谢大家。谢谢,谢谢大家。
我来说两句