大家下午好我们下午厂现在也开始继续了大家请马上就座我们开始下午的第一场分享第一场分享是来自王熙宁和史泽环给大家分享Solace's Self-SmashBased on Istio和Virtual Cooplet欢迎王熙宁和史泽环大家下午好我是来自阿利云的王熙宁今天呢我跟我的同事史泽环一起跟大家分享一个topictopic的主题内容呢就是Solace's Self-SmashBased on Istio and Virtual Cooplet那大家可能通过上午的一些学习呢已经对 Istio这个项目对我们的 Self-Smash 应该非常熟悉对于这个 Self-Smash 的概念可能之前也听过但是呢Solace's Self-Smash我相信应该是不能说第一次但至少是非常新的一个topic所以希望大家在这个接下来时间能够去领论一下我们如何基于两个开项项目去构造一个Solace的形式的一个 Self-Smash那我们就开始OK 那有东西让他这儿回车吧那今天内容的话大概是分为以下四个部分首先呢是我们对 Self-Smash 里面控制平面康兽图类它这一层面如何去做一个 Self-Smash我们会去整个这个纬度呢去看一下它是如何为什么要需要做这个 Self-Smash以及是怎么去做一些 Self-Smash那么第二部分和第三部分的话就是从它的数据平面去看一下如何去支持这个 Self-Smash那么当然在 Datapoint 这一块呢上午去大家也听了很多这个内容就是它要分两种形式一种是这种Sunder Harmony另外一种就是 Sunder Chalice比如说基于上午讲到的 Ambient Mesh如何在这个基础之上去实现 Self-Smash 的能力那最后一部分的话就是做一个总结我们去分享一下我们认为的服务网络技术下一步如何有一些眼镜首先这个图呢其实它本身的内容大家已经非常熟悉了对吧因为这是五年之前对吧 五年之前其实就Asture 1.0出来之后就是这个架构上午也有很多Speaker已经讲过这个内容我们之所以把这个图再次拎出来跟大家分享一下呢是说我们在五年之前我们差不多在Azure 1.0产品上面是一阵重模式就是Aid On的模式去上现在这个H2的功能它是作为一个Aid On跑到一个KBS机群里面其实本身跑一个Demo或者跑一个简单的应用来说它本身不会存在什么太大问题但是这种模式Aid On的模式其实是有它一定的局限性我们差不多是在运行了一年多的时候已经有其实有数百个客户在使用这种模式跑它的业务生产但当它运行了一年之后面临一些工作坪要升级大家知道Azure迭代很快 对吧每三个月就发一个版本在那个过程中我们其实就遇到一个很大的挑战客户每次升级第一个问题就会过来就说敢不敢升级在升级过程中是否有流量损失等等这一些问题那其实作为一个云共用商它是服务了其实很多很多的云商的客户公共云商客户非常多如果说我们有限的资源都去支持客户肯定不现实那其实在这个过程中我们也遇到了什么的像一些挑战比如说升级过程中用户如果是自己升级它没有去关注太多一些底层所依赖的环境比如说一个East2它底层的K-24环境如果跟它不匹配那有可能在升级过程中就会造成一些冲突导致可能就真的不可用会导致的本来是用了East2享受一些服务之力的功能结果被它搞挂了对吧这其实是在过去我们服务了很多客户的案例中真是遇到的那为什么这个模式在服务客户的过程中或客户在实用上有问题呢其实是刚才提到就是说East2在1.51.6之前对吧它本身其实组件还很多很复杂那即使到了1.6之后它实用了新的加购之后其实也存在一定的复杂度也在一定的复杂度那客户为什么就是说客户在用了它之后刚才提到它是跟底层的K-24就是有一定的依赖这个依赖呢这个依赖其实让我们的用户自己去分析它依赖去解决问题其实并不是很现实那我们其实刚才提到就是说客户遇到这么多问题对我们它那一家压力也很大那在这个过程中我们也是深究里面的跟为什么会存在这些事情那同时呢想去想出一些解决方法去解决它那么在这里面的话其实一个很重要的因素就是说控制面的组件它对底层的K-24的这个版本是有很紧密的依赖的按照社区的这个说法应该是有每一个A-24的版本大概是支持三个K-24的版本的一个跨度那除了这个三个版本之外的其他的版本其实不保证的对吧但是呢而且A-24刚才讲的跌得特别快我们的客户要求是什么状况呢一个K-24跑运行中它期望我们能泡的我有个客户有几个客户是这样听的我的泡的我不希望有任何的冲起我希望一年之内都不要滚都不要冲起这是我们真实的客户存在的一些一个现状它不是K-24永远生就随意可以冲起报的这不是这样的它并不希望去随意去冲起这些拥有那特别你会看到在这个图里面这个Mesh的Proxy对吧多于一个Sidecar跟业务的Kantana跑在一起对吧那你想让它升级还是挺难的对吧然后呢它本身又希望去使用A-24有一些新的一些版本的功能那这时候就遇到挑战遇到一些挑战即使它会找一个低峰区去升级也会遇到一些事情就是就刚才讲A-24的方式就会团在这些冲突为了解决这些事情的话我们就刚才提到就是说既然控制面这些组件有这么多的依赖那我们想到的解决方法很显然就是说要把它解有出来那这个头会看到可能跟A-24的方式不一样的地方就是说它的控制面它是一个独立的它并不是运行在一个给你的K-24的继续跑在一起的一个东西它是独立你的K-24机群之外的一个组件那这个组件的话当然我们的云产品就是说为了帮助用户降低门槛就是能够更好去使用我们把它拖管起来了就是说对用户来说它是一个开箱机用的一个东西一个能力它是这个东西就像云上一个独立的服务一样它就是云上的独立服务刚才提到它跟你的K-24机群并不是运行在一起所以它的这个版本依赖就会介入看来对吧它就不依赖你的K-24版本了上面那一块就是Many的ControlPlay就是说跑在云侧的一个组件它给你的K-24是独立的就是你的K-24的升级不太会影响整个这个环境当然上面ControlPlay的这些组件升级也不会去影响你底下的K-24机群于此同时当然它这个架构之后还有更多的一些好处是什么呢我们在上面这一块有为这个S2S2D有独立的APS Server就是有独立的K-24 APS Server有独立的ETCD帮助它去做一些这个村厨管理CRG的一个村厨管理而且在这种模式下大家可以看到控制面独立出来之后它的数据面其实就变成一个很灵活的一个形态它不论是单机群还是多机群它的形态是一样就是会看到在这个图里面我是画了两个机群做一个势力它是能够就像添加一个一个虚拟机节点到一个K-24机群一样我可以把这个数据面的K-24机群添加到这个托管的这个控制面里面去同时也会看到我上面这个控制面的整个它所依赖的K-24机群这个宝门的生命中心管理因为它底下这个数据面的K-24的一些周期管理我都是接我的他们都是接我的这就是有了这么一个架构之后其实就会看到我对上一面的H2升级就对用户来说就是一件就可以享用整个升级了底下的K-24都是独立可以去做当然你会提到比如说数据面如果K-24跨度也很大的话是不是也会存在一些冲突而答案肯定是一定的比如说你K-24的这个API对啊API version都发生改变肯定会有一些变化当然对于产品来说我们会通过控制面能够检测到你数据面的一些版本的状态能够去自适应的去下发一些不同的资源的一篇版本所以从总体来看整个模式下无论是从控制面到数据面都有一个很好的一个实配那有了这么一个模式之后还得回去了OK那有了这么一个模式之后其实就为我们在控制面做sourness就做了一个很好的一个技术储备其实sourness是什么呢就是大家知道sourness肯定是说有更好的弹性对吧对于控制面来说我既然跑在你拖拐侧那我们希望做到一个什么状态呢就是说无论你下面的数据面的机群有多少就是我们的客户无论是他这个有就是我们有呈现上网的客户在使用无论他是想去使用多大规格的这个控制面我们都有这个能力但后台有一个sourness的方式能够去自动的扩缩容能够去更好地去支持这个控制面组建的一些管理包括当然对用户来说它是一个开箱机用用户其实并不需要感觉到太多的后台是如何去这些复杂的管理能力我们既然有了这个sourness的能力的话就是我们会去利用一些弹性资源能够对控制面的这些组建做到一个自动的扩缩容能够根据用户数据面的一些比如说泡的规模你的规模比如说我们有的客户已经达到15000个泡的在它一个机群里面那这时候它控制面所需要的资源可能就不一样了它就跟一些小规模的环境不一样这时候在后端的话控制面就会做一些自动的一个扩缩能够去更好地去支持支持这个控制面的一些请求能力那当然这里面我们也是利用后台弹性资源能力能够去按好地按照这个按需所用根据用户的规模去做一些自动调整同时也会在销售的客用区大家知道单一的客用区其实就会存在一定的风险对吧如果这个客用区存在一些固扎问题就会导致控制面不可用那么我们也会重新利用调动能力能够把这个控制面组建去维护在多个客用区里面等等那里面也会为了提升整个的这个其中速度包括那个镜像的加速缓散等等都能够这一系列的手段能够让我们在控制面去做好一个很好的sourice弹性能力来更好地支持这个控制面的一些管理前面是控制面的一些sourice的背景那么第二部分其实就讲一下在数据面特别是SantaCarm而且我先讲SantaCarm模式想想它是怎么去做一些sourice那这一块的话其实我先引一下因为我的题目里面其实讲到一个一个客用项目A3给大家很熟的就不讲了还有一个项目叫Water Covalent那这也是一个开源的项目我们通常检测的叫VK那这个项目的话其实一看明的大家对covalent对吧KBS世界里面对covalent应该是比较熟悉那么那个Water Covalent的话顾名思义对吧它是提供了一个因为是一个虚拟的出现场它能够使用一个标准的KBS的API能够对你这个对底下这个Sourice Continental Pro2的资源能够去做一个标准的KBS方式的管理那在这图里会看到就是我们常用的KBS可能跑的都是一个虚拟机的上面对吧就是每一个阶点都是一个虚拟机在VK它对应的模式的话就是说底下是一个Sourice一个资源池它里边就是说对用户来说可能是一个无限大的一个资源的一个环境它对用户来说所使用的在这种资源下启用的这个跑的它的使用方式是跟标准的标准的Couple类是保持一致的那这是简单理解一下VK的一些这个方式那我们会利用这个技术去做一些数据面的一个Sourice化的一个支持右边这个图呢就是简单列了一下就是为了帮助大家去更好的理解这个VK这个优越就是列了两个这个方式我现在所有的云厂上可能都是都差不多两种方式一种方式的话就是这个就是缓和的就是ECS和这个弹性容器这个实例这正的资源是缓和实用就是在你的一个KBS机讯里面既有这个虚拟机也有这个ECS的弹性资源而是缓和的一起做一个一个一个弹性的一个场景按不同的需求来启动不同类型的这个炮的资源这是一种常见的方式那么上面还有一种方式就是完全是这种ECS的资源类型就是整个的这个整个的机群都是一个Sourice的方式它在这种情况下的话用户就可以不需要去关联任何的节点这些扩操容都是有底层的这个Sourice Content Provider来帮你去维护管理那在这两种模式下都可以用户挺无一个弹性的这个容忌那么就是在三代刚刚提到在三代看模式下怎么去做这个Sourice其实这里边还是挺有挑战的就是说大家知道网关还是可以的对吧网关它是一个独立的Prosse那我真的这个就是一个独立的一个Prosse的一个炮的其实还是比较容易去做这个这个弹性管理对吧它是跟你的业务五关的这个正正炮的就是跟你普通一个炮的去做一个客户容设一样的那三代看的话其实就挺难就是说不定就是因为你三代看的模式下它是跟你的业务用用在一起那还有一些这种别的一些约束那这里边然后我们立了两个在这里过程中需要解决的问题吧那第一个问题就是说整个这个部署的一个策略我们是这个部署策略是两种形式比如说我们是期望优先去布到这个ECI资源上面还是必须部署在这个ECI资源上面这可能是说三代看这个PROCED是需要跟你的业务用用来共同决定整整部署策略那这里边可能会涉及到一些更复杂的一些调度相关的问题就是那么能够进入马祖林的业务容器的诉求也能够让这个三代看带领呢尽可能去做具备一些soulless谈新的能力那第二个问题呢其实我们遇到一个挑战就是安全相关大家就一说这种类型的话它是对安全性隔离性是有一定的要求比如说它不能支持一些特权模式那这个时候的话就要求我们的炮弹就不能够去支持PROCED这个能力了所以我们需要在这种方式下对PROCED去做一些限制还有一个组件呢其实就是就是指这个基于可观性数据用来展示网络托谱的调用了托谱依赖关系的这么一个组件我们这儿叫称之为叫Mesh Topology网络的一个托谱那么在这个组件里面的话虽然它属于一个空之间的东西我只顺便列在这儿是原因是说在过去我们没有soulless的话之前呢这个组件是跑在KBS用户的KBS机群里面的作为一个炮的独立存在在右图里面左边这个图里面可以看到它是跑到一个用户的VPC里面显然它是受限于它所在的KBS的一些环境影响对吧它不能多一个很好的弹性的能力而且在多进行模式下它的受限场有也很多为了解决这个问题的话我们也是把它做一些soulless的话的一个支持在右边可以看到首先这个组件我们也是把它独立出来把它多一个托管的一个模式去独立运行Mesh的逃破了这个组件在上面是一个独立的方式同时的话就是说会看到在多机群模式下它就更好一些优势了在每一个机群里面我有一个PromiseAgent去采集数据同时我们会有一个聚合的一个模块能够把每个机群的Promise数据聚合在一起形成一个统一的一个数据采集的入口然后指向我们的网稿特普这个泡的这样的话在这种模式下会看到无论你机群规模是多大或者是有多少个多个机群对于我们的网稿特普来说我们可以按照按须去弹出这些泡的数量来支持更大规模的网稿特普的一些处理这就会看到说我们也是把这个组件也是进行一些soulless的话的一些管理使得它具有更好的一些弹性能力理论上它是处在一个无线扩大的一个一个一个一个资源池里面接下来一部分的话就是在讲以我的同时会讲一下这个serverless模式下如何去做soulless的话的管理OK 大家好我是史泽环然后呢接下来我给大家来分享一下就是我们的第三部分也就是我们的数据平面怎么样就是在我们的这个serverless的数据平面怎么样能做到serverless的serverless化OK我们先回顾一下就是我们的这个ambient模式下的架构是怎么样的我们通过这个回顾呢来看一看我们这个前提就是说我们怎么样才能去有这么一个去做soulless化的前提在这种模式下呢我们是Ease your ambient mesh把我们的代理从原来的和应用紧密的部署在一起的setcar变成了抽象变成了四层跟七层的代理然后他们都连接到这个控制平面从控制平面获取到各自的信息四层代理跟七层代理原来这个信息是在一起的都是通过XDS发下去的但现在呢他们就有各自的这个信息那我们当这个流量转发的时候如果我们这个应用需要有这个七层的规则我们的目标应用有七层的规则这个时候我们就可以为它选择性地去布一个七层代理那这个时候如果我们布了七层代理的话流量就会从这个四层代理出来之后去找到这个七层代理然后再从七层代理出来之后到目标服务所在的节点上面的四层代理然后再转发到我们的目标服务去然后基于这样的一种模式呢我们的四层代理跟七层代理拆分了之后呢可以看到四层代理它是在节点上面的这是一个节点级的是一个Dimensite不常去的这么一个服务但是七层代理相对来说就比较自由它是可以布在集群里面可以布在随意的任何一个节点上那这样的一个架构就给我们去做Surless化去提供了一个比较好的一个基础OK 有了这个基础之后呢就是我们为什么要去做Surless化呢我们在布七层代理的时候就是说是可以通过K8S的GatewayCR去触发我们去声明一个这样的一个我们为某一个服务去声明一个七层代理我们声明了七层代理之后呢就会触发到我们一个Vpoint Proxy Controller这个Controller发现这个CR之后会根据我们在里面声明的这些信息去把这个七层代理给布出来然后我们把这个七层代理Surless化呢其实会带来一些比较显著的优点首先当这个代理跟工作负载节隔了之后我们可以把这个代理的升级然后便配等等完全独立开运行其实我们之前在塞德卡时代其实会有一些问题就是说有些客户会问我们说我加了你这个塞德卡之后用了服务网格之后这个资源我怎么计算然后包括当我要这个想去扩容的时候因为我们知道塞德卡里面有的时候会跑一些七层的规则包括安全上啊路由上啊等等甚至还有一些比如说Wallstone脚本啊或者路阿脚本这都会使得在这部分处理上可能需要花很多时间很多的性能开销那这个时候有的时候对于这个塞德卡的这个扩容那就会变得比较重要比较也是也是客户比较希望知道的有什么好的方案那这样的话我们现在完全独立开来之后呢借助这个soulless化的能力呢我们就可以非常方便的就是用户就不用再那么有负担的去提前需要知道我要去用服网格那我要给这个七层代理要规划出来多少荣誉的这个容量对吧那我通过塞德卡less模式就可以非常好的去非常方便的去对这个七层代理进行扩容OK然后我们来看一下就是说那我们怎么去部署这个soulless化的七层代理呢我们其实有两种模式第一种模式是可以看到我们左上角是一个服网格的控制平面然后这边也有一个刚刚提到的这个we.proxy controller对吧然后当我们声明了一个这个GavelCR的时候呢其实它是有两种方式一种方式呢就说我们集群里面有一些集群里面它就是已经有有部署这个vnode就是它已经是一个soulless化的一个节点那我们可以通过对这种集群我们就可以让vnodeproxy去把这个七层代理下发到这种vnode上面那这是第一种方式其实这种方式是比较简单但是对这个集群本身是有要求的需要你集群里面本身有这个能力那对于没有这种vnode的集群我们想做soulless化怎么办呢这个时候我们提供了一种叫做managedvnode通过这个托管的这么一个池我们可以把让这个vnodeproxy呢对于这种本身没有vnode的这种集群我们可以把七层代理去布导一个专有的这个池里面通过布导这个专有的池里面其实用户的负担就更轻松了就是说这个代理就它就完全不需要感知到这个代理的存在以及这个代理怎么去运为怎么去便配之类的它都可以非常轻松地去进行这个七层代理的运为和部属但是呢其实我们把这个七层代理布到这个vnodepro里面之后啊可以看到其实它已经完全不在这个就是跟这个应用已经完全不在一个集群里了对吧那这个时候它其实也是要连到跟这个四层代理一样要连到同样的一个这个控制平面去才能获得到整个集群里面的配置的推送对吧但是我们都知道就是说这个Esteo是支持一个多集群模式的对吧但其实当我们把这个七层代理就是ambient模式下它其实对这个多集群模式的支持呢其实是会有一点问题的然后我们接下来就来看看就是说这样如果我们要把这个七层代理布到另一个集群里去我们会面临一些什么挑战OK当我们把这个七层代理我们看一下上面这个路径啊就是我们一个圆炮的发出来一个消息之后经过ZTANO也就是四层代理然后到达七层代理然后再发到目标的炮的这是我们期望的一个路径对吧但是当我们把这个七层代理从这个集群里拿出来之后呢这个路径就有问题了因为我们可以看一下这个我们提供了贴了一个四层代理的配置文件其实在ZTANO的实现里面呢ZTANO会维护一个代理和工作的节点工作负载之间的这样的一个关系我们可以看到这边就是说左边的这个配置文件啊它是有一个它是一个work cloud就是一个工作负载一个目标炮的那在这个配置文件里面呢我们就能看到它有一个vpoint addresses这个vpoint addresses里面指的这个IP其实就是说你要访问这个目标工作负载那你要先去找到1000.17.0.153这个这个vpoint先发给它然后让这个vpoint再发给这个目标炮的但是我们一步到集形外面之后啊这个时候你打开这个配置文件你会发现这个里面这个地址没有了为什么没有了呢其实就是因为当前ECEO的控制品面在处理这一部分逻辑的时候其实是它是集权隔离开来的当然除了这个问题其实当前我们社区的这个MVMesh其实对这个多级群的处理还有一些其他的问题啊就比如说因为我们现在这个四层代理里面它维护的这个工作负载跟服务之间的关系它是通过一个叫做VIP也就是说它记录的其实服务的信息并不是服务的名字而是服务的cluster IP那这个时候如果你在两个集群下面有一个名字一样的服务其实它是分不出来的就是它是不会认为这两个服务是同一个服务的也就是会这边会有这个四层代理里面的会认为它是两个服务但是我们现在重点来说这个问题就是说这个四层代理里面看不到另一个集群里的我们的serialist的这个集层代理怎么办啊OK 然后这边画了一个示意图啊就是说我们简化来看就是从我们先看右边的这个用户的集群用户的集群里面如果我们布了一个vpoint proxy的话也就是这个vpoint proxy 2啊如果我们部署一个vpoint proxy的话它会触发一个事件然后这个事件呢就会被控制面的这个控制平面的这个controller所看到看到了之后呢它就会去更新它记录的这个代理的这个registry那这个registry更新之后呢它就会触发一个重新计算我就要开始通知所有的其他的这个四层代理啊你们需要更新信息了要需要知道这个新起来的集层代理那它是谁的代理它的地址是什么等等的这样它就会发下去于是呢这个registry的信息呢就会发给Z tunnel也就是我们的四层代理它就感知到了这是一个正常的流程 对吧但是这个东西的实现其实在控制面呢其实它是分开的也就是说对于多级群的实现因为我们本身托管的这个vpoint它其实是在另外一个级群里的它是和用户的Z tunnel不在一个级群里那它每个controller里面自己独立的一套这个invent loop这个事件循环呢它其实是发现不了这个它其实是发现不了这个里面的它是发现不了这个托管的这个vpoint所以说这个时候我们需要怎么去解决这个问题呢我们的目标是希望能让它把这个事件触发到能去塞到那个controller里面去 对吧这个时候我们可能会想到说那我就直接塞进去不就好了吗对吧 但是从实现上来讲这个地方会有一些问题我们可能会想到比如说我直接去塞但是直接去塞因为它这个地方两个是独立的它是有独立的锁的所以如果你直接去操作的话两边都加锁就可能会造成死锁的问题所以说我们采用的一个什么办法呢我们会用一个单独的CRD然后在这边的触发了之后我们会往另一个机群里面塞一个CRD然后再让那边的controller在握持正常的泡的同时也去看这个CRD这个CRD里包含的信息其实跟一个泡的信息它是都有的所以这个时候它就可以正常的走旁边机群的就是那个kos机群的controller整个事件循环是不打破它整个的一个事件循环的通路的它可以完全就像处理自己机群起来一个泡的一样去处理这个事件然后完成下发OK因为时间关系我可能对最后一页呢就简单跟大家分享一下好了就是这一页呢就是跟大家分享一下我们认为的这个ServiceMesh这个技术下一步的一个发展方向就是说我们认为就是将来这个ServiceMesh一定会有一个统一的ServiceMesh在控制面它有一个统一的APN与下面不同的依购的多样的数据面进行一个整合那么在下面这个数据面这个平台里面会看到我是按照其实有三种模式一个是SandcardProsy刚刚提到这现在是在对成熟的一种方式那第二种呢就是刚才讲WePointProsy那么未来呢我们认为可能一定会出现一个叫RemoteProsySandcardWePointRemote优劲机远对吧就是以给那个ReplicationContent的距离来看的话越来越远对吧也SandcardWePoint远一点然后呢将来一定有一个Remote的形式的Prosy那就是我们刚才提到Service化的这个形态下这个Prosy可能就是一个Remote被管理托管的一种形态存在这就是我们就是前面两种形态我们的产品里面也也是在提供这些能力也有一些客户在试用有些在WePoint的这个Prosy那么第三种方式我相信也是在未来的不久吧一定会会这个由客户去试用这种方式能得到它一些好处这是我们认为的这个ServiceMesh下一步的一些发展好那我的内容就到这儿好 谢谢大家