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在一个分布式系统中，通常就扮演着缓存这样的角色
- 引入的问题：数据库和缓存的数据一致性问题
- 引入微服务，从业务上进一步拆分应用服务器：从业务功能的角度，把应用服务器，拆分成更多的功能更单一、更简单、更小的服务器
- 综上：所谓的分布式系统，就是想办法引入更多的硬件资源
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
