图解电商系统的架构演进

具体以商城为例, 展示web端应用的架构演变过程。

图解电商系统的架构演进_第1张图片

图解电商系统的架构演进_第2张图片

特点:
1、所有的功能集成在一个项目工程中。
2、所有的功能打在一个war包部署到服务器。
3、通过部署应用集群和数据库集群来提高系统的性能。

优点
1、项目架构简单,前期开发成本低,周期短,小型项目的首选。
2、开发效率高,模块之间交互采用本地方法调用。
3、容易部署,运维成本小,直接打包为一个完整的包,拷贝到web容器的某个目录下即可运行。
4、容易测试:IDE都是为开发单个应用设计的、容易测试——在本地就可以启动完整的系统。

缺点:
1、全部功能集成在一个工程中,对于大型项目不易开发、扩展及维护。
2、版本迭代速度逐渐变慢,修改一个地方就要将整个应用全部编译、部署、启动,开发及测试周期过长。
3、无法按需伸缩,通过集群的方式来实现水平扩展,无法针对某业务按需伸缩。

总结:一个web项目里包含了所有的模块,一个数据库里包含了所需要的所有表,当网站访问量增加时,首先遇到瓶颈的是应用服务器连接数,比如tomcat连接数不能无限增加,2.线程数上限受进程内存大小、3.CPU内核数等因素影响,当线程数到达一定数时候,线程上下文的切换对性能的损耗会越来越严重,响应会变慢,通过增加web应用服务器方式的横向扩展对架构影响最小,这时候架构会变成下面这样:

2、分布式架构

针对单体架构的不足,为了适应大型项目的开发需求,许多公司将一个单体系统按业务垂直拆分为若干系统系统之间通过网络交互来完成用户的业务处理每个系统可分布式部署,这种架构称为分布式架构。

如下图所示:图解电商系统的架构演进_第3张图片

图解电商系统的架构演进_第4张图片

特点:
1、按业务垂直拆分成一个一个的单体系统,此架构也称为垂直架构。
2、系统与系统之间的存在数据冗余,耦合性较大,如上图中三个项目都存在客户信息。
3、系统之间的接口多为实现数据同步,如上图中三个项目要同步客户信息。

优点:
1、通过垂直拆分,每个子系统变成小型系统,功能简单,前期开发成本低,周期短。
2、每个子系统可按需伸缩。
3、每个子系统可采用不同的技术。

缺点:
1、子系统之间存在数据冗余、功能冗余,耦合性高。
2、按需伸缩粒度不够,对同一个子系统中的不同的业务无法实现,比如订单管理和用户管理。

这时候随着网站访问量继续增加,继续增加应用服务器数量后发现数据库成了瓶颈,而数据库的最主要的瓶颈体现在两方面:

  • 数据库的最大连接数是有限的,比如当前数据库的连接数设置10000,如果每个应用服务器与数据库的初始连接数设置50,那么200台web服务器是极限, 并且连接数太多后,数据库的读写压力增大,耗时增加

  • 当单表数量过大时,对该表的操作耗时会增加,索引优化也是缓兵之计

总结:这时,根据业务特点,如果读写比差距不大,并且对数据一致性要求不是很高的情况下,数据库可以采用主从方式进行读写分离的方案,并且引入缓存机制来抗读流量。

如果读写比差距很大或者对数据一致性要求高时,就不适合用读写分离方案,需要考虑业务的垂直拆分,这时期的系统架构图如下

3、SOA架构

SOA是一种面向服务的架构,基于分布式架构它将不同业务功能按服务进行拆分,并通过这些服务之间定义良好的接口和协议联系起来。

图解电商系统的架构演进_第5张图片

图解电商系统的架构演进_第6张图片

特点:
1、基于SOA的架构思想,将重复公用的功能抽取为组件,以服务的方式向各各系统提供服务。
2、各个系统与服务之间采用webservice、rpc等方式进行通信。
3、ESB企业服务总线作为系统与服务之间通信的桥梁。

优点:
1、将重复的功能抽取为服务,提高开发效率,提高系统的可重用性、可维护性。
2、可以针对不同服务的特点按需伸缩。
3、采用ESB减少系统中的接口耦合。

缺点:
1、系统与服务的界限模糊,会导致抽取的服务的粒度过大,系统与服务之间耦合性高。
2、虽然使用了ESB,但是服务的接口协议不固定,种类繁多,不利于系统维护。

总结:这时候仍然是垂直架构,所有业务集中在一个项目里。项目维护、快速迭代问题会越来越严重,单个模块的开发都需要发布整个项目,项目稳定性也受到很大挑战,这是需要考虑业务的垂直拆分,需要将一些大的模块单独拆出来,这时候的架构图如下:

图解电商系统的架构演进_第7张图片

这时候为了进一步提升用户体验,加速用户的网站访问速度,会使用CDN来缓存信息,用户会访问最近的CDN节点来提升访问速度。

4、微服务架构

基于SOA架构的思想,为了满足移动互联网对大型项目及多客户端的需求,对服务层进行细粒度的拆分,所拆分的每个服务只完成某个特定的业务功能比如订单服务只实现订单相关的业务,用户服务实现用户管理相关的业务等
等,服务的粒度很小,所以称为微服务架构

图解电商系统的架构演进_第8张图片

图解电商系统的架构演进_第9张图片

特点:
1、服务层按业务拆分为一个一个的微服务。
2、微服务的职责单一。
3、微服务之间采用RESTful、RPC等轻量级协议传输。
4、有利于采用前后端分离架构。

优点:
1、服务拆分粒度更细,有利于资源重复利用,提高开发效率。
2、可以更加精准的制定每个服务的优化方案,按需伸缩。
3、适用于互联网时代,产品迭代周期更短。

缺点:
1、开发的复杂性增加,因为一个业务流程需要多个微服务通过网络交互来完成。
2、微服务过多,服务治理成本高,不利于系统维护。

总结:随着业务量增大,一些核心系统数据库单表数量达到几千万甚至亿级,这时候对该表的数据操作效率会大大降低,并且虽然有缓存来抗读的压力,但是对于大量的写操作和一些缓存miss的流量到达一定量时,单库的负荷也会到达极限,这时候需要将表拆分,一般直接采用分库分表,因为只做分表的话,单个库的连接瓶颈仍然无法解决。分库分表后的架构如下:图解电商系统的架构演进_第10张图片

随着流量的进一步增大,这时候系统仍然会有瓶颈出现,以订单系统为例:单个机房的机器是有限的,不能一直新增下去,并且基于容灾的考虑,一般采用同城双机房的方式,机房之间用专线链接,同城跨机房质检的延时在几毫秒,此时的架构图如下:图解电商系统的架构演进_第11张图片

由于数据库主库只能是在一个机房,所以仍然会有一半的数据库访问是跨机房的,虽然延时只有几毫秒,但是一个调用链里的数据库访问太多后,这个延时也会积少成多。其次这个架构还是没能解决数据库连接数瓶颈问题

  • 随着应用服务器的增加,虽然是分库分表,但每增加一台应用服务器,都会与每个分库建立连接,比如数据库连接池默认连接数是50,而如果mysql数据库的最大连接数是10000的话,那么200台应用服务器就是极限。

  • 当应用的量级太大后,单个的机器、电、带宽等资源无法满足业务的持续增长。这时就需要考虑SET化架构,也就是单元化架构,大体思路就是将一些核心系统拆成多个中心,每个中心成为一个单元,流量会按照一定的规则分配给每个单元,这样每个单元只负责处理自己的流量就可以了。每个单元要尽量自包含、高内聚。这是从整体层面将流量分而治之的思路。

  • 综合这些架构模式的特点和优点我们会发现,微服务架构的这些特点非常符合一种开发模式:敏捷开发,下面介绍一些开发模型:图解电商系统的架构演进_第12张图片

  • 上面的架构图,流量从接入层按照路由规则(比如以用户ID来路由)路由到不同单元,每个单元内都是高内聚,包含了核心系统,数据层面的分片逻辑是与接入层路有逻辑一致,也解决了数据库连接的瓶颈问题,但是一些跨单元的调用是无法避免的,同时也有些无法拆分的业务需要放在中心单元,供所有其他单元调用。

图解电商系统的架构演进_第13张图片

你可能感兴趣的:(架构,spring,boot,spring,cloud,系统架构)