大家好 到十一点五十了那我们就开始分享我是张海文 是来自中国移动今天我的分享的内容是服务网格在移动云中的应用实践我简单介绍一下我自己我是移动云的服务网格的负责人也是Esteo社区的member这次分享打算是分四部分来做一下分享第一部分就是讲一下服务网格在移动云里边有些什么样子的应用的场景第二部分是讲一下我们在应用的过程当中遇到了哪些技术的问题然后在技术这一块做了哪些探索第三块就是我们在使用的过程当中也在逐步的产品化在这个产品化的探索的过程当中有哪些沉淀第四个就是讲一下服务网格在移动云后面的一个未来的展望接下来讲第一部分先做一个概述吧先介绍一下移动云移动云是中国移动的云计算平台现在也是国内发展比较迅速的一个平台目前的话在公有云领域市场份额排到了第五位然后在一些细分领域的话比如说艾斯领域排到了前三然后在一些专属云的综合排名上也排到了第一这样子所以随着这个移动云的发展然后在服务网格在移动云当中也逐渐地在应用主要是在移动云里边目前有就移动云上面有很多的公有云的产品目前有将近50款产品在通过服务网格做这种汇度发布还有流量的治理还有可观测这些功能然后另外我们也形成了一个是内部的一个运为平台OPS平台去支撑内部的产品还有就是我们也形成了一个CNP的产品原生技术平台去提供给外部的用户这种服务网格的能力接下来就大概介绍一下我们的这些应用的场景第一个就是刚才说到的汇度发布这个是我们用服务网格最主要的场景简单介绍一下就是我们的汇度发布的场景比较的多就比如说有这个微服入口级的微服的汇度发布还有就是微服内部的这种微服要做汇度发布还有就是再复杂一些的就整个链路的这种微服的汇度发布流量从网关一直到了微服内部所有的所有这个链路上的微服都可能要做这种汇度的发布还有一个就是多组互场景下的微服的汇度发布这个多组互多组互场景多组互场景后面会再详细地介绍还有就是做一些可观策性方面的探索比如说服务脱补和链路追踪刚才讲到的是汇度发布然后我们还有一个应用的场景就是做这种流量的涌道就是在移动云里边有不少的产品是比较的复杂包括有有可能包括有就是几十个微服甚至是有上就是上百的微服然后这些产品的迭代又很频繁每个迭代可能会并行地再搞之后就带来一个问题就是说如果这种一个就是为每一个迭代都去部署一套环境的话其实是很困难的但是多个迭代共用一套环境的话又会带来互相之间的干扰互相之间的影响所以我们是基于East Hill家Open Telemetry做了这种全链路的这种流量涌道来实现这种各个迭代的环境之间的隔离这个是我们用的相当于是第二个场景还有一个是我们做的一个探索叫算网原生算网原生这个概念可能大家会比较地陌生我先讲一下背景这个背景就是在2022年就是国家提出了东树西算就是用简单来说就是用西部的比较低成本的一些算力资源去满足东部的这些数据计算的需求然后后来就是像移动还有业界其实大家都对应地提出了一个叫算力网络的概念今天上午的那个主论坛我看了一下农业银行的分线里边也提到了算力网络这个算力网络就是为了实现东树西算的需求能够让以算力为中心然后这个网络为基础能够去把这种算力和网络能够灵活地进行编排接下来就是到了第三个阶段就是我们云原生的话是其实是这种算力的编排的一个主要的技术但是这个算力网络就对云原生就提出了一个更大的挑战所以移动于提出了一个算网算网原生的概念我们现在其实也是在进行一个初步的探索我们就是选了一个比较具体的一个场景做了一下探索这里边的场景就是说比如说一个移动云的公有云的公有云的用户去使用移动云提供的AI服务比如说人脸识别这样子的AI服务它要访问这样子的接口的话是优先是就是究竟原则然后但是我们的这个算网原生也会动态地去把他的这个请求的流量去分配到多个资源池里面去根据这个多个资源池里面的资源的情况去分配这个流量调整流量以及调整这个算力的资源这里边就是一个核心的关键的技术就是Eastel的这个单网络然后多集群多就是单网格多集群然后多网络这样子的一个模型我大概说一下这个架构就是这里边就涉及到三个资源池比如说苏州资源池杭州资源池和成都资源池苏州资源池相当于是一个控制平面或者是说一个大脑的角色然后这里边第一就是苏州资源池里边会有Eastel这样子的就是服务网格的控制面也会有一个就是算力中心算力中心会收集比如说杭州和成都两个资源池的资源的情况然后算出来这个多个资源池的流量分配比例告诉EastelDEastelD把这个流量规则下发到就是一个网格里边的多个资源池的塞特卡里边去这样到了数据面的话一个就到了第四步一个普通的杭州的用户去访问AI服务的话就会就是会究竟访问这个Eastel的网关然后再去访问AI的开放服务再接下来再往下访问AI的模型程的这个API的时候就会按照这种相当于是算网原生计算出来的这个流量比例然后去进行流量的分配这样也能够实现也能实现一个比如说西部的资源就是成都的资源也能够实现这种东部的一个数据计算的这样子的一个需求这个是我们的在这个算力网络或者是算网原生这一块的一个探索接下来就是介绍一下我们在技术方面的一些探索主要是想要分享两块一块是多诸户方面的时间一块是那个在IPV4和IPV6双战方面的时间这个多诸户的时间可能有一些移动自己的移动云自己的特色就是移动云上的我们最一开始的时候移动云的产品是每个产品去部署在一个KBS里面然后每套KBS都申请一套物理机这样就后来发现这个资源浪费太严重了然后公司就开始进行共享KBS的这样子的一个工作计划就是让多套产品都部署在一套KBS里面去共用一个KBS每个产品都部署在单独自己的内幕space里面这样子就对East Hill这一块带来了一个挑战或者是一个问题如果按照East Hill的这种经典的部署模型的话一个集群里面就一套服务网格这样就会带来两个问题一个是性能的问题一个是故障隔离性的问题性能的问题就比如说如果这个集群里面的多个产品都共用一套数据面然后共用一套网关然后可能就会流量大的产品就会去对那个流量小的产品带来影响另外就是一些故障隔离性的问题比如说一个公共的网关发生了发生了一些故障就会影响到整个集群的产品的访问这个是一个很大的问题所以我们就产生了一个需求就是需要在Name Space级别有一个East Hill有一个多住户的解决的方案我们想要的最理想的一个解决的方案就是能够做到这种一个集群里面能够有多套服务网格做到这种完全的隔离每个产品有自己的服务网格就包括控制面和数据面都要完全的隔离但是我们就是在探索的过程当中发现这个东西是可行的但是但是涉及到涉及到需要修改East Hill的元代码然后带来会带来一些开发就是开发和维护的成本还是挺高的最后我们是没有去采用这个方案采用这个方案为什么会就是会有这个问题呢就是主要是East Hill就是服务网格里边的服务的身份认证的机制这个昨天East Hill扛上华为的超盟大佬也介绍了这一块的相关的东西我讲一下这一块的就是服务网格里边的身份的认证就是大家都知道服务网格里边服务之间的访问是要通过那个MTLS来进行访问的这就涉及到服务之间的一个身份的认证身份的认证就涉及到证书证书就就会有跟证书和每个跟证书为每个服务颁发的自己的证书就是这个问题就发生在了这个证书这一块就是大家可以看一下这个集群里边就是先讲一下只有一个服务网格的时候在这个左边的话只有一个付这个服务网格的时候就是它的机制是这样子的EastelD启动的话会为自己会生成一个就是会生成一个Root跟证书这个Root跟证书就为它这个服务网格里边的所有服务去颁发服务证书包括EastelD自己的服务证书然后颁发了这个跟证书之后就会去请求这个KBS的API去创建ConfigureMap然后把跟证书去相当于是放在这个ConfigureMap里边然后第三步就会通过KBS的Informer机制会把这个ConfigureMap去同步到这个集群的所有的NameSpaces里边接下来第四步就是到了服务网格的数据面就会把这个ConfigureMap挂载到容器里边就是相当于是就类似于我们自己自己的比如说电脑上的操作系统里边去包含了跟证书一样接下来就到了数据面要去请求第五步数据面要请求这个控制面的时候然后数据面去请求控制面它会认证这个对应的控制面的服务要进行身份的认证这个时候因为数据面包含了跟证书然后控制面的服务它的服务的证书又是对应的跟证书签发的所以就没有问题这是在一个集群里边有一个服务网格的情况下但是我们想要的是一个集群里边有两个服务网格这样就带来一个问题就是看右边的把这个服务网格它里边的数据面去挂载了左边的这个负的这个网格里边的跟证书但是它要去请求自己的控制面这个时候这个时候因为它自己是负的跟证书去请求EastLD就是它自己的EastLD的服务证书它就认证不通过这样就会带来的就是第二个服务网格里边的数据面是起不来的我们探索下来就是看了EastLD的原代码是这个地方是需要进行代码的修改的需要把这种比如说证书的这种分发不是进行这种整个集群的所有的内幕输入的全聚的分发而是要把它限定在比如说这个网格它去纳管哪些内幕输入去把这个分发限定在一定的内幕输入范围内所以我们就去探索其他的方案后来就发现了一个折中的方案这个折中的方案是一个部分隔离的一个方案就是在共享这个控制面然后数据面是进行隔离的这个方案是不需要进行代码的修改的然后也进而也不会带来那种开发和维护的成本最后我们是采用了这个方案这个就是刚才讲到的其实我们的初衷更关心的是在这种多住户的场景下数据面的一些性能和故障隔离性的问题然后这个方案的话就是做到了数据面的多住户的隔离是相当于是满足了我们最关心的最注重的需求所以就选择了这个方案这里边的一个关键的点就是EastLD的安装的时候有一个环境辨量这个环境辨量如果设置成处的话就会限定比如说一个产品要用Gateway的的话要用Gateway CR它的Gateway CR就只能绑定在刚前Name Space里边的EastLD Ingress Gateway这样子就要求要求产品就必须得在自己的Name Space里边去部署自己独占的网关这样就做到了数据面的隔离接下来是介绍一下在技术方面的第二个探索这个是在2022年的时候就是随着这个IPV6的普及移动员就包括应该国内的很多的公司都做的一个计划就是要把所有的产品都能够支持IPV4和IPV6的双占访问但是在这个2022年初的时候EastLD是不支持双占的仅支持单占这里边主要的原因是主要的原因是大家都知道EastLD控制面和数据面之间的是通过XDS协议去下发配置的其中比如说有一些关键的配置比如说Listener还有Andepoint然后这种单分的协议的话就数据面方面就只会去比如说Listener只会去监听IPV4或者IPV6的端口然后这个Andepoint的话也会相当于是只有IPV4或者IPV6的对应的IP的信息导致这个网格的话是支持是单占的后来就是我们和英特尔一起去在生成这种双分的XDS配置这样子的方案的基础上进行了探索也做了落地在分手过程当中也发现了一些就发现了问题也把相关的问题代码都又回馈给了社区提交到了双占分支上现在这个方案是已经在移动于内部以及移动集团内部都做到了一个大规模的使用就是国内的社区方案的首个成功落地的实践下边这张图就是刚才说到的Esteal的控制面会给数据面下发两份XDS配置然后对应的就会有两个协议站的配置来实现这种双占的支持但是这个双占的这个方案会带来一些数据面方面的性能的问题因为它需要双份的配置所以现在Esteal社区和以外社区是在这个基础上在做一些优化和提升就是做了一个新的方案就是这种只下发单份的XDS配置来实现支持双占现在这个已经在1.17版本中released了现在我们也正在试点这个方案接下来就是在讲一下我们在Esteal的使用过程当中逐步的产品化这个产品化的过程是什么样子的然后我们就是移动云使用服务网格的话也是经历了三个阶段吧然后是一个从第一阶使用到逐步高阶使用的一个过程就包括这三个阶段第一个阶段是在就是组建级别来使用Esteal第二个阶段是把Esteal集成到了我们内部的运为平台上然后通过内部的运为平台去使用Esteal第三步就是和OM模型结合来就是为客户来提供服务网格的能力接下来我就讲一下这个过程第一个过程是组建级别来使用Esteal这个就不讲了这个应该也比较的简单大家都比较了解然后第二个就是我们把Esteal集成到了内部的运为平台上但是我们的运为平台有一个特点就是说为了考虑灵活性和扩展性在一些核心的比如说应用的部署还有Esteal的这些挥度规则这些配置方面还是通过压膜来配的是做了一些比如说用户管理资源管理然后全线管理这样子的一些功能然后所以呢就是不管是这种组建级别的使用还是集成到运为平台上来使用都是摆脱不了就是我部署Esteal都是要通过手动来部署然后要做应用的部署还有Esteal的挥度的规则也都需要通过压膜的方式来最终生效这样就是使用Esteal的产品团队就很痛苦他们就是逐渐的就变成了需要变成一个KBS的专家然后也需要去了解Esteal的知识变成Esteal的专家另外就逐步变成一个压膜工程师我们也是在这个过程当中逐渐对这种云元身的应用平台有了一个比较清晰的认识发现我们需要需要这样子的一个平台就是满足3点第一点就是说对要屏蔽底层的东西然后让各种应用产品团队不需要去了解下面更多的这些东西降低他们的使用门槛第二个就是说要以用户为中心用户的话这些产品团队他们更多的是更熟悉应用所以应该是以应用为先应用是最核心的第三个就是说我们做的这个平台是需要具有良好的可扩展性的主要是想要说两块一块就是说我们的这个平台是能够比较方便地能够引入到把CNCF里边的各种各样子的主建能力能够引进来的灵活的引进来另一方面就是能够去满足各种产品团队他们的定制化的一些需求然后我们在探索的过程当中就发现这个OM模型是能够完美满足我们的需求的OM的话是Shia Ali-88和Vera共同开源的一个开放应用模型它就是抽象出了一些核心的概念我挑了一些比较重要的概念来讲一下OM主要就是刚才提到的这个应用是最核心的应用有限所以这里边OM里边应用是应用是最关键的这个应用就包括了比如说一个产品团队它自己的应用所有的配置应用又主要包括两部分一部分是叫competent组件然后还有第二个部分就是trade是运为特性这个competent就是一个你这个应用真正去运行的实体或者是运行的单元比如说它是一个它是一个外部服务它是一个Redis服务或者它是一个什么Angix服务这样子的一个真正运行的东西这是组件然后trade就是在这个组件的基础上定义了一些运为的属性比如说副本术然后比如说一些汇度发布的这种规则这个OM模型就是一些模型概念然后它要真正的去实现落地的话是需要有OM的这个平台这些基本上就是然后有了这个平台就是OM的平台会通过插件的方式去把各种各样子的比如说运源声的一些组件能力去可插拔的去集成到平台里边来最后一个它有一个概念就是工作流的概念工作流的概念就是工作流相当于是应用部署的一个它能够灵活地去定义每一部做什么然后以及把多个部署去搭配起来相当于是能够满足这些用户的各种各样子的部署的需求这个是OM和OM平台里边的基本的概念我们就是在OM和OM平台的基础上构建了我们自己的运源声平台运源声技术平台现在运源声技术平台是提供给移动于内部以及外部的用户来使用然后就是有了这个运源声平台之后Eastel结合OM之后一个产品团队去使用Eastel的方式就发生了很大的变化这个图上演示的第一步的话就是一个平台的开发人员比如说像CNP或者是OM平台的开发人员是去开发Eastel的插件然后去开发会度发布的一些运为属性还有就是会度发布的工作流并且把这些东西集成到平台里面就好了第二步的话就是集群的运为人员去通过插件的方式把Eastel去部署到集群里面去第三步的话就是这种产品的开发人员他们更熟悉应用他们就创建这个应用的组件第四步就是这个产品的运为人员就是在这个组件的基础上再去定义一些运为相关的属性比如说一些会度的属性然后以及定义对应的部署的工作流这样子来就是把这种会度的组件以及会度的规则送到KBS集群上去刚才也提到了就是对于平台的开发人员需要做的就是开发一些Eastel的插件还有一些会度发布的规则还有会度发布的工作流在这个界面上我也结了一些比如说Eastel插件然后是可以通过OM平台提供了一些模板的方式来开发各种各样的插件就开发一个Eastel插件也是就是去对应的去研发这样子的一个模板以及后面的那个会度发布的运为特性还有会度发布的工作流对于产品团队来说就只需要通过这个OM平台通过界面的方式就能够去使用这个服务网格的能力他们就不需要再去了解更底层的东西了就像这上面第一步的话是通过插件的方式来部署Eastel选择一个集群再选择安装Eastel然后就可以了部署一个应用的时候就是通过界面的方式来部署这个会度的组件然后再定一个第三个会定一个会度的工作流执行了这个工作流之后就可以通过这种服务脱补来看这个会度发布的效果以及可以看会度发布完之后的流量的可观测再接下来就讲一下我们后面服务网格在移动云上的一个展望吧包括三点第一点就是刚才说到的就是通过单分的XDS协议来实现这个双站的一个贪守和落地还有一个第二个就是NBMAS要进的一个探索昨天的Eastel康上也是感觉现在大家都在探索这个方向基本上有半数的演讲都在讲这个然后我们这边其实也是有对应的场景的就刚才讲到的其实移动云里边多个产品共享KBIS集群对这种资源的其实是想要提高这种资源利用率的然后AvidMesh然后也提到了这一点我们后边的话会做这方面的探索第三个就是刚才提到的算网原生方面我们在算力网络方面会做一些包括Eastel在内的这种Severlis方面的探索我今天的分享主要就是这么多内容看大家有没有什么问题张老师你好我这边有听下来可能有三个问题第一个就是关于灰度发布这边因为灰度场景其实站在体育暖角度来考虑这个场景应该说是比如我在V1版或者V2版本但是塞特卡模式或者说佛网格下的话其实必须要求客户端都上了网格之后才能够去体验这种灰度能力或者说这种这个场景但是有的场景下其实很难去推动客户端都上网格因为势必会在整个进行中有一些人可能没有上网格有一些人可能是上了网格这个问题还怎么解决然后第二个问题就是关于多租户这边的多租户这边的话其实咱们这边是用英语Gateway来做入口的隔离但是塞特卡这边的话其实还是共享一套East2的但是East2原生的塞特卡升级模式其实用Injector Webbook去做升级的做塞特卡升级的话那怎么样你去解决在多租户场景下每个租户比如说塞特卡不同版本之间的升级来做一些稳定性或者平滑的一些相关事情然后第三个就是可观测这边因为原生的观测我看到大部分都是基于Cluster位度去做观测的比如说它的一些PlumQ4的metric或者什么都是基于Cluster但是不论是做ATPATP因为原生可能ATP支持得比较好但是应该是没有一些做稀利度的观测但是我们在有一些场景下可能会遇到基于某些metric的或者某些pass去做一些稀利度观测这方面有没有一些就是可分享的好的谢谢这个问题第一个问题第一个问题是挥度是吧挥度确实是会涉及到这样子的一个问题我觉得可能是两方面就从我的经验两方面一方面是说挥度是不是一个产品团队本身觉得的一个痛点对如果他觉得是痛点的话他肯定是会拥抱这个东西的第二个的话也是那个相当于是Eastel或者说服务网格的提供者然后也要提供这种便利就比如说尽量对这种产品的改造要小然后对他们的影响比较的小就比如说他们用一些传统的传统的微服体系然后怎么把他们能够接到Eastel里面来这个对 推广然后我理解第二部分也涉及到这些技术方面的东西对这里边确实Eastel要和传统的那些微服的体系要结合的话是需要做一些事情的然后第二个是说是说那个多祝负 是吧多祝负的Sidecar的升级这一块我们也没有做过太多的探索我们做过的探索就是Eastel的版本的平滑的升级我们之前是有做过比如说Eastel官方是提倡比如说两个版本做升级对 不要太高的版本做升级然后我们也是探索了一下其实总体来说按照它的方案然后是跨度再大然后也还是OK的一个问题就是Eastel版本每三个月出一个但是它某些版本其实和Sidecar或者影外它自己的版本是有一些gap的比如说我举个例子比如说它跨得比较大到1.12以上的话它可能只能支持影外在1.2差某一个版本如果我们那个版本运动低的话这种情况就很难去推动升因为它两个之间是有一些适配或者说它的API之间一些兼容性的问题这块反正目前是有一些平静在是的 确实存在这样的问题Eastel的这个版本升级特别的快然后我们我们也是Eastel的使用者然后我们也更多的是也一样的线上对这种升级然后也是要求比较的高我们也是在就是遇到一些刚需的问题的时候比如说kbis的版本然后升了然后对Eastel你必须去升的时候可能就涉及到这种一方面会涉及到kbis怎么平化升级然后另外就是Eastel怎么去平化升级的这样子的事情我们也不会对也不是那种紧跟着版本的稍微还有一个问题来说可观测可观测那个的话跟现在在探索的就是Eastel和skywalking然后做可观测就是除了在这种流量级别的这种可观测然后也做这种想要通过skywalking来做这种比如说方法级啊什么的更细腻的这种可观测你好谢谢谢谢您刚才非常详细的分享我想提两个问题请教两个问题一个是说移动云这边在布什这个服务网的时候有遇到过什么关键性的一些性能的一些障碍比如说在严实啊或者说在布什林先生这个假密的时候对客户的泡在里面的性能是不是会有一些影响呢移动在这方面有什么考虑第二个就是在布什的利用性方面因为编车的话是是需要布什在客户的泡在里面去的对吧那么刚才前面一个朋友提到这个升级等等的一些问题那我刚刚看您讲到下面也会提到这个会探索安柄的是不是会考虑就是说把编车像安柄的一样从里面卸载到可龙或者说卸载到安柄这里面去的话就是这样使得客户或者多个Tenant的布什就跟这个网格就没有关系的可能就会解决这方面的问题我不知道是不是您考虑下一个考虑点是的我们也是产品或者说产品外部的客户然后去使用塞德卡的话他们会有这方面的一些担心然后也会就是担心塞德卡带来的性能还有资源的问题然后我们这边的话就是可能我们还觉得这些产品还没有到那种程度所以对性能方面其实目前关注的并不多关注的更多是功能方面然后就发现一些功能方面的一些问题就比如说我们的有的产品他们对这种HTGP的协议里边的各种信息其实是就是有各种各样的场景去处理里边的信息就发现在使用Israel的过程当中会或者是以外的过程当中会发现他有一些修改啊或者不满足预期的这种东西就比如说会有一些HOST整个链路过程当中有一些字段就消失掉了或者POD消失掉了或者是说哪些字段就被修改掉了就更多的是这方面的东西在这个POD在这边车之间是不是使用的是MTS信道来做的传输对 我们使用的是MTLS有遇到过比如说像身份认识的性能方面的一些压力吗这个还没有设计到这一块对我们可能目前还更多的是在功能层面对 性能层面应该后边用的越来越多然后我们现在移动云里边最复杂的一个产品叫OP平台那个平台有将近100个微服然后要用服务网格来做恢度并且他们是移动云的相当于是种的入口这个时候应该我们会遇到这样子的问题这接下来也是对我们的一个比较大的挑战这相当于是移动内部的一个OA应用 是吧不是 是移动云这个公有云平台的对 公有云平台相当于是入口服务它做比如说整个移动云平台的网关以及拥护管理订单管理就整个移动云里边最复杂的一个产品对 接下来会是一个挑战好 谢谢你好我有几个问题可能咨询一下一个刚才那个性能的问题目前移动对面没考虑是吧性能和资源占用的问题性能的话我们对 可能更多的是以色有官方然后它提供的那个那个BatchMack的那个性能的报告 对好的那就是刚才提到的那个多机群就是用以色来管这个目前解决也是主要解决那个融灾和备份相关的问题引入在移动里面引入这个多机群的Mesh对 融灾和备份是一块另外一块就是像我刚才介绍的可能就是它也能实现这种融灾和备份的这个需求然后另外也是像刚才说的是那个想要去探索一下这种动数细算或者算力网络这种多支原池级别的这种算力怎么去进行分配然后去调度这样子的一个事情好的那就是刚才提到那个动数细算的问题就是目前我从刚才教片里面看的那个算力好像目前还没体现出来是吧还是后面准备在引入算力比方说算力调度相关的一些事情是的其实这个PPT上算力调度是没有体现的其实我们就是我没有在这里边体现然后我们去年也做了这方面的探索就Eastel加上卡玛达然后一起来做这个事情的然后因为这个主要这样EastelEastel说因为我没有介绍那部分的内容然后有结合卡玛达然后卡玛达去做这种比如说去多支原池级别的然后那种算力的编排之类的事情对吧好的那就是接下来一个问题就是那个因为现在Eastel本身支持的就是原池那些网络那移动这边对那个多品面有要求吗因为现在社区这一块是还是不支持的因为现在还是一个单品面的网络吗多品面指的是什么多品面比方说现在在一个坡的里面只会通过深爱挂一条网络而且这个网络都是走原生的类似于K8的Service这种方式那有没有需求比方说走再挂两个品面两个网口或者甚更多的网口这个同时用Eastel做一些流量方面的一些治理目前我们是目前我们是没有这样子的一个需求的场景可能是我们的原生的那个程度就是我们基本上移动于的所有的产品都已经原生化了就没有对基本上都是K8S里面的那大多数基本上还是一个偏IT的一个场景是吧一个网络平面目前是不是都目前是满足你们的一些要求是吧是的好的那最后一个问题就是现在那个因为Eastel对那些协议的支持七层的还虽然有一些扩展方式但还是不是很多那大多也是GOTCP的对于UDP的这一块我不知道有没有后面有没有什么考虑因为这一块的话社区本身提了好久也是没支持这个是不是可以去看那个就是社区里面有那个照画兵然后他们开源的那个他那个还是主要是PN7层GOTCP的比较多GOTCP的好像目前还没有解决方案好像是现在是移动这边也没有这个需求是吧没有没有这块需求好的谢谢我只有一个很简单的问题就是前面有一页那个算网说那个上面是苏州是吧那边成都杭州那个其实就是一个quad region的一个流量调度其实我没看很明白就是相对于那个已有的就是本身组建的那个能力那移动做这个事情做了什么增量的能力在做这个事就是quad region调度的时候增量值增量值的是什么就是你基于这个开源的组建是吧我们来做quad region的这个调度它是在整体的架构上面或者是上面的这个策略上面做了更多的事情然后然后出来这个你刚才的这个方案这里边的话我理解我们做了的增量的部分可能不在这个easter或者服务网格这一块是在那个刚才提到的那个算就是比如说苏州支援池有一个算力中心那一块然后我们这个苏州是吧对 苏州是一个举例就是对比如说有一个算算力中心这么一个模块然后去收集各个支援池里边的支援的情况然后去进行计算对 它就是其实我们这个算力中心也只是就是它有很多场景然后我们是属于云烟山的场景整个公司还在做一个更大的一个叫算网大脑的对 它就是包括算网我理解应该是单独的课题是吧 只是中间用到的云烟山对对对然后我们这一块那个刚才提到的算网中心然后相当于是我理解是我们新增的东西然后也属于我们的算网大脑那个大的东西里边的一部分对 更多的是这个谢谢好 谢谢好 那今天的分享就到这儿谢谢大家就是Service的这个后面的就是这个需求的场景是啥需求的场景就是我们的比如说我们的产品然后是有公有云的产品嘛公有云的产品它就是要考虑一些用户要通过资源来付费这样子的然后我们也是想要比如说Service一个比较后面会像那次说Fast上面眼镜吗Fast还是目前就是用那个按需使用 按需谈缩那种方式主要是用对付率是吧对 还是按需谈缩的这种可能目前在探索Esteo和Kinitio然后再加上产品这样子的方向好 那大家再见谢谢