如果说昨天什么最火，估计就是“官宣”了吧，赵丽颖结婚据说某新浪微博甚至还瘫痪了一阵子。

传说上次有人说微博内部调整，现在已经支持八个明星同时出轨并发，那么昨天的事情还真是叫人尴尬。

吐槽新浪

并发对于开发初学者可能觉得没什么确实感觉，毕竟自己做ORM单应用项目的时候遇到的并发量就是自己，撑死了也就是十几个人的并发数。所以很多初学者对于并发崩溃并没有个概念，所以今天我们就来讨论一下各个架构可以承受的并发量是多少。

目前比较常用的架构包括但不限于ORM,MVC,RPC,SOA等和架构详情，如下图

单一应用架构：将所有功能都部署在一起减少成本和节点，这样的框架适合流量较小的网站，只需要一个应用，而简化数据库访问的增删改查是关键。

缺点：不方便维护，代码分层不明显，代码越多越难维护，开发的时候我和上帝知道，现在估计只有上帝知道了。

垂直应用架构：将应用拆成互不相干的几个应用，这样可以承受的并发有所增加，而加速前端页面开发的Web框架是关键。(这里涉及到两个面：一个是将应用按照功能模块拆分并独立部署，另外一个是代码结构上的分层，以SSM为例，分为视图层、action层、service层、dao层，各层之间通过接口之间耦合起来，jsp调用action，action调用service,service调用dao)

缺点：代码难以复用，独立的模块相当于一个独立的应用。

分布式服务架构：当垂直应用越来越多，这个时候我们管理起来很麻烦，不仅如此应用间复杂的交互更会让我们手足无措，这个时候我们可以考虑将核心模块抽取出来作为服务中心，让前端应用快速响应市场需求，这个时候，用来提高业务复用和整合应用的分布式框架(RPC)是关键。

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

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

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

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

贴一下Python的selenium代码：

#-*-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

t=threading.Thread(target=login)

t.start()

i+=1

time2=time.clock()

times=time2-time1

print(times/tasks_number)

exceptExceptionase:

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

上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。