【操作系统】​​408考研必看：操作系统体系结构详解——分层设计与模块化设计的权衡之道​

导读

大家好，很高兴又和大家见面啦！！！

在前面的内容中我们介绍了​​操作系统的运行环境​​，了解了它如何基于​​冯·诺依曼体系结构​​（由输入设备、输出设备、存储器、运算器、控制器这五大部件组成）实现其功能。

我们探讨了操作系统运行的核心机制：

• 包括​​用户态与核心态​​的划分，这两种状态确保了系统资源的安全访问
• ​​中断与异常​​作为激活操作系统并使其重新获得CPU控制权的事件
• 以及​​系统调用​​作为应用程序请求操作系统服务的唯一途径。

我们还看到，操作系统作为“管理者”，其管理的本质是“​​先描述，再组织​​”，即通过数据结构来抽象和管理各种软硬件资源。

然而，一个核心问题随之而来：

• 操作系统自身这个庞大而复杂的软件，其内部的各种管理模块（如进程管理、内存管理、文件系统等）应该如何被有效地​​组织​​在一起？

如何设计它的内部结构，才能使得这个核心系统既​​稳定高效​​，又​​易于维护和扩展​​？这正是本文将要探讨的核心——​​操作系统的体系结构​​。

它关注的是操作系统内部的模块划分与交互方式，是构建可靠、高效操作系统的蓝图。

要理解这些设计思想是如何被具体实现的，就让我们从​​分层结构​​开始，逐步深入操作系统的架构设计。

一、分层结构

1.1 定义

分层法是将操作系统分为若干层，底层（层0）为硬件，顶层（层 N）为用户接口，每层只能调用紧邻它的低层的功能和服务（单向依赖）。

graph TB
a[层 N<br>用户接口]--->b[...]--->c[层1<br>]--->d[层0<br>硬件]

上图就是对分层法的一种简单展示，其各层之间的关系为：

• 层 i 能且只能调用紧邻的低层层 i - 1 提供的功能与服务
• 层 i 能且只能向紧邻的高层层 i + 1 提供本层的功能与服务

1.2 优点

分层法将操作系统细分为了各个层次，并且各层之间的关系为单向依赖，这种方式可以带来以下优势：

便于系统的调试与验证，简化了系统的设计和实现。

由于各层之间的关系为单向依赖，因此我们可以进行从下往上逐层调试：

• 若第 i 层在调式的过程中未发现任何问题，我们就可以继续向上调试
• 若层 i 在调试的过程中出现了问题，那么问题只会出现在该层上，因为其底层（1 \sim i - 1 层）的所有功能与服务都已经完成了调试工作；

通过这种 单向依赖，我们能够更直观、简单的对各层的功能和服务进行调试与验证；

易扩充和易维护。

在分层中，由于各层次之间的关系是确定的，即层次与层次之间的通信接口是固定的，那么只要我们在保持层与层之间的接口不变的前提下，对层 i 进行增加、修改或者替换等操作时，我们不会影响与其紧邻的 i-1 层与 i + 1 层。

正因如此，我们在对系统进行维护和扩充时就变得更加方便快捷；

1.3 不足

尽管分层法有着这些优点，但同时因为分层也会带来相应的问题：

合理定义各层比较困难。

在操作系统中，有些功能是无法单独进行隔离分层的，就比如：

• 我们要实现进程控制，那么就需要涉及一些内存管理的功能；
• 而我们要对内存管理，就需要涉及一些进程控制的功能；

在这种情况下，层次之间固定的依赖关系，就显得不够灵活；

效率低下。

当我们对操作系统进行层次划分后，各层只能够执行本层对应的功能，且各层只能与紧邻的层次进行通信，无法跨层通信；

这使得操作系统每执行一个功能时，通常需要自上而下地穿越多层，这无疑增加了额外的开销，导致系统效率低下。

这里我们举一个简单的例子：

graph TB
a[用户接口]--->b[系统调用]--->c[进程控制]

当我们需要通过用户接口进行进程控制，那我们无法做到跨层通信，即：

graph TB
a[用户接口]--->b[进程控制]

我们只能先从用户接口向系统调用通信，再由系统调用来与进程控制通信，即：

graph TB
a[用户接口]--->b[系统调用]--->c[进程控制]

同理，进程控制在返回相应信息时，也无法直接将信息返回到用户接口，只能先将信息返回给系统调用，再由系统调用返回到用户接口：

graph TB
a[进程控制]--->|返回信息|b[系统调用]--->|返回信息|c[用户接口]

这还是我举的一个简单的例子，如果需要更加复杂的功能，需要从用户接口层深入到硬件层，那么可想而知，就传递指令和接收返回信息的这个过程就需要花费大量的时间，这就显著的降低了系统的效率。

二、模块化

2.1 定义

模块化是将操作系统按功能划分为若干具有一定独立性的模块。

• 每个模块具有某方面的管理功能，并规定好各模块间的接口，使各模块之间能够通过接口进行通信
• 还可以进一步将各模块细分为若干具有一定功能的子模块，同样也规定好各子模块之间的接口

这种设计方法被称为 模块-接口法。

graph TB
a[操作系统]--->b[模块1<br>进程管理]
a--->e1[...]
a--->c[模块2<br>存储器管理]
a--->e2[...]
a--->d[模块3<br>文件管理]

b--->b1[子模块1<br>进程控制]
b--->b3[...]
b--->b2[子模块2<br>进程调度]

c--->c1[子模块1<br>内存分配]
c--->c2[子模块2<br>内存保护]
d--->d1[子模块1<br>磁盘管理]
d--->d2[子模块2<br>目录管理]

上图展示的就是由模块、子模块等组成的模块化操作系统结构。

2.2 划分标准

当我们需要对操作系统进行模块划分时，需要就需要考虑两个问题：

• 模块划分的太小。
  • 此时能够降低模块本身的复杂性
  • 由于过小的模块，使得操作系统的模块数量增加，模块之间的联系过多，容易造成系统混乱的问题
• 模块划分太大。
  • 此时能够减少系统混乱的问题
  • 由于过大的模块，使得操作系统的模块数量减少，但这也导致了每个模块内部的复杂性增加

显然，为了能够合理的划分模块，我们需要在二者之间进行权衡，找到一种既能减少系统混乱，又能降低内部复杂性的划分方式；

此外我们还需要考虑模块的独立性问题。这是因为模块的独立性越高，各模块之间的交互就越少，系统的结构也就越清晰。

衡量系统模块的独立性有两个标准：

• 内聚性：模块内部各部分间联系的紧密程度。
  • 内聚性越高，模块独立性越好
• 耦合度：模块间相互联系相互影响的程度。
  • 耦合度越低，模块独立性越好

2.3 优缺点

• 模块化的优点：
  • 提高了操作系统设计的正确性、可理解性和可维护性
  • 增强了操作系统的可适应性
  • 加速了操作系统的开发过程
• 模块化的缺点：
  • 模块间的接口规定很难满足对接口的实际需求
  • 各模块设计者齐头并进，每个决定无法建立在上一个已验证的正确决定的基础上，因此无法找到一个可靠的决定顺序。

我们应该如何理解模块化的优缺点呢？

在理解模块化的优缺点之前，我们需要先理解一个观点——模块化的优缺点正来自于其高内聚，低耦合的设计理念；

2.3.1 优点

其核心优势源于“​​高内聚、低耦合​​”的设计理念，具体体现在以下几个方面：

🎯 提高系统正确性与可理解性

通过按功能划分模块，并为每个模块设定清晰的接口，开发者可以将复杂问题分解为更小、更易于管理和实现的单元。

这种“分而治之”的策略，使得每个模块的功能明确、内部逻辑集中，极大提升了代码的可读性，降低了认知负担，从而为提高系统设计的正确性奠定了基础。

由于每个模块功能单一且结构清晰，开发者可以更容易地理解其代码逻辑。

⚡ 加速开发过程

模块化允许不同的功能模块由不同的开发团队并行设计与实现。

只要模块间的接口协议已经明确，各团队就可以在互不干扰的情况下齐头并进，从而显著缩短整个项目的开发周期。

这种开发模式特别适合大型项目和团队协作。

🔧 提升可维护性

当需要修改特定功能或修复缺陷时，模块化设计使开发者能够聚焦于受影响的特定模块。

由于模块之间通过接口解耦，对某一模块的修改通常不会波及系统的其他部分，这极大降低了维护的复杂性风险，并使问题定位更为精准。

🔄 增强可适应性

系统的功能扩展或裁剪变得更为灵活。

• 需要增加新功能时，往往可以通过开发符合既定接口规范的新模块来实现；
• 同样，移除功能也通常只需卸载对应模块，而无需重构整个系统。

这种灵活性使得操作系统能够更好地适应不断变化的需求。

💎 总结

模块化通过功能分解与接口抽象，将复杂的系统转化为一系列易于管理、协作的独立单元。

它不仅提升了开发阶段的效率与代码质量，还为系统后期的维护、升级和扩展提供了极大的便利，是构建健壮、可靠软件系统的基石。

2.3.2 缺点

模块化设计的缺点主要源于其内在的“高内聚、低耦合”理念在实践中所面临的挑战，具体体现在接口设计和系统构建过程两个方面。

1. 接口规定的困境：预见性不足与变更的高成本​​

模块化的核心在于通过定义清晰的接口来组合独立模块。

然而，在项目初期，我们往往只能基于当前的需求和认知来设计接口。当后续需求发生变化或出现未预料到的交互场景时，原有接口可能无法满足新的实际需求。

这种​​前期设计的预见性不足​​，使得接口在项目演进过程中需要频繁调整。而一个模块接口的修改，常常会产生​​连锁反应​​，迫使与之交互的其他模块也随之改动，显著增加了维护的复杂度和成本。

1. 设计过程的“无序性”：决策顺序的缺失与集成挑战​​

模块化允许各模块并行开发，但这同时也带来了系统设计的“无序性”问题。

由于各模块的设计者齐头并进，他们需要在缺乏上层模块具体实现反馈的情况下做出大量局部决策。每一个决策都难以建立在另一个已被完全验证的正确决定之上，因此​​无法找到一个绝对可靠的全局决策顺序​​。

这种无序性在集成阶段会带来显著挑战，例如，当功能A需要协调调用模块1、2、3时，如果出现问题，排查工作会非常复杂，因为需要辨析问题究竟源于单个模块的内部实现，还是模块间接口调用逻辑，亦或是早期不合理的底层设计决策，这大大增加了调试和验证的难度。

结语

今天的内容到这里就全部结束了。通过本文的探讨，我们深入了解了操作系统体系结构的两种经典设计范式：分层结构与模块化设计。这两种方案体现了软件工程中在秩序与灵活之间寻求平衡的永恒追求。

• 分层结构以其严格的单向依赖关系，构建了一个层次分明、易于调试和验证的系统。它通过从底层硬件到顶层用户接口的逐层抽象，极大地简化了操作系统的设计与实现。然而，这种严格的层次化也带来了性能开销和灵活性不足的问题，特别是在需要跨层交互的场景中。
• 相比之下，模块化设计采用“分而治之”的策略，将操作系统按功能划分为相对独立的模块，通过明确定义的接口进行通信。这种高内聚、低耦合的理念大大提高了系统的可理解性、可维护性和可扩展性，允许团队并行开发，加速开发进程。但模块化也面临着接口设计困难和系统集成复杂等挑战。

这两种体系结构并非相互排斥，现代操作系统往往结合了它们的优点。例如，Linux虽然总体上采用单体内核结构，但其内部实现了模块化机制，并在某些子系统中采用了层次化思想。

操作系统体系结构的发展永无止境，从早期的模块组合结构到层次结构，再到微内核和虚拟机结构，每一种设计都在探索如何更好地组织复杂系统。了解这些基础设计理念，不仅有助于我们理解现有操作系统的工作方式，也为未来系统的设计与创新奠定了坚实基础。

感谢您阅读本文！如果觉得内容对您有帮助：

• 点赞 👍 支持一下吧~
• 关注 🔔 我不迷路，更多操作系统与技术底层原理等你来探索！
• 转发 📤 分享给更多朋友，一起学习进步！
• 收藏 💾 随时回顾这些重要的体系结构概念！

您对哪种操作系统体系结构最感兴趣？在实际工作中接触过哪些相关的设计模式？欢迎在评论区分享您的看法和经验！