前言

随着现代信息越来越丰富，更多的信息需要被处理及计算，仅仅的单台计算机已经满足不了计算，需要将更多的计算机进行同时计算，对操作系统的要求则越来越高，各种各样云计算的的操作系统也应运而生。

操作系统是什么？

操作性系统：OS（Operating System）是一组主管并控制计算机操作的，运用和运行硬件、软件资源和提供公共服务来组织用户交互的相关联的系统软件程序。

操作系统的目标

1）有效性：提高系统资源利用率；

2）方便性：用户能够更加方便处理事物；

3）可扩从性：能够增加并操纵新的硬件设备；

4）开放性：能够遵守世界标准的规范；

操作系统任务的演变

纵观电脑之历史，操作系统与电脑的硬件信息的发展息息相关，操作系统之本意就是提供简单的工作排序能力，后来辅助更新更复杂的硬件设备而渐渐演变的。

单任务系统

单任务操作系统是指一台计算机同时只能有一个用户在使用，该用户一次只能提交一次作业，一个用户独享系统的全部的硬件。

单任务操作系统 = 装载器+通用的子程序库

利用率% = 执行时间/（执行时间+读卡时间）

缺点：

1）操作复杂；

2）利用率低；

3）计算能力不足；

批处理系统

批处理系统是把一批作业以脱机方式输入到磁带上，并在系统中配上监督程序（Monitor），在它的控制下使这批作业能一个接一个地连续处理。

通过批处理系统，硬件利用率提高了，但是由于任务只能一个接一个运行，总体的利用率并不高。

优点：

1）减少CPU的等待时间；

2）多作业不间断进行；

缺点：

1）任务串行，总体利用率不高；

多程序系统

多程序系统是允许多个相互独立程序同时允许在计算机的内存当中，并且他们都存在在开始与结束之间。

从宏观上看是并行的，多道程序都处于运行中，并且都没有运行结束；从微观上看是串行的，各道程序轮流使用CPU，交替执行；

优点：

1）允许多个程序能够在内存中存在

2）提高了CPU等硬件的利用率

缺点：

1）单任务时间过长，会影响其他任务的运行

分时操作系统

分时操作系统是使一台计算机采用时间片轮转的方式同时为几个、几十个甚至几百个用户服务的一种操作系统。 把计算机与许多终端用户连接起来，分时操作系统将系统处理机时间与内存空间按一定的时间间隔，轮流地切换给各终端用户的程序使用。 由于时间间隔很短，每个用户的感觉就像他独占计算机一样。

优点：

1）最大限度提高CPU的利用率：通过CPU中断的方式，合理的将CPU按照时间片的方式提供给每一道程序，让多道程序都能使用到CPU资源，让程序执行的效率更高；

2）用户处理及时：用户能在短时间可到系统大的及时回答；

3）用户相互独立；

缺点：

1）响应时间受硬件设备、时间片大小，信息交互量，信息交互速度影响。

操作系统结构演变

单一体结构

单一体结构是最早期的结构，整个OS都是巨大的单一体，运行在内核下，为用户提供服务；

存在问题：

1）功能模块复杂，修改困难

2）容易造成循环调用死锁

分层结构

将操作系统分为不同的层次，低层次的功能为紧邻其上一个层次的功能提供服务，而高层次的功能又为更高一个层次的功能提供服务：

优点：

1）保证系统的正确性

2）易扩从和易维护性

存在问题：

1）系统效率低

2）系统开销大

微内核结构

将操作系统的核心中的核心才放在内核态运行，其他功能都迁移到用户态运行，于是就有了下面的微内核结构。

优点：

1）提高系统的可扩展性

2）增强系统的可靠性

3）可移植性性

4）减少开发系统的开销

存在问题：

1）用户态与内核态交互频次高，利用率不高

目前主流的操作系统架构图

1）Windows

2）Linux

3）Android

4） Mac

操作系统在云计算的应用

随着运算能力要求越来越高，云计算应运而生，从此操作系统不再是简单管理与控制单台机器的硬件的设备，其最核心的问题是如何把100台、1千台、1万台机器高效的组织起来，灵活的进行任务调度和管理，从而使得可以像使用台式机一样使用。在云计算，最核心的模块是分布式调度模块，它好比于单台机器中的中央处理器。目前，业界已存在多种分布式调度操作系统的实践，如腾讯VStation、伏羲、Hadoop MR、YARN、Mesos等系统。

以下是针对VStation与伏羲两个国内比较出名的分布式调用操作系统的分析与对比：

系统架构 VStation PK Fuxi

现有的调度系统架构如下，分为统一调度架构，两级调度架构和共享状态调度架构。

调度架构对比 - VStation胜于Fux

VStation是基于共享状态的调度架构进行优化调整，业界也有比较典型的代表Google Borg和Omega。

在VStation中使用的是MQ（消息队列）来进行不同模块组件的通信，主要包含以下模块。

• Compute，是宿主机上的 agent 程序，负责和后端通信，并调用 libvirt 等工具。
• Compute Access，是 Compute 与后台架构通信的一个接入层。
• Network，负责云主机的网络相关操作。
• Image，负责云主机的镜像相关操作。
• Scheduler，负责调度功能，为云主机挑选最佳宿主机。
• Resource，负责资源数据的操作。
• Volume，负责磁盘相关操作。

Fuxi是基于两级调度架构进行改优化调整的，业界也有比较有代表的YARN和Mesos系统。

在Fuxi中包含以下的几个模块：

• Fuxi Master是集群的中控角色，它负责资源的管理和调度
• Tubo是每台机器上都有的一个Agent，它负责管理本台机器上的用户进程
• 同时集群中还有一个叫Package Manager的角色，因为用户的可执行程序以及一些配置需要事先打成一个压缩包并上传到Package Manager上，Package Manager专门负责集群中包的分发。

分析过程

• VStation采用最先进的共享状态的架构，每个调度器共享资源状态，能够更快速的调度到对应的资源；
• Fuxi采用的是两级调度架构，需要Fuxi Master 、APP Master、Tubo、APPWorker多个组件模块进行配合，调度器吞吐量非常有限；

调度策略对比-Fuxi 小胜于 VStation

VStation的调度策略分几点：

• 资源同步：私有缓存和增量更新，同步数据量非常小
• 调度决策：通过过滤、排序、打散方式进行决策
• 提交调度结果：通过事物来保证资源数据的一致性

Fuxi的调度策略：

• 策略之优先级和抢占：每个Job能够根据优先级来配置和抢占资源；
• 策略之公平调度：避免了较大优先级的Job取抢占过多资源；
• 配额：每一个业务最多只能使用到指定的资源。

分析过程：

• VStation在资源同步上使用的是，私有缓存和增量更新，调度决策通过过滤、排序、打散方式来选择合适调度结果，提交结果通过事物来保证唯一性。
• Fuxi使用的通过统一的Fuxi Master进行高优先级，策略公平调度、配额上限来控制每个计算的任务的合理性 这里Fuxi胜出的原因在于，Fuxi能够针对不同的计算任务进行合理的分配资源，对于KA的业务来说，比较能够保证KA的业务资源能够合理分配，而VStation则不具备这个分配属性的，均为一视同仁，很容易造成非KA的用户占用过多的云资源，建议VStation在考虑保证KA业务计算中能够合理分配到资源

容错机制对比 - Fuxi 胜于 VStation

VStation的容错机制：几乎没有

• VStation使用的是将错误发到error模块，研发人员再针对故障进行排查，包括任务的恢复

Fuxi的容错机制：

• AppMaster进程重启后的任务调度Failover：APP Master重启后采用Snapshot机制，将Instance的运行进度保持下来，当APP Master重启后，重新加载实例；
• FuxiMaster进程重启后的资源调度Failover： 也是通过Snapshot相关的机制

分析过程：

-Fuxi在容错机制上考虑到自己系统可恢复性，相比VStation采用近乎人工的方式，更加完善，更加快捷，也是VStation的应该考虑待优化的点， 建议VStation在将每个任务都记录下来，在发生错误时，能够第一时间恢复对应的业务的状态

安全与性能隔离的PK Fuxi 胜与 VStation

VStation：在安全与性能隔离中，还没有完善。

Fuxi：则是通过全链路的反问控制，通过Capability和token进行安全的访问控制，并采用Docker和LXC混合部署的方式来实现性能的隔离。

分析：VStation在这个方面上需要完善起来，才能更好的支持好ToB的业务，因为ToB的业务也是追求安全性，机密性。

调度规模与调度速度的PK VStation 胜于 Fuxi

VStation的调度规模在单集群10W节点的规模，速度也是非常快，每分钟能到数万台。

Fuxi的调度规模在单集群5000台的规模，速度也是非常的有限。

分析：VStation在调度模块和速度都是采用先进的技术，整体的规模大，速度也非常快。

对比总结：

1.在业务层面：VStation更加适合ToC业务，在ToB的业务上还需要继续完备，Fuxi本来就是做ToB的业务的，在ToC的业务性能就比较欠缺。

2.在性能上：VStation性能明显优于Fuxi。

参考链接：

https://www.infoq.cn/article/tecent-cloud-distributed-system-vstation

https://developer.aliyun.com/article/72526

https://zhuanlan.zhihu.com/p/139282250

https://cloud.tencent.com/developer/article/1163705