Day02-01｜2.1 计算机系统概述
Day02-01｜2.1 计算机系统概述
教材版本：系统架构设计师教程（第 2 版）
教材章节：第 2 章 计算机系统基础知识 · 2.1
考试科目：综合知识、案例分析
建议用时：120～150 分钟
一、学习目标
系统架构设计师虽然主要设计软件系统，但软件始终运行在处理器、存储器、操作系统、网络和设备组成的计算机系统之上。不了解计算机系统的基本组成，就无法解释性能瓶颈、并发行为、资源争用、故障传播和部署约束。本节从整体角度认识计算机系统，建立硬件、系统软件、应用软件和用户之间的层次关系。
完成本节后，你应该能够：
- 说明计算机系统的组成和层次结构；
- 区分硬件、系统软件、支撑软件和应用软件；
- 理解软硬件协同和系统架构的关系；
- 正确使用性能、吞吐、响应时间、容量和可用性等指标；
- 在案例题中从系统资源角度分析性能和可靠性问题。
二、计算机系统的组成
广义计算机系统由硬件系统、软件系统、数据、人员和运行环境组成。硬件包括处理器、存储器、输入输出设备、总线、网络和专用设备；软件包括操作系统、数据库、中间件、编译器、虚拟机、驱动和应用程序；数据是被采集、传输、存储和处理的对象；人员包括用户、开发、运维和管理人员；运行环境包括机房、云平台、网络区域、供电和安全设施。
从系统架构角度看，不能把计算机系统理解为“服务器加软件”。应用的性能可能受到 CPU 指令执行、内存访问、磁盘 I/O、网络带宽、连接池、线程池和外部设备影响；应用的可靠性可能受到电源、节点、操作系统、数据库、网络和机房影响；安全性还会受到固件、镜像、依赖库和运维权限影响。
| 组成部分 | 主要职责 | 架构师关注点 |
|---|---|---|
| 处理器 | 执行指令和处理计算 | 核数、频率、并行、缓存和负载 |
| 存储器 | 保存程序和数据 | 容量、层次、访问延迟和持久性 |
| 输入输出设备 | 与外部环境交换数据 | 设备接口、吞吐、驱动和可靠性 |
| 网络 | 传输数据和提供连接 | 带宽、延迟、丢包、分区和安全 |
| 系统软件 | 管理资源并提供运行环境 | 调度、隔离、文件、协议和监控 |
| 应用软件 | 实现业务功能 | 模块、接口、数据和质量属性 |
三、计算机系统的层次结构
计算机系统可以看成从硬件到应用逐层抽象的结构。最底层是物理硬件和固件，向上是操作系统内核、驱动和系统服务，再向上是数据库、消息中间件、虚拟机和容器运行时，最上层是业务应用和用户界面。每一层向上提供服务，同时对下层形成依赖。
层次化的价值是隐藏实现细节和控制复杂度。应用通过操作系统提供的进程、线程、文件和网络接口使用硬件资源，数据库通过文件系统和存储设备保存数据，应用通过数据库接口执行查询。抽象层也会带来开销和限制，跨越多层的调用可能增加延迟，错误的抽象可能隐藏重要资源行为。
| 层次 | 示例 | 发生问题时的分析方向 |
|---|---|---|
| 硬件层 | CPU、内存、磁盘、网卡 | 资源容量、故障和设备性能 |
| 系统软件层 | 操作系统、驱动、文件系统 | 调度、I/O、进程和权限 |
| 平台层 | 数据库、JVM、容器、中间件 | 连接、线程、缓存、队列和事务 |
| 应用层 | 服务、模块、接口和页面 | 业务逻辑、调用、数据和算法 |
| 用户与业务层 | 角色、流程和目标 | 体验、规则、指标和合规 |
架构师要能够在层次之间建立追踪关系。例如接口响应变慢可能是应用算法复杂，也可能是数据库索引缺失、线程池耗尽、磁盘延迟上升或网络丢包。不能只在应用代码中盲目优化。
四、硬件和软件的协同
硬件决定可提供的计算、存储、网络和设备能力，软件决定如何利用和组织这些资源。操作系统通过进程、线程、虚拟内存、文件系统和网络协议向应用提供抽象；应用通过并发模型、缓存、批处理、异步和数据结构选择影响资源使用方式。
软硬件协同在嵌入式、实时、人工智能、图形处理和大数据场景中尤其明显。通用 CPU 适合灵活计算，GPU 适合大量并行计算，专用芯片可能提供更高效率；但专用硬件会增加开发、部署和迁移成本。架构师必须比较性能收益、开发难度、供应链、可维护性和可替换性。
虚拟化和容器进一步改变了系统层次。虚拟机通过虚拟硬件隔离操作系统，容器通常共享宿主机内核但隔离进程、文件和网络。它们可以提高资源利用率、环境一致性和部署灵活性，也会引入虚拟化开销、资源竞争、镜像安全和调度复杂度。
五、计算机系统的性能指标
性能分析不能只看 CPU 使用率。常见指标包括响应时间、吞吐量、并发数、资源利用率、容量、延迟、抖动和错误率。响应时间是一次请求从开始到完成的时间；吞吐量是单位时间完成的请求、事务或数据量；并发数是同时处于处理状态的请求数量；容量表示系统在规定质量目标下能够承受的最大负载。
平均响应时间可能掩盖长尾问题。实际系统应关注 P50、P90、P95、P99 等分位数。一个接口平均只需 100 ms，但 P99 达到 5 秒，用户仍可能频繁感知卡顿。性能指标还要结合业务场景，例如支付接口更关注成功率和端到端时延，日志平台更关注吞吐和数据延迟，实时控制更关注响应上界。
| 指标 | 含义 | 常见误区 |
|---|---|---|
| 响应时间 | 请求完成所需时间 | 只看平均值，不看长尾 |
| 吞吐量 | 单位时间完成量 | 忽略错误率和数据正确性 |
| 并发数 | 同时处理的请求数 | 并发高不等于吞吐高 |
| 利用率 | 资源使用程度 | 盲目追求 100% 利用率 |
| 容量 | 满足目标的最大负载 | 不说明质量目标和场景 |
| 延迟 | 数据或请求传播、处理的等待 | 忽略排队和外部依赖 |
六、性能分析的基本方法
首先明确业务场景和目标，记录请求量、数据量、并发峰值和响应指标；其次建立基线，测量 CPU、内存、磁盘、网络、数据库、线程池和连接池；再次定位瓶颈，判断是计算、I/O、锁、排队、外部依赖还是数据访问；最后提出措施并验证，避免“感觉优化”。
排队会使系统在高负载时出现非线性变慢。线程池、数据库连接池、消息队列和网络缓冲区都可能形成队列。增加并发线程并不一定提升吞吐，可能造成上下文切换、锁竞争和下游过载。架构师要设计背压、限流、超时、隔离和降级，让系统在过载时保持可控。
七、可靠性与可用性基础
可靠性强调系统在规定条件和时间内持续完成正确功能，可用性强调系统在需要时处于可使用状态。两者相关但不同：一个系统可能很少宕机但经常返回错误，说明可用但不可靠；也可能服务本身稳定但维护窗口很长，影响可用性。
系统可靠性依赖硬件、软件、网络、数据、人员和过程。架构措施包括冗余、故障检测、隔离、重试、幂等、备份、恢复、降级和演练。高可用不是简单复制节点，还要处理状态、数据、连接、配置、发布和依赖故障。没有恢复测试的灾备方案不能证明有效。
八、案例分析
某电商系统部署在三台应用服务器上，用户反馈促销期间页面变慢。监控显示 CPU 只有 50%，但数据库连接池经常耗尽，P99 响应时间超过 5 秒；商品详情允许短时间延迟，订单提交不能重复；系统计划迁移到容器平台。
参考答案
CPU 不高不能证明系统没有性能问题，瓶颈可能在数据库连接池、慢查询、锁等待、网络或下游服务。应先建立端到端指标和分段耗时，检查连接池大小、数据库活跃连接、慢查询、锁、缓存命中率和请求排队；如果应用线程在等待连接，增加应用节点可能反而加重数据库压力。
商品详情可以增加缓存、热点预热和过期策略，并设置回源保护；订单提交要使用业务幂等键、服务端幂等记录和数据库唯一约束，不能只依赖前端防重复；高峰入口可采用限流和排队，非核心通知异步化；数据库根据访问模式优化索引，必要时读写分离。迁移到容器时要设置资源请求和限制、健康检查、优雅终止、滚动发布、日志指标和回滚，并验证容器资源竞争和数据库连接总量。
九、综合知识练习
- 计算机系统除了硬件和软件还包括哪些要素？
- 为什么需要多层抽象？抽象有什么代价？
- 并发数、吞吐量和响应时间有什么区别？
- 为什么 CPU 利用率低时系统仍可能很慢？
- 容器化为什么不能自动解决性能和高可用问题？
参考答案
- 数据、人员和运行环境。2. 多层抽象可以隐藏细节、复用能力和控制复杂度，但会增加调用开销并隐藏底层资源行为。3. 并发数是同时处理的请求量，吞吐量是单位时间完成量，响应时间是单次请求耗时。4. 可能瓶颈在数据库连接、锁、磁盘、网络、线程池或外部服务。5. 容器提供隔离和部署能力，仍需设计资源、状态、数据、故障转移、监控和恢复。
十、论文素材
本节可以写“高并发系统性能优化与基础设施演进”。背景描述请求增长和长尾延迟，分析 CPU 不高但连接池、数据库和队列成为瓶颈；方案从缓存、限流、连接池治理、数据库优化、异步化、容器资源和监控展开；权衡写一致性、成本、资源利用和运维复杂度；效果用 P95/P99、吞吐、错误率、连接等待和故障恢复时间证明。
十一、今日复盘
请闭卷回答：计算机系统由哪些部分组成？软件架构为什么必须理解硬件和系统软件？如何区分响应时间、吞吐量、并发和容量？性能问题应如何从端到端定位？为什么容器化不能替代架构设计？
