。Scale-out（横向扩展）：分而治之是一种常见的高并发系统设计方法，采用分布式部署
的方式把流量分流开，让每个服务器都承担一部分并发和流量。
缓存：使用缓存来提高系统的性能，就好比用“拓宽河道”的方式抵抗高并发大流量的冲
击。
异步：在某些场景下，未处理完成之前，我们可以让请求先返回，在数据准备好之后再通
知请求方，这样可以在单位时间内处理更多的请求。
简单介绍了这三种方法之后，我再详细地带你了解一下，这样当你在设计高并发系统时就可
以有考虑的方向了。当然了，这三种方法会细化出更多的内容，我会在后面的课程中深入讲
解。
首先，我们先来了解第一种方法：Scale-out。
Scale-up vs Scale-out
著名的“摩尔定律”是由 Intel 的创始人之一戈登·摩尔于 1965 年提出的。这个定律提到，
集成电路上可容纳的晶体管的数量约每隔两年会增加一倍。
后来，Intel 首席执行官大卫·豪斯提出“18 个月”的说法，即预计 18 个月会将芯片的性能
提升一倍，这个说法广为流传。
摩尔定律虽然描述的是芯片的发展速度，但我们可以延伸为整体的硬件性能，从 20 世纪后
半叶开始，计算机硬件的性能是指数级演进的。
直到现在，摩尔定律依然生效，在半个世纪以来的 CPU 发展过程中，芯片厂商靠着在有限
面积上做更小的晶体管的黑科技，大幅度地提升着芯片的性能。从第一代集成电路上只有十
几个晶体管，到现在一个芯片上动辄几十亿晶体管的数量，摩尔定律指引着芯片厂商完成了
技术上的飞跃。
但是有专家预测，摩尔定律可能在未来几年之内不再生效，原因是目前的芯片技术已经做到
了 10nm 级别，在工艺上已经接近极限，再往上做，即使有新的技术突破，在成本上也难
以被市场接受。后来，双核和多核技术的产生拯救了摩尔定律，这些技术的思路是将多个
CPU 核心压在一个芯片上，从而大大提升 CPU 的并行处理能力。我们在高并发系统设计上也沿用了同样的思路，将类似追逐摩尔定律不断提升 CPU 性能的
方案叫做 Scale-up（纵向扩展），把类似 CPU 多核心的方案叫做 Scale-out，这两种思路
在实现方式上是完全不同的。
Scale-up，通过购买性能更好的硬件来提升系统的并发处理能力，比方说目前系统 4 核
4G 每秒可以处理 200 次请求，那么如果要处理 400 次请求呢？很简单，我们把机器的
硬件提升到 8 核 8G（硬件资源的提升可能不是线性的，这里仅为参考）。
Scale-out，则是另外一个思路，它通过将多个低性能的机器组成一个分布式集群来共同
抵御高并发流量的冲击。沿用刚刚的例子，我们可以使用两台 4 核 4G 的机器来处理那
400 次请求。
那么什么时候选择 Scale-up，什么时候选择 Scale-out 呢？一般来讲，在我们系统设计初
期会考虑使用 Scale-up 的方式，因为这种方案足够简单，所谓能用堆砌硬件解决的问题就
用硬件来解决，但是当系统并发超过了单机的极限时，我们就要使用 Scale-out 的方式。
Scale-out 虽然能够突破单机的限制，但也会引入一些复杂问题。比如，如果某个节点出现
故障如何保证整体可用性？当多个节点有状态需要同步时，如何保证状态信息在不同节点的
一致性？如何做到使用方无感知的增加和删除节点？等等。其中每一个问题都涉及很多的知
识点，我会在后面的课程中深入地讲解，这里暂时不展开了。
说完了 Scale-out，我们再来看看高并发系统设计的另一种方法：缓存。
使用缓存提升性能
Web 2.0 是缓存的时代，这一点毋庸置疑。缓存遍布在系统设计的每个角落，从操作系统
到浏览器，从数据库到消息队列，任何略微复杂的服务和组件中，你都可以看到缓存的影
子。我们使用缓存的主要作用是提升系统的访问性能，那么在高并发的场景下，就可以支撑
更多用户的同时访问。
那么为什么缓存可以大幅度提升系统的性能呢？我们知道数据是放在持久化存储中的，一般
的持久化存储都是使用磁盘作为存储介质的，而普通磁盘数据由机械手臂、磁头、转轴、盘
片组成，盘片又分为磁道、柱面和扇区，盘片构造图我放在下面了。
盘片是存储介质，每个盘片被划分为多个同心圆，信息都被存储在同心圆之中，这些同心圆
就是磁道。在磁盘工作时盘片是在高速旋转的，机械手臂驱动磁头沿着径向移动，在磁道上读取所需要的数据。我们把磁头寻找信息花费的时间叫做寻道时间。
普通磁盘的寻道时间是 10ms 左右，而相比于磁盘寻道花费的时间，CPU 执行指令和内存
寻址的时间都在是 ns（纳秒）级别，从千兆网卡上读取数据的时间是在μs（微秒）级别。
所以在整个计算机体系中，磁盘是最慢的一环，甚至比其它的组件要慢几个数量级。因此，
我们通常使用以内存作为存储介质的缓存，以此提升性能。
当然，缓存的语义已经丰富了很多，我们可以将任何降低响应时间的中间存储都称为缓存。
缓存的思想遍布很多设计领域，比如在操作系统中 CPU 有多级缓存，文件有 Page Cache
缓存，你应该有所了解。
异步处理
异步也是一种常见的高并发设计方法，我们在很多文章和演讲中都能听到这个名词，与之共
同出现的还有它的反义词：同步。比如，分布式服务框架 Dubbo 中有同步方法调用和异步
方法调用，IO 模型中有同步 IO 和异步 IO。
那么什么是同步，什么是异步呢？以方法调用为例，同步调用代表调用方要阻塞等待被调用
方法中的逻辑执行完成。这种方式下，当被调用方法响应时间较长时，会造成调用方长久的阻塞，在高并发下会造成整体系统性能下降甚至发生雪崩。
异步调用恰恰相反，调用方不需要等待方法逻辑执行完成就可以返回执行其他的逻辑，在被
调用方法执行完毕后再通过回调、事件通知等方式将结果反馈给调用方。
异步调用在大规模高并发系统中被大量使用，比如我们熟知的 12306 网站。当我们订票
时，页面会显示系统正在排队，这个提示就代表着系统在异步处理我们的订票请求。在
12306 系统中查询余票、下单和更改余票状态都是比较耗时的操作，可能涉及多个内部系
统的互相调用，如果是同步调用就会像 12306 刚刚上线时那样，高峰期永远不可能下单成
功。
而采用异步的方式，后端处理时会把请求丢到消息队列中，同时快速响应用户，告诉用户我
们正在排队处理，然后释放出资源来处理更多的请求。订票请求处理完之后，再通知用户订
票成功或者失败。
处理逻辑后移到异步处理程序中，Web 服务的压力小了，资源占用的少了，自然就能接收
更多的用户订票请求，系统承受高并发的能力也就提升了。
既然我们了解了这三种方法，那么是不是意味着在高并发系统设计中，开发一个系统时要把
这些方法都用上呢？当然不是，系统的设计是不断演进的。
罗马不是一天建成的，系统的设计也是如此。不同量级的系统有不同的痛点，也就有不同的
架构设计的侧重点。如果都按照百万、千万并发来设计系统，电商一律向淘宝看齐，IM 全
都学习微信和 QQ，那么这些系统的命运一定是灭亡。因为淘宝、微信的系统虽然能够解决同时百万、千万人同时在线的需求，但其内部的复杂程
度也远非我们能够想象的。盲目地追从只能让我们的架构复杂不堪，最终难以维护。就拿从
单体架构往服务化演进来说，淘宝也是在经历了多年的发展后，发现系统整体的扩展能力出
现问题时，开始启动服务化改造项目的。
我之前也踩过一些坑，参与的一个创业项目在初始阶段就采用了服务化的架构，但由于当时
人力有限，团队技术积累不足，因此在实际项目开发过程中，发现无法驾驭如此复杂的架
构，也出现了问题难以定位、系统整体性能下降等多方面的问题，甚至连系统宕机了都很难
追查到根本原因，最后不得不把服务做整合，回归到简单的单体架构中。
所以我建议一般系统的演进过程应该遵循下面的思路：
最简单的系统设计满足业务需求和流量现状，选择最熟悉的技术体系。
随着流量的增加和业务的变化，修正架构中存在问题的点，如单点问题，横向扩展问题，
性能无法满足需求的组件。在这个过程中，选择社区成熟的、团队熟悉的组件帮助我们解
决问题，在社区没有合适解决方案的前提下才会自己造轮子。
当对架构的小修小补无法满足需求时，考虑重构、重写等大的调整方式以解决现有的问
题。
以淘宝为例，当时在业务从 0 到 1 的阶段是通过购买的方式快速搭建了系统。而后，随着
流量的增长，淘宝做了一系列的技术改造来提升高并发处理能力，比如数据库存储引擎从
MyISAM 迁移到 InnoDB，数据库做分库分表，增加缓存，启动中间件研发等。
当这些都无法满足时就考虑对整体架构做大规模重构，比如说著名的“五彩石”项目让淘宝
的架构从单体演进为服务化架构。正是通过逐步的技术演进，淘宝才进化出如今承担过亿
QPS 的技术架构。
归根结底一句话：高并发系统的演进应该是循序渐进，以解决系统中存在的问题为目的和驱
动力的。
课程小结
在今天的课程中，我带着你了解了高并发系统设计的三种通用方法：Scale-out、缓存和异
步。这三种方法可以在做方案设计时灵活地运用，但它不是具体实施的方案，而是三种思
想，在实际运用中会千变万化。就拿 Scale-out 来说，数据库一主多从、分库分表、存储分片都是它的实际应用方案。而
我们需要注意的是，在应对高并发大流量的时候，系统是可以通过增加机器来承担流量冲击
的，至于要采用什么样的方案还是要具体问题具体分析。02 | 架构分层：我们为什么一定要这么做？
在系统从 0 到 1 的阶段，为了让系统快速上线，我们通常是不考虑分层的。但是随着业务
越来越复杂，大量的代码纠缠在一起，会出现逻辑不清晰、各模块相互依赖、代码扩展性
差、改动一处就牵一发而动全身等问题。
这时，对系统进行分层就会被提上日程，那么我们要如何对架构进行分层？架构分层和高并
发架构设计又有什么关系呢？本节课，我将带你寻找答案。
什么是分层架构
软件架构分层在软件工程中是一种常见的设计方式，它是将整体系统拆分成 N 个层次，每
个层次有独立的职责，多个层次协同提供完整的功能。我们在刚刚成为程序员的时候，会被“教育”说系统的设计要是“MVC”（Model-View
Controller）架构。它将整体的系统分成了 Model（模型），View（视图）和
Controller（控制器）三个层次，也就是将用户视图和业务处理隔离开，并且通过控制器连
接起来，很好地实现了表现和逻辑的解耦，是一种标准的软件分层架构。
另外一种常见的分层方式是将整体架构分为表现层、逻辑层和数据访问层：
表现层，顾名思义嘛，就是展示数据结果和接受用户指令的，是最靠近用户的一层；
逻辑层里面有复杂业务的具体实现；
数据访问层则是主要处理和存储之间的交互。
这是在架构上最简单的一种分层方式。其实，我们在不经意间已经按照三层架构来做系统分
层设计了，比如在构建项目的时候，我们通常会建立三个目录：Web、Service 和 Dao，
它们分别对应了表现层、逻辑层还有数据访问层。
章节小插曲：本篇只总结了"高并发系统设计"的一部分内容，还有更多资源正在整理中包含
JVM、Tomcat、MySQL、Spring、Mybatis、Redis、MongoDB、Mycat、Zookeeper
Nginx、RabbitMq、RocketMq、Kafka、Dubbo、Docker
分布式（架构设计，事务场景策略，场景解决方案，任务调度场景实现）
高并发场景应对方案、性能调优实战、海量数据场景实现、消息服务总线MQ等。
不定期更新中获取可添加助理QQ：【2986706524】
备注：【Java】审核通过后私信：【资料】 即可获取。除此之外，如果我们稍加留意，就可以发现很多的分层的例子。比如我们在大学中学到的
OSI 网络模型，它把整个网络分了七层，自下而上分别是物理层、数据链路层、网络层、传
输层、会话层、表示层和应用层。
工作中经常能用到 TCP/IP 协议，它把网络简化成了四层，即链路层、网络层、传输层和应
用层。每一层各司其职又互相帮助，网络层负责端到端的寻址和建立连接，传输层负责端到
端的数据传输等，同时呢相邻两层还会有数据的交互。这样可以隔离关注点，让不同的层专
注做不同的事情。Linux 文件系统也是分层设计的，从下图你可以清晰地看出文件系统的层次。在文件系统的
最上层是虚拟文件系统（VFS），用来屏蔽不同的文件系统之间的差异，提供统一的系统调
用接口。虚拟文件系统的下层是 Ext3、Ext4 等各种文件系统，再向下是为了屏蔽不同硬件
设备的实现细节，我们抽象出来的单独的一层——通用块设备层，然后就是不同类型的磁
盘了。
我们可以看到，某些层次负责的是对下层不同实现的抽象，从而对上层屏蔽实现细节。比方
说 VFS 对上层（系统调用层）来说提供了统一的调用接口，同时对下层中不同的文件系统
规约了实现模型，当新增一种文件系统实现的时候，只需要按照这种模型来设计，就可以无
缝插入到 Linux 文件系统中。那么，为什么这么多系统一定要做分层的设计呢？答案是分层设计存在一定的优势。
分层有什么好处
分层的设计可以简化系统设计，让不同的人专注做某一层次的事情。想象一下，如果你要设
计一款网络程序却没有分层，该是一件多么痛苦的事情。
因为你必须是一个通晓网络的全才，要知道各种网络设备的接口是什么样的，以便可以将数
据包发送给它。你还要关注数据传输的细节，并且需要处理类似网络拥塞，数据超时重传这
样的复杂问题。当然了，你更需要关注数据如何在网络上安全传输，不会被别人窥探和篡
改。
而有了分层的设计，你只需要专注设计应用层的程序就可以了，其他的，都可以交给下面几
层来完成。
再有，分层之后可以做到很高的复用。比如，我们在设计系统 A 的时候，发现某一层具有
一定的通用性，那么我们可以把它抽取独立出来，在设计系统 B 的时候使用起来，这样可
以减少研发周期，提升研发的效率。最后一点，分层架构可以让我们更容易做横向扩展。如果系统没有分层，当流量增加时我们
需要针对整体系统来做扩展。但是，如果我们按照上面提到的三层架构将系统分层后，那么
我们就可以针对具体的问题来做细致的扩展。
比如说，业务逻辑里面包含有比较复杂的计算，导致 CPU 成为性能的瓶颈，那这样就可以
把逻辑层单独抽取出来独立部署，然后只对逻辑层来做扩展，这相比于针对整体系统扩展所
付出的代价就要小的多了。
这一点也可以解释我们课程开始时提出的问题：架构分层究竟和高并发设计的关系是怎样
的？在“01 | 高并发系统：它的通用设计方法是什么？”中我们了解到，横向扩展是高并
发系统设计的常用方法之一，既然分层的架构可以为横向扩展提供便捷， 那么支撑高并发
的系统一定是分层的系统。
如何来做系统分层
说了这么多分层的优点，那么当我们要做分层设计的时候，需要考虑哪些关键因素呢？
在我看来，最主要的一点就是你需要理清楚每个层次的边界是什么。你也许会问：“如果按
照三层架构来分层的话，每一层的边界不是很容易就界定吗？”
没错，当业务逻辑简单时，层次之间的边界的确清晰，开发新的功能时也知道哪些代码要往
哪儿写。但是当业务逻辑变得越来越复杂时，边界就会变得越来越模糊，给你举个例子。
任何一个系统中都有用户系统，最基本的接口是返回用户信息的接口，它调用逻辑层的
GetUser 方法，GetUser 方法又和 User DB 交互获取数据，就像下图左边展示的样子。
这时，产品提出一个需求，在 APP 中展示用户信息的时候，如果用户不存在，那么要自动
给用户创建一个用户。同时，要做一个 HTML5 的页面，HTML5 页面要保留之前的逻辑，
也就是不需要创建用户。这时逻辑层的边界就变得不清晰，表现层也承担了一部分的业务逻
辑（将获取用户和创建用户接口编排起来）。
章节小插曲：本篇只总结了"高并发系统设计"的一部分内容，还有更多资源正在整理中包含
JVM、Tomcat、MySQL、Spring、Mybatis、Redis、MongoDB、Mycat、Zookeeper
Nginx、RabbitMq、RocketMq、Kafka、Dubbo、Docker
分布式（架构设计，事务场景策略，场景解决方案，任务调度场景实现）
高并发场景应对方案、性能调优实战、海量数据场景实现、消息服务总线MQ等。
不定期更新中获取可添加助理QQ：【2986706524】
备注：【Java】审核通过后私信：【资料】 即可获取。那我们要如何做呢？参照阿里发布的《阿里巴巴 Java 开发手册 v1.4.0（详尽版）》，我们
可以将原先的三层架构细化成下面的样子：我来解释一下这个分层架构中的每一层的作用。
终端显示层：各端模板渲染并执行显示的层。当前主要是 Velocity 渲染，JS 渲染， JSP
渲染，移动端展示等。
开放接口层：将 Service 层方法封装成开放接口，同时进行网关安全控制和流量控制等。
Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理
等。
Service 层：业务逻辑层。
Manager 层：通用业务处理层。这一层主要有两个作用，其一，你可以将原先 Service
层的一些通用能力下沉到这一层，比如与缓存和存储交互策略，中间件的接入；其二，你
也可以在这一层封装对第三方接口的调用，比如调用支付服务，调用审核服务等。
DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase 等进行数据交互。
外部接口或第三方平台：包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接
口。在这个分层架构中主要增加了 Manager 层，它与 Service 层的关系是：Manager 层提供
原子的服务接口，Service 层负责依据业务逻辑来编排原子接口。
以上面的例子来说，Manager 层提供创建用户和获取用户信息的接口，而 Service 层负责
将这两个接口组装起来。这样就把原先散布在表现层的业务逻辑都统一到了 Service 层，每
一层的边界就非常清晰了。
除此之外，分层架构需要考虑的另一个因素，是层次之间一定是相邻层互相依赖，数据的流
转也只能在相邻的两层之间流转。
我们还是以三层架构为例，数据从表示层进入之后一定要流转到逻辑层，做业务逻辑处理，
然后流转到数据访问层来和数据库交互。那么你可能会问：“如果业务逻辑很简单的话可不
可以从表示层直接到数据访问层，甚至直接读数据库呢？”
其实从功能上是可以的，但是从长远的架构设计考虑，这样会造成层级调用的混乱，比方说
如果表示层或者业务层可以直接操作数据库，那么一旦数据库地址发生变更，你就需要在多
个层次做更改，这样就失去了分层的意义，并且对于后面的维护或者重构都会是灾难性的。
分层架构的不足
任何事物都不可能是尽善尽美的，分层架构虽有优势也会有缺陷，它最主要的一个缺陷就是
增加了代码的复杂度。
这是显而易见的嘛，明明可以在接收到请求后就可以直接查询数据库获得结果，却偏偏要在
中间插入多个层次，并且有可能每个层次只是简单地做数据的传递。有时增加一个小小的需
求也需要更改所有层次上的代码，看起来增加了开发的成本，并且从调试上来看也增加了复
杂度，原本如果直接访问数据库我只需要调试一个方法，现在我却要调试多个层次的多个方
法。
另外一个可能的缺陷是，如果我们把每个层次独立部署，层次间通过网络来交互，那么多层
的架构在性能上会有损耗。这也是为什么服务化架构性能要比单体架构略差的原因，也就是
所谓的“多一跳”问题。
那我们是否要选择分层的架构呢？答案当然是肯定的。你要知道，任何的方案架构都是有优势有缺陷的，天地尚且不全何况我们的架构呢？分层架
构固然会增加系统复杂度，也可能会有性能的损耗，但是相比于它能带给我们的好处来说，
这些都是可以接受的，或者可以通过其它的方案解决的。我们在做决策的时候切不可以偏概
全，因噎废食。
课程小结
今天我带着你了解了分层架构的优势和不足，以及我们在实际工作中如何来对架构做分层。
我想让你了解的是，分层架构是软件设计思想的外在体现，是一种实现方式。我们熟知的一
些软件设计原则都在分层架构中有所体现。
比方说，单一职责原则规定每个类只有单一的功能，在这里可以引申为每一层拥有单一职
责，且层与层之间边界清晰；迪米特法则原意是一个对象应当对其它对象有尽可能少的了
解，在分层架构的体现是数据的交互不能跨层，只能在相邻层之间进行；而开闭原则要求软
件对扩展开放，对修改关闭。它的含义其实就是将抽象层和实现层分离，抽象层是对