你好，我是七牛云许式伟。

到今天为止，我们第一章“基础平台篇”就要结束了。今天，让我们对整章的内容做一个回顾与总结。

抽象信息世界的骨架

基础平台篇主要涉及的内容如下。

这些内容如果展开来讲，每一系统（或模块）都会是很厚的一本书。我们的目的，当然不是为了取代这里每一个领域知识相关的专业书籍。

我们的核心目标是以架构为导向，抽象出系统的骨架，融会贯通，把这些领域知识串起来，拼出完整的信息世界的版图。

抽象出系统骨架的过程时信息必然是有损的，怎么才能做到忽略掉众多的实现细节，把系统以简洁易于理解的方式呈现出来？

这很大程度取决于你对系统的理解程度和抽象能力。如果我们把系统想象成一个人，大部分情况下我们比较容易对其进行详尽而具体的描述，好比下图。

这相对容易。因为你只需要陈述你看到的事实，而不必拷问背后的原因。但实际上为了在最短的时间里让别人理解你的想法，你也许应该这样来描述它，见下图。

当你不是在描述这个系统本身，而是描述它与其他系统的相互关系时，你可能需要进一步简化它，变成如下图这样。

抽象有助于记忆，因为骨架需要逻辑的自洽。

这种抽象能力之所以重要，是因为它是融会贯通、疏通整个信息世界的知识脉络的关键。当你做到对世界的认知可宏观、可微观，自然一切皆在掌握。

比如，本章我们首先介绍的是冯·诺依曼体系结构，我们把它抽象为“中央处理器（CPU）+ 存储 + 一系列的输入输出设备”，并给出了系统的示意图如下。

这个图相当笼统，并没有涉及中央处理器（CPU）指令设计的真正细节。比如，我们没有介绍栈（stack）这个概念，虽然它实际上也非常关键。

为什么需要引入栈？它在中央处理器中起到了什么样的作用？

要了解这个问题，你就需要深入到中央处理器的架构设计中去。如果你对梳理中央处理器的架构设计感兴趣，可以尝试写一篇介绍它的文字。

做这样的事情会对你非常的锻炼。“你自己理解一个事物”和“把你的理解表述成文，去引导其他人也能够理解它”，是完全不同难度的事情。

如果你对中央处理器的设计细节感兴趣，可以进一步查阅相关的参考资料。也欢迎与我分享你的心得体会。

基础平台篇的内容回顾

这一章前面我们讲了些什么？为了让大家对第一章内容有个宏观的了解，我画了一幅图，如下。

**首先，我们介绍了冯·诺依曼体系结构。**从需求演进角度看，虽然我们信息科技发展日新月异，但是底层设计并没有发生过变化，非常稳定。从这一点来说，我们不能不佩服他们的远见。

**随后，我们介绍了编程语言的演进。**从汇编语言的诞生，出现了程序员这个新职业开始，此后编程语言的演进便进入高速发展期。

然而，尽管语言很多，但是编程范式的演进却并不剧烈。大家熟知的过程式、函数式、面向对象基本上能够把几乎所有的语言都囊括其中。Go 语言独树一帜地宣称自己是面向连接的语言，我们着重对比了面向对象与面向连接思想上的差异。

编程语言本身与业务架构的设计关联性不大，虽然模块规格的描述会借助语言的文法。**但是语言长期演进所沉淀下来的社区资源，是我们架构设计所依赖的重要基础。**充分利用好这些资源可以大大降低系统的研发成本。

**最后，我们开始聊操作系统。**从 UNIX => DOS => Windows/Mac/Linux => iOS/Android，从用户交互、进程管理、安全管理等角度看，操作系统的需求演变非常剧烈。

传统操作系统主要包含五个子系统：设备管理（包括存储设备、输入 / 输出设备、网络设备）、进程管理和安全管理。

输入 / 输出设备主要和交互有关，我们概要描述，基本上一笔带过。我会在后面“桌面软件开发”这一章再详加讨论。而服务端的交互比较简单，命令行基本上就满足需求，所以“服务端开发”一章我们不会再特意去展开。

另外，操作系统的商业模式也发生了剧烈的变化。

早期操作系统的营收模式以软件销售收入为主。但是从苹果的 iOS 开始，操作系统都无一例外地增加了以下三个模块：

  • 账号（Account）；
  • 支付（Pay）；
  • 应用市场（AppStore）。

注意，这里我们说的账号是指互联网账号。传统操作系统虽然也有账号概念，但是，它是本地账号，属于多用户权限隔离所需。

而互联网账号的价值完全不同，它是支付和应用商店的基础。没有账号，就没有支付系统，也没有办法判断用户是否在应用市场上购买过软件。

实现了“帐号 - 支付 - 应用市场”这样的商业闭环，意味着操作系统的商业模式，从软件销售转向了收税模式。这类操作系统，我们称之为现代操作系统。所有现代操作系统，所凭借的都是自己拥有巨大的流量红利。

基础平台篇的参考资料

概要回顾了我们“基础平台篇”的内容后，我们这里补充一下有助于理解我们内容的相关资料，如下。

有了本专栏梳理的骨架，相信对你学习和理解以上这些材料会一定的指引意义。

如果你有什么推荐的优秀参考资料，也欢迎在留言区分享，我补充到这个表格中来，我们一起来完善它。

架构之美在于悟

信息世界是无中生有创造出来的，我们不需要去记忆，而是要找到创造背后的骨架和逻辑。

架构即创造。

学架构在于匠心和悟心。它靠的是悟，不是记忆。用思考的方式去记忆，而不是用记忆的方式去思考。

我们日常所依赖的基础平台，随处可见的架构之美，**看到了，悟到了，就学到了。**如果你只能从你自己写业务代码中感受架构之道，那么你可能就要多留些心思了。

比如，如果你日常用的是 Go 语言，那么你可以做一个作业：“谈谈 Go 语言之美”。你从 Go 语言的设计中感悟到了什么样的架构思维？当然如果你不常接触 Go 语言，可以给自己换一个题目，比如“Java 语言之美”。

作为架构师，如何构建需求分析能力，尤其是需求的预判能力？

**首先，归纳总结能力很重要。**分析现象背后的原因，并对未来可能性进行推测。判断错了并不要紧，分析一下你的推测哪些地方漏判了，哪些重要信息没有考虑到。

**另外，批判精神也同样至关重要。**批判不是无中生有的批评，而是切实找到技术中存在的效率瓶颈和心智负担。尤其在你看经典书籍的时候，要善于找出现状与书的历史背景差异，总结技术演进的螺旋上升之路，培养科学的批判方法论。

结语

今天我们对本章内容做了概要的回顾，并借此对整个基础平台的骨架进行了一次梳理。

我们最为依赖，也最为强调的，是抽象能力。它对于构建信息世界的骨架至关重要。为此我们需要不断改造自己的抽象体系。例如，前面“02 | 大厦基石：无生有，有生万物”这一讲中提到过：

引入了输入输出设备的电脑，不再只能做狭义上的“计算”（也就是数学意义上的计算），如果我们把交互能力也看做一种计算能力的话，电脑理论上能够解决的“计算”问题变得无所不包。

有同学留言问：输入 / 输出设备提供的明明是一种 IO 能力，怎么能够算得上是“计算”？

但是实际上，我们人类其实就是在这种“否定自己，不断延展自己的抽象体系”，补全自己的想象力。我们以数学中最为基础的“数”为例子。数的演化大概经历了：

自然数 => 整数 => 有理数 => 实数 => 复数

输入 / 输出能力算不算是“计算”？我们不妨以广义的“计算”角度来看。

输入（Input），无非是采集物理世界的信息，将其数字化，所以一个输入设备其实可以看作是一个模数转换的“算子”。只不过这个算子非 CPU 的指令可以表达。

输出（Output），无非是将数字内容反作用于物理世界，一个输出设备其实可以看作是一个数模转换的“算子”。同样，这个算子非 CPU 的指令可以表达。

计算机 CPU 自身只能做数数转换，输入是比特信息，输出还是比特信息。结合了输入 / 输出设备提供的数模和模数转换的“算子”，连接了数字世界和物理世界的计算机，在数学上也就完备了。

如果你对今天的内容有什么思考与解读，欢迎给我留言，我们一起讨论。本章到此结束，我们将开始第二章：桌面开发的宏观视角。

如果你觉得有所收获，也欢迎把文章分享给你的朋友。感谢你的收听，我们下期再见。

限时放送

推荐阅读专栏《Go 语言核心 36 讲》正在拼团中，限时特惠 79 元，点击链接订阅专栏。