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

2019年5月14日 196次阅读 来源: 杨章隐

《“官宣”下新浪微博崩溃的架构测试》 赵小姐姐

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

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

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

《“官宣”下新浪微博崩溃的架构测试》 image.png

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

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

流动计算架构：当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

下图是新浪核心业务图，我们有理由相信新浪使用的是流动计算架构这个我不太确定，请大神纠正。

《“官宣”下新浪微博崩溃的架构测试》 image.png

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

贴一下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都不知道他能承受多少并发，但是我对它原理很了解，我相信很多人也是这样，所以我觉得有必要给大家一个实际的参考，让大家更了解自己正在使用的架构。

    原文作者：杨章隐
    原文地址: https://www.jianshu.com/p/7146eaecacbb
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞