基于阿里云产品的全链路评估

什么是全链路评估

在突发流量场景或者是新业务上线的场景，在未来某个特定的日期或者时间点将会有一轮大流量的用户请求的时候，由于没有真实生产环境运行时候的历史信息做参考，就特别需要通过链路评估来对系统承载能力进行评估，从而保证系统的可靠稳定运行。

我们理解的链路评估，是从访问入口开始，对整条链路的所有潜在的瓶颈点，进行全方位的测量，通过改造链路结构和容量配比，达到提升整体链路性能和可靠性的目的。

这里面的链路评估是相对单系统调优来说的，单系统调优重点关注的是在“机器操作”的微观级别上做具体的软件调整用以挖掘硬件的潜能，单系统调优关注的是单系统的瓶颈，解决的是一个点的问题。而我们说的链路评估，希望解决的是一条线上的问题。

整体链路评估的工作通过对活动目标进行需求分析、设计测试方案、设计指标监控方案，来完成对整个系统的链路测试和优化工作。这四个环节是一个不断循环不断迭代的过程，每当活动目标发生变化，业务场景发生变化，指标的测量结果发生变化，都需要给整个环节带来再平衡。

现在“发红包”已经成为除夕之夜上一道必备菜品，每年的春节除夕，支付宝、qq、微博等都会联合众多行业，每个行业一个品牌，每个品牌一段固定的时间，进行红包派发的活动。社交平台借着派发红包提高了平台人气，各大知名品牌，通过社交平台完成向自己的网站的引流，达到了推广自己产品的目的。在整个活动中，社交平台的网民们拼的是手速，而各大知名品牌为了可靠的推广自己的产品，则拼的是自家网站后台的技术架构。接下来，我们以一个真实案例，来分析一下，红包大促这种的高并发场景的促销活动如何进行链路评估。

红包业务背景

首先介绍一下活动背景，金融行业一个互联网公司，准备在春节除夕，利用与一个大型社交平台合作的机会，进行红包派发活动，并向自己的app引流，吸引更多的用户使用自家的app，在自家的app消费，购买产品。

活动期间，社交平台将会在固定的半个小时时段内，为该公司的app开启专属的红包派送通道，用户可在平台的首页通过刷一刷参与活动。到时候，将有上亿用户，在这半个小时的时间内，通过在平台的首页上不停的刷一刷，进入到我们客户自己的红包页面，参与到3000多万个现金或者是代金券的秒杀活动中。

按照客户的活动预期，现有250万的用户规模，希望借着这次红包活动希望能够吸引到500万以上的新注册用户，也即是说，在抢完红包之后，预计会有250多万的既有用户和500多万的新注册用户，涌入客户的手机app，进行红包的查询和消费操作。

红包的业务规模如下图所示。

在如此的业务规模之下，我们面临两大挑战：

1） 第一大挑战，3000多万红包，半个小时，一亿以上的用户来抢，而且是整点准时抢，到时候瞬间峰值会非常有考验；

2） 第二大挑战是，该红包是线上既可以消费，所以抢完红包之后，会紧接着带来线上用户注册和线上消费的峰值，抢红包、登陆注册、线上交易三种高并发写入的场景的峰值重叠在了一起，这更是增加了大促活动线上流量的复杂度；

目标需求分析

了解完活动背景，我们首先进行目标需求分析，目标需求分析包括三部分工作：

首先对业务架构进行梳理，确认整套业务架构都由哪些场景组成，各场景的操作流程是什么样的，哪些是入口场景，哪些是后续的场景，场景之间的交易路径和关联关系是什么？

其次，我们需要对活动目标进行分析，从而预估出每个场景具体的业务峰值。

第三，输出整个系统业务模型，包括所有的场景，及对应的目标峰值。

业务架构梳理

通过和客户的技术人员的调研，我们了解到整体业务架构，包括入口层、服务层、资源层和外部接口层。

入口层指的是发起终端或者调用渠道，该系统的用户的来源是社交平台进行引流，通过手机浏览器在红包系统上抢完红包之后，再下载手机app进行注册登陆并进行一系列消费活动。

服务层提供了具体的应用模块的实现，登陆app之后查询红包列表，然后会选择查询产品列表，查询产品信息，充值，消费红包等等。

资源层则用到了阿里云的rds数据库、redis数据库、oss存储等技术组件。

外部接口包括支付接口、短信网关接口以及红包接口。

将入口层、服务层、资源层、接口层串起来，得出了完整的业务处理流程，从而描绘出了整个业务架构。

业务架构梳理图如下。

业务峰值预估方法

梳理完业务系统，我们需要对整个业务系统的每个场景的峰值进行评估。

对于已上线系统

对于已经上线的系统，我们需要通过该系统的历史大促峰值流量信息对系统的业务规模进行定量的分析，得出大促活动都有哪些场景构成，各场景的占比关系如何，活动目标与入口业务峰值的比例如何。

对于入口业务，也就是说在业务流程上，调用完业务，才可以继续后端的业务流程。需要根据历史日志信息计算出活动目标与业务峰值的比例关系，比如说将具体的活动目标，一般包括在线用户数，新注册用户数，多长时间，达成多大的业务目标，转换成具体的入口业务的峰值目标。

而对于非入口场景，在业务峰值的估算方式上，具体的计算方式可以是考察在历史日志信息中，各个场景占总交量的百分比，进而换算统计这些场景之间的比例关系是怎样的。依据各场景之间的比例转换关系，计算本次大促活动的各场景的峰值。

对于未上线系统

对于没有具体的历史业务信息作为参考的系统，我们同样需要面对两种情况，入口场景和非入口场景。

对于入口场景，我们通用的方式是采用八二原则将活动目标转换成业务峰值。八二原则的定义就是：20%的投入支撑80%的产出。在我们的峰值评估场景里面就是20%的时间支撑了80%的业务量。

对于非入口业务来说，从业务入口进来的流量，在业务不频繁变更的情况下，一定会以一定的比例落到后端的各业务逻辑上。以业务入口峰值作为基准，按照经验值，给出业务入口与后续各业务的比例关系，推算出各业务行为的峰值流量。

业务峰值预估

结合本次具体抢红包业务场景，我们来看下各场景的峰值应该怎么样来预估。在半个小时的活动时间内，我们有三个活动目标，3000万的红包个数、250万的老用户登陆、500万的新增注册用户。对于本次需要评估的系统，抢红包峰值、注册登陆峰值活动都没有历史信息作为依据，所以采用八二原则，根据活动目标预估峰值tps。

非入口的后端的业务链路，参照历史交易信息的比例进行流量转换。考虑到红包场景的特殊性，将某些业务之间的转换率，根据经验，提升到了1:1。

建立业务模型

完成了业务架构的分析，得出了活动涉及到的所有场景；完成了对与活动目标和历史交易信息的分析，我们得出了各场景的业务峰值。于是我们就可以完成业务模型的建立。如表所示，我们看到一共有3个入口业务和10个非入口业务，根据八二原则对3个入口业务的峰值进行了预估，根据历史交易的比例信息，对非入口业务进行了流量的转换。最极端情况下，各种业务峰值重叠在一起，最高峰值tps会达到34.36万

序号	场景类型	场景名称	活动目标或者对应的前端场景	峰值tps(万）
1	入口场景	抢红包	30分钟、3000万+个红包	10.7
2	入口场景	老用户登录	30分钟、老会员250万+	0.8