大家好,我是庄庄盟,来自华云今天由我和人生士兵的架架师徐世宇带来服务任性的分享结合生产中的一个实践力我们将介绍网格等原生机架设施替换SpringCard的Hastrix提升服务任性的一些实践细节我是华云英讽格的架架师主要做容器、网格等原生技术的开发和设计工作世宇是人士兵的架架师主要在做人士兵的货端架构和原生的一路的工作我们这次分享主要包含三部分属于人士业任性的简介、简单介绍然后世宇会介绍人士兵的应用和技术架构和Hastrix的一些实践性后面我会来介绍通过网格等原生手段来提升服务任性的一些实践细节首先这些话相比大家都应该看过所有事情、所有事物任何时间都有可能故障AWS等于沃纳关于故障或失败这样一个经典的一个描述在我们那个系统架构设计特别是考协设计中间被广泛的适应因为所有人都有这样一些经验的教宪故障不是是否能碰到的问题而是你什么时候碰到的问题也不管前期我们做了多大的话、多大代价才得无理加固我们的系统去预防故障但是最终预防是一方面我们会发现接受是另外一方面我们需要做好在故障的时候我们怎么处理这个故障、应对这个故障保证不影响我们的用户的也最终实用最大的程度上对我们业务减少故障、对我们业务的影响这也正是任性研究的一个课题任性表达了这样一种能力就是说我们系统在故障的时候失败的时候或它过载或甚至说它受到攻击的时候还能向外提供基础的一些能力任性告诉我们虽然我们不想要失败或故障但是我们必须在系统加固设计的时候做好故障处理的一些准备故障处理的这样一些准备也就是说在故障的时候尽量减少故障对我们系统的影响尽量减少影响面尽量减少对我们核心业务的影响尽量减少对我们最终用户的实用的影响有一个说法就是故障任性虽然它不能保不能保证你挣到多少钱但它至少可以保证你少赔钱也就是像我们现在我们做各种的靠竞争竞争力它能提高我们系统的一个看上去的一个上限但实际上最终保住我们系统下限的还是一个让我们系统本身的一个任性整个公众在我们身边的各种工程或者系统世界里面其实任性是任性或者任性的理论都是获得了非常大的研究在基本仪世界里面这个也是大家非常研究非常多的一个课题在这次实现中间我们将主要聚焦服务的任性因为我们这个客户场景主要是一些微服的一些访问情况其实在这个场景下面特别是服务规模比较大数量比较多的时候我们前面讲到的任性的这些问题或者故障的这些问题它体验得更有明显比如说这是Histrix它的官网上早期关于任性的一个像一个模型策算图版就讲到说比如我有一个系统它里边有三设微服虽然每一个微服我能保障99.99%的一个叫一个正常工的市场但事实上如果三设服中间有依赖的话它最终整个系统来看它的一个正常工的市场只能在99.7%也就是说一个月里面它会两个小时以上的时间是系统是工作这对我们大部分的用户场景是基本上是不能接受的对于这个微服场景考察到服务它的一个分布式然后有网络的情况然后把我系统辞生这些情况实际上这问题会变得越来越复杂所以也就是我们只要做一些任性的事情它的一个标准就在正常的变得尤其尤其重要下面有事与来介绍一下人士兵它的一个用下构和怎么用Histrix来提高说的一个任性大家好我是徐世宇是人人视频的技术主管剑在过世人人视频是一个在线视频点播的一个APP我们主要做的是每日韩太等海外剧的一些内容我们现在拥有的一个注册用户数大概是2亿多然后日活用户数也就是DAO现在能够达到1000万然后越活用户数就是能够达到5500万我们近在上周五刚好迎来了人人视频的一个七周年的纪念日近七年我们的业务一直是实现向上发展了然后我们再来看一下我们人人视频的一个主要的一个业务架构我们现在的架构主要分成了一个四层然后就是一个第一层是一个网弯层就是Gateway层第二层是一个业务聚合层就是DFO层第三层是一个技术服务层第四层是一个数据存储及中间建议中间建议层我们技术服务层主要分成了一个五个中心第一个中心就是用户中心然后第二个是内容中心第三个是社区中心第四个是市场界线中心第五个是一个数据中心用户中心主要包括一些用户的一些信息啊健全然后内容中心主要包括一个一个视频然后解析然后视频的一些标签社区中心主要包括评论弹幕这一类然后市场中心主要包括一些活动广告一些任务一些支付相关然后数据中心主要包括推荐搜索一些封控这主要是我们的一个业务架构啊也是随着我们的一个业务的发展在早期的时候我们业务量并不是很大也其实业务架构其实也并没有那么啊一个健全吧然后就是啊就比如这这个大家可以看到这个图我们早期是并没有加一些什么容断一些保护的然后这个没有加容断保护就是看一个左边这个图就是一个什么币端的比如那个我们的一个content type然后出现了一个呃线上的一些一些主审它会导致一个上游的伏击bf层的com bf content type也进行一个业务的主审然后竟然导致一个APR网关层APR Gateway这个业务主审然后当APR Gateway进行崩溃的时候会影响到整个业务完全不可使用也就是达到了一个雪崩的一个效应然后当我们使用了一个hx进行容断保护之后就是比如呃大家看这个右边这个图就是加了一个hx然后在bf content这边加hx其实其实每个其他的业务都加了一个hx的一个现成的保护一个服务的保护呃当加了这个服务的保护之后我们看这个content type如果出现了问题它会在bf层这个bf content会迅速的对这个content type进行一个容断降级然后从而导致保保证上有的服务以及其他的一些服务能够进正常的平稳的运行呃首先我们再我们再看一下我们这个hx到底是现场怎么用的这个主要是列举一下我们现在的一个现场的一个真实的一个page呃就是在我们这个updata这个优热的时候我们设置了一个hx给这个保护主要设置它的一个核现的现成数是20然后最大的一个maximum size设置为40然后一个最大的对面数设置了1000然后一个主宰的一个主宰对立的一个门槛设置成了800就是当当业务业务请求业务请求过来的时候首先如果现成数它没有达到一个20的时候会新建一个现成最终达到一个核心现成数然后当核心超过核心现成数之后然后会放到一个对面里面去也就是我们这个最大的对面的数1000然后将这个当这个还超过这个1000的时候我们就会再新建现成最终达到一个最大的一个maximum size就核心这个最大的现成数再超过这个最大的现成数就直接拒绝掉了然后我们这个其实现上主要这个应用应用农段的时候它是设置了一些农段的一些配置参数的然后就是像这个arrow随之后的percentage这个50就是表示这个出现了百分之50的一个错误率然后下面一个参数是表示这个我们在这个农段那个时间窗内也不一定要这个请求数能够达到200这个数并且农段的错误达到那个50才会进行农段的触发然后在下面我们设置了一个休眠那个时间窗口这边我们设置的是一个10秒钟就是当农段出发之后我们进行10秒钟会进行一个业务的尝试如果在业务尝试成功之后会进行一个真正的一个假的农段的关闭就是进行正常的业务进行分发请求我们的农段主要采用到一个策略还是一个现成策略的主要除了这个现成策略还可以有那个新花亮的一个策略当我们用这个农段的时候用黑句句进行农段还有哪些弊端呢就是我们现在在真实的业务场景当中我们现在想把那个bf成了一个聚合层想转成一个够的语言那转成够的语言这个黑句句是它进行农段保护就不可以在够语言当中进行农段保护了因为这个黑句句是它是由语言限制的它只能支持加瓦然后还有一个就是用黑句句是它会设计到一个代码侵入我们如果想用黑句句进行农段保护的话必须在代码中有一些相关的驾包做一些配置然后一些一些注解代码的一些注解的一些使用然后还有一个就是现在黑句句它并没有直接的一个现有的一个策略这也导致我们现在的服务如果还要进行现有保护的话是引用了一些其他的一些现有方案的还有一个就是一个黑句句它并没有一些故障注入的一个机制就是在我们这个没有故障注入的就是在测试环境就很难发现发现一些问题然后只有到一些线上才能发现问题当我们用一些故障注入的机制的话就能够在测试环境进行故障制入然后就尽早的发现一些主要这些问题然后避免到把这个问题遗漏到一个线上主要以上就是主要一个黑句句的时候我们用的一些一些用法和那个黑句句的一些弊端然后下面就超萌哥来讲超萌哥来讲一下这个在浮网格中我们怎样进行这些解决这些黑句的一些短板下面由我来介绍浮网格等原生的能力怎么在我们这次实验中间再提高一个更高的一个任性能力首先这是我画了一张图想表达一下就是网格就是我们这次实验中间网格不只是向前面海水提供了像垄断器一样提供了这个应用层那些保护同时他还提供了像在同开发阶段到自助阶段到服务运行的机构设施到服务应用自身保护甚至到后续的OPS阶段它整个全生命系的一个任性的一些加强的能力但底下提供手段是像是浮网格这样一些一些机构设施来提供下面我们来展开看一下到底这些能力我们是分别怎么去做的我们来实验细节当然因为最广泛的还是还是熔断我们用户这边用的最短还是熔断所办的这张图实际上也是我们的一个熔断模型其实数学同意会发现这和黑色其实是一样的网格虽然没有这样一个图但实际上它成了工作原理也是这样实际上刚开始的时候服务说一个熔断不密的状态在一段实验内如果服务失败次所达到我们可以是这个预指它就进入那个熔断开设这个时候就是不能接受流量然后过一段时间之后进入一个熔断办开设的这个时间如果说服务能正常那就它可以正常接受流量了进入熔断不密的状态如果说这个时候它不正常还是不正常那接着进入熔断开设的这个服务还是不能就是还会拒绝现在发布的流量那一般了我是画账表达对比一下Hastry可以使用它的一个熔断这一般能力的差异可以看到比较大的一个差异就是Hastry的熔断是在是在是非侵入在属于面的带领来做但Hastry它是在STK在用过幼蛋版的来做所以Hastry本身来说它能提供一个一些让用过的定义forback的能力但很多这些能力本身是要用过去用过去参与的像我们看一下整个在网格中间就我们这个案例中间它的一个熔断这边一个实践的一个细节首先是服务实力它的熔断服务实力它的故障的一个过程这个图里表述了一下比如说刚开始我们服务都盛成了三个实力都可以均衡的接受流量这个时候有一个实力如果它不正常的话但甚至如果没有任何熔断保护的话上面还是同样均衡的接受流量那到最后就会发现这个服务实力上所有的请求都会是失败的比如说从我服务这个服务的一个回度来看这个服务它有三分之一的几率它是失败的比如说从用户来看比如用户从给多少钱访我这个服务的时候也用过三分之一的几率它会得到一个错误错误得到一个失败的一个请求最明显是不符合客户的预期也是不符合质量要求的如果用了网格边的熔断这个能力比如说它提供了一商店检查的能力我们看一下它怎么做呢它能做到就是在一段时间内会考察一下这个服务的一个方向情况如果它连续的错误次数超过预设的话就把这个实力隔离掉这个实力隔离就能得到流量比如说我们这边这个配置即使客户商店有一个实际配置我们配置在10分钟内如果连续出现5次5.2.5.0.3.5.0.4的一个物账在4分钟的连续出现这些物账就会把它隔离掉10分钟10分钟之后呢就会尝试再给它发流在这个10分钟内它就不健康了不会有流量10分钟之后呢就会尝试再发放流量然后只有时候它正常就可以正常进入流量如果不正常下次会隔离20分钟30分钟 40分钟以至这个服务最终它基本上就得不到流量也就是故障实力就隔离掉我们看一下前面那个故障场景下边如果配置上面的一个配置上面的一个一个规则的话它的一个表现可以看到刚开始的时候这个服务它上面是没有流量是还是故障的然后随着容量测水生效这个实际上它是测水它上面流量会越来越少以至到最后呢这个服务实际上它基本上就没有流量从整个群聚来看实际上我们最终的效果就是这个故障实力是被隔离掉流量只会分发到正常的实力上也就是从用户那边来看它所有的群聚都生长跟所有的流量不会分发到这个故障实力上也就是说达到了意思的容量达到了这样一个故障隔离的一个效果前面我们讲任性的时候其实比较说到出过任性很重要的方面就是从一个故障的状态能自动的一个恢复我们看一下前面容量怎么容断的实力它怎么是自动恢复的可以看到刚开始的时候这个服务上面它是没有流量我们这个服务它如果因为网络或其他原因它正常的话可以看到会网格的数据面会尝试逐步给它上面起来再去发放一些流量如果这个时候正常的话它就会标语成一个健康状态这样原来故障的实力就可以可原来的那个正常实力的一样的去接受流量也就是从整个服务来看拥护的又会有三个实力在相关体能能力比如说从故障中恢复回来这也是让我们任性理论里边的一个重要的一个体现网格的容断除了提问前面我们说对一个实力的一个容断隔离之外开开体验对于服务请求的一个一些容断比如说我们可以配一些预示规则当超过这个预示规则的话服务网格的水面会把这些请求给它断路掉这样的话就这些请求或这些连接就不会发到上游的服务上去从而对上游服务进行的保护比如说这个我们这也是一个实力比如说这边我们配置了对某一个服务对这个有的硬化的服务配置了最大持有80个连接但它是ATB1的一些服务然后最大配置800个请求最大配置800个请求就是对于这个是对一些ATB2服务会剩下的然后配置最大1000个等待连接1000个等待请求一般是对ATB1的服务会配置这样因为ATB2服务它每连接上可以直接处理然后配置每个连接上最大10个请求也是这样的一些预示规则当实际请求超过当实际的访问超过这样一预示的话那个上游连接就会PROX就会把连接给断路掉对所以我列了一下就是网格的它连接直接配置一些详细主要想对比一下控制面和顺面它这些配置的规律包括一些命运实际上不太一样实际实际使用中有很多用户在这会搞缓或者服了这样一个表放在这这次分享完我们就把它打开因为我们实际用户用的时候就在这个案例中间我们用户其实也碰到这样的碰过把它放在这另外一种提高服务真性的很重要一个手段实际上是超时这个实际上超时的理论其实在服务真性的实际上非常广泛比如说我们通过超时来避免我们的一个服务服务一直卡在一个请求上这样的对我服务整个的一个占用或者对这个服务甚至对我自己自愿的一个占用一直被卡在同一个请求上通过配置超时的话像在这个例子中间如果我配了一个三秒的一个超时这个时候BFF这个服务防御的result是一个服务的时候当超过三秒的时候扣断这边的带领就会把这个服务请求给它取消掉从而对上约服务进行一个保护在实际实用中间我们其实也发现不同的服务应该配不同的超时因为如果说我们曾经出现过比如说你服务这个超时时间配得特别长起不到一个保护的效果或者如果配得特别短的话如果对某一个服务来说它本来想要时间也比较长你配得特别短实际上就是就影响用户的一个正常实用它还没返回你就把它取消掉提高服务质量还有另外很重要的一块就是配重视能提高服务整个一个实际成功率特别是对一些对用户实用这边用户的一些比如说我这一些网络的问题或者服断一些运行系的顺势的一些问题通过重视它能提高服务的一个成功率有这些吧我们配了一个三次的一个重视像BFF这个服务对U的result这个服务它访问出错的时候会自动的对这个服务进行一个发泄发泄三次重视但实用中我们也发现对有些有些时候这个重视其实并不一定总是生效比如我们曾经说过有一次用户它那个声音不会写错然后这个时候你重视的话你尽不管重视多少次它都是够长的不但没有解决问题反倒引起了类似像这个我们叫重视重视风暴一样这样的问题对于用户整个准备又去造成了是一个消极的影响还有另外一个重要的一个提高服务进行的手段是线流虽然前面其实用户这边其实原来做过一些熔断的一些能力但实际上不管是Hastry的材质网格的熔断它都是在扣单这边来做的也就是说如果扣单被绕过了比如说这块没装扣单带着其实这段熔断能力其实它就是它就是没法生效而通过线流的话是可以做到对摄影服务的同一个保护然后当服务的一个顺势流量超过我们配置的预值的话将会把这一次请求给它绝掉从达到对摄影服务的一个保护特别重要的是说我们可以对不同的服务配置不同的一些线流预制位置特别是对我们核心的一些服务我们配合一些非核心服务配置一些不同的预制位置才会保证说在我系统整个过载的时候我优先保证一些优先保证我一些核心服务从整个来看牺牲我服务的一个整体一个任性可以牺牲掉一些非核心的服务把它一些请求给它绝掉这也是在这次时间中用不用的比较多的一个手段还有另外一个重要的一个任性的一个要求就是在变更的时候尽量减少变更带来风险因为有一个新版本上线的时候新版本的一些质量问题尽量避免对线上用户的一些影响挥度其实是非常使用非常多的一个手段保证两个版本同时在线然后来对挥度版本进行一些屏幕虽然网格上比较方便的做到在挥度的时候实现一些不同的分流测证比如说在这个地方我们可以配置从只切分30%流量的挥度版本上剩70%人还从用户原来保在版本的这个时候如果即使有问题也只会有30%流量受到影响而且如果出现问题的时候用两个版本同时在线即使网格这块流量这些测量和快速的回退也就是说用这一段能力用这块能力保证这块挥度能力能同非信用的方式能对用户的变工对用户的影响进行的小除了前面刚才上一页我们讲到的即使流量比例或群众的能力之外即使网格的流量测量也可以方便地配置只有某种特征流量去走到挥度版本上来留这个例子中间我们走到把国国等于第一位的这些请求发送到一个挥度版本上来其他流量还走原来的版本这个时候技术性的版本有问题了也只影响这种特征的用户在实际我们这次我们的扣实验中间它一般打上这个标记或类似标记它都是它这些有好用户或者一些能重塑掉的用户所以整个来说这个过程对用户的主要的用户的影响主要的用户是那个现任业务影响就比较小的因为有一个重要的手段就是荣誉来提供服务整体的一个可用性实际上我在在我工作早期实际上是做一些铁路桥栏方面的工作我们早期的话早期的话比如说我们原来做那钻孔桩的时候一个桥栓下钻孔桩我们一般都会做的比力学核算的要拖上几个这个理论实际上荣誉的理论在在我们身边是到处都在适应的在机能机世界里边比如说我们的为服务场景下面我们经常会说到一个服务给它配有多个实力实际上主要做的事情除了我们做多实力的服务在分担之外还有非常重要的一方面去说其实就是荣誉这样一个考虑说我有一个服务有问题有一个服务刮掉了有一个服务实力刮掉了我的服务整个来说还是能向上提供能力在容器场景和KBS它的一些像在多实力配个多副版非常容易而且它提供了一种能力就是我们能配这些基于节点或者AZ就是可恒区的反清盒能保证说我如果说某一个节点的故障某一个节点我们把实力分担在不同的节点和可恒区上如果某一个节点和可恒区故障我怎么服务来说只是这个可恒区的实力故障我怎么服务呢还是可以对我提供从整个整体上提供我的一个可恒性KBS除了提供前面的我们说布首上的一些一些一些便利之外谁在升级过程中间也提供了一种能力能保证我在升级过程中间对用户的业务真相小或者说是甚至升级过程中间对用户的业务真相小甚至做到让用户的业务不敢吃它做到了其实用户在我们这个场景下用户用得比较多就是容量要对它我们能做到如果说用户有一个新的新的版本要上线生我们想会先创建出一个新的实力然后停掉一个旧的实力然后再创建一个新的实力然后再停掉停掉一个旧的实力就让滚动完成整个生意过程像我们用户场景下边它的主要的服务都是RES的所以一些短连接的方式所以通过这种方式基本上做到在滚动过程中间对用户的业务是对用户的业务基本上是不充耐也非常优雅或者非常友好的完成这样一个生机的过程提高了整个变故过程中间的一个服务用得比较可能性任性里边其实还有另外一重要一点就是说如果说我的服务如果过载的时候能比较方便及时有过程做一个容量的一个扩展当然扩展有可能是一些你是变成资源的也可能是现在微博上线其实扩出实力来可能是更方便的操作在QBUS边我们可以配置说当服务的某些指标超过一个OPS预指的话可以先给它做一个扩展比如这个例子中间我们配置了用户的CPU说超过60%或者它的PPS超过1000我们就给它做扩展这个时候呢这个时候呢从而保证用户的这个指标在一个我设定的方面当然在文革上以下我们现在还在做比如说能使用用户的一些像QBUS或者实验这样一些方式保证用户整个服务的方式在我们规划的一个方式从而提高用户的一个总体的服务的方式我们前面讲到除了运行期或者说是运行期之外呢在实验室的服务部署之前呢在测试环境下在测试在部署之前我们还做一些物账的一些模拟测试的一个工作用网格这种非清理能力做这方面会非常方便比如在这个例子中间我们是给这个U的Result这个服务给它注入了有五秒钟的一个实验五秒钟的实验这样的话用物整个是不用改带嘛然后是通过这个配整BF5这个服务Uresult的时候它会就有五秒的实验我们就可以验证一下这个BF5这个服务它对这个实验它的处理是否适当是不是会造成BF5这个服务它最终是没有处理适当而且最终用了一个实验这样的问题但除了注入实验之外我们还可以注入一些故障比如说这个注入了一个500的故障这样我们会验证一下BF5这个服务对这种议程它是不是处理合适也没有因为没有做合适处理把500的故障直接泡给最终用户变成最终用户的实验整个这种故障的注入过程就非清理因为不用用这种一些帽和自己的带嘛或者是生产的东西这样做配置就可以这也是在用户实验中间非常好远的方式除了前面这些之外还有另外一点就是调链来完成来做一个故障的一些定居定计在这个用户场景下面其实调链前期也在用前期在那三块期用户也用到然后网格调链和传统链开发工匠它比较大的一个不同就是这个调链的买点能够是在客户单来做别说用户又它不用去管这个调链的事情只要通过配置就可以收集调链然后去通过检索调链里边我可以看到我的服务到底是那个服务故障不管是在卖的时候故障是我既然到到底是哪一阶段卖哪一阶段出动从而比较方便的完成故障的一个定位定期好以上就是这次分享的主要内容大家有问题可以提问我和世宇谢谢大家