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