好 那个各位在场的嘉宾 大家下午好对 然后很开心 今天我能够跟我的那个联合演讲者一起在这个地方 然后跟大家分享一下关于顺风边云这块业务对 然后跟云原生的一些结合然后以及如何通过云原生 边云计算这些技术然后为整个物流的一个服务对 一个创新去带来一些加速或者说是一些好的地方对 然后我的联合演讲者陈芒刚然后他现在也在位置下面然后等会到了他的这个部分然后我会邀请他上来OK行 然后边云计算的话实际上是一个已经被提过满多年的一个技术了对 然后可能在这个技术刚开始被提及的时候可能大家对边云计算理解可能会在想说边云计算是不是像是CDN这种技术ME-C这种技术也有人可能会在想说边云计算是不是就是物联网 IoT之类的一些技术但是随着边云计算的一个不断的发展然后以及我们对边云计算这个领域的一个认知的加深然后其实我们是可以根据一个设备然后距离数据中心的一个距离然后来对边云计算去进行一个简单的一个划分比如说像CDN这种场景我们可以把它称之为进场边缘因为这些设备它可能离数据中心的距离不会太远还有一些可能就是不属在客户的现场或者说家里的一些设备这种设备我们把它称之为现场边缘这些设备它可能一个比较明显的一个特性就是它的资源比较少对 但是它的一个优点就是它更加靠近我们的用户OK 然后随着边云计算的一些发展也有很多的跟边云计算相关的一些标准组织或者说是一些相关的一些技术以及学术上的一些东西平台也在不断的出来其中Cube Edge它是第一个跟云元生相结合的一个边云计算平台并且它是在2018年开源出来了然后也捐赠给了CNCF然后在20年的时候它是达到了一个副化级的一个项目然后现在Cube Edge是整个生态整个社区也正在去冲击一个毕业对 OK然后Cube Edge在发展这几年来其实也是有很多的一些实际的一些案例对 然后我这边简单讲一下首先在安防这一块的话通过边缘计算的一些技术我们可以通过边缘测视频的预分息然后来快速的去定位一些异常或可疑的场景同时边缘的这种特性可以起到这种数据隐私保护然后我们一些比较敏感的一些隐私数据它可以不需要上云防止泄露一些个人的一些隐私信息特别是安防这一块它在原区里它其实有很多的一些信息都是比较敏感的OK 然后也可以通过这种边缘平台的能力然后来达成这种智能应用的统一管理与远程的这种升级然后在交通行业的话它可以边缘测可以实时的去处理大量的一些交通数据因为它交通行业它可能它的路面上的情况 它的信息量变化是很快的所以它的一个信息量也是很大所以说边缘我们在边缘去处理的话它会比较有一个快的实施性然后交通这个案例它之前有个案例它也是能够去提升整个省界的一个收费效率对然后第三个的话就是对于这种之前的省界的一个收费的这么一个边缘项目的话它本身它的一个量非常庞大然后通过QBH这个边缘计算平台它也是可以去统一地去管理海量的抑购的这种边缘设备OK然后在物流这一块的话实际上边缘计算平台也能带来一些好处它可以去实实地去弹性扩展资源然后去满足一些不确信性的一些物流的业务量因为其实对于物流来说它可能在一些比较高峰的一些时候它的业务量是非常大的比如说像一些节假日或双十一 双十二这样然后第二点的话是可以利用我们部署在边缘节点上的一些视觉类的一些应用然后我们可以去实实地去监控以及追踪这些货物的一个位置和状态然后我们通过部署这些比较高端的比较上层的一些AI分析类应用然后我们最终也可以去跟整个底层平台结合然后来提升整个物流的一个交货准确率对所以QBH实际上它已经是在很多行业里有应用然后这也说明QBH目前对于有边缘计算需求的一些厂商来说它可以直接去对接QBH不需要从零开始然后就可以在这基础之上然后在针对自己的一些业务特定的一些需求然后去进行一些改进和优化就不需要从零开始OK然后其实各行各业的一些边缘领域都会有一些有一些它自己的一些特定的一些需求但是QBH生态它就对这些比较典型的一些边缘计算场景的一些挑战进行了一些体验和抽象首先就是边缘场景下它的一个云边的网络通信的质量会比较低它很多设备一般都是位于一些私有网络里面可能会有那种多层AAT嵌套的这种场景它的一个底层网络脱补其实是有点复杂的而且设备跟设备之间的一个双向通信也比较困难第二个就是刚才也提到过边缘的话它相对于数据中心来说它的一个资源肯定是不像数据中心那样子充足的它的资源是比较受限的所以我们部署在边缘节点上的一些组件它一定要是足够的轻量 足够的快同时因为刚刚第一点也提到边缘网络它比较质量比较低所以边缘设备或边缘节点它也经常会处于一种离线的一个状态所以对于边缘节点来说离线是一个常态是一个比较常进的一种场景或需求所以对于这种离线的时候我们必须要很好的处理能够具备业务离线自治或故障恢复的这些能力第四点就是边缘节点它高度分散它其实在有些场景下它其实边缘节点它并不会去集中分布在某一个区域或某几个区域它可能分布的它可能跨度会比较大有多个这种分散的区域去集成一个大的一个边缘集群所以如何高效地管理边缘节点或边缘的设备来降低运运成本也是一个很重要一点最后一点的话其实就是有些边缘设备它其实会来自于不同的一些厂商可能有一些设备就是一个计算单元一个盒子可能有些设备它甚至是有可能是机器人或者是家里的路由器光猫之类的设备所以这些边缘的这些资源它的依购度它是很高的那么我们必须要做到一个标准化的管理然后灵活的配置统一地去对这些资源进行一个把控然后这边简单讲一下QBH的一个架构它的架构的话首先QBH本身是依托于K8S的它会去直接利用K8S原本的一些调度的一些能力以及对资源的一些抽象的管理等等它本身云上会有一个组件叫Cloud Co它本身会有一些控制器边测的话会有一个叫HCo的轻量化的一个组件然后这个组件它本身能够去它符合CRICSI以及Ci的一些这种标准它可以去对接多个容器引擎无论是ContentDocker或者其他也好然后本身的话它右侧的话它会去对接一些物联网协议然后来对一些物联网设备进行一个管理然后同时还有一个网络插件叫EdgeMeshEdgeMesh它是为了去解决这种边缘网络跨子网的一些问题然后能够把这些处于不同区域的这些容器的一个流量进行一个打通对 然后QBH整体的一个设计的一个开发的一个原则就是右边这几点首先它是开放生态且兼容KBS的原生能力的KBS它有的一些能力它不会做清露式修改它会原封的一个继承然后第二点的话它是支持更多的节点设备的揭露相比于数据中心的KBS它可能能够揭露更多的那种边缘节点或边缘设备第三的话就是通过EdgeMesh的能力它能够去支持复杂的边缘跨边缘的网络或者说跨边边的这种跨子网的这种网络环境第四点的话就是在这种离线的常态的这种情况下它边缘节点上的一些应用和数据它能够做到离线制置对OK然后这边的话所以跟顺风是一个对QVEdge的一个比较好的一个实践除了刚刚说的那几个案例以外其实顺风在使用QVEdge的过程中它也是有对QVEdge进行一个深入的思考对然后顺风的话它其实跟QVEdge社区的整个生态它其实也是跟进得特别好的然后这个地方大概的去讲解一下顺风是如何参与到开源项目的生态的一个共建里面来的首先顺风本身会根据自身的一些业务然后深入的去使用QVEdge以及EdgeMesh的网络插件在使用的过程中它除了使用以外它还会去参与到QVEdge社区的一些立会然后去了解一些新的一些特性可能有些特性就能够在它们的一些场景里能够被使用起来然后第三点就是它们本身在用的过程中还会去考虑跟自身业务的一个结合然后去不断的去优化第四点就是它们会把这些它们思考的一些点在社区里拿出来然后跟大家讨论可能有一些它确实是可以抽象成一个通用的那种边缘计算领域的一个一个特性点OK这是对 然后第五点就是我刚刚说的可能有些点有些优化点可能确实是跟本身物流业务紧密性比较强但有些业务可能就是可以抽象成一个比较通用的适用于边缘计算的这种点然后第六步的话就是作为一个贡献者一个开源社区的贡献者它能够在开源仓库里面去提出相关的一些代码或者是提出相关的一些提案对 然后最后我们再回到第一步再接着去深度的去使用新发布的一些QBH或HMASH版本然后不断地去迭代和优化自身的一个业务OK然后这是跟QBH社区合作的一个流程然后接下来的话就有请我的一个联合演讲人对 陈鹏康先生来介绍一下他们是具体怎么在QBH在自身业务的使用由于时间关系我简单做一下自我介绍我叫陈鹏康来自顺风科技我们在整个边缘云我们顺风有个边缘云的项目只用到了我们现在QBH Tech技术我们整个是有一个完整的落地今天很容易再分享一下首先我们从背景讲一下因为我们顺风它在全国包括国际上面全球都有一定的场地然后它的场地就非常复杂它的场地有中展场有分点部还有我们场规的派将它就比较复杂然后隔得比较远场地的设备也比较复杂它有TAR86的中控机还有TAR86的服务器还有按摩的GPU壳子还有TAR86的GPU服务器反正特别混乱这种情况的机器设备都有因为它是不同阶层不同时间段采购并应用的然后网络环境这块的话这块简直就是一个难以描述的东西因为每个场地从头到尾建立它由于时间段不一样并没有完完全全的都能做到一个完全的标准化因为有的场地它可能是带公网IP的专线但有一些可能就是民用宽带这种现状我们也是有的最后还有就是未来业务我们场地上面会不足很多相关的一些应用会和我们业务的一些应用但是这些应用由于它有一些特殊的需要所以它就会有一些特别的一些要求比如一些多种类型的GPU网卡它可以有一些不同分支的另一个系统还有很多比如说共用的一些服务器共项目的服务器它包括后续业务在迭代过程中会引入一些新的技术包括用到了一些像我们现在已经存在的我们编端在我们场地我们场地和编端其实是一回事它就会用到一些迷歐EDCDMagicalNAS等一些就是从常规的那种传统的数据中心可能它用到的技术所以在这个过程中我们就遇到很多问题很多问题最常见的就是我们的应为支持不足因为我们在全国有几千个甚至过万的一个场地如果是每个地方都配置这样的一个应为人员就继续痛苦的而且同本极高其实运行环境有它也很大因为我们存在多运用共用的还有多项目共用这个系统的这样一个情况所以它同一个运行同一个机器上面运行不同系统的一些运用所以这一块对于我们这个小镇也很大其实因为它的那个机器大家存在共用那就意味着它的那个机器传统的模式它是要把对应的应用包下发到对应的机器上面而且是下发到全国N多个机器上面去进行一个发布这个过程中会非常好时间而且他们那个包非常大对于这个带宽要求也很变态所以我们这一块发板效率也是极其低下的之前的话之前是专门有一个团队每次发板的时候专门干这个事情而且一发板少则半个一个礼拜多则半个月时间极其拖的长最后就是在这个自研隔离刚才也说了因为它存在这个机器设备共用的一个情况那就意味着它的隔离其实是比较麻烦比如它GPU和GPU它不能够按照需要来隔离那最多就是个共享隔离做不到的话也就意味着这个应用之间相互影响那就有可能会比较麻烦同样的我们这个共享这块也就成了一个大问题根本就不趋势所谓的自动调度全靠轮工如果一旦出现了过多什么之类的那就要轮工去登录到这个机器上面我们有一个类似的保磊机的系统特上去手工操作调整它的自研配置这样就非常麻烦对于我们来讲我们引入Cafe Edge之后我们在这个技术上结合容器的技术我们这个时候会有一些新的东西新时代里面我们会有些很多东西首先在应用层面我们应用层面首先会有一些监控因为原来的业务它们是各自违政它自研是通过在附属启动的时候给它配置好自研的一个空军那这样的话就会有一些业务它就要做一些监控包括一些业务本身的一些监控这个之后我们也要需要去做一些监控目前我们的监控是定时化的在这个边端会部署一个采机点然后这个采机点会定时上报和常规的普拉米修斯的那种模式还不太一样所以我们就整理一个改造版其实我们边缘的应用需要一些智能的解析这一块的话主要集中在于我们比如说一个域民可能要在全国各地不同的机器不同的场地它解析出来的IP是不一样的那这种的话就类似于我们传统的智能解析了就是多线路的智能解析但是我们这个是跟场地相关的其实我们边缘的有个数据处理这块是非常麻烦因为我们的刚才也讲到了我们有那个在机器部署在边端它的数据比如说我们有那个中控机会有那个它就会去检测我们机器机器上面的那些包裹它的包裹上面有没有围巾品我们会拍照会有视频那这个东西它要本地的一个做一个处理然后这些处理它要去检测有没有围巾品这些东西这些数据量极其庞大我们之前简单的统计过每天一个场地是在T级别的所以这个数据量都非常恐怖的如果我们要在本地处理其实这个时候本地处理已经是最好的一个解决方案了再就是我们的一个设备刚才讲到的应用在下面就是我们的设备了我们的设备的话有很多但是我们目前的话除了我们主要让用户可以加进来的就是常规的这种盒子GPU浮气或者T86浮气可以加进来比如说摄像头我们目前是没有揭露的但是因为摄像头它不支持这种系统完整的操作系统它也没有办法去执行一些比较复杂的命令然后我们的这个设备是指我们的一些编端的一些机器不管是盒子也好还是普通的浮气也好它都能够通过我们的自动或者手动一些命令我们会有一些命令可以去下发给它也可以手动在我们的控制台里面产生一个指令直接就在节点上注册它就可以加入到我们这个局区里面最后就是设备的多样性的一个设备了然后我们的机器刚才也说了有不同的系统比如说无帆图有一堆的系统然后有一些GPU我们有很多很多的显卡比如说英伟达的显卡这些显卡它们的系统操作系统去驱动它都是强相关的所以我们在这个上面也是做了一些设备其实在这个基础的设备监控主要是针对的这个是我们这个KBH这个组建本身的一些基础监控还有我们的机器我们的机器本身的监控最后一个就是我们这个集群这一块集群这一块的话我们是在那个整个集群本身是高可用然后我们会有多个集群在异力是多活的多个机器那个不同的机器在它那个队的区域里面按照这个区域就按照旧进来连接这样的话节省这个一个带宽包括这个实验的问题其次还有就是我们边缘场地它在同一个场地内我们就去实验调度的因为我们这个同一个场地它情况特殊因为它可能有的机器有的场地只有一个节点可能就只有一个盒子可能有的机器有的场地有多个节点所以呢我们这个机器呢我们的场地有的有多个节点那这个时候呢它就存在一些调度我们是要在同一个集群内同一个场地做一些调度好我跟CG讲一下我们这个这边的基础架构从上往下讲吧我们最上层的是我们的顺风的那个DCN区域也就是我们的内网区域我们内网区域的话会有几个服务一个镜像服务镜像服务然后呢再就是我们的一个我们镜像服务呢通过构建之后往左边走往右边走就能看到就是我们有个总部的镜像舱库总部镜像舱库最后呢我们的那个部署的时候到总部了之后那我这个时候呢我这个总部会有对应的节点加入到我们总部的一个测试集群那这个是用于在我们的那个顺风内部做流水线那个发板测试的时候用后可以在总部测试集群这个在总部完全完成这个整个业务的测试验证它的镜像的依赖是从总部的镜像舱库里面去获取然后呢等你这个对应的镜像OK了之后呢它会要部署到我们场地啊也就是场地我们最下层啊就是最下层红色区域是场地集群场地集群的话就是各个场地它有很多场地每一个场地的话它有不同的一个设备有很多的不同数量的设备有的场地呢甚至还有一些中共企业图片服务气势类的就特别复杂然后呢我们如果要去真的把这个对应的应用部署到我们的边端的时候我们需要通过我们镜像服务触发我们的边缘云的容器管理服务这个边缘容器管理服务呢它会去控制我们在中中间区域的这一块呢是我们在公寓云上面的一个DMT区域搭建的四个区域我们目前的就是四个区域全国四个区域其实足够了我们四个区域只是作为作为异地那个多活来使用的其实真要是狠一点我也可以一个提琴搞定一个提琴搞定也是可以的只是我们为了从架构层面来讲稳定层面来讲多个区域然后呢只要把这个对应的那个对应的那个镜像通过我们总部我们那边还有一条线路就是到时候会有总部的那个镜像会把那个推到我们的公网仓库我们在公寓云上面会有对应的公网仓库把镜像推过来之后我们就可以通过我们的边缘云容器服务控制对应的那个云端的Master去下发一些部署指令那下面呢就完整的就是我们的那个CAP-AGE的一个架构的一个使用了在编刀费部署对应的那个Edge Core好我再讲一下我们在这个落地过程中我们在针对CAP-AGE做了一些优化或者说做了一些改进对的首先这个是日式的规范发出出那这个呢我们是原生的那个CAP-AGE的它是不支持这种它是用了系统的CAP-AGE Local这种方式来做日式切割我们就在这个层面上就做了一个控制就把这个日式全决管了支持日式的自动带小风格怎么滚动三处这些这个问题的改进这个玩意初中呢是因为我们边端的机器它的资源特别受限我们有的机器甚至只有总共只有8G的硬盘然后还有安装系统留给我们这个边端存储日式的可能只有500道所以这个日式空间极其紧张所以我们在这个上面要针对不同的场地的节点去配置不同的配置这样的话可以比较精整的控制日式的滚动输出的一个使用再有一个就是这个连接管理刚才这个连接管理是针对一个改进原生的那个CAP-AGE的话它这边的那个冰棒的心跳检测它其实只有一单测只有一个并只有一个并没有棒我这边就做了一个冰棒的一个银装和边端铜布都做了那这样的话就可以保证我这个连接尽量的一个稳定就做一些异常链检测死链检测还有边端的一个触发边端的一个铜连之类的这层的管理的话也就是在银端这边做一些处理我们银端的话因为我们银端最初的那个设想就是一个局群管理全国目前是几千个这个场地这样的一个节点连上来所以它这个内存要求有比较高所以我们在这个层面做了一些针对性的优化就是针对摄像的一个管理然后做一些内存的回收控制在这一块核心点就是针对真正的稳定就是消息处理这一块我们针对这个消息银端消息的数据一致性这一块我们做了很多的一些处理第一块就是按需分发按需分发这个东西根源是因为原生那一块的话它是把所有的这个命名空间下的对应的那个节点的数据它会发给每一个这个区域下的每一个节点但事实上由于我们边端应用特别多然后呢节点又特别多字眼又特别多所以呢我们不能那么干这么干的话会直接把我们要捅布的数据会无形中扩大了很多倍而且会形成这样的一个这样一个层面的一个网络风暴我们来说影响很大所以呢我们做了一个优化就按需分发那就是说一个场地对应一个命名空间我们每一个场地只捅布自己的命名空间的数据这样的话就能减少网络通讯提高这个HCore的助理速度降低这个Edmatch的那个转发效率因为Edmatch它的核心原理是AppTable的一个转发模式它就会有这样一个情况当你那个Service特别多的时候转发就会有影响因为AppTable它本身是个文件所以它太多的话会影响效率其实就是离线这一块离线的话就是说针对有一些云端不一定网络出现问题的时候节点消息丢失节点下次上线的时候可以从我们云端拿到一些离线的消息可以重新再发一次减少这种因为发送失败导致的一些不一致的情况这就是并发处理并发处理的话这种的就是说我们不各个模块他们在处理的时候目前的话因为场景限制他们延伸的设计是单携程在处理它的数据所以它的处理性能并不是特别高或者说不是直视的优化所以我这一块做了一个优化那就是并发处理这样的话能加快边端和云端的处理速度最后一个就是我们的最后一个分离这一块的话刚才也讲到了就是我们边端Io特别差尤其是机器负担极高的时候低逼读写莫论是文件锁因为它现在的解法是莫论是一个文件锁没有做任何的读写分离这样就会导致不管是读也好写也好都得去等那个锁就会特别慢而且会因为读写失败读写失败这样就导致这个消息传递处理会失败这样的话就这样的问题数据的一致性也就容易出现了这样的话读写分离就能够解决有效的解决这个数据不一致性的问题好下一个就是这一块的话应该是原生K8也有这样一个问题就是我们POD在删除的时候它的流程特别笼长它是先把POD它的状态设定为tamblin的对吧然后再去通知边端或者通知我们的tamblin的进程去把对应的POD删除同时再去上报给到云端给到我们的matter的端然后由matter的把EDCD的数据库里面的数据给清理掉这样子会导致有可能会出现它在删除的过程中会卡住会卡到tamblin的状态这种情况下其实对我们来讲很不友好因为我们的节点特别多用户不乐意在那里等待这个前部部署成功对于我们来说用户想得到的效果是什么命令先下发下去慢慢执行它都能接受这是很常见的一种常见所以呢我们就在这个上面做了一些优化主要就针对就是说最终也是异常删除POD的简单来讲就是我下发一个指令边端接收到之后立马想应一个OK我接收到了云端立马把EDCD数据库删除然后边端再执行我们的安全删除安全删除完了之后这个时候我们的那个在那个扣的扣的那端还会有一个ObjectedSync这样一个东西去对应对应的资源是否存在这个东西我们就会去通知云端删除对应的就是一个资源对应的ObjectedSync这样一个东西最后呢我们会结合Sync定时检测一场机制进行一个补堂删除但是这里其实也会有一个异端我这么改其实就把K8原生的流程全部给它打断了对吧但这样有个异端如果我POD用到了对应的物理端口这个时候就会触发这样对应的重新调度对吧但是绝大部分的场景它是不会用到物理端口的因为我们对外访问都是可以通过其他手段来解决所以这种情况下我们是通过一个棋舍就打用最终移植性加上一场直接去删除好再讲一讲我们在K8竞争了一些特性这个是在社区还没有的一些特性因为我们的版本描述比较早应该是1.11的时候就开始接现在是1.13了然后我们是会把银端的一些把边端对应的一些POD相关的一些事件上报原生的社区的1.11版本是没有这些东西的然后我们这块是做了一些事件的记录器然后会上报会有相关的事件全部上报我们在这里做了一个接管最后就是一个Magic Software一个访问的一个优化这一块的话第一块就是我们的同彻底转发这个就是因为我们将同的场地它会存在很多的节点同节点转发的话我能解决我在我们的流量很大的时候我可以通过对应的同节点转发减少网络IO的一个影响其实非同节点离线访问的一个社会的补偿访问主要是说这个是跟原生开发有关原生开发它挂掉了之后某个节点离线它就会立马触发重新调度就会导致对应的节点的POD就不可以被访问了但是这个时候由于我们的落网环境KBAD这种情况下它的节点不一定真的不可以访问所以呢我会做一个补偿访问也就是说当我所有的节点都离线了我会拿出其中一个节点去访问尝试一下但是如果在这一段过程中我的antipod信息里面有还有一个是可以被访问的我就优先用这个在线的节点去访问否则就用离线的节点去访问这是做了一个补偿访问最后就是一个改进优化改进优化的话这个是在iPadTable规则刚刚说的iPadTable规则这一块它这个是塌陆的模式我们这个在旧规则之前是这样的方式出现一个问题然后我们就进入一个塌陆的优化这就是PAD信息共享这个就是把算法计生成PAD信息这样的话在P2P转发的时候就不用通过这个类的信息做一些共享分发通过云端这样的话云端分发的话这会减少一个消耗提高这个系统的稳定性和稳定性最后一个就是我们的Message插件刚才讲到了我们有这个插件的需求需要在不同的场地同一个域名解析到不同的iPad我们就比较简单直接在这个先加一个专用的confirmable直接存储域名和IP这种就可以直接解决我们Message插件的解析问题这个就是我简单讲一下这个是我们镜像的一个转发的安全分发的问题这个是我们原来我们的镜像是分为三级倉库从总部红色的总部到我们的公有营倉库这边见到广州我们广州这边因为安全这边限制比较严格所以我们在这个过程中我们原来最突的方案是所有的都是通过广州区域然后呢通过银间专线就是黑色的图示互联网机器通过这种方式走这个到贵阳商上海北京这四个区域去推但是由于原来是一个银间专线它的那个带宽比较小只有四兆而且特别贵因为它是专线所以就很贵所以我们就改造了就把它改造成我们就改成了用那种互联网的模式互联网模式直接推过来但是由于这种情况下我们这边就做了一些限制因为互联网的数据要被访问我们就单独开发了一个多个的一个探件这个呢是做这个证书论证的证书论证这个证书论证的主要是防止一些非圣风的节点揭露到这个集群里面来拉起我们的一些隐私镜像最后就是我们因为节点很多我们有很多节点只要在部署但事实上用户不希望我们在每个节点每个场地都单独部署所以我们会有一个付出部署的功能我们首先用户在页面上提交他要把哪个对应的部署单元部署到哪些机器或者部署到哪些场地我们就可以去解析这个部署单元依赖的配置项到目标区域对吧最后呢我们就要去匹配对应的网汤库的育民去创建对应的Department最后解析对应的Service在目标创建Service这样的好处就是用户只需要在我页面批量点击一下复制就可以快速的把对应的应用部署到全国乃至全球最后讲一下我们在这个东西上完了之后我们顺风这边得到了一些什么收益吧我们原来的话是手工部署我们在这一块的话就做了一个运营环境的统一然后可以在我们的统一控制面做集中化还有可涉化的一个发布支持多种特别的发布我们也支持这个模板的线上维护包括用户可以做一些工网汤库的一些切换使用因为我们工网汤库也是异地多活的每个汤库上的镜像是一模一样的包括我们也可以执行分组的方式去部署都可以看到进度看到状态最后就是我们贷宽费用这一块贷宽费用这一块是下降得很厉害原来我们是要求在一个汤里可能要揭露一些贷工工网IP的一些贷宽然后呢在这个过程中我们就不需要了只要能够反而为我们云端的就OK了最后就是应用快速分发我们可以做到在一个小时甚至半个小时之内就可以把应用分发到全球最后就是我们异团异团治愈了这个是Cabbage本身的但是呢它能够给我们带来的好处就是用户不需要24小时带命不然我们认为不需要24小时带命去签清有一场叫轮工去启动它最后呢就是在商业上面最终的应用我们主要是和我们公司的IOID这块做了一些结合所以呢他们可以帮助他们做一些业务快速扩张其次呢还有一个是商业试点的问题因为我们不同的场地它可能会有不同的一些业务规则的一些玩法所以这个时候在我们的一个场地部署不同的应用它是可以去完成对面的商业的一个试点其实呢我们顺风也可以通过这种渠道走向商业市场好 讲一讲时间也到了就讲一讲我的一个看法就是边云这个东西他给我们顺风带来的最或者说给给整个世界带来的一个核心的东西吧他提供了我们智能化的一个水平G1浓气微服物架构我们云端是很简单但是边端其实是相当于一个迷你服务器所以我们边端已经不区分它是数据中心还是说边端了所以它的营业商这种系统下它这种微服物架构它也能够扩展下去也能够完整地扩展到我们的边端提升了系统的扩展是很稳定性最后有一个就是数据边缘处理我们边端的数据非常庞大每天都在T级了这样的话在边端处理完了之后就不需要再上报给我们全部上报个云端只有把结果上报个云端就OK了这样的话也能减少我们处理的速度好谢谢大家