淘宝应用柔性架构的探索

导读：随着淘宝业务的飞速发展，微服务架构在持续演进的过程当中，也受到了愈来愈多的挑战：如同步模型带来的资源利用率有限、依赖调用并发度有限、下游故障引起应用自身出问题；又如静态限流随着业务代码的演进、依赖拓扑的变化、部署环境的调整，而形成过期引发的稳定性隐患等挑战。

ArchSummit（全球架构师峰会）上淘宝高级技术专家——泽彬分享了为应对这些挑战，淘宝基础服务在淘系架构升级上（代号 Tango ：Taobao Architecture Next GeneratiOn ）对这些问题的认识以及让应用面对突发问题时更具柔性（应用柔性架构）的一些探索。

Reactive 全异步化

当前咱们的微服务主要是基于同步的调用模型，带来了以下挑战：

• 同步等待形成应用资源利用率很难进一步提高
• 并发度有限，技术实现没法作到业务理想程度的并发，致使 RT 增长
• 下游出现问题会致使应用自己出现问题（如应用等待下游响应的线程会被长时间阻塞）

为此，咱们引入了基于 Reactive 编程模型，以全异步、可编排的能力，来应对上述挑战：

• 经过全异步化使得资源利用率/性能进一步提高
• 经过全异步化，编排能力，使对外调用的请求并发可以突破原有并发线程的限制，作到极致并发
• 经过全异步化能力，使得应用在等待依赖响应的耦合资源从线程变成了回调对象，让下游出问题时对应用自身的影响变得十分有限，从而提高了应用自己的稳定性。

基于 Reactive 全异步的解决方案打通了全栈，使得应用可以进行全异步化升级。淘宝的一核心推荐应用，在上线后 QPS 上涨了 90%+，另外一核心应用，上线后 RT 也降低了 40%。

关注稳定性

在全异步化解决方案落地的同时，咱们也在持续关注着稳定性。业务规模不断的增长，对稳定性的挑战也在变得愈来愈大。尽管咱们对稳定性很是重视，但有时仍是不免因一些错误的判断而致使了稳定性问题。

好比，在某次大型活动中，咱们的收获地址出现了一些短暂不可用问题；又好比，在另外一次大型联欢活动中，咱们的登陆系统也出现了短暂的不可用问题。这两个经典的案例，都是在咱们对应用的容量、活动的流量预估上出现了失误而致使的问题。

虽然经过限流，咱们能够大幅度提高应用在流量方面的稳定性，但经过上述两个案例，以及业务的不断实践，咱们认为，只使用静态限流，系统仍是会由于一些不肯定性因素而带来稳定性上的隐患和风险。

由不肯定性而引起的问题

限流是保护应用稳定性的有力武器，应用在正确预估自身容量和外部流量的状况下，借助限流能够保护应用自身不被流量打垮，从而提升自身的稳定性，淘宝这么多年的活动，限流都起到了功不可没的稳定性做用。

随着微服务数量的增加，咱们发现应用在使用静态限流时，也带来了一些稳定性的隐患 —— 静态限流 与 不断演进的应用之间存在着时间上的不匹配。换句话说，应用一旦设置了限流，只要应用不断的发展，静态限流就有可能面临着过期的风险。形成过期隐患和风险的因素主要包括：

一、业务演进/依赖变化引发的不肯定性

业务一直在发展，咱们的应用代码也一直在变化，颇有可能昨天刚刚设置过的限流 QPS，在今天应用一发布，就已经不适用了。就算应用自己不发布，应用自身依赖的后端服务的拓扑不停的变化，也会引起应用可以承受的 QPS 发生变化，带来不肯定性

二、流量模型发生变化引发的不肯定性

应用和服务一般包含多种方法调用，每种方法调用消耗的系统资源都不一样，这要求在对应用压测时的流量模型要足够的合理准确，才能找到有效的限流值，然而业务的流量模型每每也是在不断的变化，这也会为应用的 QPS 评估带来不肯定性。

三、不一样容器实例容量引发的不肯定性

随着运维环境和方法愈来愈复杂，交付给业务的容器，也变得不肯定，如咱们的混部、CPU Sharing 。同时，同一应用的不一样容器，极可能会有不一样的容量，如同一个应用的不一样容器，压出来的基线 QPS 都极可能有很大的差别。底层机器资源的不肯定性，也为应用限流QPS 评估带来了不肯定性

所以，针对应用的限流阈值设置，应用开发就会很纠结：

• 若是设置的限流阈值偏保守（偏低），那么：有的机器资源使用率上不去，浪费机器，形成成本升高问题。
• 若是设置的限流阈值偏乐观（偏高），那么：有的机器尚未达到限流阈值，就会被压垮，形成稳定性问题。

上述的不肯定性，也是咱们在大型活动前，进行封网的缘由之一。

应用柔性架构升级

面对着如此多的不肯定性，咱们但愿咱们的应用自己可以具备一些『柔性』的特征，使得在面对不肯定的场景忽然出现时，应用仍可以承受这些变化，就像太极同样，可以作到以柔克刚。咱们认为，应用架构要作到柔性，至少须要有如下特征（针对应用柔性架构的特征，咱们也在持续的探索中）：

一、故障容忍

• 如使用隔离进行解决。阿里的异地多活单元方案，能够隔离地区出现的问题；微服务化提高了研发效率，同时也隔离了其余独立链路出现的问题；而咱们提出的全异步化解决方案，也增长了上游对下游出问题时的隔离做用。

二、过载保护

• 如使用自适应负载调节进行解决。来应对因为流量容量预估不许而带来的稳定性问题。

为解决上述提到的不肯定性带来的应用过载隐患问题，咱们引入了自适应负载调节来升级应用的过载保护能力，解决应用过载的稳定性隐患。

自适应负载调节

经过自适应负载调节来应对上述不肯定性，使得应用可以就地实时的评估自身负载，让接受的 QPS 与处理能力同步，防止限流评估出错而致使的稳定性问题和资源利用率问题；同时，在应用接收到超高压时，单机压垮的 QPS 可提到更高。从而可以应对更高的突发流量，加固应用自身的稳定性。

整个方案的主要由两部分构成：

一、与应用整合的负反馈组件

• 在应用的入口设置一个负反馈组件，根据应用自身的负载状况，对进入的请求进行针对性的拦截
• 为了适用更多业务，此组件还支持服务权重，优先拒绝权重低的服务，使得在过载时，资源可以尽可能往权重高的服务倾斜。

二、组件自己的快速迭代机制

• 为了让方案自己可以在不一样的场景下有效，咱们从不少不一样的维度展开，组合成多个场景，再经过自动化的场景压测，来快速进行算法在不一样场景下的效果评估和改进，从而提高整个方案的迭代演进速度。

最终，整个方案沉淀了自适应负载调节的自动迭代平台，迭代出基于 CPU 的自动控制算法。

上线案例

淘宝某核心业务的应用，在一次大型活动压测中的效果获得验证：在某个机房的机器数比预期少 22.2% 的状况下，抗住了 130% 的压测流量。按照以往双十一的压测经验，在少这么多机器的状况下，这个机房的应用扛不住如此大的流量。

另外一核心应用，因为担忧不肯定性缘由，静态限流值设置的偏保守，在接入自适应负载调节后，限流值能够进一步提高，使得服务的有效 QPS 提高了 230%，同时应用的压垮 QPS 提高了 3 倍，在压测大流量事后，秒级恢复，迅速提供正常服务（原需 6 分钟+ ）。

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

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

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

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

加入咱们

欢迎加入淘宝基础平台基础服务团队，团队成员大牛云集，有阿里移动中间件的创始人员、Dubbo核心成员、更有一群热爱技术，指望用技术推进业务的小伙伴。

淘宝基础平台基础服务团队，推动淘系（淘宝、天猫等）架构升级（代号Tango），致力于为淘系、整个集团提供基础核心能力、产品与解决方案：

• 业务高可用的解决方案与核心能力（应用高可用：为业务提供自适应的限流、隔离与熔断的柔性高可用解决方案，站点高可用：故障自愈、多机房与异地容灾与快速切流恢复）
• 新一代的业务研发模式FaaS（一站式函数研发Gaia平台）
• 下一代网络协议QUIC实现与落地
• 移动中间件（API网关MTop、接入层AServer、消息/推送、配置中心等等）

原文连接 本文为云栖社区原创内容，未经容许不得转载。