好,那我们开始然后我们今天跟大家分享的主题是在任何机组设施上用Open Function来运行Solace的工作负载简单介绍一下我是青云科技的可观测和Solace团队的货便节然后我也是Open Function和Google Sphere的Mettender同时也是其他几个开源项目的一个Mettender我是那个来自青云科技的工程师王一飞然后我也是Open Function和Google Sphere的Mettender今天跟大家要分享的这个主题其实包含了这么几部分首先我们探讨一下就是构建我们一个开源的发子平台它的必要性和可行性接下来是Open Function的一个介绍然后可能谈到Solace大家可能绕不过去的一个话题就是说这个冷启动然后我们也介绍一下我们在冷启动方面的一些探索包括把Dyper给它变成Proxy的模式然后以及Walsum函数的一个支持然后接下来是我们社区用户的一个用力就是我们在自动驾驶来的领域它去用Open Function去处理车端的一个数据接下来是最后会有一个Dymo然后之前会介绍一些社区一些路线图之类的这样的一个信息给大家构建发子平台的一个必要性Solace领域这个著名的等式大家可能都熟悉Solace等于Fuzz加上Buzz就是Bacan的Solace对于函数来讲函数去到平台的一点函数肯定是不可或缺的也就是说Fuzz是它这个主题但是你这个函数其实又不是生活在真空里的它总是需要和一些后端服务去打交道也就是说Buzz服务去打交道然后才能够把你的业务就是对你的业务其实是更有意义所以这个丰富的后端服务它也是不可或缺的一个依托对于云长商的一些函数来讲它通常是只和它的自己的云上的后端服务来去做了一个交互就是和自己云上的后端服务的集成是比较好然后通常可能也就是把它的函数绑定在自己的后端服务上了我们其实大家做在讲云其实最近我们其实也看到了一些比如说有一些公司它因为云上的成本过高它要下云或者是说它要从一个云迁到另外一个云这样的时候如果你的函数是绑定在云的Buzz服务上其实就不太利于说你跨云的迁移或者是你迁移到线下就不太利于这样的一个场景然后就是说如果你跨云迁移之后你怎么样去处理你的业务逻辑和云上的各种后端服务的一个结果的差异其实这个都会提出一些挑战从另外一个角度讲就是从你开发函数绑定平台这个角度讲的一个Fuzz平台可能需要多种语言比如说我们需要五种语言那它这五种语言它如果是需要和比如说十种后端服务去打交道那每种语言都要去对接一下这个后端服务比如说我配色要对接卡不卡要对接Redis要对接NARTS对吧然后就不依据力了这样它的复杂度会就是五成十就是五十你要有五十种实现所以这个实现是比较复杂的那怎么解决这个问题呢后来我们其实就注意到了DyperDyper其实它是一个分布式应用的运行室就是它是能够把分布式应用的这个能力给它抽象成一个一个的Building block那举几个例子来讲比如说一般的分布式应用程序都有Service之间的相互调用所以它有一个Service的这么一个Building block然后一般的分布式应用它都会比如说有PublishSubscribe这样的模式所以Dyper会有一个Pump sub这样一个Building block那包括还有一些就是会有一些输入输出然后它有一个Binding的一个Bilding block然后包括还有一些状态管理就是说我要存取一些数据那这些Building block之外呢其实会后面会由一系列的Component去支撑比如说我们这个Pump sub里边它就可以支持比如说各种云上的这种MQ比如说Google的这个Pump sub然后Amazon的SQS或者是一些开源的中间键比如说Redis, Kavka, NAS然后Binding同时其实也差不多它也支持一些云上的一些存储那同时也会支持一些开源的组件比如说Kavka或者是Mexico, Redis这样的一些组件然后包括状态存储其实也是一样的你可以把你的状态存到Mexico里边也存到Redis里边或者是存在一个云上的Dynamino DBE里边对吧然后也就是说它这个一个一个的Building block后面有一系列的Component去做支撑那这样的好处是什么呢就是我们刚才讲过的那个问题就是说你函数巨蛋平台的每一种语言你只需要和Dyper的API去打交道然后Dyper的API再去和后面的构成Building block的一个Component去打交道也就是说它这样的话就是把你的函数巨蛋平台的实现给你极大了做了一个减化然后我们从5×10的这么一个复杂度就变成了5×1的一个复杂度然后这样的另外一个好处就是说我这个函数比如说我在之前我用的这个后钻服务是Yamakun的云上的一个Dynamino DBE做一个State 一个Stone但是我迁移到比如说我迁移到别的云或者是迁移到线下的时候那我可以不用改我的函数代码我只需要把我的Page改一下它就能够用其他云上的存储或者是用一个开源的Redis去做它的一个状态存储所以其实这样的话其实就解决了我刚才讲的说你跨云迁移的问题或者是一个云上云上上绑定的一个问题这个我觉得就是说它是Dyper的出现其实是能够用API的方式不管是ATP或者JAPC把一些分布式应用的能力给你提供出来然后我们函数巨蛋平台只需要和Dyper的API去做一个集成就好了对那Open FunctionOpen Function我们是青云科技在2022年4月2022年砍年初开源的然后我们是在2022年的4月加入成为了Sinsa附在Sandbox的项目然后如我所说就是我们是通过引入Dyper的API就实现了和各个云上云上的Buzz服务以及中间间的Buzz服务做了一个解偶然后同时支持同步函数和异步函数同步函数就是避免不了的就一个问题就是说它要有一个入口这个入口我们选择了KBS的Gateway的API实现作为实现了一个Open Function的Gateway作为一个同步函数的一个入口这个一会儿一飞同学后面会有一个介绍异步函数我们就是通过Dyper能够从Dyper的各种比如说banding或者pump sub来直接输入事件来触发异步函数的一个运行涉及到另外一个问题就是说我这个函数的怎么样从代码变成一个可运行的一个净项这个是我们是用的KlanetedBuildFileX去做的这件事情它的一个对于它是和我们传统Build的净项都是用DoggerFile的方式大家写个DoggerFile就好了但是KlanetedBuildFileX它是就不需要你DoggerFile然后它会自动的检测你的代码是配合的还是够的然后用相应的技术去一层一层地把这个净项给你升了出来是符合OCI标准的一个净项对我们是用的这种技术当然这个自动的伸缩是避免不了的然后另外一个就是我们不仅能够运行函数也能够运行应用另外就是我们在1.0的时候加上了WallSumAge的几成也就是说我们可以运行WallSum函数用OmFunction运行OmFunction函数然后包括有更完善的CNCD这是OmFunction整个一个架构图可以分为这么几块BuildingFunction, Serving和Events其实主要的其实大家用户经常打交道的就是Function这个模块因为Function模块可以看作是一个主控模块它会去控制函数的构建和函数的设定包括一些函数的一些status然后Gateway的一些status或servingsBuilded status都会显示函数的CRD里面Build的时候像如我所说就是我们支持这种用Buildpacks的方式去构建函数的净项当然也可以用DoggerFile的方式去构建一个servings的一个应用这都是可以的然后我们后端的技术是用的ShipRideShipRide它可以切换它构建Image的引擎包括它可以切换成BuildAH或者是用BuildCat去用DoggerFile去Build这个净项它也可以用Buildpacks这种不依赖DoggerFile的方式去构建函数的或者应用的一个净项这个净项构建出来之后就需要把它放到一个运行室里面去运行我们现在就是放到serving的阶段这个serving我们可以看到我们最开始是支持同步和一步函数两种运行室然后一步函数是由Dyper和Kada做了它的一个支撑Dyper是和后端服务打交道然后Kada服务的这种伸缩然后同步函数我们最开始是支持Kinitio最近我们发的1.2的一个版本已经支持了Kada LDP的这种同步函数运行室就是它和Kinitio的作用是类似的你可以认为它是一个Kinitio的一个平体然后刚才也介绍了我们在1.0加上了BossMind这个运行室的支持可以运行BossMind的函数所以我们现在是支持四个运行室然后Events这个其实是类似Kinitio Evening但是我们觉得Kinitio Evening可能是用户用起来稍微有点复杂所以我们也做了自己的Events的框架这个Events的框架其实它的一个特点就是其实也是用通过Dyper来实现了它的底层的Broker和它实际的MQ的一个解奥然后也就是说我们的Events的Boss是用Dyper Pop Sub去实现的然后它因为它是一个Building Block然后它底层可以是各种云上的MQ也是可以是一种开源的MQ所以它是不会绑定的你用某一个Broker的对然后Gateway下面有这个一飞来介绍一下OK接下来我们来介绍一下OpenFoundInGatewayOpenFoundInGateway是在OpenFoundIn0.7.0版本就是实现了一个新的特性然后它是基于这个KBISGateway API来实现的我们选择KBISGateway API主要是因为它CRD和它的下游实现它是接吻的就是我们OpenFoundIn的用户可以选择它喜欢的Gateway的实现比如说API-6或者是Control或者Youtube就是不会对用户对相关的Gateway的实现产生板电另外就是Gateway API也提供了一些很多新的特性比如说HTTP流量的分发以及QuartNemSpaces的一个比如说Rooting的功能这个对Fast平台来说都很有吸引力然后我们可以看一下图里边这个流量转发的一个路径以前的话就是OpenFoundIn需要把流量先转发到ConnectiveGateway有ConnectiveGateway路由到ConnectiveRevision里面这个连络会比较长现在的话我们可以直接把流量转发到ConnectiveRevision也就是说我们就不再依赖Connective网络相关的组件了整个连络也会变短接下来就说我们为什么要引入OpenFoundInGateway原来我们访问函数的话是通过ConnectiveGateway提供了一个随机助传组成的Service的URL就是我们通过这个URL不能判断它到底是属于哪一个函数或者是我们有一个椅子的函数但是我们也不能从这个函数的名字或者Limspice推测它的URL应该长什么样子现在如果通过OpenFoundInGateway来访问函数的话我们就可以通过它的方音的内幕和Limspice然后加上集群内部的一些Safix组成这个URL来访问函数另外还可以通过Gateway的Service加上这个方音的Limspice和Lim来进行一个就是PassBase的一个访问我们也可以继续OpenFoundInGateway的IP然后加上就是后视的相关的Head来进行一个HoldBase的一个访问另外就是如果我们想在集群外部访问集群内部的访问性的话我们可以在OpenFoundInGateway上面配置多麦相关的字段把它配置成这个Matic DNS这样我们就可以直接在集群外部通过域名来访问集群内部的访问性接下来我们来描一下就是能启动优化能启动优化一直是发视平台的一个比较难的一个点然后我们之前的话采用的是DepthSetCard的模式就是每一个方式能破的都会包含一个DepthSetCard它们它就会影响整个方式启动的一个时间因为有可能我们的函数甚至很小然后整个DepthSetCard的Content启动它需要花时间另外还有就是它的DepthClient初始化这个整个过程一般也比那个方式启动的这一个时间要更长所以说它会影响我们能启动的一个时间所以我们设计了一个叫做DepthPoxy的模式就是让所有方式能破的可以共享一个DepthSetCard这样就不用再特别是比如说我们方式现在扩拾我们的时候我们如果扩拾到很大负面数很多那么SetCard也会造成大量的一个资源开销但如果以后DepthSetCard比如说推出Pro的相关的一些方式的话可以替换掉当前这一个模式接下来我们就是有一个机率破的一个能启动优化的计划就是刚刚我们聊到了DepthPoxy我们发现对它进行优化之后我们来测试方刻性的一个启动的时间发现对是进行了优化但是还没有完全优化因为整个Port创建的过程还是收到K8S整个Port创建的整个比如说调度啊这一个逻辑的整个时长的一个影响所以说我们就想到有可以用就是Port的一种方式我们的方刻性Port里面可能它先跑了一些GaleryCodePort这一Port已经是专利状态只是它不是针对某一个方刻性的Port那这时候如果有方刻性调用的请求进来我们会根据这个方式这个请求相关的一些信息判断它要调用哪个方式然后对这个方式的Code进行一个热加载把它变成一个针对某一个方刻性的Port然后后续的流量的话就直接进入到这一个特定的方式的Port这个过程的话就不再需要K8S整个调度啊创建了这个逻辑的参与所以说它对能启动的整个时间的优化应该是非常显著的OK 接下来我们是在1.0版本的话就是支持WashmenAZ作为Washmen的一个运行室WashmenAZ作为Fast平台的运行室的话它本身天生就带很多优势比如说它的启动时间很短然后它的整个镜像底级也很小比如说我们比如说出来的镜像的话因为它在镜像当中它只包含WashmenAZ的一个字节码它就整个镜像可能只有几10K 十几K 甚至几K整个镜像拉取的时间也会很短另外就是它本身支持Sandbox所以它的安全性也会比较高我们选用WashmenAZ的话因为就现在DeprWashmen相关的就是它有不同的实现目前这个标准的话也还没统一WashmenAZ相对来说是对HTTP这一块支持的比较好的一个运行室接下来我们看一下WashmenFunk信就是访问后端服务的一个问题因为我们知道WeberSambly程序访问API它是受限的所以它更需要通过Depr这样的一个组件能够给它提供一个相对统一的方式来完成对后端服务的一个访问但是现在的话比如说DeprWashmen SDK以及DeprWashmen相关的项目它还不够成熟所以我们暂时还没有对它进行集成后续的话等相关的生态成熟之后我们会把Depr集成进来然后为WashmenFunk信提供更好的一个后端服务访问的一个能力下面我跟大家介绍我们一个社区用户叫预示科技它把我们Funk人用来自动驾驶领域的一个案例增加时其实这个简单来讲就是车端会上传很多传感器的数据到云端那就是这么一个场景那它云端需要对这些数据进行处理那这是一个云端的一个架构图然后比如说你车端的MQTG的这个Broker把云端的数据传到了云端的一个MQ上那这个它会就是预示科技的小伙伴会创建各种各样的异物函数和统布函数来处理这个数据那比如说有的MQTG topic的这个数据会有一函数处理然后其他数据会有另外一个函数处理然后它们处理完的数据分别存到了不同的这种后端服务里边去因为它的业务比较多然后可能有的业务也是不同的团队去实现的所以它需要用不同的语言去实现这么一个事情那这是一个车端数据处理的这么一个例子然后下面这个就是有两个比较高阶的一个例子这个左边的这个代码呢就是它是就说它会把车端的上传一些MQTG的数据然后呢会通过这个异不函数左边就是异不函数这个代码就是从这个MQTG的数据里面提取出一些metrics然后再把它发送到ProM修司的Push Gateway这样的话就是相当于是你把车端的数据给它变成了一个metrics然后存下来那这个过程是由一个异不函数来完成的所以这是预示科技的小伙伴一个比较非常高阶的一个用法然后因为我们可以通过代码去很好的对接MQTG一个broker所以呢它就是很容易的就是写几行代码就是写这几行代码就把车端的那个MQTG数据的提取出metrics然后就我觉得非常酷然后他们为什么需要这么一个厂商中立的发的平台呢就是我刚才说的那几点就是他们的客户有的时候需要他们把自己的方案部署到不同的云上然后有的客户也需要部署在私有云上然后它如果是不同的云都要去适配这个成本就比较高所以呢就是用OpenFunction这样一套方式呢就是说我写一套代码我做不同的配置然后就能够在不同的云上去运行就可以了然后他们的业务就是车端的业务它也有一个潮汐的需求嘛所以它有一个自动伸缩的一个需求就是比较适合用Service这种方式去做的对然后社区然后因为我们讲的dipr然后我们也和就是bio-comfunction怎么用dipr呢和dipr的两位这个创始人做了一个交流就是在dipr的那个社区的会议上做了一个交流然后呢他们其实对OpenFunction的这种用法也是非常的欣慰然后然后我们可能还就是会后和那个dipr的一个mentender还要做一个深入的交流对具体的一些路线图其实第一个呢就是韩束框架支持State这个我们在1.1的时候已经实现了然后呢现在对Person的支持也正在优化中然后呢然后就是刚才可能运行时的就是刚才易飞讲的最重要的就是我们要基于泡的池的一个能启动优化的方案这个可能下一步是一个比较大的一个工作然后很多用户也互换这个我们方正一个控制台这个我们可能也也也在这个计划中然后另外就是现在这个AIGC大模型的这个比较比较这个呼声比较高嘛但是我想到的一些场景比如说他处理这个数据的时候呢其实可以和我们的义务韩束做一些结合然后我们也会考虑说这个AI的韩束我们怎么样去做一个支持然后贡献者呢就是主要的mentender是来自Goose Fair然后有一些比如说社区的贡献者比如说来自Skywalking的同学帮我们集成了这个Skywalking用来追寻韩束的性能还有预示科技的小伙伴SAP的小伙伴然后包括那个微众银行最近有一位同事有一位小伙伴正在做一个叫灰度发布的这么一个功能就是我们现在这个同伴说不支持灰度发布然后他在帮我们做一个灰度发布这样一个功能就是有点类似这个argo rollout但是我们没有用argo rollout是自己实现了一个逻辑然后包括这个微众银行还有值得一提的就是微众银行的小伙伴也在帮忙就是把用他们那个event mesh来替代diper做一个buzz服务的一个集成他们现在也在推进这个事情对然后现在采用的公司包括以致的是国内某一个著名的电信厂商的一个云他是在用OpenFungus做他的那个银行术然后刚才提到预示科技还有微众银行还有喜马拉雅还有一个国内一个证券公司对然后接下来就是由易飞给大家介绍两个dialogOK 接下来我给大家演示一下OpenFungus相关的一个势力首先第一个是一个典型的同步寒宿触发一步寒宿的一个势力他整个触发的面图的话就是客户端对这个同步寒宿的一个弟子发起请求然后他会触发一个diper的output banding那么他会把这个event publicity到卡夫卡时候然后卡夫卡input这个event寒宿的话他订阅了这一个相关的topic所以说相关的事件进来之后的话就会触发他的input banding然后最终触发bandingevent来调用这一个event寒宿然后我们可以看一下具体这些这个同步寒宿和event寒宿的定义OK 这里是这个FunkingFond这个Funking的CR这里的话我们可以看到它这个部分是HTTP说明它是一个由HTTP请求触发的一个同步寒宿然后banding部分定义了一个名叫卡夫卡时候的一个diper component它的banding它的type是banding.卡夫卡下面是一些卡夫卡的连接信息topic信息可以看到这里是sympotopic然后我们在output部分引用了这个diper component来作为它的output banding我们可以看一下他的代码当中做了一些什么这里定义了一个Fond to卡夫卡的寒宿我们可以看到这个寒宿签名它参数包含两个部分第一个是我们方个性定义的一个context第二个是一个battery的数捉然后我们方个性context提供了剩的方法可以向我们的output发送一个比如说这里是grating的一个数据OK 这是同步寒宿然后我们看一下这个event寒宿event寒宿的缺德部分它是由diper说明它是一个有diper input的banding来触发的一个event寒宿然后我们可以看topic的定义也是一个diper的banding component然后相关的参数它刚刚到的同方寒宿其实它是一致的然后它会多一些定义比如说skill op系里面它有k大相关的skill object就是这个寒宿要怎么进行扩展我们的一个参数另外还有就是trigger这里就是定义了k大相关的这也是kavka的一个链接然后它的预值和topic也就是说当topic当中有消息的时候只要它不是0它就会把这个方形的portskill op起来然后如果这个synport topictopic里面都记得消息数量很多比如说是200个那么它会根据这个预值算一个它期望的work load的一个副本比如说200的话在这里可能就是10个副本OK 接下来我们就是在实际的环境当中演示一下就是它同步寒宿怎么触发这个异部寒宿的一个流程OK 这里可以看到我们的方形这两个方形已经定义好了就是它也是running的状态然后我们看一下它相关的port现在没创建因为没有HTDP请求也没有相关的事件所以它已经被skill到了0然后我们对这个同步寒宿发起一个请求然后OK可以看到这个同步寒宿的这个port已经被触发被skill up然后我们可以看一下它的日子它收到了这个我们发给它的messageor什么方形然后它会触发output的班点然后让这个异部寒宿的port也运营起来你可以看到它的启动时间是比同步寒宿要晚的然后我们可以看这个异部寒宿的一个logOK 它收到了这个我们一开始发给同步寒宿的一个消息也就是说明它这个寒宿被它触发skill up并且它收到了相关的事件这就是一个同步寒宿触发异部寒宿的一个完整的一个流程接下来我们可以简单介绍一下更多的一些例子这个的话是目前我们发现最新的版本1.2当中实现的一个飞鞋就是关于KTIGTTP的这KTIGTTP的话我们可以简单看一下它的定义它跟普通的同步寒宿其实并没有太大的区别我们可以看到它主要是trigger部分它是HTTP然后NGIN字段的字是KTIGTTP说明它是KTIGTTP这个原因是另外skill up新里面它这里KTIGTTPskill up新的部分它是需要定义这个才可以根据HTTP相关的指标进行一个伸缩这个我们就不演示了另外还有刚刚介绍的Whatsum方式相关的一些定义我们也可以看一下这是一个有Rust写的一个简单的HTTP Server然后它跟其他的Runtime的函数不太一样的就是它的Walkload的字段的值是Whatsum一击有了这个值以后的话OpenFounding的Controller Manager在Reconcil的时候会比如说对于Biota那么它会调用Whatsum一击相关的一个ClustBiota Stratage完成Whatsum方式的一个构建比如说它会用到Biota会加上一些相关的Allotation然后对于生命部分的话就是它在生产工作负载的时候不管是那个比如说Clientive SVC或者其他的Walkload那么它会在Walkload的那个Runtime Class上面设置它的运行时比如说它是C软或者其他软C之类的一些运行时另外它还会加上一些Whatsum一击函数运行需要的一些Allotation然后它就可以运行了这里可以简单看一下刚刚说了它的进行体积非常小可以看到这一个Dockfile它最后的话只是把这一个Cargo Build出来的这一个Whatsum的字节码copy到了这一个空的这个进行里面所以它体积非常小接下来可以看一下Redis Stratastore相关的一些用力Open方形的话现在也支持了DepthState Component我们这里看到它定义了一个叫做Redis然后Type是State.Redis的一个Component那么相关上面有相关的连接信息比如说它的密码HOST相关的东西我们看一下在方形当中怎么使用它我们可以看到这里的代码首先我们可以从Connect里面获取这一个DepthCount有了这个DepthCount之后的话我们可以根据我们的警觉比如说是Gate Post或者Delete然后调用Depth相关的GateBugState或者是CivBugState或者Delete所以DepthCount的话它提供了很多的API不止这些就是这个就根据我们具体的业务需求可以进行选择最后我们简单说一下就是Service Application因为就是我们比如说对于HOST这些语言来讲Open方形社区的话目前还没有提供OpenFM1可能够直接写放不写那么对于Application的话它跟Open方形的一个区别可能最大的不同就是它包含一个迈韩数它不需要依赖其他的FM2可以直接运行那么所以我们这里提供了两个例子就是一个是可以有Dogfile的这是一个Go的例子然后可以看到它对一个Dogfile是一个很简单的一个Builder然后在这里指定它的Builder为标档然后它的class标的Static为标档那么就可以完成这一个Go的方形的Go的Application的一个构建另外还有一个就是Service Application without Dogfile这是一个加弯的例子这是Builder Pax这个仓库的提供了一个Simple然后我们可以看到它也有一个嘛我们要构建这一个的话因为它是没有Dogfile的没有Dogfile的话其实也很简单对于这个例子来说就用Cloud native of Builder Pax提供的一个叫做Simple Builder的一个进行就可以构建这一个加弯的Application基本上今天的赛事就结束了然后大家如果是想加入微信的就是OpenFunction的交流群可以扫这个二文码然后回复OpenFunction然后就可以加入这个OpenFunction的交流群然后看看大家有什么问题没有我想了解一下就是那个YSNH你们支持的话它的那个扩缩容的话是怎么支持的你可以把它理解为一个continental runtime就把Vosom Edge 理解成一个continental runtime然后它的扩缩容是由Kinitl或者是k.idp去控制的然后其实我们生成的Vosom Edge的这个Vosom的函数的镜像它其实你可以把它理解成一个continental镜像只不过这个continental镜像是由Vosom Edge来运行起来的并不是由continental D或者是这种CIO来运行起来的明白明白那也就是说就是关于容器编排这一块像你们有Ki的这个支持它天然的就可以跑在机群里面对对就是说它和KiOS是可以跑到KiOS里的就是可以把Vosom Edge装在KiOS里然后它能够通过KiOS的调整能力把它调整起来同时也可以比如说本地跟一些云端打通这样跑对那个可能就看见到网络了谢谢是的我有几个问题第一个是就Open Function我看你们前面有一个架构图那个Open Function的安装起来的话然后架构图里面的所有的组件都有都包括吗对我们有几种安装方式就是你可以全都安装然后你可以选择性的安装比如说你可以指安装同步含述的运行室或者是指安装易不含述的运行室或者是指安装比如说你可以指定指安装Kinitio和Deper你也可以指安装Deper和Kinitio你也可以指安装Deper和Kinitio对它是比较灵活的然后第二个的话是你们有一个Open Function Gateway它是实现了Kinitio里面的那个Kinitio Gateway是吧对然后第三个还是那个架构图里面就是你能稍微介绍一下比如Kinitio和Kinitio的区别吗然后Kinitio可能它更多的是一个对同步含述支持的是比较好然后它易不含述可能就是用Kinitio Eventing去实现的然后我们觉得Kinitio Eventing是用起来稍微复杂了一点然后我们注意到了KataKata其实它就是能够根据各个事件员特有的特性去伸缩你的副本比如说你看不看消息堆积超过10个它给你多出一个副本超过20又给你多出一个副本这样的话就是能够根据你的事件员的特性去伸缩你的副本这样的话其实比你单纯的用CPU或者是这个LDP的请求数量会更智能一点对然后这是最开始的Kata是这样的然后它没有但是它缺少这个LDP的这种流量的这种伸缩的支持然后但是它是最近是通过了Kata LDP这个插件加上这么一个支持然后也就是说它既能够根据同步的这种LDP流量去伸缩也能够根据事件员的一些特性去伸缩对那我再补充 还有一个问题就是假如说我的事件员是一个卡福卡卡福卡里面比如我定一个topic的时候派对运数量已经固定好了比如有20个是吧那假如说比如我们之前用的是那个卡福卡的问题它默认的话就是只能从每一个派对信里面去消费那它的并发最多是20是吧假如说有那种消息堆积的话有可能比如说加大底层的这个Port的扩容的能力吗Kata的话你说的这个非常好就是我们也在开发中遇到过一个问题我们开发中发现我们这个函数老是不扩容为什么呢就是因为它只有一个Portation所以它的这个扩容的上限就是和你卡福卡的Portation的上限是慢吃的对是这个就是具体的MQ它实现的不一样卡福卡它有Portation的概念但是你像如果是Pause或者是其他的一些云上的MQ它没有这个概念它可能就扩容可以扩的很多谢谢对你好我有个问题就是想问一下就是关于函数这边一不函数就现在有没有一些状态监控的一些能力就是任务下发下去之后我也不确定它有没有运行之类的这种情况这个确实是我们需要去提供的一些加强的一些地方我们目前是还没有这样的一个对没有这样的一个能力但是可能需要你说的就是需要把一些Metrix给暴露出来好谢谢就是这张图里面我们其实依赖了很多的开玩组建是吧包括大部分可以点就这一那核心问题是说我们OpenFind的那个眼睛路线跟这么多开玩组建的眼睛路线的一个关系是什么样就是假因为包括这里面核心后端是不是主要是Connective跟深缩那块主要是KDMA然后后端对接主要打扮这些组建的路线如果有些社区或者听证眼睛或者有些路线上的一些差异的时候我们后续的一些我觉得你说的这个问题是很好的一个问题然后我们选择我们的后端依赖了组建的时候也是比较深重的然后你可以看到KD和Connective现在基本上都是Connective应该是已经进入到SenseF的这个服务化阶段了包括Depart也是然后KD好像也是进入SenseF的服务化阶段所以我们选择的一些组建基本上都是比较成熟的一些组建然后另外一个就是说如果就不幸像你所说的如果某一个它停止眼睛了那其实我们你可以看到我们的方式其实是有就是它是一个可差拔的一个架构就是说我们是通过function的这种CRD的定义屏蔽了它后端的一个实现就像我们支持Wassom Match的运营时我们是有一个Wassom Workload的这么一个字段去定义就是说你可以用Wassom Match你也可以用其他的Wassom的Runtime就是类似对于Connective或者是KD也是类似的相当于那个中间适配层到时候再会再重新做适配改造对如果它停止眼睛了那我们会做一个改造对是的但是对用户内层的那个语义比如多云的时候用户内层它的兼容性和韩束内层的定义这一套是我们欧盟方形的那个规范是吧假如到其他的上面它是就是你这个韩束和其他的云的那个后端服打交道我们是目前是通过Dapper来实现的然后我们的韩束里边我们现在直接眼镜成了就是你直接调用Dapper的Client就可以Dapper Client提供什么API你都能够可以去调用然后我们最近也在和微众银行的Euntmatch的这个项目他们也在做集成也就是说如果你不用Dapper你也许后面可以用Euntmatch去提供这个和后端服务集成的这个能力就是我们之前是把Dapper的API做了封装但是我们觉得这个可能不太好就是就是后来就直接把这个Dapper的Client给爆了出来了嗯对像Buzz和Fuzz我印象Buzz好像是也有一套社区标准在眼镜的那我们会遵同那套标准吗因为各家云厂上也在往那套标准去靠吗嗯你说的这个标准我可能还我是不太就是您说的是哪套标准嗯也是Buzz后端那个标的我觉得可能我觉得可能现在Dapper就是一个就是类似一个标准就是我觉得他已经是就是非常受欢迎的一个项目了然后我觉得可能如果做标准的以后可能他也可能也会就是把Dapper作为一个参考实现吧对行 大家还有什么其他问题吗喂 您好 我想问一下就是你们最早是集成到KNATU吗对后面是加的那个KDAJHTTP然后你刚才也说的KDAHTTP实际上可以理解成KNATU的评计对那么就是你们就是支持两个以后你有发现他们这个功能上差别很大吗还是说完全就是没有优势或是区别度这种KNATU当然是更成熟一点这个是不可否认的然后KDAHTTP呢现在是进入了这个Beta状态其实它还没有GA然后我们其实一点点加入呢其实我们也观望了很久然后在它Beta的时候我们才把它给集成进来然后在之前前一两年就关注到这个项目但是没有做集成 对好 谢谢然后还想那我继续问一下就是说那它还没有GA它肯定会有GA的一天吗对那作为Open Function这个项目那你其实两个功能差不多的这种Round Time或是运行时的话那你是会后续一直都支持还是说你会到时候做取舍后续我觉得应该会并存就是让用户去选择让用户去选择对我们可能是比如说可以有一个默认的运行时是KNATU好 谢谢好好 那时间差不多那我们要交流的话可能先下载交流吧 好吧