概述
在进行技术学习过程中，由于没有经历过一些中大型系统的实际经验， 导致无法从全局理解一些概念，所以本文以一个 "电子商务 " 应用为例，介绍从一百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，方便大家对后续知识做深入学习时 有一定的整体视野
常见概念
在正式引入架构演进之前，为避免对架构中的概念完全不了解导致低效沟通， 优先对其中一些比较重要的概念做前置介绍
应用（Application）/ 系统（ System）
为了完成一整套服务的一个程序或者一组相互配合的程序群。生活例子类比：为 了完成一项任务，而搭建的由一个人或者一群相互配的人组成的团队。
模块（Module）/ 组件（ Component）
当应用较复杂时，为了分离职责，将其中具有清晰职责的、内聚性强的部分，抽 象出概念，便于理解。生活例子类比：军队中为了进行某据点的攻克，将人员分为突击小组、爆破小组、掩护小组、通信小组等
分布式（ Distributed）
系统中的多个模块被部署于不同服务器之上，即可以将该系统称为分布式系统。 如 Web 服务器与数据库分别工作在不同的服务器上，或者多台 Web 服务器被分别部 署在不同服务器上。生活例子类比：为了更好的满足现实需要，一个在同一个办公场 地的工作小组被分散到多个城市的不同工作场地中进行远程配合工作完成目标。跨主机之间的模块之间的通信基本要借助网络支撑完成。
集群（Cluster）
被部署于多台服务器上的、为了实现特定目标的一个 组特定的组件，整个整体被 称为集群。比如多个 MySQL 工作在不同服务器上，共同提供数据库服务目标，可以 被称为一组数据库集群。生活例子类比：为了解决军队攻克防守坚固的大城市的作战 目标，指挥部将大批炮兵部队集中起来形成一个炮兵打击集群。
分布式 vs 集群。通常不用太严格区分两者的细微概念，细究的话，分布式强调的是物理形态，即工作在不同服务器上并且通过网络通信配合完成任务；而集群更在意逻辑形态，即是否为了完成特定服务目标。
主（ Master）/ 从（ Slave）
集群中，通常有一个程序需要承担更多的职责，被称为主；其他承担附 属职责的被称为从。比如 MySQL 集群中，只有其中一台服务器上数据库允许进行数据的写入 （增 /删/改），其他数据库的数据修改全部要从这台数据库同步而来，则把那台数据库称为主库，其他数据库称为从库。
中间件（ Middleware）
一类提供不同应用程序用于相互通信的软件，即处于不同技术、工具和数据库之间的桥梁。生活例子类比：一家饭店开始时，会每天去市场挑选买菜，但随着饭店业务量变大，成立一个采购部，由采购部专职于采买业务，称为厨房和菜市场之间的桥梁
容器编排(K8S)
kubernetes，简称 K8s ，是用 8代替名字中间的 8个字符 “ 而成的缩写。 是一个开源的，用于管理云平台中多个主机上的容器化 的应用， Kubernetes 的目标是让部署容器化的应用简单并且高效。可以理解为一个货船，安装集装箱的大小，货物情况合理的来组织集装箱完成整体货物的搬运。
可用性（ 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）这个非量化目标简要表达系统的追求。