萧山建设银行招聘网站,佛山家居企业网站建设,推广型网站建设机构,网站seo是什么意思导读#xff1a;随着淘宝业务的飞速发展#xff0c;微服务架构在持续演进的过程中#xff0c;也受到了越来越多的挑战#xff1a;如同步模型带来的资源利用率有限、依赖调用并发度有限、下游故障引发应用自身出问题#xff1b;又如静态限流随着业务代码的演进、依赖拓扑的… 导读随着淘宝业务的飞速发展微服务架构在持续演进的过程中也受到了越来越多的挑战如同步模型带来的资源利用率有限、依赖调用并发度有限、下游故障引发应用自身出问题又如静态限流随着业务代码的演进、依赖拓扑的变化、部署环境的调整而造成过时引起的稳定性隐患等挑战。 ArchSummit全球架构师峰会上淘宝高级技术专家——泽彬分享了为应对这些挑战淘宝基础服务在淘系架构升级上代号 Tango Taobao Architecture Next GeneratiOn 对这些问题的认识以及让应用面对突发问题时更具柔性应用柔性架构的一些探索。 Reactive 全异步化
当前我们的微服务主要是基于同步的调用模型带来了如下挑战
同步等待造成应用资源利用率很难进一步提升并发度有限技术实现无法做到业务理想程度的并发导致 RT 增加下游出现问题会导致应用本身出现问题如应用等待下游响应的线程会被长时间阻塞
为此我们引入了基于 Reactive 编程模型以全异步、可编排的能力来应对上述挑战
通过全异步化使得资源利用率/性能进一步提升通过全异步化编排能力使对外调用的请求并发能够突破原有并发线程的限制做到极致并发通过全异步化能力使得应用在等待依赖响应的耦合资源从线程变成了回调对象让下游出问题时对应用自身的影响变得十分有限从而提升了应用本身的稳定性。
基于 Reactive 全异步的解决方案打通了全栈使得应用能够进行全异步化升级。淘宝的一核心推荐应用在上线后 QPS 上涨了 90%另一核心应用上线后 RT 也下降了 40%。
关注稳定性
在全异步化解决方案落地的同时我们也在持续关注着稳定性。业务规模不断的增加对稳定性的挑战也在变得越来越大。尽管我们对稳定性非常重视但有时还是难免因一些错误的判断而导致了稳定性问题。
比如在某次大型活动中我们的收获地址出现了一些短暂不可用问题又比如在另一次大型联欢活动中我们的登录系统也出现了短暂的不可用问题。这两个经典的案例都是在我们对应用的容量、活动的流量预估上出现了失误而导致的问题。
虽然通过限流我们可以大幅度提升应用在流量方面的稳定性但通过上述两个案例以及业务的不断实践我们认为只使用静态限流系统还是会因为一些不确定性因素而带来稳定性上的隐患和风险。
由不确定性而引发的问题
限流是保护应用稳定性的有力武器应用在正确预估自身容量和外部流量的情况下借助限流可以保护应用自身不被流量打垮从而提高自身的稳定性淘宝这么多年的活动限流都起到了功不可没的稳定性作用。
随着微服务数量的增长我们发现应用在使用静态限流时也带来了一些稳定性的隐患 —— 静态限流 与 不断演进的应用之间存在着时间上的不匹配。换句话说应用一旦设置了限流只要应用不断的发展静态限流就有可能面临着过时的风险。造成过时隐患和风险的因素主要包括
1、业务演进/依赖变化引起的不确定性
业务一直在发展我们的应用代码也一直在变化很有可能昨天刚刚设置过的限流 QPS在今天应用一发布就已经不适用了。就算应用本身不发布应用自身依赖的后端服务的拓扑不停的变化也会引发应用能够承受的 QPS 发生变化带来不确定性
2、流量模型发生变化引起的不确定性
应用和服务通常包含多种方法调用每种方法调用消耗的系统资源都不同这要求在对应用压测时的流量模型要足够的合理准确才能找到有效的限流值然而业务的流量模型往往也是在不断的变化这也会为应用的 QPS 评估带来不确定性。
3、不同容器实例容量引起的不确定性
随着运维环境和方法越来越复杂交付给业务的容器也变得不确定如我们的混部、CPU Sharing 。同时同一应用的不同容器很可能会有不同的容量如同一个应用的不同容器压出来的基线 QPS 都很可能有很大的差异。底层机器资源的不确定性也为应用限流QPS 评估带来了不确定性
因此针对应用的限流阈值设置应用开发就会很纠结
如果设置的限流阈值偏保守偏低那么有的机器资源使用率上不去浪费机器造成成本升高问题。如果设置的限流阈值偏乐观偏高那么有的机器还没有达到限流阈值就会被压垮造成稳定性问题。
上述的不确定性也是我们在大型活动前进行封网的原因之一。
应用柔性架构升级
面对着如此多的不确定性我们希望我们的应用本身能够具有一些『柔性』的特征使得在面对不确定的场景突然出现时应用仍能够承受这些变化就像太极一样能够做到以柔克刚。我们认为应用架构要做到柔性至少需要有以下特征针对应用柔性架构的特征我们也在持续的探索中
1、故障容忍
如使用隔离进行解决。阿里的异地多活单元方案可以隔离地区出现的问题微服务化提升了研发效率同时也隔离了其他独立链路出现的问题而我们提出的全异步化解决方案也增加了上游对下游出问题时的隔离作用。
2、过载保护
如使用自适应负载调节进行解决。来应对由于流量容量预估不准而带来的稳定性问题。
为解决上述提到的不确定性带来的应用过载隐患问题我们引入了自适应负载调节来升级应用的过载保护能力解决应用过载的稳定性隐患。 自适应负载调节 通过自适应负载调节来应对上述不确定性使得应用能够就地实时的评估自身负载让接受的 QPS 与处理能力同步防止限流评估出错而导致的稳定性问题和资源利用率问题同时在应用接收到超高压时单机压垮的 QPS 可提到更高。从而能够应对更高的突发流量加固应用自身的稳定性。
整个方案的主要由两部分构成
1、与应用整合的负反馈组件
在应用的入口设置一个负反馈组件根据应用自身的负载情况对进入的请求进行针对性的拦截为了适用更多业务此组件还支持服务权重优先拒绝权重低的服务使得在过载时资源能够尽量往权重高的服务倾斜。
2、组件本身的快速迭代机制
为了让方案本身能够在不同的场景下有效我们从很多不同的维度展开组合成多个场景再通过自动化的场景压测来快速进行算法在不同场景下的效果评估和改进从而提升整个方案的迭代演进速度。
最终整个方案沉淀了自适应负载调节的自动迭代平台迭代出基于 CPU 的自动控制算法。
上线案例
淘宝某核心业务的应用在一次大型活动压测中的效果得到验证在某个机房的机器数比预期少 22.2% 的情况下抗住了 130% 的压测流量。按照以往双十一的压测经验在少这么多机器的情况下这个机房的应用扛不住如此大的流量。
另一核心应用由于担心不确定性原因静态限流值设置的偏保守在接入自适应负载调节后限流值可以进一步提升使得服务的有效 QPS 提升了 230%同时应用的压垮 QPS 提升了 3 倍在压测大流量过后秒级恢复迅速提供正常服务原需 6 分钟 。
应用柔性架构升级 - 后续展望
为了让应用更具高可用我们从故障的角度围绕着从故障发生前的预防能力到故障诱因发生中的防御能力再到故障发生时的恢复能力来打造应用的高可用能力进行应用的柔性架构升级。
同时针对自适应负载调节目前的策略为就地拒绝提高了稳定性但仍有稳定性风险后续我们需更进一步丰富策略如结合集团的中间件产品进行快速扩容/缩容操作应用向上游反馈压力使得压力从上游杜绝分布式回压等。同时为了在应用的依赖出现问题时仍能够有柔性能力我们也会针对同步模型的应用引入自适应的隔离/熔断能力使得应用下游出现问题时不会影响到应用本身。
应用高可用关注的是应用自身除了应用高可用我们也在积极推进淘系业务整体的高可用能力比如在站点出现问题时我们如何做到以最快的速度切换流量恢复业务最终提升整个淘系的高可用。更多关于应用高可用、淘系业务高可用的理解和落地我们在持续地探索。
加入我们
欢迎加入淘宝基础平台基础服务团队团队成员大牛云集有阿里移动中间件的创始人员、Dubbo核心成员、更有一群热爱技术期望用技术推动业务的小伙伴。
淘宝基础平台基础服务团队推进淘系淘宝、天猫等架构升级代号Tango致力于为淘系、整个集团提供基础核心能力、产品与解决方案
业务高可用的解决方案与核心能力应用高可用为业务提供自适应的限流、隔离与熔断的柔性高可用解决方案站点高可用故障自愈、多机房与异地容灾与快速切流恢复新一代的业务研发模式FaaS一站式函数研发Gaia平台下一代网络协议QUIC实现与落地移动中间件API网关MTop、接入层AServer、消息/推送、配置中心等等
原文链接 本文为云栖社区原创内容未经允许不得转载。
