“官宣”下新浪微博崩溃的架构测试
上一篇 / 下一篇 2018-10-19 09:48:35 / 个人分类：软件测试
如果说昨天什么最火，估计就是“官宣”了吧，赵丽颖结婚据说某新浪微博甚至还瘫痪了一阵子。
传说上次有人说微博内部调整，现在已经支持八个明星同时出轨并发，那么昨天的事情还真是叫人尴尬。
吐槽新浪
并发对于开发初学者可能觉得没什么确实感觉，毕竟自己做ORM单应用项目的时候遇到的并发量就是自己，撑死了也就是十几个人的并发数。所以很多初学者对于并发崩溃并没有个概念，所以今天我们就来讨论一下各个架构可以承受的并发量是多少。
目前比较常用的架构包括但不限于ORM,MVC,RPC,SOA等和架构详情，如下图
缺点：不方便维护，代码分层不明显，代码越多越难维护，开发的时候我和上帝知道，现在估计只有上帝知道了。
垂直应用架构：将应用拆成互不相干的几个应用，这样可以承受的并发有所增加，而加速前端页面开发的Web框架是关键。（这里涉及到两个面：一个是将应用按照功能模块拆分并独立部署，另外一个是代码结构上的分层，以SSM为例，分为视图层、action层、service层、dao层，各层之间通过接口之间耦合起来，jsp调用action，action调用service,service调用dao）
缺点：代码难以复用，独立的模块相当于一个独立的应用。
分布式服务架构：当垂直应用越来越多，这个时候我们管理起来很麻烦，不仅如此应用间复杂的交互更会让我们手足无措，这个时候我们可以考虑将核心模块抽取出来作为服务中心，让前端应用快速响应市场需求，这个时候，用来提高业务复用和整合应用的分布式框架（RPC）是关键。
缺点：实际开发中发现有点难，其次网络存在问题的时候远程调用可能较慢，增加服务器资源当并发量降低之后容易造成资源浪费，但相对于dubbo曾经扛起了阿里巴巴帝国就已经可以看出多强悍了，不过还是上一张图对比常用的RPC框架
流动计算架构：当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。
下图是新浪核心业务图，我们有理由相信新浪使用的是流动计算架构这个我不太确定，请大神纠正。
#-*-coding:utf-8-*- importrequests importthreading importtime classpostrequests(): def__init__(self): self.url='请求的url' defpost(self): try: r=requests.post(self.url,files=self.files) print(r.text) exceptExceptionase: print(e) deflogin(): login=postrequests() returnlogin.post() #if__name__=='__main__': #login() try: i=0 #这里是线程数 tasks_number=150 print('测试启动') time1=time.clock() whilei<tasks_number: t=threading.Thread(target=login) t.start() i+=1 time2=time.clock() times=time2-time1 print(times/tasks_number) exceptExceptionase: print(e) |
以下是框架并发测试过程和内容
测试对象：单应用
测试对象搭建：首先是单应用，简单的sql查询，开发一个简单的API接口，代码不贴。
首先使用7个线程同时执行7个请求，请求时间超过7秒就算测试失败，代码如下：
| @Test(threadPoolSize=7,invocationCount=7,timeOut=7000) |
结果：通过没有报错没有超时。
把所有参数翻了一番之后
| @Test(threadPoolSize=14,invocationCount=14,timeOut=7000) |
结果：开始出现异常，请求时间出现测试失败的。
测试对象：SSM
使用技术：JAVA的TestNg和Python的selenium
测试对象搭建：MVC，简单的sql查询，简单的API接口，代码不贴。
首先使用14个线程执行14次，请求时间超过5秒就算测试失败，代码如下：
| @Test(threadPoolSize=14,invocationCount=14,timeOut=5000) |
结果：通过没有报错没有超时。
把所有参数提升
| @Test(threadPoolSize=180,invocationCount=1800,timeOut=5000) |
结果：请求明显变慢，有些测试开始失败超时，但是并没出现异常。
继续增加参数值
| @Test(threadPoolSize=2000,invocationCount=8000,timeOut=5000) |
结果：请求明显变慢，开始失败超时，并出现异常。
注：这里有人会说可以使用redis缓存来提高数据库速度，我这里也配置了redis进行测试在@Test(threadPoolSize=2800,invocationCount=28000,timeOut=4000)出现异常和超时请求
测试对象：dubbo
使用技术：JAVA的TestNg和Python的selenium
测试对象搭建：dubbo分布式集群，使用三台服务器做集群分布，权重一致，使用redis缓存+mysql数据库技术。
首先使用2000个线程执行18000次，请求时间超过4秒就算测试失败，代码如下：
| @Test(threadPoolSize=2000,invocationCount=18000,timeOut=4000) |
结果：执行了很长时间，但是并没出现超时和异常。
把所有参数翻了一番之后
| @Test(threadPoolSize=4000,invocationCount=24000,timeOut=4000) |
结果：还是没有出现异常，也没有出现超时
继续提升参数值
| @Test(threadPoolSize=20000,invocationCount=200000,timeOut=4000) |
结果还是没报错
于是修改策略，并发请求*5台电脑
| @Test(threadPoolSize=40000,invocationCount=200000,timeOut=4000) |
结果：终于出现异常和超时请求，当然这还是三台服务器，相信更多的资源可以有更好的体验。
备注：由于测试对象的业务逻辑比较简单，当然，如果测试对像业务逻辑复杂可能会出现误差，以大神你们的为准。
第四个臣妾只能说我做不到，首先增加资源吃力，其次我以为测试用例只需要增加计算器线程数，同时增加并发请求，但是后来发现这样的请求并没办法模拟出那么恐怖的并发量。这个希望技术提升后来继续操作，毕竟对高并发这块兴趣还是蛮大的。今后有可能会继续模拟环境，当然大神也可以补充改正我。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8052)，我们将立即处理。
TAG: