八种架构演进

最新推荐文章于 2024-04-28 10:01:42 发布

学习自省

最新推荐文章于 2024-04-28 10:01:42 发布

阅读量1.2k

点赞数

文章标签：架构

本文链接：https://blog.csdn.net/c_study__c/article/details/132315630

版权

日升时奋斗，日落时自省

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）处理故障困难：需要查查看不同的日志完成问题定位，每个都是独立的，如果出问题需要慢慢排查