刘国强,云智慧技术中心(Technical Center)副总裁。

在加入云智慧之前，他拥有超过18年的IT行业研发、IT管理、服务器和桌面虚拟架构、数据库和云计算、企业级方案的经验。历任CA大中华区CTO，售前技术总监。Citrix中国区首席专家顾问，虚拟化系统工程师。

本文根据TOP100Summit旗下技术沙龙品牌 into100 在上海 COCO SPACE举办的第17期沙龙录音整理原创首发，转载或节选内容前需获授权。

互联网时代的倒逼

现在我们处于一个互联网的时代。现在所有的日常的衣食住行都依赖于软件，大家可以想想，从出门到工作到日常购物，你基本上不用出门：你可以订快餐给你送上门；买东西可以通过京东给你送上门；你要买东西，比如说买玩具在网上买，第二天就送到了；我订机票也是通过网络来定；我去旅游也是通过网上来订。这个时候软件应用度越来越高，软件的价值也越来越大。在这样的情况下，我们的企业包括我们的从业人员如何应对呢？这是一些简单的数字分享。

移动支付，我昨天专门查了一下，5108亿这是2015年第二季度的数字。那么软件的可靠性、可用性、性能就变得非常重要。在这样的大背景之下，其实软件的发布速度是快的令人惊讶，我们做了一个调查。

94%的应用程序发布的速度前所未有的快。大家简单来看，以我们自己为例，我们的产品是SaaS产品，我们的产品每周都会发布新的版本。在这样的情况下，我们做商业化，基本上互联网产品是按周去发布的，其他的App也是，更新速度非常快。在这样的情况下，因为你的版本更新速度非常快，用户是不是就可以容忍你的系统崩溃呢？是不是你的应用速度很慢，用户也会体谅你也觉得你挺好？

其实用户对软件的要求没有降低，这就要求我们必须得快还不能提供差的服务。如果说你的应用程序延迟超过3秒，25%的用户就会离你而去。大家可以想想你平时写的程序是不是超过3秒，如果说超过的话大家最好想办法进行修改。

高并发关键点

在这样的大背景下如何做到高并发？

其实我总结了一下，高并发的关键点在哪里？平时我们都做压力测试，各位有很多做高并发的经验，这种压力测试的关键点很多是以内部测试为主，在试验里去压测。但是有几个问题没有注意到：

1. 你是不是真实的生产环境，是否测试到应用外网带宽；

2. 是否测试到CDN，CDN有没有发挥作用；

3. 不知道防火墙是不是配置得当；

4. 负载均衡器是不是配置合理；

不要在「温室」里做压测

大家觉得这些事情压力测试都可以做到，其实未必，现在的压测更多是在一个「温室」的环境，是一个「温室」的高并发。一开始我叫「实验室」高并发，我觉得「实验室」这个词不足以引起重视，因此我用了「温室」这个词。大家知道温室的花朵出了温室很可能就活不下来了，压力测试也是如此，如果说你的测试是在温室的话，你出事的概率就非常高。

那么在温室和真实环境到底有什么差异？

左边是真实的情况，我们希望做以下几个方面。

1. 真实、准确有弹性。你要确保你的用户是真实发起的用户；

2. 网络是用户真正的网络；

3. 能不能准确定位问题；

4. 线上性能实时检测；

5. 随时随地发起；

这就是我们不要做「温室」的高并发。

其实我们做高并发我们建议做到几点：

1. 速度。你必须要考虑到你的速度，要能很快的去做，而不是说我要去申请，要预算，找领导去批复，可能是用了三个月。我们希望可以做到随时随地，或者是三个小时，或者是一天就可以发起。这是速度。

2. 规模。你可以想像一下，你是300万并发可能需要上千台的服务器，这个服务器是自己购买还是怎么做。现在比较好的是可以利用云资源。

3. 高性价比。如果说你的成本非常高，公司可能就不会做了，领导会有非常大的顾虑。如果说你可以做到速度、规模和高性价比，那么你就成功了。

   
   

如何设计压测方案

1. 做并发要找到合适的交易，你不要去编写程序，最好的方法是直接录制交易。比如说我们最近做的一个案例。用户就用手机端，用户操作一遍，后我们把它录下来。录下来之后我把它变成数据，这样就变得很简单，你只需要录制就可以，不需要自己写程序。
   
   
   

2. 定义测试任务，我什么时候发起，我发起的策略是什么？比如说我刚刚发起是300并发，什么时候加到500，什么时候加到1000，什么时候加到2000或者是3000。
   因此你要设置压力曲线，你要做一个压力曲线设置，在什么时间点上加，能不能加到你想要的高度。我们不希望写一个脚本写了三五天时间，这个效率就太低了。最好是操作一遍录下来，然后准备数据，准备数据是需要时间的，这个要看你准备的时间。
   
   
   

3. 选择你的压测点。以前做法效率是很低的，那么能不能做到我就选阿里的，从华北、华东、华南三个地方发起。
   
   
   

4. 压力测试之后，随时随地查看。我们建议的做法是什么呢？压测同时直接看当时的曲线数据情况。你实时加压，实时看数据情况。看你发的多少数据，接收了多少数据，有多少的请求发起，你的数据库的状态如何，有没有错误，错误率是多少等等这些都要在你实时监测的页面可以看到，进行实时的数据分析。
   
   
   

5. 需要实时的监控大屏，尤其是电商的大促，不仅是监控交易量，你还要关注交易量背后资源的消耗量。这个实时监控的大屏大家看几个数字：1）总事务数；2）每分钟的事务数；3）成功/失败的事务数；4）错误的事务数；5）发送/接收的流量；6）当时的虚拟用户数。
   
   

   
   

业务系统拓扑

接下来是业务系统拓扑。我们一方面希望看到高并发，另一方面发起高并发之后我们应用程序内部的架构情况。大家可以想像一下。现在用java写，或者是用JS写，都是要用程序写，写出来之后，你一般看到的是使用资源的消耗量，那么你能不能知道你现在系统的整体的动态的应用拓扑架构。你要看到动态架构的实时生成，我们压测的同时，业务系统的拓扑可以呈现出来。

业务系统的拓扑我们在图上用各种颜色标注这个机器或者是系统的负载是什么样的。绿色的代表他上面的所有业务请求都在500毫秒以内，这个机器的负载是可以的。如果说是黄色的，这个机器的负载在500到2000毫秒之间。而如果说是红色的，则是大于2秒的。

接下来我们看一下应用请求概览，这是一个手机银行的例子。我们看到他正常的是多少，缓慢的是多少，非常慢的是多少。我们看到缓慢的事务分析。这个图有三个维度：第一个维度是底下的时间，整个高并发发起的时间点，比如说早上8点到中午12点。最左边是响应时间，最右边是并发的次数。这个请求次数是多少，响应时间多少，在什么时间点发起。你也知道在高并发起来的时候会不会有突然的发起下降。你通过黄色和绿色的柱状图可以看到每一个请求的时间点。

我同时会列出每一个缓慢请求的拓扑图。告诉你，你现在压侧的每一个请求的情况，比如说可能是5秒，在这个5秒的时间里，到底这个请求是怎么走的，我会把拓扑图画出来。

我们可以看到系统后端事务的追踪。

同时我们可以发起深入代码级的问题诊断。如果说你的速度非常慢，我们会提供代码级的性能优化参考。

这是应用请求拓扑。

代码的详细诊断。我们可以看到整个代码的详情，到每一个请求的参数，他的SQL语句。前端有高并发，后端有应用数据的抓取。

这是数据库的，如果说你有大量的数据库，如何进行所有数据库的SQL分析，应用的SQL响应时间我们会在这里列出。

同时如果一般做压力测试的，如果系统出现崩溃或者是异常，大多数人是看日志，及时也可以从另外一个角度去看到底有没有错误信息，你在高并发过程当中，所有应用程序内部有没有出错，有多少次，什么样的错误，我们会把这些错误记录下来，你可以查看你的错误列表。

后面同时还有一个异常的列表。大家写程序的人都知道，你有一个请求，后面可能会有异常处理。那么这个异常是什么在什么时候，什么时间点发生的，可以通过程序来发起抓取。

后台主机的性能也是一样的，包括主机的列表，监控、服务的列表。

然后是JVM性能分析报告你可以看到JVM线程，JVM内存使用统计，包括GC垃圾回收统计。

真实压测案例看300VU-3000VU

我前面讲了两个部分。接下来我们举一个案例，一个测试场景。这个测试场景我们是从300并发开始，基本上每隔5分钟左右加一次，加到500，加到1000最后是加到3000并发。我们看到左边是用户数，上面是用户所有请求平均响应时间，随着虚拟用户数增加，响应时间会增加。到3000并发的时候变成了427毫秒，服务器处理能力一直没有太大变化，带宽也变化不大；到两三千并发的时候有一些错误。简单来看，服务器的处理能力不够了，他就能处理这么多，你增加的再多，只是增加了响应的时间。这是我们的一个总体的结论。

那么我们详细分析一下这个测试场景下我们分析的问题。

我们分析下来，首先是响应时间过长的请求，我们看到响应时间过长的超过了3秒。

第二个结论是什么呢？我们发现在这个请求过程当中有一些重复请求。就是一模一样的事情重复了两次，我们看到这当中有两次，我们用红色标注出来。有一个是四次，这是消耗的带宽，拉长了你的响应时间，影响了性能。

我们把所有的事务列了出来，这是每一个事务的响应时间，我们做了两个端，一个是IOS，一个是安卓，我们模拟两种App同时做起并发。我们可以看到300、500、1000、2000、3000一直到4000的并发情况。第一个是打开App，你会发现时间逐步增加，从1058到3386毫秒。第二个是登陆系统，我们可以看到从2000毫秒一直到13秒，这个差异是非常大的。

我们再看一看分指标的解读。在300并发的情况下，当时我们在执行到两分钟的时候截了一张图。错误数为0，然后是消耗带宽的情况，服务器处理能力每分钟2400笔。

我们再看一下300并发的平均时间，我们是从北京和广州两个地方发起的。我们看到北京和广州稍微有一些差异，一个绿色，一个蓝色，北京的响应时间比较长，广州的响应时间比较短。我们看到虚拟用户数和平均相应时间的关系。

第三个是和错误的关系，和带宽的关系。我们再看300并发的情况下，我所有的交易请求的情况。这当中我标了一个数字，就是90%，我压到300并发，90%的情况下，交易时间响应是多少。简单来看打开IOS的时间这里面是2s，在90%的时间，在300并发的情况下，打开时间是2s。我们再看一下500并发，500并发的时候，服务器的处理能力没有太大的变化，就是每秒2400笔，变化不大，出现了错误，我们看到总共发的请求带宽消耗。

这张图可以看到300和500并发的关系，先看最左边的图，蓝色和绿色就是300和500并发下两个地方的差异。再看并发数的响应时间对应关系，你会发现在300并发的时候，响应时间是非常快的，但是到500的时候，突然响应时间就上去了，机器的负载响应的比较慢。我们看到响应时间500并发的时候达到3秒左右了，刚刚是2秒。带宽上有所增加，但是没有太大的本质上的变化。

而在1000并发的时候，有发生了巨大的变化，错误数达到了15个，服务器的处理能力还是2400笔左右，没有太大变化。我测过几个不同的案例，有的用户是带宽不够，有的用户是机器的负载不够，有的用户是负载均衡器不行，他经常是一个机器响应，其他的机器没有响应。我们发现从300到500到1000，响应时间不断地增加。这表明要么是程序算法有问题，要么是服务器负载出现了状况。

我们来看1000并发，从300到500到1000响应时间突然就上去了，变化很大。这是1000并发下到了5秒，刚刚是2秒、3秒，现在是5秒，带宽和刚刚没有太大变化。

再看2000并发的情况。响应时间发生变化，错误数达到20个，服务器处理能力还是每秒2400笔左右，平均请求响应时间达到了250毫秒。我们看到响应时间增加，错误数增加。

到2000并发时响应时间达到了6秒，带宽为30M，稍微增加了一些。

到3000并发时，我们发现服务器处理能力变化不大，带宽消耗基本上还是在30M左右，带宽变化不大。响应时间变成7秒，所以你会发现，响应时间不断地增加。我们看到1000、2000、3000并发时带宽都是30M，错误数达到了20个。

压测后的分析

简单来说这是一个场景，我简单分析一下这个场景发现的问题：

1. 在混合场景当中出现了重复和多余的请求。有一些请求，用户一看这个请求不应该发生的，不应该有这样的请求在这个时候发生，这个请求是多余和重复的；

2. 随着用户数增加，平均响应时间增加，服务器的负载没有增加，等待时间增加；

3. 当时我们只是进行了一个普通的监控，看了CPU和内存的情况，当时没有做服务器里面细致的检控，我们建议应该有更多的后端代码的监控；

4. 服务器配置有问题，要验证一下负载均衡器是不是有合理的转化。另外我们也建议做常态化测试，就是定期的，每个月或者是每周做一个常规的测试，而不是很长时间做一次。

5. 我们发现活动首页有问题，缓存比较少，这是一个问题。

这是我给大家分享的内容。我简单汇总一下：第一、高并发不要做温室的发起；第二、在发起同时要看到当时代码的情况，SQL的执行情况；第三、整个压测的过程和解决问题的方法论。