本篇要回答的问题：作为架构师，看一个程序时该有怎样的"全局视野"？一座软件大厦从地基到顶层，到底是怎么搭起来的？
开篇第一讲不讲招式，讲内功——先建立宏观的全局掌控能力。把应用程序比作一座大厦：架构师负责搭结构，程序员负责填砖；而大厦稳不稳，关键看地基。所以本篇从地基开始，自底向上鸟瞰一个程序的完整构成。
为什么需要建立宏观视角？
架构师需要的第一个能力，是宏观的全局掌控能力。你对所依赖的基础架构了解得越全面，做业务架构设计就越从容。
学这些不是让你真去实现冯·诺依曼体系或浏览器，而是要懂它们的核心思想，知道哪些信息必须深刻理解，以便更好地驾驭它们。
应用程序的基础架构
学一个程序的基础架构，本质就是弄清楚电脑怎么工作、程序怎么运行。任何智能设备都可统一看作：
中央处理器（CPU） + 存储 + 一系列输入输出设备
电脑这么简单，为何能干无穷多的事？依赖两点：
| 关键能力 | 含义 |
|---|---|
| 可编程性 | CPU 指令集有限（计算类 / I/O 类 / 跳转类），但存储中的指令序列无穷，可能性也就无穷 |
| 开放的外设支持 | CPU 只和设备交换数据、不理解数据含义；厂商提供配套软件完成协作 |
这套设计就是 1945 年冯·诺依曼体系结构。在它之上逐层长出基础软件：
| 基础软件 | 解决的问题 |
|---|---|
| 编程语言 + 编译器 | 机器指令太难写、没法维护 → 把人类语言翻译成机器指令 |
| 操作系统 | 多个软件如何在一台电脑共处 → 软件治理 + 基础编程接口 |
关键判断：基础架构解决与业务无关的通用问题，通常以独立软件存在（Linux / Nginx / MySQL / PHP）。软件服务化大趋势下，很多基础软件以互联网服务方式提供，这就是云计算。
完整的程序架构是怎样的？
基础架构越强大，应用开发要关注的问题就越收敛，开发效率就越高。当只需关注业务问题本身时，我们是在做业务架构（应用架构）。
| 层次 | 解决什么 | 代表 |
|---|---|---|
| 基础架构 | 与业务无关的通用问题 | 冯·诺依曼体系、操作系统、编程语言 |
| 业务架构 | 应用本身的业务问题 | 遵循相同架构原则 + 设计范式（MVC、游戏引擎等） |
客户端架构则多了一层麻烦——多样性挑战（数十种操作系统、无数种设备）。消除多样性、提供统一编程接口的第一个尝试者是浏览器：
- 浏览器可看作"操作系统之上的操作系统"；它能解决多大问题，取决于市场占有率。
- Web 应用与原生应用的差别，只在于底层指令是 JavaScript 而非机器码；WebAssembly 正在改变这一点。
- 微信引发的小程序之战，“本质上是一场浏览器的战争”。
- 基于浏览器技术核心也能构建跨平台框架（如 React Native）。
架构师不只要想清楚业务怎么分解，从底到顶每一层都要做决策：先做 iOS 还是小程序？选 Java 还是 Go？这些都是架构的一部分。
总结
本篇从"计算机如何工作"出发，登高鸟瞰了程序的完整架构体系——自底向上是冯·诺依曼体系、操作系统/编程语言等基础架构，再到应用本身的业务架构。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 基础架构 | 与业务无关、做什么应用都要面对的通用问题 |
| 业务架构 | 应用本身业务问题如何构建，因领域而异 |
| 浏览器 | 操作系统之上的操作系统，价值取决于市场占有率 |
| 云计算 | 把基础软件以互联网服务方式提供 |
一句话速记
架构能力是内功，写代码是招式——内功修的，就是把"程序从地基到顶层"这条脉络反复梳理、融会贯通。
思考题
你对今天的内容有什么思考与解读？回到你正在做的系统：从底层硬件到最顶层的业务，每一层你都做过明确的架构决策吗，还是有些层是"默认接受"的？
