网站从构建之初的很少有人问津,用户数量较少,并发量较低,到之后的拥有千万上亿用户,数万量级的高并发,之间经历了怎样的过程,小型网站架构是怎样逐步演化的,本文简单探讨下这方面的内容,主要参考《大型网站架构设计》,这本书知识点总结的还是比较全面的。
网站开始是没有太多访问量的,只需一台服务器就绰绰有余了,应用程序,数据库,静态资源等全部都在一台服务器上,一般使用LAMP/LNMP(Linux+Apache/Nginx+MySQL+PHP/Python等)就可以实现自己的网站了,具体架构如下所示:
随着网站业务的发展,用户访问量的增加,存储数据的增长,单台服务器逐渐不能满足需求,需要将应用服务与数据服务分离,具体如下图所示:
由于负责提供的服务不同,每台服务器对硬件资源的需求是不同的,具体如下所示:
服务器类型 | 处理业务 | 所需资源 |
应用服务器 | 处理所有业务逻辑 | 更快、更多CPU |
文件服务器 | 存储用户上传文件或服务自身所需文件资源 | 更大的磁盘空间 |
数据库服务器 | 做数据缓存以及进行数据检索 | 更大的内存以及更快的磁盘 |
随着用户逐渐增多,数据库压力太大,导致访问延迟,影响用户体验,而网站性能优化最优先考虑的就是 缓存 ;
网站访问特点所遵循的二八定律 :80%的业务访问集中在20%的数据上;
网站使用缓存又可分为应用服务器本地缓存和远程分布式缓存,远程分布式缓存一般可采用集群的方式部署,对服务器内存有比较高的要求,具体如下图所示:
随着访问量进一步增大,单台应用服务器已逐渐不能应对越来越多的请求连接,单台服务器硬件资源再强,也会逐渐满足不了业务高峰时的负载压力;
网站解决高并发、海量数据问题最常用的手段还是使用 集群 ,做横向扩展,集群可以很好地满足 伸缩性 ;
负载均衡服务器实现可以有比较多的方案,LVS,Nginx,F5等,可以和HA软件,如Heartbeat与Keepalived等一起使用;
通过应用服务器集群部署,使用负载均衡调度器,可以将用户的请求分发到多台应用服务器集群中的任一台机器上,而且根据用户访问量的多少,可以很容易增删服务器,是每台服务器负载都在可接受范围之内,具体如下图所示:
对于缓存没命中和缓存过期的数据,仍需要从数据库中来读取,并且所有写操作也都需要访问数据库,数据库压力还是会随着访问量增加而增大;
可采用 主从热备 的方案,实现 读写分离 ,例如mysql的 master-slave 模式,当读操作量级更高时,还可采用 一主多从 的方式来实现;
应用程序中的数据访问模块需要 保证数据库的读写分离对应用透明 ;
具体如下图所示:
中国网络环境复杂,不同地区用户访问相同网站,速度差别较大,而网站访问延时和用户流失率正相关;
主要加速网站访问速度,减轻后端服务器负载压力的方式就是使用 CDN 和 反向代理 ;
CDN和反向代理的基本原理都是 缓存 :
CDN部署在网络提供商的机房,缓存网站的一些热点静态资源,用户在请求网站服务时,从距离自己最近的网络提供商机房获取数据,如视频、图片等;
反向代理部署在网站的中心机房,属于网站前端架构的一部分,当用户请求到达中心机房后,首先访问反向代理服务器,如果缓存着用户请求的资源(静态),就直接返回;
反向代理比较成熟的开源软件:Squid、Varnish,推荐使用 Varnish ,从稳定性、访问速度、并发连接数目比较来看,Varnish都更强大一点;
使用缓存的前提条件: 1. 数据访问热点不均衡,某些数据会被频繁访问; 2. 数据在某个时间段内有效,不会很快过期,否则可能造成缓存数据已经失效,产生脏读,影响结果正确性
具体如下图所示:
随着业务量的增长,网站最常用的数据库拆分是 按业务分库 ,将不同业务的数据库部署在不同的服务器上;
一般分布式数据库是网站数据库拆分的最后手段,只有在单表规模非常庞大的时候才使用;
具体如下图所示:
全文检索 对于大型网站来说已成为不可或缺的一部分,例如 Lucene 、 Solr 等;
对非格式化的数据使用NoSQL存储更为方便,NoSQL也更适合大数据计算,较为流行的NoSQL数据库有HBase、MongoDB、CouchDB、Redis、Cassandra等;
不同NoSQL数据库使用的存储方式不同,例如Redis,Memcache等采用的是Key/Value键值对存储,MongoDB,CouchDB等采用的是按文档存储,一条记录中所有数据都存储在文档中,HBase,Cassandra等采用的是列存储;
具体如下图所示:
网站在发展壮大之后,往往包含了多种复杂的业务场景,使用分而治之的手段将整个网站业务分成不同的产品线,将网站拆分成多个不同的应用,每个应用独立部署维护,应用之间可以通过超链接、消息队列等关联起来,具体如下图所示:
在上面业务拆分的基础上,将一些公共的业务抽取出来,独立部署,如给用户管理、商品管理等,这些可复用的业务连接数据库,提供公共服务,而应用系统只需管理用户界面;
具体如下图所示:
分布式主要还是为了解决高并发问题,但也引入了一些其他问题: 1. 服务调用必须通过网络,可能会对性能造成较大影响; 2. 服务器越多,故障概率越大,一台服务器宕机可能会导致连锁反应(滚雪球效应),导致很多应用不可访问,网站可用性降低,设计时应尽量避免; 3. 数据在分布式环境保持数据一致性也比较困难,分布式事务难以保证,这对网站业务正确性和业务流程可能造成影响; 4. 导致网站依赖错综复杂,开发管理维护困难;
驱动网站技术发展的主要力量永远是网站业务的发展; 网站都是逐渐演化而来的,根据需要灵活应对才是最重要的; 技术是为了业务而服务的,永远不要为了技术而技术;