架构技能（三）：扩展性

最新推荐文章于 2025-04-05 22:22:50 发布

棕生

最新推荐文章于 2025-04-05 22:22:50 发布

阅读量1.2k

点赞数 30

分类专栏：架构技能文章标签：架构技能扩展性冯诺依曼体系结构计算机启动扩展性微型状态机扩展性

本文链接：https://blog.youkuaiyun.com/wang_zong_sheng/article/details/145241046

版权

架构技能专栏收录该内容

14 篇文章

订阅专栏

做软件系统设计或代码设计，经常会提到扩展性。

扩展性，到达是在谈什么呢？

简单来说：扩展性，是指以不变应万变的特性，即以一种不变的能力可以满足多种应用的需求。

所以，在做软件架构设计、系统模块设计和代码实现时，需要分析清楚 “不变的能力” 是什么和 “多种应用的需求” 是什么。

冯诺依曼体系结构

我们对信息技术追本溯源，从最初的冯诺依曼体系结构来聊扩展性。

冯诺依曼体系结构本身很简单，但从事很多领域很长时间的软件架构设计和代码开发之后，再来分析冯诺依曼体系结构，会发现它最大的奥秘之一是其扩展性。冯诺依曼体系结构见下图。

输入设备与输出设备统称 “外设”，包括手表、洗衣机、冰箱、汽车、无人机等目前已经影响我们日常生活的各类设备；
存储器，专指可与中央处理器直接交互的内部存储器（不包括硬盘，硬盘是外设），存储器上存储着中央处理器能识别和执行的指令；
中央处理器，即CPU，包括运算器和控制器，它从存储器上按顺序读取和执行每一条指令；
中央处理器和存储器合称 “主机”，所以计算机由 “主机” 和 “外设” 两大部分组成。

就是这样一个简单的计算模型，经过仅仅几十年的迭代和发展，形成了目前我们五彩缤纷的信息世界并影响了我们生活的方方面面，它是怎么做到的呢？

需要注意：直接影响我们生活方方面面的是冯诺依曼体系结构中的 “外设” ，而非 “主机” 。

“主机” 并不知晓它所接收到的指令的来源是一台洗衣机还是一辆行驶在高速路上的智能汽车，“主机” 也不知道它所发出的指令的接收者是一块手表还是一架正在高空巡航的 A380。从某个视角来看，CPU 其实很 “傻”，它只认识它所配套的指令集中的指令而已，只是运行速度非常快而已。各类厂商生产的各类外设，就是基于 CPU 的指令集编制的应用程序，来有效控制外设进行作业。

分析到这里，冯诺依曼体系结构的扩展性可以用下图进行说明。

CPU 只能识别和执行指令集中的指令，如：x86 架构 CPU 有其复杂指令集，arm 架构 CPU 有其精简指令集；
各类外设，基于指令集编制出各种各样的应用程序；也就是通过对指令集中的某些指令进行排列和组合后形成各类应用程序，到底有多少种取决于指令集规模和我们现实生活的业务需求；
编制的应用程序直接运行在 CPU上。

冯诺依曼体系结构，解决了一切可以用 “计算” 解决的问题，CPU 只管识别执行指令集中的指令即可，但却提供给了应用程序编制的一切可能性，这就是它的扩展性：“不变的能力” 是 CPU 识别和执行指令集中指令的能力，“多种应用的需求” 是编制出影响生活的方方面面和构造出色彩斑斓信息世界的各种应用程序。

计算机启动过程

冯诺依曼体系结构只是一个计算模型，我们落到实际的计算机中，看下计算机本身的扩展性。

提一个问题：如果没有操作系统，我们编写的应用程序可以正常运行吗？

要回答这个问题，需要了解普通计算机的启动过程，见下图。

计算机加电启动后，CPU 会首先去一个固定的地址（这个地址一般在主板上）开始读它开机后的第一条指令；在这个固定地址里一般只有一条指令，而且这条指令一般是一条跳转指令；
固定地址里面的跳转指令会引导 CPU 到 ROM （ROM 一般也在主板上）中读指令，ROM 是只读存储器，里面存储着 BIOS 程序；BIOS ，即基本输入输出系统（Basic Input Output System），里面主要是基础外设的驱动程序，比如键盘、鼠标、显示器等，因为有了 BIOS，所以开机就可以使用键盘和显示器了；
BIOS 程序的最后一般也是一条跳转指令，该指令会引导 CPU 到硬盘的引导区读指令，硬盘中的引导区是一个非常小的区域，主要作用是引导 CPU 跳转到操作系统的启动程序；如果计算机安装了多个操作系统，引导区的引导程序会提供菜单让我们选择需要运行的操作系统。

以上就是普通计算机的开机启动过程，回答上述问题：

如果没有操作系统，我们编写的应用程序可以正常运行吗？当然可以，只要有一条跳转指令做引导即可。

我们分析上述计算机的启动流程：

开机启动时，共有三次指令跳转：固定地址中的跳转指令跳转到 ROM 中的 BIOS，BIOS最后的跳转指令跳转到硬盘引导区，硬盘引导区中的跳转指令跳转到待启动的操作系统；
CPU 加电后的第一个动作一定会去固定地址读指令，这是厂商规定的；既然固定地址中只有一条跳转指令，为什么不把这条跳转指令放到 CPU 中呢？因为有一天如果要修改该跳转指令，修改主板的固定地址要比修改CPU省事很多。
固定地址中的跳转指令，赋予了计算机更多的可能性，它可以跳转到 BIOS 程序，来加载基础外设的驱动，如果不需要键盘鼠标和显示器，也可以直接跳转到硬盘的引导区程序直接加载操作系统；
在很多嵌入式的应用领域中，甚至不需要操作系统，只需要最基础的输入和输出以及应用程序，这个时候我们可以对 BIOS 程序做裁剪，然后由 BIOS 最后的跳转指令跳转到需要运行的程序即可。

计算机的启动过程，解决了按需加载的问题，这就是计算机本身的扩展性：“不变的能力” 是跳转指令引导 CPU 执行指定区域程序的能力，“多种应用的需求” 是根据场景按需裁剪或加载程序的需求。这样的设计与网关系统的插件架构有异曲同工之妙。

微型状态机

关于扩展性，上面两个例子更偏底层一些，我们举一个上层业务系统的例子。

在电商系统中，存在大量的订单记录，每一条订单都有很多的状态，而状态之间存在大量的转换关系。举例见下图。

图中圆形表示订单的一种状态，状态之间的带箭头线表示事件，状态是持续一段时间，而事件是瞬时发生的；也就是订单的状态在事件的作用下会发生状态转移，转换成另一种状态。

上图表示的仅仅是订单状态中与 “退款” 相关的状态转换情况，如果把订单所有状态转换关系全部画出，转换图将十分庞大；更甚者，这仅仅是 C2C 电商模式的状态转换，在一个同时支持 C2C、B2B、C2B2C的多模式电商系统中，状态转换图将会有怎样的复杂度。并且，随着业务的不断发展和迭代，订单的状态转换关系也会不断变化。

面对这样的一个状态转换图，应该如何设计实现呢？如果在代码中充斥着大量的 if-else 和 switch 语句，维护这样的业务系统，将会是怎样的一场噩梦？有没有一劳永逸的简单的解决方案呢？

我们通过 “微型状态机” 抽象出一个业务组件，解决复杂状态转换图的问题，见下图。

由下往上，最底层是状态转换图的结构化存储，即将各类复杂状态转换关系通过关系表来描述和存储；
中间是状态执行机，用于解析状态转换关系，和执行状态转换时的业务逻辑；
最上层是具有各个复杂状态转换逻辑的业务线。

状态转换图的结构化存储，见下表。

表中每一条记录，描述一个具体的状态转换关系：

id：关系表记录的唯一标识；
fsm_type：描述一个业务线，比如：1 是C2C业务，2是B2B业务，3是C2B2C业务；
op_type：描述驱动状态转换的事件，比如：卖家发货事件、申请退款事件；
role：描述触发事件发生的角色，比如：只有 “买家” 这个角色触发 “申请退款” 事件，才有效；
source_status：描述源状态，比如：支付成功状态；
target_status：描述目标状态，比如：退款状态；
handler : 描述一个具体的方法名称，当状态发生转移后，会执行由 handler 指向的固定代码逻辑。

理解上述状态转换图的结构化存储逻辑后，整个微型状态机业务组件的原理就非常简单了：

首先，所有业务线通过配置化的方式将其状态转换逻辑关系写入到关系表中；
然后，当状态发生变化时，状态执行机会根据条件判断目标状态，并通过反射机制执行配置的handler所指向的代码逻辑。

微型状态机通过配置化的方式解决了各种复杂状态转换的逻辑问题，这就是微型状态机的扩展性： “不变的能力” 是根据配置的状态转换结构执行handler的能力，“多种应用的需求” 是各类电商模式下各种订单状态的多种状态转换的需求。

最后，总结文中关键：

扩展性，是指以不变应万变的特性，即以一种不变的能力可以满足多种应用的需求;
冯诺依曼体系结构的扩展性：“不变的能力” 是 CPU 识别和执行指令集中指令的能力，“多种应用的需求” 是编制出影响生活的方方面面和构造出色彩斑斓信息世界的各种应用程序；
计算机启动过程的扩展性：“不变的能力” 是跳转指令引导 CPU 执行指定区域程序的能力，“多种应用的需求” 是根据场景按需裁剪或加载程序的需求；
电商系统微型状态机的扩展性：“不变的能力” 是根据配置的状态转换结构执行handler的能力，“多种应用的需求” 是各类电商模式下各种订单状态的多种状态转换的需求。