学习笔记: 架构师训练营 - 第四周

1、系统架构在互联网中有哪些挑战

• 高并发、大流量：高并发用户和大流量访问

• 高可用：系统 7x24 小时不间断服务

• 海量数据：需要管理和存储海量数据

• 用户分布广泛，网络情况复杂

• 安全环境恶劣：易受黑客攻击

• 需求快速变更，发布频繁：快速变更需求，发布新版本

• 渐进式发展：大型网站都是从小型网站渐进的发展起来

2、高并发挑战的两个方向

2.1、关键指标

• 响应时间：系统对请求做出响应的时间。例如系统处理一个 HTTP 请求需要 200ms，这个 200ms 就是系统的响应时间

• 吞吐量：单位时间内处理的请求数量

• 每秒查询率 QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显

• 并发用户数等：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

2.2、与多线程之间的关系

高并发和多线程”总是被一起提起，给人感觉两者好像相等，实则 高并发 ≠ 多线程。线程是完成任务的一种方法，高并发是系统运行的一种状态，通过多线程有助于系统承受高并发状态的实现。

高并发是一种系统运行过程中遇到的一种“短时间内遇到大量操作请求”的情况，主要发生在 web 系统集中大量访问或者 socket 端口集中性收到大量请求（例如：12306 的抢票情况；天猫双十一活动）。该情况的发生会导致系统在这段时间内执行大量操作，例如对资源的请求，数据库的操作等。如果高并发处理不好，不仅仅降低了用户的体验度（请求响应时间过长），同时可能导致系统宕机，严重的甚至导致 OOM 异常，系统停止工作等。如果要想系统能够适应高并发状态，则需要从各个方面进行系统优化，包括，硬件、网络、系统架构、开发语言的选取、数据结构的运用、算法优化、数据库优化……而多线程只是其中解决方法之一。

2.3、两个方向之垂直伸缩

在单一服务器上不断扩充自己的计算资源，提升自己的处理能力以此来应对高并发的用户请求访问压力，通过升级硬件和网络吞吐能力可以实现垂直伸缩。由于不需要改变应用架构，所以通常被认为是最简单的短期伸缩性方案

• 通过使用 RAID（独立冗余磁盘阵列）增加 I/O 吞吐能力。

• 通过切换到 SSD（固态硬盘）改善 I/O 访问速度。

• 通过增加内存减少 I/O 操作 。

• 通过升级网络接口或者增加网络接口提高网络吞吐能力。

• 更新服务器使用更多处理器或者更多超线程。

缺点：

• 达到某个程度后，增加计算能力需要的更多的花费

• 垂直伸缩有物理极限

• 操作系统的设计或者应用程序自身 制约着垂直伸缩最多只能达到某个点

2.4、两个方向之水平扩展

• 水平伸缩是指通过增加服务器提升计算能力的一类架构方法

• 水平伸缩被认为是伸缩性的圣杯，水平伸缩可以克服垂直伸缩带来的单位计算成本随计算能力增加而迅速飙升的问题

• 另外，水平伸缩总是可以增加更多服务器，这样，就不会像垂直伸缩那样遭遇到单台服务器的极限

对架构技术、架构要求、开发要求又带来了新的挑战！

3、互联网架构演化

摘自《大型网站技术架构-核心原理与案例分析》

3.1、架构演化第零阶段：最简单的互联网应用架构

应用程序、数据库以及文件服务都部署在一台服务器中为单体应用，当应用程序、数据库、文件服务器其中之一宕机时，会造成服务不可用，并且服务并发数量不高

3.2、架构演化第一阶段：应用数据分离

应用服务器、数据库、文件服务分别部署在多态服务器中，服务内部局域网互相访问，提高单台服务器利用率，根据不同服务的硬件要求做出响应的配置：应用服务器需要处理大量的业务逻辑，因此需要更快更强大的 CPU；数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存；文件服务器需要存储大量用户上传的文件，因此需要更大的硬盘。

同样会随着用户逐渐增多，数据库压力过大导致访问延迟。

3.3、架构演化第二阶段：使用缓存改善系统性能

为了解决数据库压力过大，使用缓存来改善数据访问性能，将系统中热点数据加载到缓存中。缓存分为本地缓存和远程分布式缓存，本地缓存虽然快，但受限于应用服务器内存限制，缓存数量有限以及和应用服务争抢内存，而远程分布式缓存使用集群的方式，部署在大内存的服务器中，理论上可以做到不受内存影响。

虽然解决了数据库压力过大的问题，但是应用服务器处理接收到的请求是有限的，同样会带来系统访问瓶颈。

3.4、架构演化第三阶段：使用应用服务器集群改善系统的并发处理能力

当一台服务器的处理能力、存储空间不足时，使用水平扩展，利用集群来解决高并发、海量数据问题，因为单台服务器的处理能力、存储空间是有限的。对网站架构而言，只要能通过增加一台服务器的方式改善负载压力，就可以以同样的方式持续增加服务器不断改善系统性能，从而实现系统的可伸缩性。

通过负载均衡调度服务器，可将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不再成为整个网站的瓶颈。

3.5、架构演化第四阶段：数据库读写分离

网站在使用缓存后，使绝大部分数据读操作访问都可以不通过数据库就能完成，但是仍有一部分读操作（缓存访问不命中、缓存过期）和全部的写操作需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。

目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能，实现数据库读写分离，从而改善数据库负载压力。

应用服务器在写数据的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库获得数据。为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离对应用透明。

3.6、架构演化第五阶段：使用反向代理和 CDN 加速网站响应

随着网站业务不断发展，用户规模越来越大，由于中国复杂的网络环境，不同地区的用户访问网站时，速度差别也极大。加速网站访问速度主要手段有使用 CDN 和反向代理，CDN 和反向代理的基本原理都是缓存，区别在于 CDN 部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户

3.7、架构演化第六阶段：使用分布式文件系统和分布式数据库系统

任何强大的单一服务器都满足不了大型网站持续增长的业务需求。数据库经过读写分离后，从一台服务器拆分成两台服务器，但是随着网站业务的发展依然不能满足需求，这时需要使用分布式数据库。文件系统也是一样，需要使用分布式文件系统。

分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。不到不得已时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上

3.8、架构演化第七阶段：使用 NoSQL 和搜索引擎

随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂，网站需要采用一些非关系数据库技术如 NoSQL 和非数据库查询技术如搜索引擎。NoSQL 和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

3.9、架构演化第八阶段：业务拆分

大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务分成不同的产品线，如大型购物交易网站就会将首页、商铺、订单、买家、卖家等拆分成不同的产品线，分归不同的业务团队负责。

具体到技术上，也会根据产品线划分，将一个网站拆分成许多不同的应用，每个应用独立部署维护。应用之间可以通过一个超链接建立关系（在首页上的导航链接每个都指向不同的应用地址），也可以通过消息队列进行数据分发，当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

3.10、架构演化第九阶段：微服务及中台化

随着业务拆分越来越小，存储系统越来越庞大，应用系统的整体复杂度呈指数级增加，部署维护越来越困难。由于所有应用要和所有数据库系统连接，在数万台服务器规模的网站中，这些连接的数目是服务器规模的平方，导致存数据库接资源不足，拒绝服务。

既然每一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。由这些可复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用共用业务服务完成具体业务操作，大型网站的架构演化到这里，基本上大多数的技术问题都得以解决，诸如跨数据中心的实时数据同步和具体网站业务相关的问题也都可以通过组合改进现有技术架构来解决。

3.11、架构演化第十阶段 大数据与智能化

对于不用的用户显示不同的信息，智能化的推荐使用每个人看到的都是自己感兴趣的信息，典型案例：今日头条，每个人看到的内容不一样，不通的地区显示的新闻不同，其本质是构建大数据平台，通过对大数据进行分析，根据每个人不同的喜好分析出各自的内容。

4、架构的模式与要素

模式的关键在于模式的可重复性，问题与场景的可重复性带来解决方案的可重复使用，互联网架构模式就是试图去描述那些为解决互联网系统高性能、高可用、易扩展、可伸 缩、安全等目标，被很多互联网应用重复使用的一些解决方案，这些解决方案是互联网 软件系统的重要组成部分。

• 分层：分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分， 每个部分负责一部分相对比较单一的职责，然后通过上层对下层依赖和调用组成一个完 整的系统。

• 分割：如果说分层是将软件在横向方面进行切分，那么分割就是在纵向方面对软件进行切分。系统越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于软件的开发和维护；另一方面， 便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。

• 分布式：对于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着解决同样的问 题可以使用更多的计算机，计算机越多，CPU、内存、存储资源也就越多，能够处理的并发访问和数据量就越大：分布式应用和服务、分布式静态资源、分布式数据和存储、分布式计算。

• 集群：使用分布式虽然已经将分层和分割后的模块独立部署，但是对于用户访问集中的模块， 比如网站的首页，还需要将独立部署的服务器集群化，即多台服务器部署相同应用构成 一个集群，通过负载均衡设备共同对外提供服务。

• 缓存：缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第 一手段，现代 CPU 越来越快的一个重要因素就是使用了更多的缓存，在复杂的软件设计 中，缓存几乎无处不在。大型网站架构设计在很多方面都使用了缓存设计：CDN、反向代理、本地缓存、远程缓存

• 异步：计算机软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间越少直接关系， 那么就越少被彼此影响，越可以独立发展。大型网站架构中，系统解耦合的手段除了前 面提到的分层、分割、分布等手段，还有一个重要手段是异步，就是将一个业务操作分 成多个阶段，每个阶段之间通过共享数据而不是直接调用的方法进行协作：提高系统可用性、加快网站响应速度、消除并发访问高峰

• 冗余：互联网应用需要 7×24 小时连续运行，但是服务器总有可能会出现故障，特别是服务器规 模比较大的时候，服务器宕机是必然事件。要想保证在服务器宕机的情况下网站依然可 以继续服务，数据不会丢失，就需要一定程度的服务器冗余运行，数据冗余备份

• 自动化：在无人值守的情况下网站可以正常运行，一切都可以自动化是网站的理想状态。目前互 联网的自动化架构设计主要集中在运维方面。

• 安全：互联网的开放特性使得其从诞生起就面对巨大的安全挑战，网站在安全架构方面也积累了许多模式：通过密码和手机校验码进行身份认证；登录、交易等操作需要对网络通讯 进行加密，网站服务器上存储的敏感数据如用户信息等也进行加密处理；为了防止机器 人程序滥用网络资源供给网站，网站使用验证码进行识别；对于常见的用于攻击网站的 XSS 攻击，SQL 注入，进行编码转换等相应处理；对于垃圾信息、敏感信息进行过滤； 对转账交易等重要操作根据交易模式和交易信息进行风险控制

5、互联网系统架构核心要素 如何衡量一个系统的架构设计

5.1、高性能

性能是互联网的一个重要指标，除非是没得选择，否则用户无法忍受一个响应缓慢的应用。一个打开缓慢应用会导致严重的用户流失，很多时候系统性能问题是系统架构升级优化的触发器。可以说性能是互联网系统架构设计的一个重要方面，任何架构设计方案都必须考虑可能会带来的性能问题。

也正是因为性能问题几乎无处不在，所以优化网站性能的手段也非常多，从用户端到数据库，从代码到机房部署，影响用户请求的所有环节都可以进行性能优化。

5.2、高可用

保证服务 7X24 小时可用，系统高可用的主要手段是冗余，应用部署在多台服务器上同时提供访问，数据存储在多台服务器上互相备份，任何一台服务器宕机都不会影响应用的整体可用，也不会导致数据丢失

5.3、可伸缩

伸缩性：指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增 长的数据存储需求。

衡量架构伸缩性的主要标准就是是否可以用多台服务器构建集群，是否容易向集群中添 加新的服务器。加入新的服务器后是否可以提供和原来的服务器无差别的服务。集群中 可容纳的总的服务器数量是否有限制。

5.4、可扩展

衡量系统架构扩展性好坏的主要标准就是在系统增加新的业务产品时，是否可以实现对 现有产品透明无影响，不需要任何改动或者很少改动既有业务功能就可以上线新产品。 不同产品之间是否很少耦合，一个产品改动对其他产品无影响，其他产品和功能不需要 受牵连进行改动。

可扩展架构的主要手段是事件驱动架构和分布式服务。

5.5、安全

衡量系统安全架构的标准就是针对现存和潜在的各种攻击与窃密手段，是否有可靠的应 对策略