GreatBook《大型网站技术架构》

在多年工作实践中，对前端、后端服务分层架构长期处在零碎的实践体会，即便身在云平台也极少有机会从整体视角来认识云平台的深层架构原理。网上零碎资料文章虽多，但缺少严谨地架构知识讲述，不足以作为专业认识的入口。所以当看到李智慧这本书《大型网站技术架构》时，让人非常激动，多年来处于朦胧不清的架构知识被智慧哥用通俗易懂的语言总结出来。

于是速速读来，慢慢体会，将书中个人认为的最为精要的“架构认知点”进行系统梳理总结。

A、服务器架构演化

架构的演化方向，如果归结为笼统原则，就是“缓存化”+“分布式化”。

书中将小网站演化到大型网站需要10步。这10步也可以理解为架构演化的标准路线，带着上面所说的笼统原则来看看这10步演化路线，也会更能体会进行的方向。

1. 初始阶段的网站架构：比如，单体应用，单体LAMP架构。在这个阶段，应用程序，数据库，文件等所有的资源都在一台服务器上。（对应下图1.1）
2. 分离“应用服务器”和“数据服务器”：这个时候，应用和数据分离后整个网站使用三台服务器，a应用服务器，b文件服务器和c数据库服务器。这也是第一步进行分离的架构操作，由此迈出架构进化路线。（对应下图1.2）
3. 使用缓存改善网站性能：网站使用的缓存可以分为两种：缓存在，应用服务器上的a本地缓存和缓存在专门的分布式缓存服务器上的b远程分布式缓存。（对应下图1.3）
4. 使用应用服务器集群改善网站的并发处理能力：每一种集群都是一种类型的应用服务器，进而能进行均衡负载且冗余容错支撑。使用集群也是网站解决高并发、海量数据问题的常用手段。（对应下图1.4）
5. 数据库读写分离：目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能，实现数据库读写分离，从而改善数据库负载压力。（对应下图1.5）
6. 使用反向代理和CDN加速网站响应：CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。（对应下图1.6）
7. 使用分布式文件系统和分布式数据库系统：分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。不到不得已时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上。 （对应下图1.7）
8. 使用NoSQL和搜索引擎：随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂。网站需要采用一些非关系数据库技术NoSQL和非数据库查询技术如搜索引擎来进行满足。应用服务器通过一个统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。（对应下图1.8）
9. 业务拆分：大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段讲整个网站业务分成不同的产品线。应用之间则通过一个超链接建立关系，背后也可以通过消息队列进行数据的分发。（对应下图1.9）
10. 分布式服务：既然每一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。由这些可复用的业务连接数据库，提供共用业务服务。

如果能够有幸跟随某个产品某个网站一起成长到第10步，那会是非常难得的机遇和挑战。

架构的演化方向，归结为笼统原则，就是 “缓存化”+“分布式化”，这有助于理解上面的进化方向。当然这个说法还不够专业和理论化，所以就有了下一部分B中提到的 “服务器架构模式”。

B、服务器架构模式

关于什么是模式，这个来自建筑学的词汇是这样定义的：“每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复工作”。

模式的关键在于模式的可重复性，以及指出了事物本质的共性。

换一种说法，架构模式就是一种： “架构师进行架构工作的核心思维方式”。

用下面一张导图来概括这些架构模式。

再选取其中关键的要素进行阐述，比如，分层，分布式，缓存

• “架构的分层”：分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。分层结构在计算机世界中无处不在，网络的7层通信协议是一种分层结构；计算机硬件、操作系统、应用软件也可以看作是一种分层结构。
• 架构的分布式：对于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着可以使用更多的计算机完成同样的功能，计算机越多，CPU、内存、存储资源也就越多，能够处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。【分布式常有：1.分布式应用和服务；2.分布式静态资源；3.分布式数据和存储；4.分布式计算；】
• 架构的缓存：缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段，现代CPU越来越快的一个重要因素就是使用了更多的缓存，在复杂的软件设计中，缓存几乎无处不在。大型网站架构设计在很多方面都使用了缓存设计。使用缓存的例子：CDN，反向代理，本地缓存，分布式缓存。

架构模式，简单的理解，就可以认为主要是“分布式化”+“缓存化”再进行场景细化针对的实践。

C、服务器核心架构要素

一般来说，除了当前的系统功能需求外。软件架构还需要关注 性能、可用性、伸缩性、扩展性和安全性这5个架构要素。

C-1、性能

衡量网站性能有一系列指标，重要的有响应时间、TPS、系统性能计数器等。通过检测这些指标以确定系统设计是否达到目标。这些指标也是网站监控的重要参数，通过监控这些指标可以分析系统瓶颈，预测网站容量，并对异常指标进行报警，保障系统可用性。

改善性能的手段要素，可以借鉴上面10步进行路线中针对每一种阶段遇到的问题进行性能的针对性提升。

也就是泛指的 缓存化+分布式化。这也是实现 “高性能架构”的主要进化策略。

C-2、可用性

可用性，其实可以理解为全年全天360 * 24 * 7 hour的可用性，因为大型服务器架构任何时候都有用户的活跃性，所以就需要极高的无缝可用性。

网站高可用的主要手段是 集群化的冗余。应用部署在多台服务器上同时提供服务访问，数据存储在多台服务器上相互备份，任何一台服务器挂掉都不会影响整体服务的可用性。（在庞大的服务器集群中服务器意外宕机都是能够进行容错的，这就是高可用的基础）

集群化的冗余。这也就是实现“高可用架构”主要策略。

C-3、伸缩性

大型网站面对海量用户的高并发访问和数据IO，随着架构升级，演化为通过集群的方式将多台服务器编排组成一个整体的服务集群来共同提供服务。

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

实践高伸缩性的主要策略就是，设计一种友好便携的集群机器的增减策略。

C-4、扩展性

衡量网站架构扩展性好坏的主要标准就是在网站增加新的业务产品时，是否可以实现对现有产品透明且无影响，不需要改动或者很少改动既有业务功能就可以上线新产品。不同产品模块之间可以极少相互牵制的耦合关系。

网站伸缩架构的主要手段是 事件驱动架构和分布式服务。

• 事件驱动架构，就是设计一个消息队列MQ，将用户请求or其他业务事件构造成消息防止到消息队列，消息队列MQ再去集群中寻找消息处理者。这就将消息产生，消息处理分离开，可以在遇到吞吐量不足时灵活在集群中增加消息处理应用。

• 分布式服务，则是上面提到的几种分布式手段。

C-5、安全性

架构安全性是个大话题，由于业务生产需求和产品经理的节奏一定快于安全措施的跟踪实施，所以在进行架构扩张时，最容易出现重大安全隐患，所以这需要在快速业务和安全性间保持平衡。也需要在产品稳定后进行查缺补漏相应的安全措施。