架构层面高并发解决方案选择----项目架构模式选择

Web项目，尤其是面向C端的项目，做到中后期往往要解决高并发的问题。本文通过对三种架构的并发性能分析，为这一阶段的开发和重构提供参考。

基本概念

并发：在操作系统中，是指一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理机上运行，但任一个时刻点上只有一个程序在处理机上运行。

并发访问：同一时间对系统的访问。

QPS：每秒请求数。平常所谓的高并发是指QPS值。

 PV：综合浏览量（PageView），即页面浏览量或者点击量，一个访客在24小时内访问的页面数量。

UV：独立访客（UniqueVisitor），即一定时间范围内相同访客多次访问网站，只计算为1个独立访客。

系统容量预估

预估步骤：

（1）       注册用户数-日均UV量-每日的PV量-每天的并发量；

（2）       峰值预估：平常量的2~3倍；

（3）       根据并发量（并发，事务数），存储容量计算系统容量。

 

项目需求：3~5年用户数达到1000万注册用户；

 

每秒并发数预估：

（1）       每天的UV为200万（二八原则）；

（2）       每日每天点击浏览30次；

（3）       PV量：200*30=6000万；

（4）       集中访问量：24*0.2=4.8小时会有6000万*0.8=4800万（二八原则）；

（5）       每分并发量：4.8*60=288分钟，每分钟访问4800/288=16.7万（约等于）；

（6）       每秒并发量：16.7万/60=2780（约等于）；

（7）       假设：高峰期为平常值的三倍，则每秒的并发数可以达到8340次。

（8）       1毫秒=1.3次访问；

结论：按一台web服务器，支持每秒1000个并发访问计算。平常需要3台服务器， 高峰期需要9台服务器（不过多考虑硬件和网络条件）。

 

几种Web系统架构模式

(一)       单体式架构

打包、部署后，运行在同一台服务器的同一进程中，功能、代码和数据集中，这样的应用称为单体式架构应用。

单体式架构应用，应从代码以及数据库层面提升并发性能。

 

(二)         集群架构

计算机集群简称”集群”，是一种计算机系统，它通过一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。在某种意义上，他们可以被看作是一台计算机。集群系统中的单个计算机通常称为节点，通常通过局域网连接，但也有其它的可能连接方式。集群计算机通常用来改进单个计算机的计算速度和/或可靠性。一般情况下集群计算机比单个计算机，工作站或超级计算机性能价格比要高得多。

为了提高性能，当单体式架构应用达到当前服务器硬件极限时，应考虑增加服务器的方式，也就是构建服务器和数据库集群，来提升并发性能。这种架构，在原有的单体式架构基础上增加负载均衡层，将原有的代码部署在多台服务器上，通过负载均衡层分发请求。单体式架构的项目可以平滑升级为集群架构。另外，集群架构还具有以下几个优秀特性。

性价比：几台普通服务器可以胜任价格高昂的单台高性能服务器的工作

可伸缩性：集群系统中的结点数目可以增长到几千个，乃至上万个，其伸缩性远超过单台超级计算机。当服务器负载压力增长的时候，系统能够扩展来满足需求，且不降低服务质量。

高可用性：在硬件和软件上都有冗余，通过检测软硬件的故障，将故障屏蔽，由存活结点提供服务，可实现高可用性。

技术门槛低：相比分布式架构，集群架构的不用考虑多进程通讯、分布式事务等棘手问题，技术门槛较低

 

 

 

 

(三)         分布式（微服务）集群架构

分布式（微服务）架构可以实现将整个项目按业务拆分成独立的多个服务（子项目），多个服务可以独立部署。这种架构虽然美好，但结构复杂、技术门槛高、开发运维难度大，不适合中小型项目。

另外，大部分分布式相关技术解决方案和技术文档，包括分布式框架、多进程通信和分布式事务等，都是亲Java的。虽然不能说其他语言不能做分布式，但是如果你用的不是Java，而且还没有大佬带，还是不要考虑这种架构了。

 

 

 

小结：

根据上面的系统容量预估分析，单体式架构项目运行在一台普通的服务器上，可以支撑一百万注册用户的1000并发。在考虑集群之前，应先做好代码和数据库层面的性能提升，也就是做到服务器硬件所能容纳并发的极限。

在代码和数据库层面做了足够的优化，用户数接近单服务器支撑极限时，考虑负载均衡加集群的架构进一步提升并发性能，当然有实力的团队可以直接考虑分布式架构。