八种架构演进

日升时奋斗,日落时自省

目录

1、单机架构

2、应用数据分离架构

3、应用服务集群架构

4、读写分离/主从分离架构

5、冷热分离架构

6、垂直分库架构

7、微服务架构

8、容器编排架构

9、小结


1、单机架构

特征:应用服务和数据库服务器公用一台服务器

出现场景:访问量较小,单机可以满足,由于现在硬件的升级,所以一台服务器够支持很多请求

 红色箭头表示请求访问,蓝色箭头表示响应

 单机程序中,其实靠的不就是数据库信息的拉取嘛,但是数据库也不是不能去掉,光服务器负责所有操作(单机架构是比较常见架构使用)

一台主机的硬件资源是有上限的,CPU、内存、硬盘、网络每次请求都会收到一个请求,都是需要消耗上述的一些资源,现在一台主机都够用(不行了其实也可以增加硬件资源,但是肯定硬件资源不能在加了就开始使用分布式)

优点:部署简单、成本低

缺点:性能有严重平静、数据库和应用互相竞争资源

2、应用数据分离架构

特征:应用服务和数据库服务使用不同服务器

出现场景:单机架构存在严重的资源竞争,导致站点变慢

  红色箭头表示请求访问,蓝色箭头表示响应

优点:成本相对可控、性能相比单机有提升、数据库单独隔离、不会因为应用把数据库搞坏,不至于数据库瘫痪

缺点:硬件成本变高、性能有瓶颈,无法对应海量并发(当前数据库仍然是要接收所有请求处理处理)

3、应用服务集群架构

特征:引入负载均衡,应用以集群方式运作

出现场景:单个应用不足以支持海量的并发请求,高并发的时候站点响应变慢

注:能接收请求量多到数千,多个应用服务器集群同时处理大量请求量(此处tomcat就是横向扩展

 注:如果请求量更大呢,其实也同样可以按照上面的方法,交给一个更大应用服务接收请求,不够再进行横向扩展(第一先交给上层管理,第二同层进行横向扩展

   红色箭头表示请求访问,蓝色箭头表示响应

 注:根据需求而定不是说这样的架构一定好,能承载越多并发量就越适合当前,根据情况而定;对于图解有个解释,上面画的只是一个大概的图,实际上有了上层之后,下层就需要更多来接收,毕竟上层是负载均衡器,还是要给下层分配的

优点:

针对应用服务器

(1)高可用:应用满足高可用,不会一个服务出问题整个站点挂掉

(2)高性能:如果不是访问数据库,应用相关处理海量请求快速响应

(3)扩展能力:支持横向扩展

缺点:

针对数据库

(1)性能瓶颈:无法应对数据库的海量查询

(2)可用性:数据库是点单的,所以一旦崩溃就是整个系统挂掉

(3)运维成本高:扩展部署运维工作增加

(4)硬件成本高:说的就是F5这个硬件

4、读写分离/主从分离架构

特征:将数据库集群化,但是为了保证所取数据都是相同的,就让一个数据哭来下,剩下的小弟们跟随大哥进行同步;数据库服务器搭建主从集群,一主一从、也可以一主多从都可以,,数据哭主机负责写操作,从机只负责读操作

出现场景:数据库到达瓶颈,而互联网应用一般读多写少,数据库承载压力主要来源于读的请求你造成的,那么针对这样的情况把读操作和写操作分开

注:红色箭头表示请求是写操作;浅蓝色箭头表示读操作;紫色箭头表示写操作进行同步,同步给从库;蓝色箭头表示响应

优点:

针对请求访问

(1)读取性能提升

(2)读取操作为主数据库减轻了大部分请求的压力,写操作性能也得以提升

(3)可用性:一个数据库的坍塌不会给系统带来致命的伤害,提高了可用性

缺点:

针对热点数据

(1)读库虽然分担了很多请求量,但是它也会负载,热点数据的疯狂访问

(2)同步从库挂掉,或者延时,导致主库和从库数据有一定可能不一致

(3)服务器成本需要增加(添东西了,能不增加)

5、冷热分离架构

这里针对冷热数据进行解析:针对所谓数据都有常用数据,不常用数据,也就衍生出了“二八原则”,20%的热点数据,能满足80%的访问需求(不是说一定就是20%,按照业务需求来定夺分配,“一九”也不是没有)

特征:引入缓存,实行冷热分离,将热点数据放到缓存中快速响应

出现场景:海量的请求导致数据库负载过高,站点响应在度变慢,说明数据库已经开始吃力了;不足以提供较高的舒适度

 优点:大幅度降低数据库的访问请求,性能提升非常明显(访问缓存相比访问数据库快)

缺点:

(1)涉及到缓存就会设想到缓存到来的相关问题,缓存击穿、缓存失败、缓存雪崩等问题

(2)服务器成本的提高

(3)业务量支持变大,数据库单库太大,单表个体太大还是会导致数据库查询很慢,导致数据库再度到达瓶颈期

6、垂直分库架构

特征:数据库的数据被拆分,数据库数据分布式存储,分布式处理,分布式查询,也可以理解为分布式数据库架构

出现场景:写操作比较多,单机库性能已经支持不了了,需要拆分数据库,数据表的数据量太多,操作压力大,需要进行分表,降低运维难度,就有了分布式数据库,库表本来也就支持分布式

分库分表:

垂直分库:是指按照业务功能模块进行分库,将不同的业务模块分别放在不同的物理数据库中,这样可以提高系统的性能和扩展性

水平分库:是指按照用户属性(地市或者ID的hash)进行分库,将全省划分为个大区,每个大区有一个物理数据库,这样可以提高系统的扩展性和性能

注:这里就不在往整个架构图中带入了,这里直接将常见到的应用带入到架构中,这些中间件都是可以支持分库操作,内部实现思想也基本如上

分布式数据库:

 优点:数据库吞吐量大幅度提升,不再是瓶颈期

缺点:

(1)跨库join操作,分布式事务等问题,需要对应进行解决,目前的mpp都有解决对策

(2)数据库和缓存结合能够支持海量的请求,但是应用代码整体耦合,修改一行代码就需要连带修改很多,整体重新发布

7、微服务架构

特征:按照业务板块来分应用代码,是单个应用的职责更清晰,相互之间可以做到独立升级迭代

出现场景:场景不定全看自己对微服务的定位,这里针对几点进行评定

(1)扩展性差:应用程序不能轻松扩展,因为每次需要更新应用程序时,都必须重新构建整个系统

(2)持续开发困难一个很小的改动会惊动整个系统的代码连带改动,无法频繁并容易发布(这个是灵活性的体现)

(3)不可靠:一个功能不起作用了整个系统可能不能动

(4)代码维护比较吃力,都是在一起的,接手人需要了解整个系统才能每步修改

微服务体现:

 架构演示:

 注:图并没有画完,这里解释当我们找商品的时候,是可以去访问用户,返回用户信息之后,在去找商品,商品查找操作是一样的,先找缓存,如果缓存没有在找数据库

优点:

(1)灵活性高:服务独立测试、部署、升级、发布

(2)独立扩展:微服务将功能独立起来,各自扩展互不干扰

(3)提高容错性:一个服务问题,不会两边挂

(4)支持编程语言多

缺点:
(1)运维复杂度高:应用和服务的部署变得复杂,同一台服务器上不是多个服务还要解决运行环境冲突的问题,如果需要动态扩缩场景,需要水平扩展服务的性能,就需要在新增服务上准备运行环境

(2)资源使用变多:独立一个微服务是需要消耗CPU和内存的

(3)处理故障困难:需要查查看不同的日志完成问题定位,每个都是独立的,如果出问题需要慢慢排查

8、容器编排架构

特征:借助容器化技术(Docker)将应用/服务可以打包为镜像,通过容器编排工具(k8s)来动态分布和部署镜像,服务以容器化方式运行

出现场景:

(1)微服务拆分细致,服务多部署工作量大,配置复杂容易出错

(2)微服务数量多扩缩容麻烦,而且容易出错,每次缩容后再扩容又需要重新配置服务对应的环境参数

(3)微服务之间运行环境可能冲突,需要更多的资源来进行部署或者通过修改配置来解决冲突

容器化举例:

这里就我们比较熟悉的Java一套体系来说 java应用涉及:java、jdk、centos7 但是我们放到服务器上一次一次放太麻烦了,docker可以直接打包这个三个体系称为一个体系,直接部署到服务器上

 容器化体现:

 容器编排架构:

 红色箭头表示请求,蓝色箭头表示响应,紫色箭头表示去拿用户信息,浅蓝色箭头表示缓存没有,访问数据库

注:这里的图没有画完,同样是访问商品时拿到用户数据信息,再次进行数据访问,先访问缓存,数据不存在访问数据库

 优点:

(1)部署运维简单快速:一条命令就可以完成几百个服务的部署或者扩缩容

(2)隔离性好:容器与容器之间文件系统,网络相互隔离,不会产生环境冲突

(3)支持滚动更新:版本间奇幻都可以通过一个命令完成升级或者回滚

缺点:

(1)技术栈变多,技术要求严格

(2)运维成本极高,机器不是随时都会面临如此的资源消耗,一般只会维持一段时间,剩余时间还是闲置状态,此时资源利用率低,推荐云厂商服务器解决问题

9、小结

注:最后压力给到了应用,但是并没有结束,应用的改动会影响整个系统的代码耦合性太高,导致运维部署发布都需要很多次,任务量很大(图太长了,不太会截,这里分开截,内容是连续的)

 下面就有了微服务,微服务并没有解决运维任务量大的问题,微服务只是将代码解耦,能让开发更加便捷,各司其职互不影响,运维的麻烦还是经过docker容器化打包成镜像交给k8s进行编排降低运维的任务量

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>