华龙区乡村网站建设,广告牌设计,我们的优势的网站,wordpress 为分类定模板聊聊电商系统架构演进 具体以电子商务网站为例#xff0c; 展示web应用的架构演变过程。 1.0时代 这个时候是一个web项目里包含了所有的模块#xff0c;一个数据库里包含了所需要的所有表#xff0c;这时候网站访问量增加时#xff0c;首先遇到瓶颈的是应用服务器连接数 展示web应用的架构演变过程。 1.0时代 这个时候是一个web项目里包含了所有的模块一个数据库里包含了所需要的所有表这时候网站访问量增加时首先遇到瓶颈的是应用服务器连接数比如tomcat连接数不能无限增加线程数上限受进程内存大小、CPU内核数等因素影响当线程数到达一定数时候线程上下文的切换对性能的损耗会越来越严重响应会变慢通过增加web应用服务器方式的横向扩展对架构影响最小这时候架构会变成下面这样 2.0时代 这时候随着网站访问量继续增加继续增加应用服务器数量后发现数据库成了瓶颈而数据库的最主要的瓶颈体现在两方面 数据库的最大连接数是有限的比如当前数据库的连接数设置8000如果每个应用服务器与数据库的初始连接数设置40那么200台web服务器是极限 并且连接数太多后数据库的读写压力增大耗时增加 当单表数量过大时对该表的操作耗时会增加索引优化也是缓兵之计 这时根据业务特点如果读写比差距不大并且对数据一致性要求不是很高的情况下数据库可以采用主从方式进行读写分离的方案并且引入缓存机制来抗读流量。如果读写比差距很大或者对数据一致性要求高时就不适合用读写分离方案需要考虑业务的垂直拆分这时期的系统架构图如下 3.0时代 3.1 读写分离 这时候仍然是垂直架构所有业务集中在一个项目里。项目维护、快速迭代问题会越来越严重单个模块的开发都需要发布整个项目项目稳定性也受到很大挑战这是需要考虑业务的垂直拆分需要将一些大的模块单独拆出来这时候的架构图如下 4.0 业务垂直拆分 这时候为了进一步提升用户体验加速用户的网站访问速度会使用CDN来缓存信息用户会访问最近的CDN节点来提升访问速度。此时的架构图如下 4.1 使用CDN来缓存信息 随着业务量增大一些核心系统数据库单表数量达到几千万甚至亿级这时候对该表的数据操作效率会大大降低并且虽然有缓存来抗读的压力但是对于大量的写操作和一些缓存miss的流量到达一定量时单库的负荷也会到达极限这时候需要将表拆分一般直接采用分库分表因为只做分表的话单个库的连接瓶颈仍然无法解决。分库分表后的架构如下 4.2分库分表架构 随着流量的进一步增大这时候系统仍然会有瓶颈出现以订单系统为例 单个机房的机器是有限的不能一直新增下去并且基于容灾的考虑一般采用同城双机房的方式机房之间用专线链接同城跨机房质检的延时在几毫秒此时的架构图如下 4.3 同城双机房 由于数据库主库只能是在一个机房所以仍然会有一半的数据库访问是跨机房的虽然延时只有几毫秒但是一个调用链里的数据库访问太多后这个延时也会积少成多。其次这个架构还是没能解决数据库连接数瓶颈问题 随着应用服务器的增加虽然是分库分表但每增加一台应用服务器都会与每个分库建立连接比如数据库连接池默认连接数是40而如果mysql数据库的最大连接数是8000的话那么200台应用服务器就是极限。 当应用的量级太大后单个城市的机器、电、带宽等资源无法满足业务的持续增长。这时就需要考虑SET化架构也就是单元化架构大体思路就是将一些核心系统拆成多个中心每个中心成为一个单元流量会按照一定的规则分配给每个单元这样每个单元只负责处理自己的流量就可以了。每个单元要尽量自包含、高内聚。这是从整体层面将流量分而治之的思路。这是单元化后的机构简图如下 5.0 单元化 从上面的架构图里能看到流量从接入层按照路由规则比如以用户ID来路由路由到不同单元每个单元内都是高内聚包含了核心系统数据层面的分片逻辑是与接入层路有逻辑一致也解决了数据库连接的瓶颈问题但是一些跨单元的调用是无法避免的同时也有些无法拆分的业务需要放在中心单元供所有其他单元调用。 参考文章 文章主要参考自 李智慧的 《大型网站技术架构》 https://blog.csdn.net/caoyuanyenang/article/details/86943397 https://www.cnblogs.com/lfs2640666960/p/9021205.html http://www.hollischuang.com/archives/728 本文由 mdnice 多平台发布
