个人博客

系统架构演变

一、单机系统服务

picture

初始阶段的小型系统,一般都是应用服务器、数据库、文件等资源都在一台服务器上。通常是选用linux系统做服务器系统、nginx作为web服务器、mysql作为后台数据库、选一个后端开发语言进行应用服务器开发。

此时系统的所有服务都在一个服务器上,能处理多大的并发能力,取决于一台服务器的性能。

二、应用服务和数据库服务分离

picture

随着系统访问人数的增加,很快就出现了服务器在高访问的情况下,数据量增加,单台服务器性能及存储空间不足。

此时需要将应用和数据分离,将应用程序、数据库、文件分别部署在独立的资源上,以提高并发处理能力和数据存储空间。

三、使用缓存服务

picture

当发现系统的访问量大之后,所有的请求都打到了数据库上,数据库的压力比较大,响应比较慢,容易因数据库的性能影响用户的使用体验。

系统的性能受限于数据库时,此时需要考虑从减少数据库压力来增加系统处理速度,可以通过添加缓存服务。

将部分热点数据,缓存在缓存服务中,通过先访问缓存数据,没有在访问数据库,这样减少了数据库压力,减少了IO次数,自然服务器的处理速度就上去了。

四、应用服务器集群

picture

再减少了数据库的压力之后,系统的处理能力上升了,但随着访问量的增加,系统的瓶颈出现在了应用服务器的处理上,应用服务器处理时间太长,导致服务器性能上不去。

此时,可以通过增加应用服务器节点,同时处理更多的数据,来提高系统的并发能力。通过nginx进行负载均衡,将请求发到各个节点去,平摊每个节点的压力。

使用多台服务器通过负载均衡同时向外部提供服务,解决单台服务器处理能力和存储空间上限的问题。使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源,提升系统的并发处理能力,使得服务器的负载压力不再成为整个系统的瓶颈。

五、数据库读写分离

picture

随着系统的访问量再次上升,发现增加应用服务器节点也不能提高性能时。此时可以发现,服务器的压力,在数据库的访问上,大量的写入操作,数据库处理不过来,由于数据库读写都是同一个,写的处理影响了读的处理。

为了解决数据库访问的问题,将数据库进行读写分离,设置数据库的主从模式,往主数据库写,从从数据库读 。

这样让写的压力不影响读的性能,也可以将从库部署到每台应用服务器的集群上,通过本地数据库访问,减少网络IO的消耗。

六、数据库分库分表

随着系统运行的时间和人数的上涨,数据库的数据越来越大,大量的数存储,会影响每次读取的速度,影响了访问性能。

此时问题出现在数量大的情况影响了读取速度,需要对数据库数据进行分库分表,减少单表数据量过大导致的访问速度下降的问题。

1,垂直分表

picture

根据表的字段,进行数据进行划分,拆分成不同的表,减少单表的字段来减少单行的数据量。

可用于系统绝对并发量并没有上来,表的记录并不多,但是字段多,并且热点数据和非热点数据在一起,单行数据所需的存储空间较大。以至于数据库缓存的数据行减少,查询时会去读磁盘数据产生大量的随机读IO,产生IO瓶颈。

垂直分表的拆分原则是将热点数据(可能会冗余经常一起查询的数据)放在一起作为主表,非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来,进而减少了随机读IO。拆了之后,要想获得全部数据就需要关联两个表来取数据。

2,水平分表

picture

当系统运行时间长了,单表数据量上升,上千万条数据,影响了读取的速度。通过水平拆分,将数据拆分到多个分表,降低单表的数据量。

可用于系统绝对并发量并没有上来,只是单表的数据量太多,影响了SQL效率,加重了CPU负担,以至于成为瓶颈。

水平分表拆分的原理,就是将单个表的数据量减少,单次SQL执行效率高,自然减轻了CPU的负担。

3,垂直分库

picture

当所有的业务都堆积在一个数据库上的时候,所有的服务都访问这个数据库,自然数据库的压力就会增大。通过对系统的业务进行垂直分库,将不同的业务分到不同的数据库中,减少单库的压力。

可用于系统绝对并发量上来了,并且可以抽象出单独的业务模块。

到这一步,基本上就可以服务化了。例如,随着业务的发展一些公共的功能越来越多,登录服务、权限服务、支付服务等功能大部分系统都使用到,可以独立到单个服务库中,甚至是服务化。

4,水平分库

picture

当系统的并发量越来越大,单库的分表不能解决并发增大带来的问题,性能受限,此时,需要将表进行水平分库,将压力分到多个数据库服务上,减少单数据库压力,增大并发能力。

可用于系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库。

水平分库的原理就是数据库多了,io和cpu的压力自然可以成倍缓解。

相关标签
回到顶部