今天给大家分享一个话题，那就是假设你公司要搞一场双 11 大促，现在告诉你说，咱们公司就是打算搞了，那你此时会一脸懵逼的说，双 11 大促？会有多大并发啊？我们系统能抗住吗？
你要这样的话，那老板是一定不高兴的了。所以今天就得给大家分析一下，假设你公司要搞大促，你怎么去通过全链路压测评估一下你的核心系统链路能抗多大流量？
公司核心系统业务调用链路
首先，如果要为双 11 大促做准备，咱们必须要对线上系统直接发起全链路压测。
比如说在凌晨业务低峰期的时候，我们自己用压测系统对咱们的线上核心链路发起全链路压测，看看到底我们的整个系统可以抗多少流量，然后再分析一下，搞大促的时候，大概会有多少流量，接着就可以针对大促活动的流量预估，去扩容一下机器。
那么如果要搞全链路压测的话，这个全链路压测背后的原理大家知道吗？我们得先给大家讲一下这个全链路压测背后的原理。
先说一个非常典型的链路，假设我们整个平台的入口是业务系统 A，然后他的核心链路里面，他会调依次调用业务系统 B、业务系统 C、业务系统 D，同时还会读写自己的数据库。
然后业务系统 B 又会调用业务系统 E，业务系统 E 又会调用业务系统 F，业务系统 D 又会调用业务系统 G，每个业务系统都会读写自己的数据库。
如下图所示：
看看上面这个链路是不是感觉非常复杂？没错的，对于很多公司的核心系统链路来说，就是可能会有很多个系统调用的链路。
那么这个时候来说的话，我们假设所有业务系统都是单机部署的，现在来看看，整个这个链路集成在一起，大概一秒钟可以跑完多少次这个链路？
QPS 和 TPS 的概念
这里给大家解释一下 QPS 和 TPS 的概念，QPS 是 Query Per Second，往往是针对单个系统自己的接口的，意思就是说自己这个接口每秒被请求多少次，TPS 是 Transaction Per Second，意思就是说每秒钟可以完成的事务数量。
所以这个 QPS 就不太符合我们这里对全链路压测的定位了，因为全链路跑下来，那不是说每秒多少请求可以定义的。
TPS 是比较符合这个定位的，因为我们要看的是每秒钟这个链路跑完，可以跑多少次，跑完一次完整的链路，咱们可以认为一个 TPS，每秒钟可以跑完多少次这个链路，那就是 TPS 了。
一次链路跑完是靠什么跑的呢？
好，那么接着给大家分析，这个一次链路跑完是靠什么跑的呢？
答案显而易见，靠的是咱们链路入口的那个业务系统 A 的一个线程，因为假设业务系统 A 抗的是 http 请求和流量，那么业务系统 A 必然是靠 tomcat 来接收 http 请求的。
然后 tomcat 是会启动多个线程来处理一个一个的请求的，每一个请求进来都会交给一个线程来处理。
大家看下图：
接着呢，这个线程收到了一个请求之后，就会按照调用链路依次去调用，所以说，要走完一个链路，等于业务系统 B、业务系统 E、业务系统 F 这条链路得先走完，然后业务系统 C，接着是业务系统 D 和业务系统 G，再有是自己的数据库访问。
单击全链路压测 TPS 估算
这整个链路跑完大概要花多久呢？这就要看情况了，要看每个业务系统要处理多少时间了，但是这么复杂的链路，往往跑完起码要几百毫秒，我们算他 500ms 吧，基本不多也不少了。
那所以说，此时我们的 tomcat 中一个线程，等于每秒也就跑完两次链路而已。
那如果说业务系统 A 的 tomcat 里开启了 200 个线程呢？那等于是每秒的 TPS 大概也就 200*2=400 而已。
也就是业务系统 A 单台机器在一秒内，200 个线程可以处理 400 个请求，跑完 400 次链路，这就是全链路压测的意义所在，我们要看的是全链路跑完一次要耗费多久，然后在较大压力下，一个线程每秒可以跑完几次链路，再计算单机的 TPS。
进而就可以根据这个单机全链路压测去估算搞大促的时候，每秒要接收多少请求，跑完多少次链路，然后就知道要部署多少台机器了。
