全链路压测(7)：核心链路四问

前言

前面的文章介绍了全链路压测的落地实施全流程，其中有个环节我特别提到了它的重要性，同时这也是本篇文章的主题：核心链路梳理。

那什么是核心链路？为什么要确定核心链路？如何进行核心链路梳理？梳理核心链路的目的又是什么？这篇文章，我会给你答案。

 

什么是核心链路？

之前在一些线下沙龙分享或者线上直播时候，很多同学都会问我一个问题：什么是核心链路？

好像这个词有种魔法，很难让人去理解。这里我试图用自己的理解和一些案例，来让大家理解核心链路。

很多企业都会有自己核心的业务范围，这些核心业务也往往是主要的企业利润来源。

以电商企业为例，为用户提供商品的购买服务，为商家提供商品的管理和上架及定价展示，利润大多为撮合用户和商家交易所来带的服务费以及广告等相关费用。

和上篇文章中提到的确定业务范围的内容相结合，所谓的核心链路，从技术角度来说可以这么理解：

核心业务对应的核心应用中，保证达成企业利润实现的最主要请求流量经过的路径，即是核心链路。

这么说比较拗口，再直白一些就是：哪些接口会影响用户下单支付，哪些就是核心链路。

下面附一个常见的电商企业核心链路流程图，供大家参考。

为什么要确定核心链路？

做测试的同学对这一点很熟悉，无论是需求评审的优先级，还是写测试case时候为开发提供的冒烟case，甚至提交BUG时候对BUG进行优先级划分，都会进行优先级划分，什么原因呢？

因为我们大多数时候面临的情况，是要在有限的时间和人力资源范围内，即保证交付的质量，又要尽可能多的完成更多工作任务和需求。

特别是对于类似电商双11大促这种很复杂的项目，要做的事情太多，时间和人力资源有限，涉及到的业务范围应用范围又很多，这个时候需要做一个取舍。

可能部分未在覆盖范围内的业务和应用会出现一些问题，但如果保障核心业务和应用的稳定性，可以使企业的业务目标更好的达成，那这些损失还是可以接受的。

而且并不是说非核心的业务和应用稳定性我们就不关注了，而是通过其他技术手段如限流、降级、熔断或者业务入口关闭来解决这个问题。

 

如何进行核心链路梳理？

上图是以电商企业订单应用为例子，进行了一个简单的业务调用链路的梳理，这里做一个拆解性的讲解。

1. 确定核心业务范围为交易业务；
2. 确定核心应用其中有订单应用；
3. 订单服务中流量请求占比最高的接口为订单确认、订单创建、订单列表和订单详情；
4. 通过链路追踪的手段确定这四个接口的下游依赖调用都是哪些服务和接口或者中间件；
5. 确定这些下游依赖的关系是强依赖还是弱依赖，以及是否有外部三方服务的调用关系；
6. 强依赖熔断，弱依赖降级，订单服务的接口本身做限流，外部三方服务依赖进行mock；

 

梳理核心链路的目的是什么？

这个时候就要祭出我之前分享时多次使用的一张图了，示意图如下：

梳理核心链路的主要目的，主要有获取流量模型、知道强弱依赖、制定稳定性预案。

流量模型

我在前面的文章《生产全链路压测实施全流程》中有提高转化技术指标的一个案例，这里再次回顾下：

• 客单价为500，单日GMV为10亿，那么支付订单量为10亿/500=200W；
• 假设日常支付订单量为50W，支付转化率为40%，订单支付QPS峰值为200。预估大促时的支付转化率为60%，则可得：大促峰值订单支付QPS为（200/40%）*60%*（200W/50W）=1200QPS。这个1200QPS是个保底数值，一般为了留有一定冗余空间，会上浮30%，即订单支付的QPS预估为1500；
• 电商的导购浏览下单支付转化链路一般为：首页→商品详情→创建订单→订单支付→支付成功，这个过程是类似漏斗的一个转化逻辑。假设首页→商品详情转化率为40%，商品详情→创建订单转化率为40%，创建订单→订单支付转化率为40%，那么可得：创建订单QPS为1500/40%=3750，商品详情QPS为3750/40%=9375，首页QPS为9375/40%=23437；

确定了核心链路的预期流量指标后，可以通过链路间的依赖关系不断的扩大评估范围，直到形成一个流量模型。

流量模型是个类似漏斗状的转化过程，从流量入口到最底层的DB是有不同的转化率的。链路越向下，QPS越低。

通过转化率来评估预期的流量然后通过链路依赖梳理，来形成一个流量模型。

这里需要注意的是，用户日常和大促时候的流量模型是不一样的，因为大促时候用户的目标更明确，因此转化率较高。从业务指标转化为技术指标，需要你对业务很熟悉，不要只盯着技术。

强弱依赖

通过流量模型以及梳理得到强弱依赖关系后，接下来就是根据依赖的关系设定各种稳定性预案了。

这里要注意的一点是，很多的预案需要和业务或者产品做提前沟通，比如主动降级或者业务入口关闭，因为这些降级动作是需要业务方知晓并且配合来操作的，而不仅仅是一个技术上的动作。

稳定性预案

稳定性预案，主要目的是保障线上应用在类似电商双11期间的流量峰值冲击下能保证服务的稳定性，为业务目标的达成提供良好的保障。

稳定性预案也分不同的类型，或者说不同情况下要设定不同的预案，而不是一个通用的东西，需要根据企业的技术设施建设以及技术团队具体的情况来评估。

最常见的稳定性预案就是我们上面提到的限流熔断降级，再高大上点就是容灾恢复、主备切换、业务入口关闭甚至什么断电保护之类的种种。

关于稳定性预案，我会在后面的文章中专门写篇文章，来聊聊如何梳理稳定性预案，以及常见的一些案例。