抖音技术能力大揭密!钜惠大礼、深度体验,尽在火山引擎增长沙龙,就等你来! 立即报名>> 了解详情
写点什么

淘宝应用柔性架构的探索

2019 年 8 月 19 日

淘宝应用柔性架构的探索

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 提升了 23s0%,同时应用的压垮 QPS 提升了 3 倍,在压测大流量过后,秒级恢复,迅速提供正常服务(原需 6 分钟+ )。


应用柔性架构升级 - 后续展望

为了让应用更具高可用,我们从故障的角度,围绕着从故障发生前的预防能力,到故障诱因发生中的防御能力,再到故障发生时的恢复能力,来打造应用的高可用能力,进行应用的柔性架构升级。


同时,针对自适应负载调节,目前的策略为就地拒绝,提高了稳定性,但仍有稳定性风险,后续我们需更进一步丰富策略,如结合集团的中间件产品,进行快速扩容/缩容操作;应用向上游反馈压力,使得压力从上游杜绝(分布式回压)等。同时,为了在应用的依赖出现问题时,仍能够有柔性能力,我们也会针对同步模型的应用,引入自适应的隔离/熔断能力,使得应用下游出现问题时,不会影响到应用本身。


应用高可用关注的是应用自身,除了应用高可用,我们也在积极推进淘系业务整体的高可用能力,比如在站点出现问题时,我们如何做到以最快的速度切换流量,恢复业务,最终提升整个淘系的高可用。更多关于应用高可用、淘系业务高可用的理解和落地,我们在持续地探索。


本文转载自公众号淘宝技术(ID:AlibabaMTT)


原文链接


https://mp.weixin.qq.com/s/uW8gNGCI-oj4NitU9dHZjQ


2019 年 8 月 19 日 08:004442

评论 1 条评论

发布
用户头像
动态调整能力,是使用了响应式编程的背压特性么?
2019 年 08 月 20 日 12:56
回复
没有更多了
发现更多内容

腾讯高工亲授“MySQL学习方法”【思维导图+学习笔记+实战文档+面试题库】让你站在数据库领域的顶峰 笑傲江湖!

比伯

Java 编程 架构 面试 计算机

Alibaba2020年度内部全技术栈PPT总结(基础+架构+算法+大数据+手册)

Crud的程序员

Java 架构 后端 技术栈

再见 2020!Apache RocketMQ 发布 4.8.0,DLedger 模式全面提升!

阿里巴巴云原生

阿里云 开发者 云原生 存储 消息中间件

加密数字货币钱包系统软件开发|加密数字货币钱包APP开发

开發I852946OIIO

系统开发

四万字干货 | 《高博士区块链观察18讲》文字稿,带你系统了解区块链

CECBC区块链专委会

区块链

Openresty协程调度对比Go协程调度

行如风

高并发 协程 openresty Go scheduler

软件测试---BUG的生命周期

测试人生路

软件测试

看完老板哭着让我留下来!带你彻底搞懂Android启动速度优化!Android篇

欢喜学安卓

android 程序员 面试 移动开发

python 技术面试没过,居然是没有用 pytest 测试框架

和牛

Python 测试 测试框架 pytest

HTTP 请求流程

大导演

浏览器 HTTP 前端进阶训练营

零基础也能看得懂!Android面试心得必备技能储备详解,Android面试题及解析

欢喜学安卓

android 程序员 面试 移动开发

Java多线程并发控制工具信号量Semaphore,实现原理及案例

码农架构

Java Java并发 并发编程 后端

如何在 OpenShift 中运行 Collabora Office

东风微鸣

openshift

换个角度,聊聊全链路压测

老张

团队管理 性能测试 系统稳定性 全链路压测

28天写作挑战——坚持28天,每天500字

TGO鲲鹏会

活动专区 28天写作

Uniswap去中心化交易所系统开发

W13902449729

去中心化交易所系统开发 uniswap

泪目!美团点评APP在移动网络性能优化的实践,附赠课程+题库

欢喜学安卓

android 程序员 面试 移动开发

架构师第7周作业

Geek_xq

Filebeat同步写位点文件引发的磁盘IO问题

秦宝齐

Java多线程并发控制工具CountDownLatch,实现原理及案例

码农架构

Java 并发编程 后端

测开之函数进阶· 第8篇《多个装饰器装饰同一个函数,三个内置的装饰器》

清菡

测试开发

吴桐/数字化的下一个十年,你可能不会更幸福

CECBC区块链专委会

数字化时代

MySQL不会丢失数据的秘密,就藏在它的 7种日志里

程序员内点事

MySQL

大数据应用及其价值

andy

量子通信触达消费者

CECBC区块链专委会

量子通信

智慧城市智能化建设,平安社区平台建设综合解决方案

t13823115967

智慧城市

掌上警务,二维码一键报警定位系统

t13823115967

二维码定位报警系统开发

云算力挖矿系统APP开发|云算力挖矿软件开发

开發I852946OIIO

系统开发

AMD台式CPU市场份额距离英特尔还有多远?刚到四分之一

新闻科技资讯

大数据指标分析思考

andy

惊艳!阿里人用29篇讲明白了多线程与高并发+设计模式,惊呆了!

996小迁

Java 面试 设计模式 多线程 高并发

Study Go: From Zero to Hero

Study Go: From Zero to Hero

淘宝应用柔性架构的探索-InfoQ