写点什么

全面异步化:淘宝反应式架构升级探索

  • 2019-01-15
  • 本文字数:3015 字

    阅读完需:约 10 分钟

全面异步化:淘宝反应式架构升级探索

2018 年初,淘宝开始尝试对整体架构进行升级,经过近一年的探索,实现了全面异步化,这一架构升级在部分应用中取得了 40%以上的性能提升,同时也为后续的回压推进打下了基础。负责该项架构升级的是淘宝技术专家许泽彬,他在 2018 领域驱动设计中国峰会上做了《淘宝应用架构升级——反应式架构的探索与实践》的分享,InfoQ 也趁此机会对他进行了采访,了解了更多细节。


2018 领域驱动设计中国峰会(DDD2018)是 ThoughtWorks 发起的技术会议,旨在给国内的 DDD 实践者们提供一个互相交流、分享自己团队的成功经验的机会的平台。


许泽彬是淘宝技术专家,目前负责淘宝应用架构升级。曾参与淘宝用户增长设施与平台建设,负责过分布式调用链跟踪框架和系统“鹰眼”,曾经是阿里分布式数据库中美异地机房数据同步的核心开发,也是阿里旗下开源项目 otter 和 canal 的核心开发者。


淘宝此次架构升级,重点在于将同步的架构改为异步、面向流的开发,以便为后续的回压方案打下基础, 这里所说的回压方案要解决的问题是:应用在突发流量下的稳定性保证,以及最大化提升资源利用率。 许泽彬将其称为反应式架构。


经过近一年的推进,反应式架构已经在生产环境落地,在 2018 年双 11 万亿级大规模处理量下,架构升级对多个核心应用进行了验证落地,取得了超出预期的效果:


  • 其中『猜你喜欢』应用上限 QPS 提升 96%,即只需一半的机器就能支撑现有业务;

  • 而另一核心应用『我的淘宝』实际线上响应时间下降了 40% 以上,意味着用户可以更快得到响应。


在淘宝内部,这仅仅是回压——突发流量下的稳定性以及最大化提升资源利用率方案 —— 刚刚迈出的第一步。

什么是反应式架构

反应式架构里的反应式,就是 Reactive,国内对这个词的翻译并不统一,有的叫响应式,有的叫反应式。许泽彬认为,这里将其称为反应式更为准确,响应式更多用于前端的界面中,对应的英文是 Responsive。


反应式架构与一般架构相比,其反应体现在:


第一个,对用户有反应,对用户有反应我们才说响应,一般我们说的响应,基本上都说得针对跟用户来交互。


第二个,要对失败有反应,应用失败了系统不能无动于衷,等着它挂掉,要有反应。


第三个,要对容量和压力变化有所反应,比如说淘宝的秒杀,系统需要反应来保证对用户的响应性,再如那个当流量降下来,将系统缩容,可以节约成本,这也是一种反应。


第四个,对输入有反应,响应系统的输入,也可以叫做消息驱动。


要做到反应式,需要做到三点:


  • 适应性,也就是发生失败能恢复回来,无论是系统、网络、代码出现了问题都能恢复。

  • 弹性,这点主要是应对流量的变化,弹性的前提是做到可伸缩性 Scalability,从软件设计上,要做到去中心化;同时,在运行时,要感知节点当前的系统负载,将压力往上游进行反馈,做到系统可以感知链路级别的节点压力,使得系统可以针对整体压力进行有目的地扩容缩容。这样才能够做到真正的弹性,根据系统负载进行扩容或缩容,这也是淘宝的回压方案在后续所需要支撑的场景。

  • 消息驱动,有了消息驱动才能比较好的做到上面两个点。在反应式架构里,以前这点叫做事件驱动,后来改为消息驱动,消息驱动强调无阻塞、无 callback,所以不会有线程挂在那里,不会有持续的资源消耗。同时,事件驱动或消息驱动都是异步化,而异步化会将操作系统中的队列情况显式地提升到了应用层,使得应用层可以显式根据队列的情况来进行压力负载的感知,这对于淘宝后续的回压方案非常重要,而要做到这点,就需要异步了。


反应式架构中的核心概念是“流”,流就是面向数据的顺序串行执行的一系列操作组合,它同传统的编程相比,将业务逻辑导致数据改变,变成了操作改变数据,反过来影响业务逻辑的改变。面向流编程就是面向数据编程。


面向流的开发的优势主要体现在:


  • 提供大量强大的操作符,包括创建、过滤、转换等。声明式表达比过程式编程更加完备、高级、快捷。

  • 在并发控制方面,不同的流之间无依赖,通过切换 Scheduler 就可以自动多流并发,而业务按照语义编写,可以更友好的并发控制,更优的维护性和性能。

  • 更高的资源利用率。通过更少的上下文切换、更低的竞争,可以降低负载,提升资源的有效利用率。

  • 流可以加强分布式架构的治理能力。流引用可被远程化,从而实现系统级的流式贯通,而流提供的更好的回压、三角模式透传,以及天然的截面编程能力等,可以给架构治理提供更好的帮助。目前淘宝正在推进回压的方案,就是为了给系统在稳定性和资源利用率上提供更高级的治理手段。


淘宝反应式架构实践

淘宝之所以要做架构升级,是因为现有架构存在一系列问题:


  • 同步等待造成资源浪费,现有的同步模型线程多负载高,导致资源利用率较低。

  • 架构的并行度有限,无法实现纯业务依赖并发,微服务化让问题更加凸显,服务增加造成响应时间累积。

  • 而响应时间累积又带来一些连锁反应,包括为了降低响应时间而过早的引入 cache,每个服务都需要设置超时来解决长时间无响应问题,而这些带来维护成本的提升,也提高了业务实现的复杂度。

  • 同时,在应用系统无事先准备的情况下,面对突发大流量时,很容易被打挂,造成稳定性问题,导致用户体验严重下降。


而经过调研后,淘宝架构团队认为使用反应式架构是当前可行的一个方案。原因包括,Java 8 已经逐渐普及,因为它包含对 Lambda 的支持,这让开发者对 Lambda 的接受度大大提高;同时 Reactive 相关的业务框架在业界已有成熟的实现,RxJava 已经广泛在大小公司中应用;最后,包括 Java 9(引入 Reactive Sreams 规范 API)、Spring 5(引入 Reactor/WebFlux)、Spring Boot 2 都开始拥抱 Reactive,说明反应式编程的确是趋势。


整个方案对业务架构的升级主要包括编程框架、中间件,以及业务方的升级。中间件的升级,包括服务框架(RPC)、网关、缓存、消息(MQ)、DB(JDBC)、限流组件、分布式跟踪系统、移动端 Rx 框架。


这其中值得注意的包括,对服务框架的升级,流式实现将在 Dubbo 3 中放出;DB 中的异步集成使用 Ali JVM 协程或用线程池实现;移动端为了支撑已有的 iOS 应用,淘宝开发了 AliRxObjc 并即将开源。


最后,改造后的架构如图:



实施反应式架构的难点


反应式架构在各个模块上基本都有成熟的方案,除了个别领域如数据库,基本没有特别的瓶颈。实施反应式架构的难点主要在于工程师的思维转换,因为之前工程师主要使用同步式的思维写程序,突然要换成以流的方式编写,思维必须要做转换。


因此,要做到全面异步化,组织必须从上到下全力支持。淘宝的做法是,成立虚拟小组,在每个业务线里挑选能力比较强的同学统一进行异步式的培训和指导,之后由他们在团队内部推广。


同时,要让业务方有动力去做异步化的改造,需要让他们认识到这么做的好处,因此异步化改造首先要做出一些标杆性的成绩出来。这中间的策略包括选择面临瓶颈的地方,业务逻辑简单的, 以及业务压力不大的应用来进行试点,一旦做出成绩,就可以给其它团队以信心和动力。

淘宝应用架构升级后续规划

目前,淘宝的异步化改造在技术上已经大部分完成,后续的规划主要包括:


  • 回压的实现

  • 分布式上下游的联动回压,解决高并发压力下的响应时间、有效请求数、系统自恢复、链路短板自发现等问题,解决系统在突发流量下的稳定性问题,以及提高资源利用率。

  • 自适应回压解决静态配置无法应对系统波动变化问题

  • 实现全异步/流式为核心的服务框架,让业务方做到异步优先;

  • 考虑引入 Kotlin 协程,它的异步设计符合过程式的编程习惯。


淘宝的回压方案,目前正在推进和实施的过程当中,后续他们也将会有更多的经验分享出来,欢迎关注。


2019-01-15 09:4820122
用户头像

发布了 164 篇内容, 共 106.9 次阅读, 收获喜欢 392 次。

关注

评论 8 条评论

发布
用户头像
“QPS 提升 96%,响应时间下降了 40% 以上”,之前的系统架构和工程师得有多垃圾,还是过于夸大吹牛逼的成分了,我感觉是后者
2019-09-06 16:11
回复
同意观点。如果之前的系统cpu利用率本身已经很高了,你QPS还能提升这么多?
2020-03-20 16:09
回复
限定的是那两个应用,QPS说的还是上限,响应时间也没说是max or avg
2020-06-12 17:30
回复
用户头像
阿里 JVM 不是有协程吗?为什么淘宝还搞反应式?协程不好用?
2019-05-29 12:46
回复
用户头像
playframework一直在践行反应式开发,虽然是小框架,但是思路跟楼主是一样的。
2019-01-18 09:34
回复
用户头像
好文章,收藏了
2019-01-16 10:45
回复
用户头像
mark
2019-01-15 20:29
回复
用户头像
这篇文章回答了什么是反应式架构的概念。又举了很多淘宝的例子。真是一篇不可多得的文章。
反应式编程是未来的趋势。作为Java技术栈的朋友们,这是下一个金矿。
希望能放出Slides或PPT,了解细节。
2019-01-15 11:00
回复
没有更多了
发现更多内容

企业新道路怎么走?火山引擎AB测试助力决策选择

字节跳动数据平台

大数据 ab测试 对比试验 企业号 8 月 PK 榜 数字化增长

Docker 搭建Web服务器nginx

霍格沃兹测试开发学社

计算机网络知识,一文搞定

霍格沃兹测试开发学社

四层负载均衡的NAT模型与DR模型推导 | 京东物流技术团队

京东科技开发者

负载均衡 企业号 8 月 PK 榜 四层负载均衡 NAT模型 DR模型

【深入浅出系列】之代码可读性 | 京东云技术团队

京东科技开发者

Java 企业号 8 月 PK 榜 代码可读性

web自动化解决文件上传和弹框

霍格沃兹测试开发学社

活动回顾|阿里云 Serverless 技术实践营 Serverless +AI 专场

Serverless Devs

阿里云 Serverless 云原生

生成式AI改变业务流程:自动化、优化、高效

百度开发者中心

AIGC #人工智能 ChatGPT 文心一言

生成式AI驱动的数据中心网络变革

百度开发者中心

AIGC #人工智能 ChatGPT 生成式AI 文心一言

生成式AI:游戏产业的未来发展驱动力

百度开发者中心

游戏 #人工智能 生成式AI 文心一言

DBeaverEE for Mac(数据库管理工具) v23.2.0激活版

mac

数据库管理工具 苹果mac Windows软件 DBeaverEE

DEFI应用开发技术|DApp借贷理财挖矿系统源码逻辑

V\TG【ch3nguang】

DeFi去中心化系统开发 质押挖矿

App自动化控件定位

霍格沃兹测试开发学社

医疗器械行业的MES系统解决方案

万界星空科技

解决方案 MES系统 医疗器械

生成式AI:开启全新产业机遇

百度开发者中心

智能客服 AIGC #人工智能 文心一言

生成式AI:开启智能科技新纪元

百度开发者中心

#人工智能 生成式AI 文心一言

【VLDB 2023】基于预测的云资源弹性伸缩框架MagicScaler,实现“高QoS,低成本”双丰收

阿里云大数据AI技术

#人工智能

WinRAR<6.23 远程代码执行漏洞【Poc公开】(CVE-2023-38831) [有POC]

墨菲安全

网络安全 漏洞分析 WinRAR

如何有效进行RLHF的数据标注?

Baihai IDP

AI 强化学习 数据标注 RLHF 大语言模型

区块链量化合约交易所开发,永续合约交易所源码部署示例

V\TG【ch3nguang】

永续合约系统开发 量化合约

百亿补贴通用H5导航栏方案 | 京东云技术团队

京东科技开发者

移动开发 H5页面 企业号 8 月 PK 榜 导航栏

Appium WebView 技术原理

霍格沃兹测试开发学社

IPQ5018 vs IPQ4019-IPQ4029 is safer, lower power consumption and faster-Difference wifi5 and wifi6?

wifi6-yiyi

wifi6 wifi5

CorelDRAW Graphics Suite 2022 for Mac(矢量图形设计工具) v24.4.0.636激活版

mac

苹果mac Windows软件 CorelDRAW2022 矢量图形设计软件

Andriod微信小程序自动化测试

霍格沃兹测试开发学社

@Configuration 注解的 Full 模式和 Lite 模式!

江南一点雨

Java spring

带你上手基于Pytorch和Transformers的中文NLP训练框架

华为云开发者联盟

人工智能 华为云 大模型 华为云开发者联盟 企业号 8 月 PK 榜

代码质量,众包项目的关键成功因素

知者如C

代码质量

dapp/defi/lp发行代币流动性质押系统项目开发

V\TG【ch3nguang】

代币 DAPP系统开发 质押挖矿

从原理聊JVM(五):JVM的编译过程和优化手段 | 京东云技术团队

京东科技开发者

Java JVM jvm调优 企业号 8 月 PK 榜 JVM编译过程

自动化测试之模拟器控制

霍格沃兹测试开发学社

全面异步化:淘宝反应式架构升级探索_架构_徐川_InfoQ精选文章