deepread10｜案例+Web系统架构设计详解

ONEPSOFT | 软考学习知识库

---

deepread10｜案例+Web系统架构设计详解

知识点深度解读：Web 系统架构设计（高并发 / 缓存 / 负载均衡）

一、知识点定位

• 主要教材出处：第 16 章 Web 应用系统（16.1 Web 应用特征、16.2 架构设计原则与分类、16.4 部署环境与数据存储），同时涉及 第 4 章 4.4 负载均衡器、第 5 章 5.8 分区/内存缓存、第 20 章 微服务系统、第 19 章 19.2.1 高可用。
• 在考试中的角色：案例分析科目 " 应用系统分析与设计 " 重点（大纲案例 1.2 Web 应用架构设计）。综合知识的 " 软件架构设计（第 10 章）" 也会考到架构风格与质量属性。
• 与备考关联：你同时备高项和系规——高项里 " 负载均衡/集群 " 常出现在信息系统规划与资源规划章节，系规里 " 高可用/运维 " 是重点，本章的 " 负载均衡 + 缓存 + 弹性扩展 " 本质上就是在讲系统怎么抗住大流量还不宕机，和运维息息相关。

一句话先讲透：Web 系统架构设计，核心就一句话——让一台机器干不了的活，分给很多台机器一起干，并且让最常被要的数据放在最近、最快的地方。高并发是 " 问题 "，负载均衡是 " 分活 "，缓存是 " 减负 "。

二、教材原文精摘（原封不动，跨章节全覆盖）

【第 4 章 · 4.4 负载均衡器】原文：

负载均衡器是一种服务，它根据可用性或预定义策略将流量负载分布在不同的服务器之间来平衡流量负载。当负载均衡器中收到用户请求时，它会根据可用性和可伸缩性检索服务器的运行状况，并将请求路由到最佳服务器。负载均衡器可以是硬件组件，也可以是软件程序。

负载均衡可以通过如下两种方式完成：(1) TCP/IP 级别负载均衡，基于 DNS 的负载均衡。(2) 应用级负载均衡，基于应用负载的负载均衡。

软件负载均衡又分为四层负载均衡和七层负载均衡。四层负载均衡中性能较为突出的有 LVS 和 Haproxy 等……七层负载均衡中性能较优的有 Haproxy 和 Nginx 等，两者都支持虚拟主机，在负载均衡的同时都有保持 session 的方案，并且可以进行动静分离。硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备……常见的有 NetScaler、F5、Radware、Array 等商用的负载均衡器。

【第 16 章 · 16.4.2 Web 应用系统数据存储 · 缓存系统】原文：

缓存系统是一种本地数据存储，有助于快速访问应用程序服务器的数据，而不是每次都联系数据库。在传统设置中，数据存储在数据库中。当用户发出请求时，应用服务器会从数据库中请求该数据并将其呈现给用户。当再次请求相同的数据时，服务器应再次执行重复且耗时的相同过程。通过将此信息存储在临时缓存中，应用可以快速向用户呈现数据。

缓存系统可以设计为如下 4 种模型：(1) 应用程序服务器缓存。(2) 全局缓存。(3) 分布式缓存——缓存分布在节点上，其中一致哈希函数用于将请求路由到所需的数据。(4) 内容交付网络 (CDN)——用于交付大量静态数据。

【第 16 章 · 16.2.2 Web 应用架构分类】原文：

整体式架构：所有组件相互依赖，扩展困难，单点故障可能使应用瘫痪。

微服务架构：代码开发为松散耦合的独立服务，通过 RESTful API 通信，每个微服务有自己的数据库，易于扩展和修改，适合高可扩展和复杂应用。

【第 20 章 · 20.1.2 微服务系统特征 · 弹性和可伸缩性】原文：

微服务系统可以根据需求进行水平扩展，只需增加特定服务的实例数量，而不需要整体扩展。

【第 19 章 · 19.2.1 大数据处理系统架构原则 · 高可用】原文：

负载均衡是指将工作任务分配到多个节点或计算单元上，以平衡每个节点或计算单元的负载，从而提高系统的可用性和性能。负载均衡也可以通过一些专门的工具或框架来实现，如 Haproxy、Nginx、LVS 等。

三、系统解读（逐段讲透）

• 针对【4.4 负载均衡器】：教材把 " 负载均衡器 " 定义成一台 " 调度员 "——它手里有所有服务器的健康档案（谁能干、闲不闲），来一个请求就派给最合适的一台。它可以是 " 软件 "（装在普通服务器上的 Nginx、LVS）也可以是 " 硬件盒子 "（F5、NetScaler 这类专用设备）。四层（LVS）看 " 网络层地址 " 粗分，七层（Nginx）能看懂 " 具体应用请求 " 细分，还能保持用户会话（session）不变、把动态请求和静态文件分开处理（动静分离）。
• 针对【16.4.2 缓存系统】：这段是整章最该记住的。数据库每次被查都很累、很慢；把 " 刚要过、大家都要 " 的数据临时搁在离应用更近的地方（内存），下次直接给，不用再跑数据库。教材给了 4 级模型：单机内存缓存 → 全局缓存（大家共用一份）→ 分布式缓存（数据摊在多台机器上，用 " 一致性哈希 " 决定谁存哪块）→ CDN（把图片/视频等静态资源放到离用户最近的边缘节点）。缓存和高并发是直接挂钩的：它干的就是 " 减负 " 的活。
• 针对【16.2.2 架构分类】：整体式（单体）像一栋楼所有功能塞一栋里，一处塌全塌、想加层得整体加固；微服务像把楼拆成多个独立小单元（每个单元自己有水电气、自己数据库），哪个单元忙就单独给哪个单元加副本。高并发、复杂系统选微服务更扛造。
• 针对【20.1.2 微服务弹性】：点出 " 水平扩展 "——不是把一台机器换大，而是 " 同样的机器多摆几台 "。流量涨了就加实例，这也是配合负载均衡用的。
• 针对【19.2.1 高可用】：再次确认负载均衡的 " 双重收益 "——既分摊压力（性能），又避免单台挂掉全停（可用性）。

核心一句话总结：高并发不是靠某台神机，而是靠 "分活（负载均衡）+ 减负（缓存）+ 拆开可扩（微服务/水平扩展）" 三件套一起上，让系统像能自动加车道、自动开备用道的高速公路。

四、工程实践举例（土木工程类比）

你的背景是土木工程，咱们用 " 城市路网与供水系统 " 来套：

想象你负责一座新城区的交通与供水规划。早高峰突然涌进 10 倍车流（高并发）：

1. 负载均衡 = 路口智能信号灯 + 环岛调度。原来所有车只走一条主干道（单台服务器），必堵死。你在进城口设一个 " 总调度岗亭 "（负载均衡器），按各条支路的拥堵情况把车流分到不同方向（四层按区域粗分、七层按车型/目的地细分），还能让同一辆车的往返都走同一条路（session 保持 / Client Affinity，比如送外卖的车固定走物流道）。
2. 缓存 = 小区门口的便民水站。家家户户天天要喝水，不可能每次都跑到城外大水厂（数据库）取。你在每个小区门口放个小蓄水池（缓存），常喝的几样水就近取，大水厂压力骤减。CDN 就像把桶装水预存在各街区便利店（边缘节点）。
3. 微服务/水平扩展 = 多开同种收费站 + 模块化水厂。某个方向车多，就单独给那个方向多开几个收费亭（加实例），不用把整个路网推倒重建。

正对应这里——负载均衡和缓存就是保障系统 " 不宕机、响应快 " 的两大运维抓手，案例题常让你给一个扛不住流量的系统 " 开药方 "，药方基本就是这三件套。

知识点 ↔ 工程实践 对照表

教材知识点要素	你的实践场景对应	映射说明
高并发（流量洪峰）	早高峰 10 倍车流涌入城区	都是 " 瞬时需求远超单点处理能力 "
负载均衡器（分发请求）	进城口总调度岗亭按拥堵分车流	都是 " 把活分给多路、避免单点堵死 "
四层/七层、session 保持	按区域粗分 / 按车型细分、外卖车走固定道	都是 " 不同粒度分发 + 同一事务走同路 "
缓存系统（4 种模型）	小区便民水站 / 街区便利店蓄水桶（CDN）	都是 " 热点数据就近取、减轻源头压力 "
微服务 + 水平扩展	多开同种收费亭、模块化水厂	都是 " 拆成独立单元、按需加副本 "
高可用（不宕机）	主干道塌了还有备用环线	都是 " 避免单点故障导致整体停摆 "