写点什么

程序原本(四):系统的基础部件

  • 2020-02-13
  • 本文字数:2329 字

    阅读完需:约 8 分钟

程序原本(四):系统的基础部件

编者按:本文节选自周爱民著《程序原本》一书中的部分章节。

系统应付规模问题只有两个总法则

聪明的曹冲称出了大象的重量。此前我们仅仅将这一思想归纳为“通过某种系统将大象的重量映射为石头的重量”,但这还远远不够。因为我们只触碰到了这个问题的一个解——映射,而“为什么需要映射”才真正是问题的本身。


曹冲的高明之处在于,他认识到“不能称象”的本质原因是:大象不能被分割。“不能分割”才是灾难之源。因此,如果系统如我们此前所讨论的,是“通过在程序组织上的结构化来解决规模问题”的一种策略,那么程序所解决的问题集“能否分割”以及“如何正确地分割”,就是所有系统问题的核心所在。


对此,曹冲称象的故事提出了一种可能的解:如果“被运算对象”是不可分割的,那么我们可以将它映射为可分割的对象。但即使这个解总是存在的,我们也只是看到了问题的一半。因为在曹冲称象的故事中,我们忽略了一个非常重要的事物:秤。


秤,实质上就是一个数据处理系统:


  • 其一,它具备一个数据处理系统的两个基本要素:处理信息与反馈信息,例如称一块肉,并反馈结果:二斤六两。

  • 其二,它存有一个基本限制:能够处理的信息边界,例如只能称重 100 斤。


也正是因为秤的数据处理能力有限,我们才称不出大象的重量。所以整个“称象问题”既可以看做是“象太大”1,也可以看做是“秤太小”。


1 可见“象太大”才是最原始、顶层的根本问题,所谓“大象不能分割”事实上是“化整为零”这个求解方案所带来的第二层问题;而“将大象重量映射为石头重量”,是进一步的求解方案。“映射/如何映射”作为第三层的问题,是远离原始问题的以及其本质的。


我们的计算机理论是基于这样一个事实,即计算系统的本质就是“算数”。而“被运算对象”的分割只是解决了其中“的问题”。因此当我们将逻辑上的计算系统映射为一个实际实现——例如“称象”或者“计算机”时,我们也可以尝试去解决“的问题”。


换言之,系统应付规模问题的总法则只有两个:


运算能力的分布,以及运算对象的分布。

分布的两个基本特性:可拆分与可处理

但什么是“分布”呢?


分布并不等于分割。“分割”是指一个问题集(无论是运算能力还是运算对象)能否被切分,例如前面一再提及的大象就是不可被分割的。而“分布”,指的是分割的结果能否被各个独立地加以处理。因此,我们说大象映射为石头之后具有了“(数据的)可分布性”,并不仅仅是因为在形式上进行了分割,还因为这些石头能被逐一称重。所以说:


“可拆分”与拆分的结果“可处理”,这两个特性在“分布”中缺一不可。


与一把秤相类似,一个函数实质上也是一个数据处理系统:


  • 其一,很明显,它能“处理数据”2并反馈一个返回值;


2 这其实并不那么明显。其一,处理(process)是函数的基本抽象含义,如同它在数学中的含义是求解;其二,数据(data)是处理的具体对象,这是函数入口参数的基本抽象含义,如同数学中的公式是函数,而代入公式的那些数才是求解的问题(即数据)。


  • 其二,函数能处理的数据也有类型、边界以及运算总量的限制。


就我们通常使用的、单处理器的个人计算机而言,“所有软件构成的全集”所提供的功能总和可以被理解为“一个函数”(设为函数 F)。因为从计算机通电运行开始,系统开始了唯一一个程序入口与处理过程:


  • 步骤一:进行系统自检、BIOS 预设等常规的、硬件系统自有的处理程序;

  • 步骤二:尝试按照约定次序加载移动存储、外部存储等设备中的处理程序3


3 引导光盘、引导软盘,以及硬盘活动分区的引导扇区等。


  • 步骤三:将系统的控制权转移给步骤二中找到的处理程序(的入口)。


请注意,在上述这个过程以及其后的全过程中,处理器(CPU)的处理其实是在单一的时间序列中进行的。而我们的操作系统之所以能同时运行多个程序(例如 Windows 的资源管理器与记事本),以及在后台与前台运行不同的服务与应用程序等,是操作系统:


  • 将“所有软件所提供的功能总和”,即是我们上面假定的函数,分成了多个函数,计为

  • 理解为进程的入口,并假定 可以再分成多个函数,计为

  • 理解为线程的入口,并假定 可以再分成……


可见我们的操作系统(或某个硬件环境下的软件系统)无非是在对需要运算的总量进行拆分,并尝试将这些拆分结果分布在“不同的逻辑单元”4中进行处理。


4 这里仅基于 Windows 系统的“进程-线程”模型进行讨论。事实上这些逻辑单元在不同系统中有着多种类型、多种层次与关系的抽象,例如作业(Job)、任务(Task)、进程(Process)、线程(Thread)、协和(Coroutine)、流(Flow)、事务(Work)、会话(Session)等。


这一计算模型在单处理器时代被称为“分时处理”,即通过任务调度,将单一处理器的处理能力分配给不同的函数。这些函数在宏观层面上是同时运行的进程、线程等执行体,即并行5;而在微观层面上是分时运行的、单处理器的时间序列下的一个时间片,即串行


5 注意这样的实现其实是基于“进程-线程”模型的并发(Concurrency),这些执行体只是在宏观上看来是并行的而已,并非真正意义上的、与串行(Sequential)相对的并行计算(Parallel, Parallel computing)。


回顾分时处理模型,其核心仍然基于“顺序机器”这一基本假设。与此相应地,其基本计算逻辑也是基于结构化程序设计观念,即可以将分支逻辑与循环逻辑统一为顺序逻辑的一个部分。进一步地,也可以将函数理解为一个子函数序列的连续运算。再进一步地,可以说:


如果子函数可以分布,则整个系统是可以分布的。


图书简介https://www.ituring.com.cn/book/2429



相关阅读


程序原本(一):应用开发基础


程序原本(二):应用开发技术


程序原本(三):开发视角下的工程问题


2020-02-13 14:005347

评论

发布
暂无评论
发现更多内容

如何在Ubuntu 20.04|18.04上安装FreeSwitch

百度搜索:蓝易云

云计算 Linux 运维 FreeSwitch

Linux下搭建Java环境[IDEA,JDK8,Tomcat]

百度搜索:蓝易云

Java tomcat Linux IDEA jdk8

[LINUX使用] iptables/tcpdump/wireshark/tshark

百度搜索:蓝易云

云计算 Linux 运维 iptables NAT

劳动节,聊聊AI究竟在替代谁的工作?

脑极体

AI

《自动机理论、语言和计算导论》阅读笔记:p215-p351

codists

编译原理

Linux设备驱动系列(十)——等待队列Waitqueue

Linux内核拾遗

队列 Linux内核 设备驱动

2/28 业务系统高可用设计(上)

hackstoic

架构设计 TGO写作小组28天挑战

TIKV分布式事务的异常处理逻辑

TiDB 社区干货传送门

TiKV 底层架构 学习&认证&课程

【TiDB 社区走进 360】5 月 18 日北京站!和大咖们聊聊全球视野下的 TiDB 应用实践!如何做到成本、效率两手抓!

TiDB 社区干货传送门

唐刘:关于产品质量的思考 - 测试的窘境

TiDB 社区干货传送门

数据库前沿趋势

唐刘:关于产品质量的思考 - UT in TiDB

TiDB 社区干货传送门

数据库前沿趋势

Linux中的chgrp命令及示例

百度搜索:蓝易云

云计算 Linux 运维 云服务器 chgrp

理想中的开源社区是怎么样的?来自 TiDB 社区运营表妹的浅认识

TiDB 社区干货传送门

一次元数据锁MDL故障排查经历

TiDB 社区干货传送门

实践案例 故障排查/诊断 7.x 实践

支付系统概述(十四):收入模型

agnostic

支付系统设计与实现

TiDB 升级方案选择

TiDB 社区干货传送门

实践案例 版本升级

淘宝商品详情API接口:实时获取SKU价格及库存信息

技术冰糖葫芦

API Explorer API boy pinduoduo API

开源框架 NanUI 项目宣布将暂停开发,作者转行卖钢材

源字节1号

开源 软件开发 前端开发 后端开发 小程序开发

AI 如何赋能优质直播内容创作?

自象限

【Java代码规范】阿里编码规约 VS CheckStyle

百度搜索:蓝易云

Java 云计算 Linux 运维 checkstyle

OpenMLDB v0.9.0 发布:SQL 能力大升级覆盖特征上线全流程

第四范式开发者社区

人工智能 机器学习 数据库 开源 特征

数据库不应该盲目的只看通用基准测试,还有更重要的东西

TiDB 社区干货传送门

数据库前沿趋势

OceanBase开发者大会·2024精彩PPT合集

菜根老谭

oceanbase

ubuntu 20.04设置authorized_keys让VS Code ssh远程免密连接

百度搜索:蓝易云

Linux ubuntu 运维 SSH Code

阿里云ubuntu服务器搭建ftp服务器

百度搜索:蓝易云

云计算 ubuntu 运维 云服务器 vsftpd

程序原本(四):系统的基础部件_文化 & 方法_周爱民_InfoQ精选文章