目录
- 1.单机架构
- 2.应⽤数据分离架构
- 3.应⽤服务集群架构
- 4.读写分离/主从分离架构
- 5.引⼊缓存⸺冷热分离架构
- 6.垂直分库/分表
- 7.业务拆分⸺微服务
- 8.总结
1.单机架构
- 只有一台服务器,这个服务器负责所有的工作
- 大部分公司的产品,都是这种单机架构
- 大部分公司的产品,都是这种单机架构
2.应⽤数据分离架构
- 当业务进一步增长时,用户量和数据量都会水涨船高,一台主机难以应付的时候,就需要引入更多的主机和更多的硬件资源
- 一旦引入多台主机,该系统就可以称之为"分布式系统"了
- 实际上,引入分布式,也是"万不得已"的举措,因为此时系统的复杂度会大大提高
- 特点:将数据库服务独⽴部署在同⼀个数据中⼼的其他服务器上,应⽤服务通过⽹络访问数据
- 应用服务器:可能包含很多业务逻辑,比较吃CPU和内存
- 数据库服务器:需要更大的硬盘控件,更快的数据访问速度
- 综合以上特点,可以达到较高的性价比
3.应⽤服务集群架构
-
理论上来说,有两种方案
- 垂直扩展/纵向扩展Scale Up:通过购买性能更优、价格更⾼的应⽤服务器来应对更多的流量
- 优势:在于完全不需要对系统软件做任何的调整
- 劣势:硬件性能和价格的增⻓关系是⾮线性的,意味着选择性能2倍的硬件可能需要花费超过4倍的价格,其次硬件性能提升是有明显上限的
- ⽔平扩展/横向扩展Scale Out:通过调整软件架构,增加应⽤层硬件,将⽤⼾流量分担到不同的应⽤层服务器上,来提升系统的承载能⼒
- 优势:在于成本相对较低,并且提升的上限空间也很⼤
- 劣势:带给系统更多的复杂性,需要技术团队有更丰富的经验
- 综上,实际上基本用的都是水平扩展的方案
- 垂直扩展/纵向扩展Scale Up:通过购买性能更优、价格更⾼的应⽤服务器来应对更多的流量
-
为了解决水平扩展这个方案,需要引入一个新的组件:负载均衡
- 为了解决⽤⼾流量向哪台应⽤服务器分发的问题,需要⼀个专⻔的系统组件做流量分发
- 用户的请求,先到达负载均衡器/网关服务器(单独的服务器)
- 负载均衡器对于请求的承担能力,要远超过应用服务器
- 类似于"多线程"
- 如果请求量大到负载均衡器也扛不住了,怎么办?
- 引入更多的负载均衡器 --> 引入更多的机房
- 实际中负载均衡不仅仅指的是⼯作在应⽤层的,甚⾄可能是其他的⽹络层之中
- 为了解决⽤⼾流量向哪台应⽤服务器分发的问题,需要⼀个专⻔的系统组件做流量分发
-
流量调度算法有很多种,简单介绍⼏种较为常⻅的:
- Round-Robin 轮询算法:即⾮常公平地将请求依次分给不同的应⽤服务器
- Weight-Round-Robin 轮询算法:为不同的服务器(⽐如性能不同)赋予不同的权重, 能者多劳
- ⼀致哈希散列算法:通过计算⽤⼾的特征值(⽐如IP地址)得到哈希值,根据哈希结果做分发
- 优点:确保来⾃相同⽤⼾的请求总是被分给指定的服务器,也就是平时遇到的专项客⼾经理服务
4.读写分离/主从分离架构
- 到目前为止介绍的架构⾥,⽆论扩展多少台服务器,这些请求最终都会从数据库读写数据,到⼀定程度之后,数据的压⼒成为系统承载能⼒的瓶颈点
- 可以像扩展应⽤服务器⼀样扩展数据库服务器么?
- 肯定不行,因为数据库服务有其特殊性:
- 如果将数据分散到各台服务器之后,数据的⼀致性将⽆法得到保障
- 数据的⼀致性:针对同⼀个系统,⽆论何时何地,都应该看到⼀个始终维持统⼀的数据
- 肯定不行,因为数据库服务有其特殊性:
- 解决办法:保留⼀个主要的数据库作为写⼊数据库,其他的数据库作为从属数据库
- 从库的所有数据全部来⾃主库的数据,经过同步后,从库可以维护着与主库⼀致的数据
- 主服务器一般是一个,从服务器可以有多个
- 同时,从服务器可以通过负载均衡的方式,让应用服务器进行访问
- 为了分担数据库的压⼒,可以将写数据请求全部交给主库处理,但读请求分散到各个从库中
- 由于⼤部分的系统中,读写请求都是不成⽐例的(读的频率比写高),所以只要将读请求由各个从库分担之后,数据库的压⼒就没有那么⼤了
- 当然这个过程不是⽆代价的,主库到从库的数据同步其实是有时间成本的,这个问题暂时不做进⼀步探讨
- 应⽤中需要对读写请求做分离处理,所以可以利⽤⼀些数据库中间件,将请求分离的职责托管出去
- 从库的所有数据全部来⾃主库的数据,经过同步后,从库可以维护着与主库⼀致的数据
5.引⼊缓存⸺冷热分离架构
- 问题:数据库有个天然的问题,响应速度比较慢
- 分析:随着访问量继续增加,发现业务中⼀些数据的读取频率远⼤于其他数据的读取频率
- 把这部分数据称为热点数据,与之相对应的是冷数据
- 针对热数据,为了提升其读取的响应时间,可以增加本地缓存,并在外部增加分布式缓存
- 缓存热⻔商品信息或热⻔商品的html⻚⾯等
- 通过缓存能把绝⼤多数请求在读写数据库前拦截掉,⼤⼤降低数据库压⼒
- 其中涉及的技术包括:使⽤
mem cached
作为本地缓存,使⽤Redis作为分布式缓存,还会涉及缓存⼀致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等问题
- 解决方案:二八原则
- 把数据区分"冷热",热点数据放到缓存中
- 缓存的访问速度往往比数据库要快多了
6.垂直分库/分表
- 引入分布式系统,不光要能够去应对更高的请求量(并发量),同时也要能应对更大的数据量
- 需求提出:随着业务的数据量增⼤,⼤量的数据存储在同⼀个库中已经显得有些⼒不从⼼了,所以可以按照业务,将数据分别存储 --> 一台主机存不下,多台主机一起来存储
- 如果某个表也特别大,大到一台主机存不下,也可以针对表进行拆分
- 例如:针对评论数据,可按照商品ID进⾏hash,路由到对应的表中存储;针对⽀付记录,可按照⼩时创建表,每个⼩时表继续拆分为⼩表,使⽤⽤⼾ID或记录编号来路由数据
- 只要实时操作的表数据量⾜够⼩,请求能够⾜够均匀的分发到多台服务器上的⼩表,那数据库就能通过⽔平扩展的⽅式来提⾼性能
7.业务拆分⸺微服务
-
之前的所有应用服务器,一个服务器程序里面做了很多的业务,这就可能导致这一个服务器的代码变得越来越复杂
- 为了更方便代码的维护,可以将一个复杂的服务器,拆分成更多的,功能更单一,但是更小的服务器 --> 微服务
-
注意:微服务本质上是解决了"人"的问题
- 一般只有大厂才会涉及到"人的问题"
-
随着⼈员增加,业务发展,将业务分给不同的开发团队去维护,每个团队独⽴实现⾃⼰的微服务,然后互相之间对数据的直接访问进⾏隔离
- 可以利⽤Gateway、消息总线等技术,实现相互之间的调⽤关联
- 甚⾄可以把⼀些类似⽤⼾管理、安全管理、数据采集等业务提成公共服务
-
引入微服务,解决了人的问题,付出的代价呢?
- 系统的性能下降,拆出来更多的服务,多个功能之间要更依赖网络通信
- 系统复杂程度提高,可用性受到影响,出现问题的概率更大了
-
微服务的优势:
- 解决了人的问题
- 使用微服务,可以更方便于功能的服用
- 可以给不同的服务进行不同机器配置的部署
8.总结
- 单机架构:应用程序 + 数据库服务器
- 数据库和应用分离:应用程序和数据库服务器,分别放到不同的机器上部署了
- 引入负载均衡,应用服务器 --> 集群:通过负载均衡器,把请求比较均匀的分发给集群中的每个应用服务器
- 引入读写分离,数据库主从结构:一个数据库节点作为主节点,其他N个数据库节点作为从节点
- 主节点负责写数据,从节点负责读数据
- 主节点需要把修改过的数据同步给从节点
- 引入缓存,冷热数据分离:进一步提升了服务器针对请求的处理能力 --> 二八原则
- Redis在一个分布式系统中,通常就扮演着缓存这样的角色
- 引入的问题:数据库和缓存的数据一致性问题
- 引入微服务,从业务上进一步拆分应用服务器:从业务功能的角度,把应用服务器,拆分成更多的功能更单一、更简单、更小的服务器
- 综上:所谓的分布式系统,就是想办法引入更多的硬件资源