大家好 大家下午好那个 其实刚刚我们也在这边有一个援助讨论这次又是我来分享这个让我们重新思考一下辅网格的这个负载均衡然后这个演讲呢我希望反正就是尽量的简单通俗让大家都能听懂 都能理解好的然后我先开始一下然后我还是先介绍一下吧然后大家避免大家不认识我我是来自于华为云的许中虎然后那个我现在在开演社区工作然后同时East Joe的这个开员呢大概也有五六年的时间了吧应该是然后现在是East Joe治理委员会的这个member还有也是East Joe网络组啊还有安全组的这个Metana那之前我在这个Volcano还有Creator这个项目中也是担任这个Metana的一个角色对那最开始的话我们开员的团队主要是在cover在这个Koenetics这个社区本人也成为这个Koenetics的这个top100的这个贡献者然后今年呢这个Google还授予了我这个Open Source PI Bonus的这个奖励也是很荣幸然后本人也参与了这两本书的这个编写而这下面是我的这个Gatehouse ID然后呢如果大家如果这些通过这两天的这个分享对我们East Joe感兴趣的话可以去下面我们开员展区F3有个East Joe展台然后的话我们有开员社区的这个Metana也在现场解答大家的问题就在F3啊OK我们先来看一下这个富旺阁这边的这个商业化使用的这个增长这个数据来源于SyncCypher 2022年的这个调查报告我们看到从2020年的这个SurfaceMesh的这个商业采用率是从27%提高到2021年的36%然后以及再到2022年的这个47%当然今年在2023年的这个调查报告还没还没开始公布然后另外一个这个调查报告是显示的是这样的就是这个这个的调查报告跟这个还不一样这个是专门针对SurfaceMesh的这个微的微调查报告然后这个结果显示呢我们在这个调查人群中有60%的人是在生产环境中去采用了这个富旺阁然后另外19%的人呢他是正在评估我们是否应该采用富旺阁然后另外10%是说我们正在开发环境中去已经测试这个东西然后另外19%是实际上是没有说没有采用一丝络的打算的这个报告呢其实面向的那个就是采样人群其实是更精准的就是更多的是这个微服务相关的人员OK然后我们还有一个调查报告通过调查报告里面去显示啊就是在所有的这个由于富旺阁相关的这个特性中大家对关心哪些能力也就是说我Adopt这个Salesmax之前我会优先考虑哪些能力然后79%的人呢就是当然这是一个多选项啊79%的人呢比较在意这个安全例如这个MTS就是联系人的这一套东西这是79%的人比较关注这个特性然后其中另外就是这个群体中有78%的人群它是比较关注可观察性的比如说去关注一些这个业务的这个监控指标然后因为这个反正我们EastQ尤其是EastQ这边它这个可观察性方面还是比较比较强大的包括Metrex啊日治啊还有那个可以看我们的我们的服务的调用脱谱然后其中62%的人呢去比较关心这个traffic management例如去做一些汇动发布啊去做蓝绿发布啊等等这个是62%的然后其中有56%的人比较关心这个可靠性比如说我其实就是这个我服务之间调用的这个健壮性OK然后再讲一下这个这里看一下我们这个呃调研中哪些是影响这个我Adopter一个特别是麦识方案中呃最关键的非技术的一个挑战然后从这个结果中可以看到就是70%的人群47%的人群啊就是会回答的是我们缺乏这个工程性的知识和经验对呃就是因为这是非技术的嘛就是平台性的工程性的这个经验缺乏是吧然后其中41%的人呢去去回答的这个结果是就是说现在SofsMesh这边的这个呃架构啊还有技术啊它是比较复杂的它可能扣不住然后36%的人啊说这个采用服务格的时候我们缺乏一些这个指导啊还有一些呃指导最佳实践的一些东西就比如我想用一个功能我不知道怎么用我也不知道去哪查可能会有这种感觉啊然后22%的人呢就会觉得就是我呃比较难以选择是选择East2啊选择LinkD啊还是选择CLM啊等等对吧然后另外的小手群体就是说可能是另外其他的东西的OK再来看一下这个技术方面的这个最大的一些挑战是什么技术层面啊呃首先32%的人最大的群体认为这个是呃与其他的工具啊还有服务的这个集成呃是他们面临的比较大的挑战呃62%26%的人呢认为他这个呃还是这个本身SavageMesh这个技术这个框架他是否可靠啊他是否就是就是在版本眼镜中能够保持一致就是前后API能不能能不能保持兼容这是他的一个对待挑战然后25%的人呢就是不是这上面的这些呃这个选择这个这个其实没有什么意义啊然后22%的人呢觉得我去定义我的呃配置啊定义我的这个策略啊比较难呃这个是22%的人觉得呃其实我们也可以理解啊就现在的East2的API呃还是说呃还有那个Gateway的API实际上我们可以看到就是关于流量拆分去复杂均衡去Spirit然后做权重的拆分的时候这个这个从这个层面来讲哎我们都是很直接的都很简单是吧都很容易配置但是如果我们想用更丰富的功能然后发现很难配置然后另外就是说我们的配置容易跟其他人的配置其他team其他服务呃其他服务的配置进行冲突啊这个是配置比较难的根本原因然后百分之二十二的人呢会认为这个监控和Tracing是比较难的因为这个这个难呢主要是在于我的那个其他的平台的缺失啊可能就我没有监控平台然后百分之二十一的人呢会是说这个策略管理策略管理就是说我们怎么要去呃在前后保持兼容怎么去避免相互影响这个是比较难的然后另外百分之二十的人会比较在意这个福旺格的这个性能就在我们调用的实验上面这个展现的然后百分之七的话就是奥斯认证健全呃回到我们这个主题啊我们福旺格这边的这个附带均衡附带均衡那其实是比较简单大家其实都很了解它是一种呃技术是用来就是去分发这个我进出的进出呃最开始其实主要是用来做那个进出这个南北向的网南北向的这个流量去用用户设备啊或者是pc啊这个移动啊移动abp啊这边发出的流量啊到达我们的数据中心我们等下去分发对吧然后这个比较比较famous的一些罗罗Balance的这个帕尔斯也就包括Invoi啊Endings啊HRproxy啊都能基本上都能做这个现在的这个呃七层的这个附带均衡就是呃去选一个最佳实力把流量分发过来那这个时候呢其实主要是呃这个附带均衡主要是做那个反扬代理的这个这个这个作用对吧然后其实在使用场景上面来讲我们也是有时候也是很复杂的啊就是呃在一些我们会有一些Global的一个服务全局的一个服务的话会部署在什么两地三中心啊多多机房的这种部署是很常见的啊这个时候附带均衡的这个脱补就更复杂了这是最简单的一种模型就是选一个Endpoint然后倒倒流量对吧然后这个采用附带均衡的这个想法也是很简单的它目的是会是啥呢目的就是第一个就是提升这个我们想用的这个速度对吧呃想用其实想用的速度说的就是说我究竟的把这个流量就导到究竟的这个服务实力他们来然后呃第二个就是增加这个这个reliable的可靠性增加可靠确实是有一些负载进行都有些这个呃重视啊呃超时啊就是这种这种这个简单的这些功能是都有的这些包括Endings啊AzureBoss啊都有是吧然后第三个就是可以用来做它呃为了更高的那个高可用呃扩展支持就是水平扩展这些服务去支持更大的规模然后这个是我们做负载进行的一个主要目的吧ok然后我们再简单的看一下EastQ这边支持的目前支持的一些负载进行的一些算法啊这个呃其实大家也都听说过这些算法基本的是这样的ListreRequest然后这个是当前EastQ中这个默认的这个调动算法就是流量调动算法也是负载进行算法啊就是RR原来原来叫什么原来最默认的那个呃负载进行算法是那个RRRounder Robin就这个这个是他原来那个默认的那后来呃从从哪个版本开始有点忘记了就是改成了这个ListreRequest这个就选择一个当前的这个他认为从客户端的角度看到的是呃这个当前呃请求处理数最少的这个呃实力把这个流量导到那边去这样然后第二种算法是随机随机算法就是随机选一个这个Endpoint这个也是其他的比较常见的一些算法呃刚说了这个Rounder Robin还有一种就是带权重的Rounder RobinVT的Rounder Robin啊这个是原来是默认的啊然后第四种的话可能稍微就高级一点的它是一种伊致因哈希的一个算法伊致因哈希呢就是目前有两种一种是呃环形哈希另外一种就是那个MegalabMegalab这个是主要是在做那个呃Redis的那个呃负责均衡的时候会选用这种Megalab的这个算法呃可能好多人用不到下面的这些东西啊下面的这个更高级的这个East Joe现在现在支持的一些算法呢就是主要是我列了几个第一个是那个Locality'sAware的这个Rounder Balancing这个是什么意思呢就是说我的流量会呃优先发送到跟我的客户端在同一个Region同一个AZ然后同一个撒不动的这个呃 Endpoint 中这个是他优先去把这些流量发送到这边去然后呢当我这个同一个Region 同一个同一个也就是同一个最小的那个物理物理单元中这些Endpoint如果是故障了这个流量能够自动的去做那个Fillover到其他的Region其他的AZ其他的Region这个优先其实是递减的呃这个因为没有一个图大家就理解一下就好了然后第二个的话就是那个基于优先级的这个负载均衡这个优先级呢其实也是会把那个Endpoint分成呃1到N那么几个组然后每一个组是有不同优先级的比如说他会优先把流量导到呃导到这个最高优先级的这一组Endpoint中当然这个导到过程中这个在这一组Endpoint中去怎么去选这些Endpoint的选一个具体的其实还是由上面的这个算法来决定的我可以就是说默认默认现在就是List Request然后当我这个最高优先级这一组Endpoint然后有挂掉有故障的时候他就会自动地把流量然后Fallback到另外一个更低优先级的这个组里面这个就是他的这个Prioritized的Lullabensing怎么样去表示我们一个优先级的这个概念呢就是在我们这个API里面实际上是有那个呃我不知道大家清楚那个Destination Rule里面有个Track Policy里面其实是有一个Failover Priority的它里面可以去指定这些呃标签就通过那个标签的去匹配标签跟呃客户端的标签匹配的程度然后去去分他的这个划分他的这个优先级组这么干的呃当然其实这个这个其实是一个比较比较新的一个东西了他相对于原来这个只支持Rigin、Azure这种Failover它是一个更先进的更高级的呃另外还有一些什么呢另外一些就有那个呃对指定的Rigin、Azure进行这个流量的这个裁分这个也是最早比较早的支持跟Locality、Azure是一块支持的然后呃最最新的其实就是这个Slow Start就是呃能启动的这个过程中尤其是加把的程序他启动的时候他那个呃这个加把的这个服务是不能够达到他最有效的处理这些请求的这个新其实达不到他对对颠峰的这个性能的所以说就在这个过程中我们有一个Slow Start的一个时间让这段时间他那个流量进来的时候是按照这个线性增长的他不是说一下就把所有的流量给导到这里来导到这个Slow Start的过程中的这个NPU上面这个就是呃现在Slow Start这边做的一个事情啊刚才讲到的这个我们这个高级的这个算法实际上是跟这个Basic的这个算法是一起工作的对吧这个是这个是我想在这边给大家说明白的意思事情啊ok然后再看一下我们这个E9中现在支持的一些routine的也非常吧就是只讲只讲这个负载均衬的话大家可能还是比较偏这个偏向算法一点ok呃然后我们现在这个E9结合这个负载均衬结合路由啊他能做啥吗做什么呢就是可以做到应用感知对吧然后第二个是动态路由然后去呃以及支持这个呃各种协议吧支持各种应用的协议比如说大家都知道对其实对HDDP类的这个协议啊ADB1HDDP2HDDPJRPCADPS呀其实他是支持的是最好的这个是然后呢对Reddix呀达爆这种协议的话大家如果使用的话可能要通过这个Involve Filter这种Patch的方式然后去使用对吧呃这个下面这两个图呢就是说我们现在其实最最关心的一些呃中国这边其实很多用户啊我接触的都是很关心这个呃Blue Green蓝绿的部署对吧会把这个流量权重呃由这个比如说他开始的时候这个绿色的代表一个服务的一个版本然后开始的话这个流量是百分之百导到这个呃这个版本上面来然后后面我又在升级的过程中我会有一个新的版本然后再把流量一次性全部切在这里来这是一个蓝绿的一个部署的过程然后呃更平滑的一种方式呢就是这个灰度的灰度的我们也叫那个金丝雀的这个发布它是一种流量慢慢切的过程就是呃流量开始的时候可能百分之百是在V1版本然后后面变成百分之八十到V1然后百分之二十到V2这是一种这个金丝雀的发布的一个过程然后很多很多用户比较接受这种方式啊ok然后我们这个其实就是这种方式的话就会更面向我们在路由过程中就会呃对用户呃对用户的应用是更加的这个友好的就不只是从这个附在均衡的这个角度上来讲对ok然后再看一下我们这个如果是要做一次那个candler release需要怎么配置啊呃结果我也讲了如果单纯的意思就是使用某一个某一个小功能的话其实配置都是比较简单的你看就这么一个即行的压构就可以做一个灰度的发布对然后呢但是它我前面也讲了就是如果说跟其他的这个配置去同时去使用啊可能会因为使用不当会造成一些冲突这个时候就我们在定位的时候有时候就比较麻烦会查日式啊包括是查那个呃查那个查DF配置啊都可能会通过那些图进去查然后最后就定位更衣ok然后我在这边会列了一个这个蓝绿发布的一个模型啊就是说呃你看我这边会声明当我的这个请求hider匹配到是json的时候那我的把这些流量露由到v2的这个版本然后其他的这个没有匹配到这个呃投射json的这个这个请求的时候就会把这些流量然后露由到这个reviews这个v1这个版本啊这个是呃我的蓝绿发布的一个部署的一个配置其实也是很简单就单独看都是很简单的对吧ok然后我再想问一下大家对其实对当前这个e2这边这个负载均衡的这个算法其实是能够满足你们的使用场景吗可以回答一下满足的举手不满足的举手其实我看到其实满足的多啊大家还是还是跟我的想法其实一样的其实大部分场景其实大部分比较典型的场景实际上都是够的这些这些算法因为这些这些算法也是从几十年来从不同的这个负载均衡的这个软件中去继承过来的嘛也不是说它独创的都是一些几十年就有的对吧然后呢其实在一些特殊场景其实是也是不够的其实当然这些场景可能就比较特别一点了呃第一个就是说什么呢就是说我们当我们一个机器因为举个例子就是在K8S机群中我们每一个机器的性能其实不一样的虽然说大家有可能就是部署的时候都是呃同一个walkload的去资源分配的时候就可能给它分配四核啊4U啊8G啊对吧但是它的CPU那个它的核心不一样有的是主频是两G的有的是三G的对吧有的是当然是不同的硬件啊都可能所以说它这个单纯的从这个K8S角度来讲它不能够区分这个它的这个服务器的这个这个这个快慢没办法所以说呃我们的在每一个每一个在这个每一个节点上去部署的这个呃炮的也就是在服务中我们称为Endpoint它这个每一个它处理性能其实不一样的嘛对吧每个处理性能是不一样的然后呃在一些比较差的机器上的那个差的机器上部署的这些服务那可能它处理的这个请求的这个速度肯定也是慢的这个是一个场景啊另外一个第二个就是呃呃List Request的这个算法它本身也有些缺陷我们来看一下典型的这个呃在East用这个东西项的这个请求的时候会发现我们的这个负载军行实际上是跟那个Client放在一块去做的就在Client端去做的然后每一个这个Client这边会选一个他认为请求最少的这个server去发送那这个数据哪来呢这个数据就是Client这边自己去维护的那个连接时啊以及暗报案里边他自己去记录的一些那个数据本身他自己这边角度看到了对吧假如说我有不同的Client同时会看到我像比如说像这一个server去呃发送的这个请求比较少那我大家同时都往这边去比如说都去往这个server上同一个server上去发送一些请求那我们就会出现这个呃精神效应对吧因为因为每个每个人每个这个envoy都是从自己的角度去发现这个呃服务端的这个request数目的那这样看起来就会出现这种精神效应对吧然后另外一点就是没有考虑到我们这个服务器的这个容量对吧有容易这个在这种情况下也会容易把这个呃某一个服务实力给它压垮呃另外就是说我们在这个listre request之中啊就是没有考虑到我们每一个request之间的区别也就是说呃有的request有可能是嗯其实有可能每一个request有可能还是常连接呢对吧这个是我在envoy这边是没有办法区分的现在是没有办法区分的至少然后它的包括它的请求的size啊呃请求的这个类型啊请求的这个诱言级啊呃请求的我们需要请求的这个呃它的latency啊其实是不一样的对于每个请求它其实没有没有细分的所以这种场景的话它会产生一些不好的效果呃第三个就是虽然e-sql现在是支持那种waited sub-set的cluster就是会对下面这个每一个就是其实简单一点来说就是我现在virtual service的支持把流量切分到不同的那个sub-set中sub-set的组对吧这种这种场景但是呢它不支持这个sub-set的这个forback呃其实从前几年就有人在社区提一岁网就要支持这个sub-set的这个forback就是其实对点心的场景也是这个呃不同版本同时存在的时候呃用户想比如说有N个服务是调用链的调用的关系比如说服务1服务2服务3是相互调用的那我想的是服务1的v1版本调用服务2的v2版本调用服务3的v3版本这是很自然的事情对吧那假如说我当时当前这个服务2的这个v1版本是不存在的或者挂掉的那我其实是想这样的就是服务1的这个v1版本是调用服务2的v2版本再说来报告他v2版本然后服务2的v2版本呢其实会看到我其实因为前面的这个流量其实是v1版本从服务1这边来的那还是要走到这边那个想到服务3的那个v1版本这是一种用sub-set的这个forbac的这个机制其实是可以解决的但是其实现在也没有做OK那我们其实从刚刚也分析到他现在的支持的一些现状还有一些我们当前其实对于一些场景方面其实支持的不好或者有天生缺陷的一些一些方向的时候我们去思考一下其实这个也是借鉴了其实之前读到了一个Netflix这边他去做这个负载均衡的时候他们也内部去考虑的一些事情吧然后是这样的我们去做负载均衡我认为这边的这个指导原子呢首先就是我们要学习其他的包括论文啊包括其他开员项目中一些优秀的算法实践对吧然后在前人的基础上站在前人的肩膀上面然后就是针对于List Request的这种场景我们可以说是通过Choice of Twoand Probation Algorithm这种算法去解决掉List Request带来的精确的效应Choice of Two是什么意思呢其实这个算法也是比较简单啊其实就是随机的选两个这么意思就是随机的选两个N-PoNt然后从中选一个最小的最小请求的实力然后把这个请求发送到这个实力上面去这样会避免精确效应Probation算法呢其实是考虑到服务端的上线的不同的差异情况这样其实我们第二个原则是保证就是说在任何的情况下我们不会说只要我们服务端服务实力数够的情况下能够处理所有的扣端的流量负载我们要保证每一个任何一个服务实力不会因为突发的负载把我们压垮这个是我们基本原则然后第三当然这个原则前提就是说我们要实现负载是均衡的我们负载是均衡的要求不能说某一个流量就像list requests发生流量的很大的倾斜这是杜绝的然后第三个是去处理请求的时候会又先考虑这个最小的实验就做负载均衡的时候去考虑到会把这个实验作为一个因素还有一些它的每一个request的handling的时间然后也会去考虑network的latency以及服务端的处理时间当然这个是一个指导原则但实际上可能像比如说网络实验或者是尤其是服务端的处理的性能的话如果说我们再去外接一个其他的第三方的监控的软件或者监控的平台的话就自然会对我们负载均衡这边的效率会产生影响当然这个都是我们生产过程中要考虑的OK第四点就是说我们要避免扣端这边去进行复杂的配置和人工的去调整参数去调整这个配置的过程OK然后我们觉得从这些方向考虑我们觉得有哪些方法可以去做一些进一步的去解决一些当前的问题第一个就是说去做自适应的复杂均衡的一个调整要把客户端视角的请求的严实跟server的复杂作为一个复杂均衡的算法的输入去共同的去选择一个合适的判断这个是自适应的这是一种可能的方向然后第二个就是把join的sortice to kill这个算法和choice of two去结合然后去选择一个最佳的服务实力然后这样会避免精逊效应然后第三个就是properation机制减少这个飞裂和提高可靠性韧性对提高我们的韧性这是我们大概可能未来可以用到的方向然后再看一下我们其实这个东西其实是暗暴市区最早提出的就是去上报服务端的资源利用率的一些proposal当然大家可以看到这个proposal很久了大概是2019年Google的人他去提出了这个方案就是说我当前这个负载军行的时候没有考虑到服务端的Utilization我们应该设计这么一种方式就是他这个方式叫ORCAOpen Request Cost Aggregation就把服务端的开销去聚合上报也好或者直接返回给这个DPLB就是Data Plan LB其实映射到服务架中这边就是变成了四暗暴是可以把这个OCRA直接发给这个客户端的这个Envoy还是说有一个中心式的这么一个组件也可以对 它只是定义了这么一种ORCA的一个协议当然这个ORCA的这个协议这个标准大家可以有那个兴趣的话可以参考一下其实像就是这个server端会主动报它的这个Request Service Bounce的这个时间啊 资源消耗啊CPU啊内存啊这是最基本的这些会在这个API里面去报给它它这边去决定是怎么样去使用它不规定你客户端的实现方式它只是一个说我server端的utilization的一个上报的过程你server端去怎么样去利用是你自己可以实现自己的算法OK然后我们总结一下今天这个演讲的内容我们意思就现在是其实是完全是在数据面是Base On这个Envoid但是呢是扩展了很多高级的这个能力尤其是在KBiS这个环境中OK像我们这个优先级负载均衡中的这个metadata这个这个是我们很重要的基于KBiS做的KBiS泡的一个标准做的对 然后第二个是Loriband Things是现在其实还不算是意思就是这个性能评价当然这个性能评价主要是在results and operation的这个复杂性上面这个ocre这个proportor还没有实现但是呢在意思之中我们可以去推动这个Envoid中去实现这个东西OK然后第四个就是说我们现在是利用了这个现有的算法去实现这个更高阶的这个能力比如说我们未来需要去做到针对Headless的这种service去做一些Persistent Session以及做Supposite Fallback这个可能是我们面临的一个比较大的困难现在向Headless这个汇发保持还有Supposite Fallback其实我觉得可能是未来我们要重点去解决的事情ocre的话这个可能相对于依赖比较多一点这个可以独立去解决应该就是这个就是我今天演讲的内容了然后这个是我的个人微信大家有兴趣的话可以加我一下然后我的slack上面slack上面也可以找到我一次就slack上面OK感谢大家