大咖分享 | PerfMa时晖《流量洪峰下的弹性架构设计》

Posted 2021-06-25 VCEC

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了大咖分享 | PerfMa时晖《流量洪峰下的弹性架构设计》相关的知识，希望对你有一定的参考价值。

本文整理自VCEC共创学院线下沙龙第3期

沙龙主题：大促活动场景下的质量保障

演讲主题：《流量洪峰下的弹性架构设计》

分享嘉宾：时晖

大促场景是对应用系统的终极大考，从性能容量、可用性等方面，对系统设计提出了近乎苛刻的要求。年复一年的大促活动，也在推动着系统架构设计的不断演进。在“流量洪峰下的弹性架构设计”的主题演讲中，PerfMa首席架构师时晖以大促为切入点，探讨高可扩展、高可用架构设计之道。

大促的商业价值VS技术价值

大促的商业价值

大促是人为创造的商业活动规则，它将本来相对均匀分布在一段时间内的购买力，集中到了一天甚至一个特定时刻，制造了一场商家与消费者的联合狂欢。关于大促模式对社会经济是否有促进作用、起了多大程度的作用，尚存不少争议。如今各大电商平台各种名目的大促活动也层出不穷，消费者往往已经陷入审美疲劳。

但无论如何，我国互联网经济正迈入一个空前繁荣的时代，这是不争的事实。大促模式对于激活互联网经济、促进商业社会发展，还是起到了重要的作用的，其社会意义总体上来说是值得肯定的。

大促的技术价值

起初人们往往更聚焦于大促的商业价值，比如“今年双11营业额多少钱”。但客观上业务也在不断驱动着技术的发展。对于技术来说，关注点未必是金额，而更多是交易笔数、TPS这样的技术指标。大促这样的高强度应用场景，成为了考验技术水平的最佳战场，其技术价值至少体现在几个方面：

1、促进架构设计前瞻性

多年以来，双11都是技术的年度大考。根据往年的统计经验，双11当天平稳运行时的流量，基本上会成为未来1~2年的日常运行的流量。这就意味着我们所做的一些技术的架构演进必须有一两年的提前量，促使我们提前考虑未来会面临的技术挑战。避免出现系统已经快要扛不住日常量，才被迫做应变的情况。

2、驱动对技术极限的探索

就像奥林匹克精神对“更高、更快、更强”的孜孜追求，技术人对于技术指标的极限值，也在不断地寻求突破。以支付宝为例，秒级支付峰值从早年的几百、几千笔，在历年业务的蓬勃发展和技术的不断突破下，已经达到了数十万笔，这在全世界范围内都已经是非常领先的记录了。

3、提供以战练兵的机会

在筹备大促活动的时候，从技术架构优化到应急保障措施、团队协同机制，都经历了高强度的考验，提升了整体应急响应水平。这样在日常时候遇到各类突发问题的时候，可以更加游刃有余地处理。

大促秘籍之《九阳神功》篇

打通经脉，消除扩展瓶颈

类比武侠小说中“内功”这个设定，它是一个顶尖高手必须具备的硬实力。对于系统架构设计来说，消除了扩展瓶颈，可以做到只要有足够的资源，就能支撑无限多的业务。当然这只是一个理想情况，现实中没必要也做不到无限扩展。在不断的技术架构优化中，突破各个层面的扩展瓶颈的过程中，就是所谓的“打通经脉”。

1、应用层可扩展

从单体应用架构演进到SOA架构，乃至现在通行的微服务，应用层的可扩展能力是比较容易实现的。只要应用设计成无状态的，就可以随意地水平扩展，用更多的实例承载更多的业务。

2、数据层可扩展

无状态应用层不断水平扩展，瓶颈最终会体现在数据层上。数据层是有状态的，无法像应用层那样简单扩容。这就是我们要打通的下一层经脉。

数据层扩展通常有以下几个思路：

1）垂直拆分

根据不同的业务，将数据拆分到不同的数据库，减少单个库的压力。此方案最容易实现，但能拆的粒度是跟业务相关的，效果有上限。

2）读写分离

对于读多写少，并且读操作不要求强一致性的场景，适合采用读写分离的思路。可以用多个只读副本乃至缓存来承载大量读请求。电商业务中，很多场景都符合此要求。

3）水平分片

通过选取特定字段，作为分库分表的依据，实现数据的水平分片。水平分片的方案，要求不同分片的数据尽量无关联，也要尽量避免跨分片的全局查询。订单类数据通常符合此要求。

3、机房级可扩展

随着业务量的进一步增加，单个机房的容量也可能成为制约系统能力的瓶颈。于是就出现了同城双活、同城多活，甚至异地多活这样的架构。

在异地多活场景下，应用到数据的跨地访问耗时将无法忽略。所以诞生了单元化架构，从应用到数据的访问链路都收敛在同一个逻辑单元内，避免了跨地数据访问。逻辑单元可以部署到分布在全国各地的物理机房内，实现异地多活，突破地域级瓶颈，也可以实现异地容灾。

大促秘籍之《乾坤大挪移》篇

削峰填谷，弃卒保车，优化资源利用

在具备了架构可扩展的深厚“内力”之后，理论上就可以靠堆资源来满足业务需求。但实际上，整个大促期间的流量并不是均匀的。根据业务规则的设计，在某些特定的时间点（如0点、1点），业务峰值会远超过大促当日平时流量。如果全部按照高峰时刻的指标来准备系统资源，其成本将非常高昂，不是一个经济的选择。

我们可以采取一些削峰填谷的方式来分摊高峰压力，还可以在特定时段暂停非关键功能，将资源省给关键业务。这样，就可以用有限的成本支撑业务高峰。这种依靠内部资源的优化调配，来以尽量小的成本达成业务目标的思想，可以类比为“乾坤大挪移”。

1、削峰填谷

整体思想上是利用队列来蓄洪，以稳定的速率向下游释放压力，以消化流量洪峰的冲击。这里的队列是广义的，既可以是消息队列中间件，也可以是内存中的队列数据结构。

支付宝开发了一个高性能的内存队列中间件zqueue。平时收银台调用支付核心，是同步RPC；在大促高峰期，可以切换成zqueue，具备了缓冲能力，同时通过异步转同步机制又能基本保证用户体验。

2、弃卒保车

在2010年双11，支付宝经历过惊魂一刻，最核心的账务库告急，就快顶不住了。时任CTO程立当机立断决策杀掉会计系统（内部对账的系统，会连接账户库）的所有服务器，释放账务库的资源给账务系统，保障付款业务的正常进行。这个决策力挽狂澜，保障了当年双11的成功。

随着大促保障方法论的逐渐成熟，这种惊险场面一去不返。一些降级措施已经纳入常规计划，例如：暂停或延后大促当天凌晨的跑批任务；关闭内部管理系统的批量查询功能；隐藏确认收货/退款功能入口，暂停自动确认收货，节省交易系统资源；提前关闭商家编辑商品详情的功能，做详情页静态化；分布式事务启用“第二阶段异步化”……

大促秘籍之《独孤九剑》篇

充分预演，见招破招

在武侠小说中，独孤九剑针对敌方的不同招式，运用不同的破法，依靠包罗万象的应敌预案，做到料敌先机，一切皆可破。类比到大促中，就是一套严谨的保障体系，从容量评估/流量保护，到突发情况的应急预案，都是需要事先设计考虑到，并通过不断的压测和演练来强化，将不确定性变为确定性。

生产全链路压测技术，自从2014年在阿里诞生以来，已经成为稳定性保障的神器，并被业界广泛学习。有了全链路压测、限流保护、应急响应预案的加持，大促活动稳定性保障，从一开始的小心翼翼如履薄冰，发展到了如今的“丝般顺滑”“喝着咖啡过大促”。

稳定性保障手段中，降级和限流是两种最常用的。它们的思想上有一定的相通之处，都是牺牲一部分利益，让整体收益最大化。又有一定的区别：降级是给每个用户都提供次优的服务，来保障尽量多的用户能得到服务；限流是停止给一部分客户服务，而保障给另一部分用户提供优质的服务。这两种思想各有各的适用场景，需要根据业务的实际情况来使用。