目录
一、常见概念
应用（Application） / 系统（System）
模块（Module） / 组件（Component）
分布式（Distributed）
集群（Cluster）
主（Master） / 从（Slave）
中间件（Middleware）
容器（Docker）
容器编排（K8S）
评价指标（Metric）
可用性（Availability）
响应时长（Response Time RT）
吞吐（Throughput） vs 并发（Concurrent）
二、架构演进
单机架构
1.简介
2.出现原因
3.架构工作原理
4.技术案例
5.架构优缺点
6.相关软件
应用数据分离架构
1.简介
2.出现原因
3.架构工作原理
4.技术案例
5.架构优缺点
应用服务集群架构
1.简介
2.出现原因
3.架构工作原理
4.技术案例
5.架构优缺点
一、常见概念
应用（Application） / 系统（System）
为了完成一整套服务的一个程序或者一组相互配合的程序群。生活例子类比：为了完成一项任务，而搭建的由一个人或者一群相互配的人组成的团队
模块（Module） / 组件（Component）
当应用较复杂时，为了分离职责，将其中具有清晰职责的、内聚性强的部分，抽象出概念，便于理解。生活例子类比：军队中为了进行某据点的攻克，将人员分为突击小组、爆破小组、掩护小组、通信小组等
分布式（Distributed）
系统中的多个模块被部署于不同服务器之上，即可以将该系统称为分布式系统。如 Web 服务器与数据库分别工作在不同的服务器上，或者多台 Web 服务器被分别部署在不同服务器上。生活例子类比：为了更好的满足现实需要，一个在同一个办公场地的工作小组被分散到多个城市的不同工作场地中进行远程配合工作完成目标。跨主机之间的模块之间的通信基本要借助网络支撑完成
集群（Cluster）
被部署于多台服务器上的、为了实现特定目标的一个/组特定的组件，整个整体被称为集群。比如多个 MySQL 工作在不同服务器上，共同提供数据库服务目标，可以被称为一组数据库集群。生活例子类比：为了解决军队攻克防守坚固的大城市的作战目标，指挥部将大批炮兵部队集中起来形成一个炮兵打击集群
分布式 vs 集群：通常不用太严格区分两者的细微概念，细究的话，分布式强调的是物理形态，即工作在不同服务器上并且通过网络通信配合完成任务；而集群更在意逻辑形态，即是否为了完成特定服务目标
主（Master） / 从（Slave）
集群中，通常有一个程序需要承担更多的职责，被称为主；其他承担附属职责的被称为从。比如 MySQL 集群中，只有其中一台服务器上数据库允许进行数据的写入（增/删/改），其他数据库的数据修改全部要从这台数据库同步而来，则把那台数据库称为主库，其他数据库称为从库
中间件（Middleware）
一类提供不同应用程序用于相互通信的软件，即处于不同技术、工具和数据库之间的桥梁。生活例子类比：一家饭店开始时，会每天去市场挑选买菜，但随着饭店业务量变大，成立一个采购部，由采购部专职于采买业务，称为厨房和菜市场之间的桥梁
容器（Docker）
Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux 或 Windows 操作系统的机器上，也可以实现虚拟化。可以理解为一个集装箱，集装箱里面是每个用户的货物，整体打包
容器编排（K8S）
kubernetes，简称 K8s，是用 8 代替名字中间的 8 个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用， Kubernetes 的目标是让部署容器化的应用简单并且高效。可以理解为一个货船，安装集装箱的大小，货物情况合理的来组织集装箱完成整体货物的搬运
评价指标（Metric）
可用性（Availability）
考察单位时间段内，系统可以正常提供服务的概率/期望。例如： 年化系统可用性= 系统正常提供服务时长 / 一年总时长。这里暗含着一个指标，即如何评价系统提供无法是否正常，我们就不深入了。平时我们常说的 4 个 9 即系统可以提供 99.99% 的可用性， 5 个 9 是 99.999% 的可用性，以此类推。我们平时只是用高可用（High Availability HA）这个非量化目标简要表达我们系统的追求
响应时长（Response Time RT）
用户完成输入到系统给出用户反应的时长。例如点外卖业务的响应时长 = 拿到外卖的时刻 - 完成点单的时刻。通常我们需要衡量的是最长响应时长、平均响应时长和中位数响应时长。这个指标原则上是越小越好，但很多情况下由于实现的限制，需要根据实际情况具体判断
吞吐（Throughput） vs 并发（Concurrent）
吞吐考察单位时间段内，系统可以成功处理的请求的数量。并发指系统同一时刻支持的请求最高量。例如一条 2 车道高速公路，一分钟可以通过 20 辆车，则并发是 2，一分钟的吞吐量是 20。实践中，并发量往往无法直接获取，很多时候都是用极短的时间段（比如 1 秒）的吞吐量做代替。我们平时用高并发（Hight Concurrnet）这个非量化目标简要表达系统的追求
二、架构演进
单机架构
1.简介
应用服务和数据库服务共用一台服务器
2.出现原因
出现在互联网早期，访问量比较小，单机足以满足需求
3.架构工作原理
以电子商城为例，可以看到通过应用(划分了多个模块)和数据库在单个服务器上协作完成业务运行
4.技术案例
5.架构优缺点
（1）优点：部署简单，成本低
（2）缺点：存在严重的性能瓶颈，数据库和应用互相竞争资源
6.相关软件
Web 服务器软件： Tomcat、 Netty、 Nginx、 Apache 等
数据库软件： MySQL、 Oracle、 PostgreSQL、 SQL Server 等
应用数据分离架构
1.简介
应用服务和数据库服务使用不同服务器
2.出现原因
单机存在严重的资源竞争，导致站点变慢
3.架构工作原理
以电子商城为例，可以看到应用(划分了多个块)和数据库在各自的服务器上通过网络协作完
成业务运行
4.技术案例
5.架构优缺点
（1）优点：成本相对可控；性能相比单机有提升；数据库单独隔离，不会因为应用把数据库搞坏有一定的容灾能力
（2）缺点：硬件成本变高；性能有瓶颈，无法应对海量并发
应用服务集群架构
1.简介
引入了负载均衡，应用以集群方式运作
2.出现原因
单个应用不足以支持海量的并发请求，高并发的时候站点响应变慢
3.架构工作原理
以电子商城为例，可以看到应用不再是一个，而是变成了多个,通过负载均衡来支持海量的并发
4.技术案例
5.架构优缺点
（1）优点：应用服务高可用:应用满足高可用，不会一个服务出问题整个站点挂掉；应用服务具备一定高性能:如果不访问数据库应用相关处理通过扩展可以支持海量请求快速响应；应用服务有一定扩展能力:支持横向扩展
（2）缺点：数据库成为性能瓶颈，无法应对数据库的海量查询；数据库是单点，没有高可用；运维工作增多，扩展后部署运维工作增多，需要开发对应的工具应对快速部罢；硬件成本较高
