随着并发量上升服务器架构设计演变

        对于一个刚起步的创业公司，不需要考虑太多复杂的服务器架构，能把业务跑起来就行了。但是在早期业务逻辑设计时，了解一些高并发大流量的服务器架构的逻辑，在设计上做好必要的预留，后面可以少走很多弯路。

 

下面这个图估计大家都明白，这就是最基础的服务器架构。傻瓜式的方法是把应用服务器、文件服务器、数据库服务器全部混合在一起，呵呵呵！但这并不是最科学的。

 

 

 

当业务量持续增加到一定量以后，执行应用程序、读写文件、访问数据库应该有所区分，保证各自的需求都能得到满足，这时候你需要考虑把应用服务器、文件服务器、数据库服务器分离，这个时候的服务器架构应该是下面这样的，它是由三个独立的服务器组成，各司其职。

 

 

 

 

随着业务量持续增加，应用程序访问缓存数据会成为瓶颈，这个时候需要增加本地缓存，有的也需要分布式缓存。分布式缓存是指缓存部署在多个服务器组成的服务器集群中，以集群的方式提供缓存服务，其架构方式主要有两种，一种是以JBoss Cache为代表的需要同步更新的分布式缓存，一种是以Memchached为代表的互不通信的分布式缓存。如下图：

 

 

 

 

接下来，应用服务器需要更多台以应对复杂的业务逻辑，那么就需要负载均衡调度服务器来调度和分配应用服务器的工作任务。

 

 

 

 

再往后，需要考虑数据库服务器的承压能力，通常可以采用主从式数据库服务器架构，把读、写两部分分开，既可以提高数据访问的安全性，也能提高数据读写的效率。

 

 

 

 

 

随着业务量暴增，单一区域的服务器带宽将不能承载全国的业务需求，这时候需要增加反向代理和CDN服务器。CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。

 

 

 

 

 

 

同样，服务器架构师应该分析文件服务器和数据库服务器的网络读写速度，进一步部署分布式的架构。

 

 

 

 

对于有搜索和大量查询的网络业务，还需要增加独立的搜索引擎和NoSQL服务器。

 

 

 

 

 

 

对于更复杂的系统，还需要进一步拆分应用服务器，增加消息队列服务器。增加消息队列服务器有以下几点好处：

 

1，由于消息队列服务器的速度远远高于数据库服务器，所以能够快递处理并返回数据；

 

2，消息队列服务器具有更好的扩展性；

 

3，在高并发的情况下，延迟写入数据库，可以有效降低数据库的压力。

 

 

 

 

 

 

对于一些超大型综合互联网业务，应用服务器也需要分布式的架构，这个时候在不同业务的应用服务器之间做好消息协同会有较大的挑战。

 

 

 

 

下面列举服务器架构中重点技术的流行方案：

CDN：腾讯云cdn/华为云cdn/阿里云cdn/网宿科技/联通/移动/电信

反向代理：nginx/Apache TS

负载均衡：Lvs/Nginx/HAProxy

分布式缓存：Redis，memcache

消息队列：Kafka/ActiveMQ/DDMQ

 

并发测试工具：

• Apache JMeter
• Visual Studio性能负载测试
• Microsoft Web Application Stress Tool
• 阿里云性能测试