软件架构与计算机组成原理有啥关系？

为什么学架构要学组成原理？

（一）软件架构和计算机组成原理有关系吗？

先来看一看什么是软件架构？简单来说，业内存在两大流派：组成派，指负责不同计算任务的“组件”通过“交互”完成一系列信息处理功能，即“组件+交互”；决策派，指软件构建过程中一系列重要决策的集合。

“我是真的，你是假的！”，“不对！我是真的，你是假的！”。好了，别争了，二位都有理，不妨中和一下重新来过：软件架构可以看成是以用户需求为输入，在构建过程中经过一系列重要的决策，输出一系列“组件+交互”的设计指导实现，最终构造出符合用户需求的软件制品。（注：关于软件架构的内涵，笔者后续会发文进行深度阐释，这里暂且如此理解）

当然软件架构在不同的软件开发周期（如：瀑布、RUP、敏捷开发等）中，实施过程会有所不同，撇开这些暂且不谈只说架构本身。由上述可知架构是软件构造过程中的设计环节，上承需求下启开发，输出实现了信息处理功能的“组件+交互”，是现实世界与计算机领域的桥梁。因此架构过程就是一个从无到有的构建过程，是信息处理承载体（此处指“组件+交互”形式）的创造过程。

既然提到信息处理载体，计算机历史上最早实现信息处理的是计算机硬件体系，那时人们用按钮操作计算机。指令程序也是后来才发展出的一种操作硬件的方式，就连操作系统当时也只是计算机体系的附庸。遥想当年蓝色巨人IBM把PC操作系统DOS外包给微软，后来差点反被微软收购，这场软硬件争霸的反转大戏，真是令人唏嘘。正因为硬件、软件的先后发展关系，很多软件设计理念源于硬件、借鉴硬件。

同时，软硬件在功能实现上可以互通，软件功能可以硬件化，硬件功能也可以由软件实现。比如：常说的高清视频“硬解码”就是软件功能的硬件实现方式，“虚拟机”就是由软件实现硬件体系。由此可见，软硬件在信息处理模式上是同一的，或者说都可以用“组件+交互”的模式来表述，区别仅在于具体实现的技术不同，一个是电子电路实现，一个是计算机语言实现。在不考虑具体实现的前提下，学习计算机组成原理就是学习一组成熟的信息处理模式，或者一组经典的架构模式。

说的好听不如“举几个栗子”。

比如：CPU就是一种任务密集型的处理架构。如果把每条指令看做一个任务，程序就是任务集合。任务集合的执行速度，取决于每个任务的执行速度和同时执行的任务数。CPU整个架构的演化，就是为了不断优化这两个指标。以x86系列的CPU为例，先是通过不断提升主频和流水线细化分级，提高单条指令执行速度和指令并行度。接着引入多条指令流水线即超标量技术，进一步提升指令并行。为了避免流水线闲置，又引入超线程技术虚拟两个CPU核心。为解决超线程之间共享资源的竞争，物理上引入多核从而实现真正的多线程并行。

另外，CPU的数据访问架构也是经典。CPU访问内部寄存器最快，但是寄存器只是临时存储，必须要访问内存。不过访问内存就慢多了，随着CPU速度越来越快，内存难以望其项背，CPU只能等着干着急。后来发现CPU访问数据有特点（即“局部性”后面课程会详细讲），果断引入高速缓存，继而发展为多级缓存。有样学样，有了这套访问模式，再拉上磁盘乃至 络，就形成了一个基于缓存的存储器层级结构。笔者曾经主持的某大型分布式系统就是借鉴了CPU的任务处理和数据访问架构的设计思路，受益匪浅正所谓“一花一世界，一叶一菩提”。

再有，大家都玩过3D游戏吧，负责3D渲染的就是显卡。3D图像的实时渲染可是个数据密集型的计算任务，与CPU的任务密集型大不相同。因此， CPU干起这活来非常吃力，这就诞生了GPU。GPU的“众核架构”就是为这种数据密集的计算任务而生的，也正因为此GPU现在又承担了AI算法模型的训练，正朝着一种通用计算平台去发展。如果看一下GPU计算核心的集群模式，简直跟大数据的分布式结构有异曲同工之妙。

现代家用计算机，都是多媒体的高手，而计算机核心只有“CPU+内存”，其他都是外设，比如：磁盘、显示器、音箱、键盘、鼠标等。面对这些不同处理速度、处理模式的外设，计算核心如何与之交互呢？此时基于适配器及总线的异构系统集成架构就粉墨登场了，其间又涉及同步异步的交互，并行串行的传输等等不一而足。大型企业应用的系统集成和微服务化，都可以在其中找到借鉴思路。

看到这里，您还能说软件架构和计算机组成原理没关系吗？我想答案您最清楚！

（二）不学编程能学架构吗？

答案：能！这个真可以有！

您可能不信，因为大家常见的说法是“要先学编程，干几年开发，再逐渐学习架构”。这个说法对吗？也对，也不对。

说它对，是因为从软件开发的角度看，必须得会编程才能“制造”软件。如果不懂编程，架构的产出就只是概念模型，或说逻辑模型。必须要和具体的开发技术结合起来，才能继续细化架构使之指导开发，构建结构合理的软件实体。

说它不对，是因为架构过程是一个“信息处理承载体”的创造过程，引导这个过程开展的当然是创造性思维，而创造性思维与编程技术没有必然联系。从古 至今所有人造物无论简单复杂，都呈现为零部件相互连接、相互协作实现一定功能的形态。比如：古代的马车零部件有上百个，而现代轿车至少有2万个，虽然构造原理、复杂度大为迥异，而创造性思维所构建的“零部件+连接”的形式却初心不改、始终如一。由此可见，“组件+交互”形式就是创造性思维在信息处理领域，所引导的一系列决策的结果，这是架构思维的本质。可见，架构思维与编程是没有关系的。但是用于指导开发的架构成果（即设计）却必须是要与编程技术有关的，否则将无法实现为软件制品。

而笔者所见过的很多开发人员没有成长为架构师，并不是缺少编程技术，而是缺少创造性思维或说架构思维，即使开发多年也很难走向架构之路，所以说学架构重点是要学会架构思维。架构思维是需要被训练的，而且需要时常的、不分“场合”的刻意训练。这就如同我们熟知的大侦探福尔摩斯，他时刻都在训练他的推理能力。路过一个人，他只要看一眼，就可以准确判断这个人的经历、工作、行踪等诸多隐匿信息，不禁让人惊呼神技。而这就是他年复一年、日复一日，刻意训练的结果。

训练架构思维，不是非要学会编程或者工作几年之后才进行，而是从一开始接触计算机就要训练，一直贯穿整个职业生涯，除非你不再从事技术工作。但由此习得的创造性思维方式，却弥足珍贵，让你终生受益。

前面讨论过，计算机组成原理作为基础中的基础，最好一开始就去学。这时就可以刻意训练架构思维了，但是如何训练呢？这就是下面要讨论的内容。

为什么要自己推导组成原理？

围棋当中有一种训练方法叫做“复盘”。也就是在每次博弈后，双方棋手把对局再重复一遍，或者按照棋谱排演即“打谱”。复盘之时，需要分析每一步如何设计，如何预想后续下法，以及双方每一步的得失。同时提出假设，是否有其他走法，怎么走最好。通过复盘可以不断激发新的方案、新的思路，产生新的思维乃至新理论。实践中当某种类似局面出现时，就会知道如何应对，并有多种应对方法，而且能够根据当前状态判断未来走向。

借鉴复盘的方法训练架构思维，就需要复盘“信息处理载体”的创造过程。计算机硬件体系作为一个经典的复杂信息处理结构，虽然实现技术是电子电路的，但在信息处理层面软硬件是相通的，都可以还原为“信息处理组件+组件交互”的模式。采用推导或说决策推理的方式，复盘计算机体系构建的决策过程（当然会忽略电子电路的具体实现），不仅能学到组成原理的知识，还能学会“模块设计”方法，并锻炼架构思维。

从不会到会，秘诀是重复。架构思维的训练同样需要重复，组成原理中包含大量案例可以用来重复训练。基于此，笔者将推出针对组成原理的系列教程，目的在于在学习组成原理的同时，训练架构思维。

通过复盘的方法，学到的知识不仅能知道是什么，还能知道为什么。这样的知识是“活的知识”，是可“自推导的知识”，是不用还给老师的知识，这样才算是“学透”。因此笔者提出一个口 以为共勉：“要想弄懂它，那就创造它”。

架构思维是创造思维，除了软件开发，还可以应用到生活、工作任何需要创造的场景，比如：写文档、演讲布道、技术培训等等。希望小伙伴记得要“不分场合”的刻意训练。

感兴趣的小伙伴，可以继续关注笔者后续教程。