“官宣”下新浪微博崩溃的架构测试

Python 212 2018-10-24 16:57
“官宣”下新浪微博崩溃的架构测试-JEESNS

如果说昨天什么最火,估计就是“官宣”了吧,赵丽颖结婚据说某新浪微博甚至还瘫痪了一阵子。
传说上次有人说微博内部调整,现在已经支持八个明星同时出轨并发,那么昨天的事情还真是叫人尴尬。


“官宣”下新浪微博崩溃的架构测试-JEESNS

并发对于开发初学者可能觉得没什么确实感觉,毕竟自己做ORM单应用项目的时候遇到的并发量就是自己,撑死了也就是十几个人的并发数。所以很多初学者对于并发崩溃并没有个概念,所以今天我们就来讨论一下各个架构可以承受的并发量是多少。
目前比较常用的架构包括但不限于ORM,MVC,RPC,SOA等和架构详情,如下图


“官宣”下新浪微博崩溃的架构测试-JEESNS

单一应用架构:将所有功能都部署在一起减少成本和节点,这样的框架适合流量较小的网站,只需要一个应用,而简化数据库访问的增删改查是关键。
缺点:不方便维护,代码分层不明显,代码越多越难维护,开发的时候我和上帝知道,现在估计只有上帝知道了。
垂直应用架构:将应用拆成互不相干的几个应用,这样可以承受的并发有所增加,而加速前端页面开发的Web框架是关键。(这里涉及到两个面:一个是将应用按照功能模块拆分并独立部署,另外一个是代码结构上的分层,以SSM为例,分为视图层、action层、service层、dao层,各层之间通过接口之间耦合起来,jsp调用action,action调用service,service调用dao)
缺点:代码难以复用,独立的模块相当于一个独立的应用。
分布式服务架构:当垂直应用越来越多,这个时候我们管理起来很麻烦,不仅如此应用间复杂的交互更会让我们手足无措,这个时候我们可以考虑将核心模块抽取出来作为服务中心,让前端应用快速响应市场需求,这个时候,用来提高业务复用和整合应用的分布式框架(RPC)是关键。

缺点:实际开发中发现有点难,其次网络存在问题的时候远程调用可能较慢,增加服务器资源当并发量降低之后容易造成资源浪费,但相对于dubbo曾经扛起了阿里巴巴帝国就已经可以看出多强悍了,不过还是上一张图对比常用的RPC框架
“官宣”下新浪微博崩溃的架构测试-JEESNS

流动计算架构:当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的资源调度和治理中心(SOA)是关键。
下图是新浪核心业务图,我们有理由相信新浪使用的是流动计算架构这个我不太确定,请大神纠正。
“官宣”下新浪微博崩溃的架构测试-JEESNS

好,罗列清楚,有概念了我们就做简单的并发测试

贴一下Python的selenium代码:

# -*- coding: utf-8 -*-
    import requests
    import threading
    import time
    class postrequests():
        def __init__(self):
            self.url = '请求的url'
            
        def post(self):
            try:
                r = requests.post(self.url,files=self.files)
                print(r.text)
            except Exception as e:
                print(e)

    def login():
        login = postrequests()
        return login.post()
    # if __name__ == '__main__':
    #     login()
    try:
        i = 0
        # 这里是线程数
        tasks_number = 150
        print('测试启动')
        time1 = time.clock()
        while i < tasks_number:
            t = threading.Thread(target=login)
            t.start()
            i +=1
        time2 = time.clock()
        times = time2 - time1
        print(times/tasks_number)
    except Exception as e:
        print(e)

以下是框架并发测试过程和内容


测试对象:单应用

使用技术:JAVA的TestNg和Python的selenium
测试对象搭建:首先是单应用,简单的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)

结果:终于出现异常和超时请求,当然这还是三台服务器,相信更多的资源可以有更好的体验。
备注:由于测试对象的业务逻辑比较简单,当然,如果测试对像业务逻辑复杂可能会出现误差,以大神你们的为准。

第四个臣妾只能说我做不到,首先增加资源吃力,其次我以为测试用例只需要增加计算器线程数,同时增加并发请求,但是后来发现这样的请求并没办法模拟出那么恐怖的并发量。这个希望技术提升后来继续操作,毕竟对高并发这块兴趣还是蛮大的。今后有可能会继续模拟环境,当然大神也可以补充改正我。

写这篇文章的感觉大概就是我写了一年多的ssm都不知道他能承受多少并发,但是我对它原理很了解,我相信很多人也是这样,所以我觉得有必要给大家一个实际的参考,让大家更了解自己正在使用的架构。

文章评论