目录
单机架构
服务器负载过高问题
解决方法
分布式系统
引入更多的服务器节点
负载均衡
数据库读写分离
引入缓存
数据库分库分表
引入微服务
基本概念
应用（Application）/ 系统（System）
模块（Module）/组件（Component）
分布式（Distributed）
集群（Cluster）
主（Master）/从（Slave）
中间件（Middleware）
评价指标（Metric）
可用性（Availability）
响应时长（Response Time RT）
吞吐（Throughput）VS 并发（Concurrent）
分布式小结
单机架构
- 只有一台服务器，该服务器负责所有工作
实例理解
- 此处假定是一个电商网站
- 此处的应用服务，就是写的服务器程序（如 Java Spring 写的 HTTP 服务器）
- 数据库服务 如 MySQL
- MySQL 是一个客户端服务器结构的程序，本体是 MySQL 服务器（存储和组织数据的部分）
注意：
- 绝大多数公司的产品，都是这种单机架构
- 随着计算机硬件性能飞速发展，单台主机的性能也非常高，足以支持非常高的并发 和 非常大的数据存储
服务器负载过高问题
- 如果业务进一步增长，用户数量和数据量均水涨船高，一台主机难以应付的时候，就需要引入更多的硬件资源，引入更多的主机
- 一台主机的硬件资源是有上限的，包括 CPU、内存、硬盘、网络等
- 服务器每收到一个请求，都需消耗上述的资源
- 如果同一时刻，处理的请求多了，此时就可能会导致某个硬件资源 不够用
- 无论是哪个方面不够用了，都可能会导致服务器处理请求的时间边长，甚至处理出错的问题
解决方法
节流
- 软件上优化，通过性能测试，找到哪个环节出现了瓶颈，再对症下药
- 该方式对 程序员水平要求高
开源
- 简单粗暴，直接增加更多的硬件资源
- 当然一台主机上能增加的硬件资源也是有限的，取决于主板的扩展能力
- 当 一台主机扩展到极限 还不够用的情况下，便只能引入多台主机了
- 不是说新的机器买来就直接可以解决问题了，也需要软件上做出对应的调整和适配
- 一旦引入了多台主机了，咱们的系统就可以称之为是 分布式系统
注意：
- 引入分布式，必须是万不得已的
- 因为系统的复杂程度会大大增加，即出现 bug 的概率也会更高
分布式系统
- 多台不同的服务器中部署不同的服务模块
实例理解
- 此处假定是一个电商网站
- 应用服务器，里面可能会包含很多的业务逻辑，可能会吃 CPU 和 内存
- 数据库服务器，需要更大的硬盘空间，更快的数据访问速度，可以配置更大的硬盘服务器，甚至还可以上 固态硬盘
注意：
- 此处我们可以针对不同服务器的特点，来配置不同硬件类型的机器，从而可以达到更高的性价比
引入更多的服务器节点
- 应用服务器是比较吃 CPU 和 内存 的
- 如果把 CPU 或者 内存 吃没了，此时应用服务器就顶不住了
- 则需引入更多的应用服务器，来有效解决上述问题
注意：
- 当机器变多了，管理成本 和 出现问题的概率也会随之提高！
实例理解
- 此处假定是一个电商网站
- Scale Out 译为横向扩展
- 用户的请求先到达 负载均衡器/网关服务器（单独的服务器）
- 假设有 1W 个用户请求，有2 个应用服务器，此时按照负载均衡的方式，就可以让每个应用服务器承担 5k 的访问量
负载均衡
- 负载均衡器的主要功能是将外部发送来的请求均匀分配到多个应用服务器上
- 而应用服务器需要根据请求执行相应的业务逻辑
- 所以 负载均衡器对于请求量的承担能力，要远超过应用服务器
注意：
- 如果请求量大到连负载均衡器也扛不住了的话，引入更多的负载均衡器即可
数据库读写分离
- 虽然增加 应用服务器 确实能够处理更高的请求量
- 但是与此同时 存储服务器 要承担的请求量也会变得更多
- 所以我们可以引入更多的 存储服务器
实例理解
- 此处假定是一个电商网站
- 在实际的应用场景中，读的频率是比写要高的！
- 主服务器一般是一个，从服务器可以有多个（一主多从）
- 同时数据库通过负载均衡的方式，让应用服务器进行访问
引入缓存
- 数据库天然有个问题，响应速度比较慢的（读硬盘）
- 把数据区分 冷热 ，热点数据放到缓存中，缓存的访问速度往往比数据库要快很多
- 热点数据 即会频繁访问到的数据
- 二八原则，即 20% 的数据，能够支持 80% 的访问量
实例理解
- 此处假定是一个电商网站
注意：
- 此处 Redis 便可作为缓存服务器
数据库分库分表
- 引入分布式系统，不光要能够应对更高的请求量（并发量），同时也要能够应对更大的数据量
- 所以可能会出现 一台主机无法存下全部数据的情况，引入多台主机存储即可
实例理解
- 此处假定是一个电商网站
- 由原来的 一个数据库服务器，即 数据库服务器上有多个数据库（database）
- 转变为 引入多个数据库服务器，每个数据库服务器存储一个或一部分数据库（database）
注意：
- 如果某个表特别大，大到一台主机存不下，也可以针对表进行拆分
- 具体分库分表如何实践，还是要结合实际的业务场景来展开
引入微服务
- 之前应用服务器，一个服务器程序里面做了很多的业务
- 这就可能导致这一个服务器的代码变得越来越复杂
- 为了更方便与代码的维护，就可以把这样的一个复杂的服务器，拆分成更多的，功能单一的，但是更小的服务器（微服务）
- 而且随着服务种类和数量增加，我们可以根据业务需求，灵活地调整每个微服务的规模和配置
实例理解
- 此处假定是一个电商网站
注意：
- 当应用服务器复杂了，势必就需要更多的人来维护了
- 微服务的本质上是在解决 人 的问题
- 按照 功能 拆分成多组 微服务，有利于 人员的组织结构 分配
问题：
1. 系统性能的下降
- 拆出来更多的服务，多个功能之间要更依赖 网络通信
- 网络通信的速度很可能是比硬盘还慢！
- 要想保证性能不想下降太多，只能引入更多的机器，更多的硬件资源
2. 系统复杂程度提高，可用性受到影响
- 服务器更多了，出现问题的概率就更大了
- 这就需要一系列手段，来保证系统的可用性（更丰富的监控报警，以及配套的运维人员）
优势：
- 解决了 人 的问题
- 使用微服务，可以更方便于功能的复用
- 可以给不同的服务进行不同的部署（机器硬件配置）
基本概念
应用（Application）/ 系统（System）
- 一个 应用 或 系统，就是 一个或一组服务器程序
模块（Module）/组件（Component）
- 一个应用里面有很多个功能
- 每个独立的功能，就可以称为是一个 模块 或 组件
分布式（Distributed）
- 本质上就是引入多个服务器 或 主机，来协和配合完成一系列的工作
- 物理上的多个主机
集群（Cluster）
- 本质上就是引入多个服务器 或 主机，来协和配合完成一系列的工作
- 逻辑上的多个主机
主（Master）/从（Slave）
- 分布式系统中一种比较典型的结构
- 多个服务器节点，其中一个是主，另外的是从，从节点 的数据要从主节点这里同步过来
中间件（Middleware）
- 和业务无关的服务（功能更通用的服务）
- 如 数据库、缓存、消息队列 等
评价指标（Metric）
可用性（Availability）
- 系统整体可用的时间 ➗ 总的时间
- 一个系统的第一要务
响应时长（Response Time RT）
- 衡量服务器的性能
- 越小越好
- 和具体的服务器要做的业务密切相关
吞吐（Throughput）VS 并发（Concurrent）
- 衡量系统的处理请求的能力
- 衡量性能的一种方式
分布式小结
1、单机架构（应用程序 + 数据库服务器）
2、数据库和应用分离
- 应用程序和数据库服务器 分别放到不同主机上部署了
3、引入负载均衡 把请求比较均匀的分发给集群中的每个应用服务器
- 当集群中的某个机器挂了，其他的主机仍然可以承担服务，提高了整个系统的可用性
4、引入读写分离 数据库主存结构
- 一个数据库节点作为主节点，其他N个数据库节点作为从节点
- 主节点负责写数据，从节点负责读数据
- 主节点现需要把修改过的数据同步给从节点
5、引入缓存 冷热数据分离
- 进一步提升了服务器针对请求的处理能力
- 二八原则
- Redis 在一个分布式系统中通常被用作 缓存
- 引入的问题是 数据库和缓存的数据一致性问题
6、引入分库分表 数据库能够进一步扩展存储空间
7、引入微服务 从业务上进一步拆分应用服务器
- 从业务功能的角度，把应用服务器 拆分成更多的功能更单一、更简单、更小的服务器
注意：
- 上述这样的几个演化的步骤，只是一个粗略的过程
- 实际上一个商业项目，真实的演化过程，都是和它的业务发展密切相关的
- 业务是更重要的，技术只是给业务提供支持的
- 所谓的 分布式系统 就是想办法引入更多的硬件资源来解决当下的业务问题
