文中谈到操作系统的抽象在并行计算的云平台上已经不再适用。
谈谈我的想法：从几个方面来考虑。一共要抽象计算、内存、存储、网络四个方面。
计算：单机计算可以以虚拟机或容器（比如docker）为单位。虚拟机或容器的好处是可以做实时迁移（live migration），从而可以自动均衡负载。多机并行计算，需要把计算抽象为可以随时（或定期）存储和加载（类似于操作系统的休眠和恢复）的步骤（这一点可以在操作系统层面实现），步骤与步骤之间可以通过存储（或网络，但实际上可以抽象为存储，后面会讲到）来交互。这样做的好处有几点：首先一个程序的整个进程都运行在一台机器上，不必改变这方面的编程模型。线程模型可以继续适用于单进程内的计算。
跨进程的计算将被强制要求封装为步骤，并采用BSP模型。好处有：所有步骤的执行序列就相当于状态机，与具体的物理机无关。所有步骤都可以在机器间迁移。对于静态输入来说，给定一个全局初始的存储状态（存储在云上），所有并行步骤的最终执行结果必然是一致的。对于动态输入来说，只要存储的内容被很好地保存了，即便一台机器出了错，只要上面的步骤迁移到另一台机器以同样的初始存储内容重新执行一次，任务仍然可以被完成。只有当存储或存储更新本身被丢失的情况下，数据才会丢失。
我认为大多数情况下除非是外网的访问，需要遵循外网协议，所有内网访问都可以直接抽象成“带事件通知机制的”存储（提供块存储、对象存储 [类似于文件系统]、数据库存储等类型）。在这个抽象层面之上，可以构建出消息队列等机制。使用存储来抽象网络通信的好处是，抽象简单，Unix的everything is a file机制能更好地得到利用。一个间接的好处是，临时的网络通信数据也会被临时地存储，方便调试。当然，一个缺点是，所有数据都要被云存储存储一份，带宽会有问题。为此，对于带宽需求量大的通信，可以单独优化成“不存储”的临时数据，类似操作系统层面的memory mapped file（内存映射文件）中的page file backed（由页面文件支撑的）数据。
存储系统所带的事件通知机制，其含义是，程序可以指定在对象存储，或数据库存储中的指定目录、指定对象（或文件）、指定数据库表的指定键值上进行监视，一旦在云存储中的这些数据上值发生改变，那么就通知该程序。
master data（主数据，比如员工列表等极少改变，却经常需要访问的数据）需要人工定义，由云存储跨机房备份和replicate（复制）。但相对动态的transaction data（事务数据）和communication data在概念上不作区分。云存储系统将自动根据数据的读取频率和写入频率、应用程序提供的实时性标志（应用程序可以接受多旧的数据）、数据访问的源机器所在的网络位置等自动优化数据访问，包括做多少个复制副本等。但需要注意的是，对于SQL等数据库存储来说，由于其数据粒度比文件系统小得多，于是只能根据数据冷热来区分数据，而不是像大个文件数据那样，仔细地为每个文件做优化。
最后来谈内存。事实上这个是最无法被优化的东西——内存只能在结点本身上面使用。网络分布SSD还有不少用处，因为SSD是毫秒或微秒级的，网络最快也是毫秒或微秒级。但内存是纳秒级的，没有办法通过网络共享内存来提高速度。最多就是把swap或page file（交换文件或页面文件）放在云存储上罢了。所以，内存的使用，就在于充分利用一台机器，让它CPU和内存尽可能以同样速度接近饱和，而不是一个遇到瓶颈了，另一个还空闲很多。
瞎想了许多，请各位看官自行定夺。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
