操作系统课程：从虚拟化到云原生与Serverless
大家好，我是你们的操作系统课程老师！今天我们将从虚拟化技术讲到现代的云原生 和Serverless架构，带你看看计算机系统如何从早期的虚拟机（VM）演进到容器，再到如今的微服务和函数即服务（Function as a Service, FaaS）。这些技术听起来高大上，但其实并不复杂，我会用通俗的方式讲解，并通过流程图帮你梳理清楚。让我们一起探索这场技术革命的舞台是如何搭建的吧！
1. 云原生与微服务：现代应用的雏形
现代应用程序的架构已经从传统的单体应用转向云原生 和微服务 。这些概念听起来可能有点陌生，但其实它们建立在我们之前学习的虚拟化和容器技术之上。简单来说，云原生就是让应用程序更小、更轻、更灵活，每个应用就像一个独立的HTTP服务，通过API与数据库或其他服务交互。
教务系统的例子
以一个教务系统为例：
- 前端：用户通过浏览器访问网页，前端从CDN拉取HTML、JavaScript等静态资源。
- 后端 ：用户点击"选课"按钮，前端发送HTTP请求到后端服务（如
teach.nju.edu.cn/fetch）。 - 服务逻辑：后端服务解析请求，查询数据库（比如MySQL），将结果序列化为JSON返回给前端。
- 扩展性：通过容器技术，可以运行多个服务副本，处理大量并发请求。
云厂商（如阿里云）提供API Gateway，自动将请求分发到集群中的不同服务实例，实现负载均衡。这让开发者只需专注于业务逻辑，底层资源管理由云厂商搞定。
微服务的运行流程
我们用流程图展示微服务的运行机制：
用户访问前端 前端发送HTTP请求 API Gateway接收请求 负载均衡到后端服务实例 服务查询数据库 返回JSON数据
这个流程图展示了微服务如何通过API Gateway处理用户请求，实现高效的分布式协作。
2. 从容器到Serverless：函数即服务
微服务已经很轻量了，但我们还能更进一步------Serverless（无服务器）架构。在Serverless中，开发者甚至不需要管理容器，只需提供函数代码，云厂商负责运行和扩展。
为什么需要Serverless？
传统服务器或容器的模式要求开发者指定资源需求（如内存、CPU），并保持容器运行，即使没有请求也会占用资源。而Serverless将应用拆解为函数，每次请求触发一次函数执行，用多少资源付多少钱，极大提高了资源利用率。
例如，你写一个函数get_enroll_list()，查询教务系统的课程列表：
- 将函数代码上传到Git仓库，告诉云厂商需要的内存、超时时间等配置。
- 云厂商自动分配容器，运行函数，返回结果。
- 如果请求量增加，云厂商自动扩展容器；请求量减少，则销毁多余容器。
Serverless的运行流程
我们用流程图展示Serverless的工作机制：
请求量增加 请求量减少 开发者上传函数代码 云厂商拉取代码 配置容器（内存、超时等） 用户请求触发函数 云端运行函数，返回结果 自动扩展容器 销毁多余容器
这个流程图展示了Serverless如何动态分配资源，降低开发者的运维负担。
Serverless的经济性
Serverless让云厂商（那些"黑心商人"）更开心，因为他们可以通过**超售（oversubscription）**最大化资源利用率。例如：
- 容器可能需要128MB内存，即使实际只用30MB。
- 函数的资源需求更小，执行时间更可预测，云厂商可以更紧凑地调度资源，榨取每一台机器的性能。
3. Serverless的应用：云上的多媒体处理
Serverless不仅适用于Web服务，还可以处理多媒体任务。比如，我录制的课程视频需要转码，但B站不支持CRF（质量优先）编码，强制转为CBR（固定比特率），导致画质下降。传统方式是用本地的FFmpeg工具转码，但Serverless提供了一种更优雅的解决方案。
云端FFmpeg的例子
假设我直播结束后，视频文件已存储在云端（如阿里云OSS）。我可以调用一个Serverless函数（如ffmpeg_get_metadata），直接在云端提取视频元数据或转码：
- 输入：云存储中的文件名和访问密钥。
- 输出：处理后的结果，计费按函数调用次数。
这比本地运行FFmpeg更高效，因为云端有强大的计算资源和散热支持，开发者只需调用API，无需管理服务器。
云端多媒体处理的流程
我们用流程图展示Serverless多媒体处理：
直播结束，视频存至云端 调用Serverless函数（如ffmpeg_get_metadata） 云端分配容器，运行函数 访问云存储，处理视频 返回处理结果 按调用次数计费
这个流程图展示了Serverless如何简化多媒体处理，开发者只需关注函数逻辑。
4. 云原生的未来：从PC到云终端
Serverless和云原生技术正在改变我们对计算机的理解。传统的PC模式（本地CPU、内存、存储）可能逐渐被云终端 取代。未来的操作系统可能只是一个Shell，文件系统、命令行工具都在云端运行。
鸿蒙PC与Chromebook的启发
最近发布的鸿蒙PC被认为是一个"Chromebook式"的系统，整个操作系统围绕浏览器运行，所有应用都是云端服务。这种模式下：
- 文件存储在云盘，随时共享。
- 命令行工具（如FFmpeg）以Serverless函数形式运行。
- 用户只需一个终端设备（如手机或低配PC），所有计算在云端完成。
这对网络提出了更高要求，但随着5G和边缘计算的发展，这种模式完全可行。
云终端的运行流程
我们用流程图展示云终端的工作机制：
用户打开终端（如鸿蒙PC） Shell连接云端 调用云端函数（如FFmpeg、AI推理） 云端分配容器，运行函数 返回结果到终端 用户查看结果或共享数据
这个流程图展示了云终端如何将计算任务交给云端，终端只负责显示和交互。
5. CICD：自动化部署的利器
云原生离不开CICD（持续集成与持续部署）。CICD通过自动化工作流简化了开发和部署过程。
CICD的例子
假设你开发了一个教务系统服务get_enroll_list.py：
- 你推送到Git仓库的
dev分支，触发CI（持续集成）运行单元测试。 - 测试通过后，合并到
main分支，触发CD（持续部署），自动将代码部署到云端。 - 云厂商可能还支持A/B测试或灰度部署，监控用户访问和异常日志。
以我们实验室的官网为例：
- 每次推送到
master分支，触发一个HTTP请求到服务器。 - 服务器验证身份后，自动拉取代码，更新网站。
CICD的运行流程
我们用流程图展示CICD的工作机制：
测试通过 开发者推送代码到Git仓库 触发CI：运行单元测试 合并到main分支 触发CD：自动部署到云端 运行A/B测试或灰度部署 监控用户访问和日志
这个流程图展示了CICD如何自动化代码测试和部署，提高开发效率。
6. AI与云原生的结合
随着AI的普及，AI推理（如大语言模型）占程序运行时间的比例越来越高。本地运行AI推理需要大量计算资源，而云端的Serverless架构更适合：
- 调用OpenAI或类似服务的API，运行推理任务。
- 云端支持FPGA或专用加速器，效率远超本地设备。
例如，爬取教务系统成绩时，传统正则表达式可能因网页结构变化而失效，而大语言模型可以直接解析HTML，生成结构化数据，适应性更强。
AI推理的云端流程
我们用流程图展示云端AI推理：
用户提交任务（如解析HTML） 调用云端AI推理API 云端分配容器，运行推理 返回结构化数据
这个流程图展示了AI推理如何通过Serverless高效运行。
7. 总结：从虚拟化到云原生的革命
今天我们从虚拟化讲到云原生和Serverless，回顾了技术如何从NEMU到虚拟机，再到容器和函数即服务。云原生让应用更小、更灵活，Serverless让开发者无需管理基础设施，CICD和AI推理进一步提升了开发效率。这些技术的背后，是"黑心商人"对资源最大化的追求，也是开发者对便捷性的需求。
未来，计算机可能只分为云 和终端，本地高性能PC或许会逐渐消失。希望这节课让你感受到操作系统的魅力，以及它如何支撑了云时代的革命！如果有任何疑问，随时告诉我，我们下节课继续探索！
通过这篇博客，我以老师的身份带你沉浸式地学习了云原生和Serverless的架构，并通过流程图直观展示了每个关键机制。如果你想深入探讨某个部分，比如CICD配置或AI推理优化，告诉我，我会为你进一步讲解！