今天想跟大家分享一个话题，就是假设你们公司要搞双11促销，现在我告诉你我们公司打算搞，那你会发呆说、双11大促？会有多少并发？我们的系统能抵抗它吗？如果你要这样做，老板肯定会不高兴的。那么今天就不得不为大家分析一下。假设你的公司要搞大促，如何通过全链路压测评估你的核心系统链路能承受多少流量？公司核心系统业务调用链路先行，如果要为双11大促做准备，必须直接对线上系统发起全链路压力测试。比如在凌晨的业务低峰时段，我们通过压测系统对我们在线的核心链路进行全链路压测，看我们整个系统能承受多少流量，然后进行分析。大促的时候会有多少流量，然后可以预估大促的流量来扩机。那么如果要进行全链路压测，你知道这个全链路压测背后的原理吗？先说一下这个全链路压测的原理。先说一个很典型的环节，假设我们整个平台的入口是业务系统A，那么在它的核心环节，会依次调用业务系统B、业务系统C、业务系统D，并在同时读写自己的数据库。那么业务系统B会调用业务系统E，业务系统E会调用业务系统F，业务系统D会调用业务系统G，每个业务系统都会读写自己的数据库。如下图：上面的链接是不是感觉很复杂？是的，很多公司的核心系统环节，系统调用的环节可能很多。那么这个时候我们假设所有的业务系统都部署在一台机器上。现在我们来看一下，整个链接整合起来，这个链接一秒能跑多少次？QPS和TPS的概念就到这里我给大家解释一下QPS和TPS的概念。QPS即QueryPerSecond，常针对单个系统的接口，即每秒请求该接口的次数。TPS是TransactionPerSecond，意思是每秒钟一个时钟可以完成的事务数。所以这个QPS不太符合我们这里对全链路压测的定位，因为全链路跑下来，不代表可以定义每秒的请求数。TPS比较符合这个定位，因为我们要看的是链接每秒能跑多少次。跑完一个完整的链接后，我们可以把一个TPS想成每秒能跑多少次。此链接是TPS。完成链接的依据是什么？好吧，那我给大家分析一下，这个环节完成的依据是什么？答案很明显，取决于我们链接Thread入口的其中一个业务系统A，因为假设业务系统A是针对http请求和流量的，那么业务系统A必须依赖tomcat来接收http请求。然后tomcat会启动多个线程逐个处理请求，每个请求都会交给一个线程处理。看下图：接下来线程收到请求后，会根据调用链接依次调用。所以，要完成一个环节，等于是业务系统B，业务系统E，业务系统F，必须先完成这个环节，然后是业务系统C，然后是业务系统D，业务系统G，然后是自己的数据库访问。点击全链路压测TPS，预估跑全链路需要多长时间？看情况，每个业务系统处理需要多少时间，但是这么复杂的一个环节，往往跑到最后至少要几百毫秒，我们算他500ms吧，基本不多也不会少。所以，这个时候，我们tomcat中一个线程相当于每秒运行两个链接。那么如果在业务系统A的tomcat中开启200个线程呢？也就是说每秒的TPS大约是200*2=400。即业务系统A单机1秒内可以处理400个请求200个线程，跑400个链接。这就是全链路压力测试的意义。一次需要多长时间，高压下，一个线程每秒可以跑好几个链接，然后计算单机的TPS。然后根据这个单机全链路压测，你可以预估大促期间你每秒会收到多少请求，完成多少链路，你就知道你需要部署多少台机器了。
