一. 概念解释

1. 应用（Application）/ 系统（System）

一个应用, 就是一个/一组服务器程序

2. 模块（Module）/ 组件（Component）

一个应用, 里面有很多功能, 每个独立的功能, 就可以称为是一个模块/组件

3. 分布式（Distributed）

系统中的多个模块被部署于不同服务器之上，即可以将该系统称为分布式系统。如 Web 服务器与
数据库分别⼯作在不同的服务器上，或者多台 Web 服务器被分别部署在不同服务器上。

4. 集群（Cluster）

被部署于多台服务器上的、为了实现特定⽬标的⼀个/组特定的组件，整个整体被称为集群。

分布式 vs 集群。通常不⽤太严格区分两者的细微概念，细究的话，分布式强调的是物理形态，即
⼯作在不同服务器上并且通过⽹络通信配合完成任务；⽽集群更在意逻辑形态，即是否为了完成特定
服务⽬标。

5. 主（Master）/ 从（Slave）

集群中，通常有⼀个程序需要承担更多的职责，被称为主；其他承担附属职责的被称为从。⽐如
MySQL 集群中，只有其中⼀台服务器上数据库允许进⾏数据的写⼊（增/删/改），其他数据库的数据
修改全部要从这台数据库同步⽽来，则把那台数据库称为主库，其他数据库称为从库。

6. 中间件（Middleware）

和业务无关的服务, 例如数据库, 缓存, 消息队列…

7. 可用性（Availability）

考察单位时间段内，系统可以正常提供服务的时间 / 总的时间
平时我们常说的 4 个 9 即系统可以提供 99.99% 的可⽤性，5 个 9 是 99.999% 的可⽤性，以此类推。
我们平时只是⽤⾼可⽤（High Availability HA）这个⾮量化⽬标简要表达我们系统的追求。

8. 响应时长（Response Time RT）

指用户完成输⼊到系统给出用户反应的时长。
这个指标原则上是越⼩越好，但很多情况下由于实现的限制，需要根据实际情况具体判断

9. 吞吐（Throughput）vs 并发（Concurrent）

吞吐考察单位时间段内，系统可以成功处理的请求的数量。
并发指系统同⼀时刻⽀持的请求最高量。
实践中，并发量往往⽆法直接获取，很多时候都是⽤极短的时间段（⽐如 1 秒）的吞吐量做代替。
我们平时用高并发（Hight Concurrnet）这个⾮量化⽬标简要表达系统的追求。

二. 架构演进

1. 单机架构

只有一台服务器, 这个服务器负责所有的工作

应用服务, 指的是我们写的服务器程序
数据库服务, 值得指的是如MySQL
如果业务进一步增长, 用户量和数据量都变多, 服务器不够用的场景:

1. 开源
   增加更多的硬件资源
   但是, 一个主机上面能增加的硬件资源也是有限的, 取决于主板的扩展能力
   如果一台主机扩展到极限了, 还是不够用, 这时就要引入多台主机了, 此时的系统就叫做**“分布式系统”**
   但是并不是引入更多的主机就可以解决问题, 还需要在软件上做出对应的调整
   (引入分布式, 是万不得已, 系统的复杂程度会大大提高, 出现bug的概率也会提高)
2. 节流
   在软件上进行优化
   (需要进行性能测试, 找到是哪个环节出现了瓶颈, 再去对症下药, 是很困难的)

2. 应用数据分离架构

应用服务和数据服务分离

应用服务器, 包含更多的业务逻辑, 会更吃CPU和内存
数据库服务器, 需要更大的硬盘空间, 更快地数据访问速度
(机械硬盘, 便宜, 慢 固态硬盘(SSD硬盘), 贵, 快)
可以根据不痛的作用来选择不同配置的服务器, 达到更高的性价比

3. 应用服务集群架构

引入更多的应用服务器

负载均衡, 就像一个组的领导一样, 要负责管理, 要负责把任务分配给每一个组员
用户的请求, 先到达负载均衡器/网关服务器(单独的服务器)
如果请求量达到一个负载均衡器也扛不住了, 就需要引入更多的负载均衡器(引入多个机房)
与此同时, 存储服务器要承担的服务器也就更多了

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

实际的应用场景, 读的频率是要比写高的

主服务器一般是一个, 从服务器可以有多个
但是数据库响应速度是很慢的

5. 引入缓存----冷热分离架构

把数据区分"冷热", 热点数据放在缓存中, 缓存的访问速度往往比数据库要快很多
(二八原则: 20%的数据, 能够支持80%的访问量)
但是缓存, 存储空间小

Redis在一个分布式系统中, 通常就扮演者缓存这样的角色

6. 垂直分库分表

针对数据库进行进一步拆分

本来一个数据库服务器, 这个数据库服务器上可能有多个数据库(database)
现在就可以引入多个数据库服务器, 每个数据库服务器存储一个或一部分数据库(如果某个表特别大, 也可以根据表进行拆分)

7. 微服务架构

之前的应用服务器, 一个服务器程序里面做个很多业务, 这就可能会导致一个服务器的代码也越来越复杂
为了方便代码维护, 就可以把这样的一个复杂的服务器, 拆分成更多的, 功能更单一, 但是更小的服务器, 称为微服务

微服务, 本质上是在解决"人"的问题
当应用服务器复杂了, 就需要更多的人来维护, 人多了, 就需要配套的管理, 把这些人组织好, 划分组织结构, 分成多个组, 就要将业务按照功能, 拆分成多组微服务

引入微服务, 付出的代价:

1. 系统性能下降
   拆分出更多的服务, 多个功能之间要更依赖网络通信, 网络通信的速度很可能是比硬盘还要慢的
   (现在硬件技术, 网卡有万兆网卡, 读写速度已经能超过硬盘读写了, 但就是贵!!)
2. 系统复杂程度提高, 可用性受到影响
   服务器多了, 出现问题的概率就更大了, 就需要一系列手段, 保证徐彤的可用性

微服务的优势:

1. 解决了人的问题
2. 使用微服务, 可以更方便于功能的复用
3. 可以给不同的服务, 进行不同的部署