赵小姐姐
如果说昨天什么最火，估计就是“官宣”了吧，赵丽颖结婚据说某新浪微博甚至还瘫痪了一阵子。
传说上次有人说微博内部调整，现在已经支持八个明星同时出轨并发，那么昨天的事情还真是叫人尴尬。
吐槽新浪
并发对于开发初学者可能觉得没什么确实感觉，毕竟自己做ORM单应用项目的时候遇到的并发量就是自己，撑死了也就是十几个人的并发数。所以很多初学者对于并发崩溃并没有个概念，所以今天我们就来讨论一下各个架构可以承受的并发量是多少。
目前比较常用的架构包括但不限于ORM,MVC,RPC,SOA等和架构详情，如下图
image.png
单一应用架构：将所有功能都部署在一起减少成本和节点，这样的框架适合流量较小的网站，只需要一个应用，而简化数据库访问的增删改查是关键。
缺点：不方便维护，代码分层不明显，代码越多越难维护，开发的时候我和上帝知道，现在估计只有上帝知道了。
垂直应用架构：将应用拆成互不相干的几个应用，这样可以承受的并发有所增加，而加速前端页面开发的Web框架是关键。（这里涉及到两个面：一个是将应用按照功能模块拆分并独立部署，另外一个是代码结构上的分层，以SSM为例，分为视图层、action层、service层、dao层，各层之间通过接口之间耦合起来，jsp调用action，action调用service,service调用dao）
缺点：代码难以复用，独立的模块相当于一个独立的应用。
分布式服务架构：当垂直应用越来越多，这个时候我们管理起来很麻烦，不仅如此应用间复杂的交互更会让我们手足无措，这个时候我们可以考虑将核心模块抽取出来作为服务中心，让前端应用快速响应市场需求，这个时候，用来提高业务复用和整合应用的分布式框架（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都不知道他能承受多少并发，但是我对它原理很了解，我相信很多人也是这样，所以我觉得有必要给大家一个实际的参考，让大家更了解自己正在使用的架构。
网友评论