为了操作系统的时间线

这学期给自己挖了个坑：由于觉得应该帮助学生了解分布式计算（现在的大数据是分布式计算在当下的典型代表），就在负责的操作系统中允诺梳理下所谓的 DOS （Distributed Operating System）的内容。其中比较费精力的就是梳理出计算机和操作系统的历史演变：因为操作系统的核心功能就是管控资源（硬件资源自然是主要的部件，此外也还有所谓的文件系统、数据结构等资源），那么，计算机变了，操作系统也就必须随之改变。
而之所以费精力，就是因为那些时间往往隐含在许许多多的网页、书籍等资料中，而且有时候不同资料中记录的时间信息也有冲突（有些体会到清末疑古派所做考据功夫的艰辛😀）。
临近期末，好赖也就这样了，也就有了下面的按照时间线梳理的相关事件的图例。

Evolution of Computers and OSs-1.0(20211101).png

*1: 之所以有 Communication一列，是为了突出它，因为分布式系统的基础功能就是要支持远程进程间的相互协同，Communication自然是其中的关键；

*2: 查阅很多所谓的 分布式系统的视频，其实大量探讨的是 "分布式数据库管理系统" 的专题，所以，在梳理过程中于 DOS 应该包含哪些内容就很困惑。后来，觉得还是以"支持程序的运行"这一根本特征，也所以分布式数据库管理系统的内容就剔除了出去，如 2PC (2 Phase Commit) 和 3PC (3 Phase Commit)

也有一些有趣的体悟：

• 当下OS课程的专题，可概括为 "在von Neumann 架构(有限的资源 - 1个CPU和2个线性地址空间 [内存和硬盘])的计算机上支持多个程序的并发运行"；类似的，DOS的专题可概括为"在分布式系统或并行计算机上支持多个程序的并发运行"

• 分布式环境下，操作系统的角色更多地对应Local OS + Job Scheduler 的方式 - 对于 Local OS，现在Linux 是主流 （从SuperComputer Top 500 中可窥一斑）；而 Job Scheduler，早期有 UNIX集群上的 PBS，后来 Linux计算上的 LSF、SLURM，以及面向大数据环境的 Borg、K8S。国内华为的 Donau算是混合集群的调度器。

• 在 "操作系统的角色更多地对应Local OS + Job Scheduler 的方式" 的环境下，分散的 CPUs、内存和 分布式文件系统、分布式Naming、分布式事务管理等，也就只是起到了 被"Local OS + Job Scheduler"管控的"资源"

  • 按照 Communication，TeleCommunication --> TCP/IP --> RPC (RMI等) --> 专门的 通信接口 (PVM和 MPI等) --> Middleware (CORBA, DCOM等) --> Web Service Middleware (Globus, SOA) --> Clouding
  • 微内核其实是失败了的 - 不管是 Ameoba, MINIX, 还是Chorus。主要的原因是因为性能太差，而 UNIX 以及后来的 Linux很不错
  • 而 Job 往往是 "MPI +" 的编程方式来实现的，如 "MPI + OpenMP"、"MPI + CUDA" 、"MPI + Deep Learning"等

• 保障集群节点的状态一致，PAXOS 是绕不过去的协议！由 Leslie Lamport 1989年以故事的形式撰文，但故事性太强不符合工科学者的思维，后来2003年"PAXOS made simple" 版本才妥协使用计算机术语来撰写。

  • 看资料，有学者认为：在 Consensus 问题上，方案就两种，一种是 PAXOS，另一种是其他
  • RAFT是 PAXOS的简化版本，发表于2014年
  • PAXOS 等和 2PC、3PC 虽有相似之处，但应对的场景是不同的：后者的理解可以参考网上订票 - 涉及出票系统和扣钱系统，它们要遵循"要么都完成，要么啥也不能改变" 的事务的概念；而前者往往只用于状态的记录(也就多对应 "分散节点的日志要保障一致")

• 虽然相关概念和技术(计算机和操作系统) 的 "0-->1" 主要是国外完成的，但是，在"1 --> N" 的环节，国人奋起赶上，如操作系统有 华为的 鸿蒙、欧拉，阿里的 龙蜥；在大数据领域就更多了，Kylin、OceanDB、X-DB、TiDB、ShardingSphere、RoketMQ等等