DC/OS的基本思想——为什么说他是数据中心操作系统

所谓的DC/OS，全称为数据中心操作系统，其基本的思想就是使得运维人员操作整个数据中如操作一台电脑一样。

DC/OS使用了哪些技术可以做到这一点呢？

如图，左面是普通的Linux操作系统，右面是DC/OS，在这里做了一个对比。

无论是哪种操作系统，都需要管理外部的硬件设备，最重要的四种硬件资源即CPU，内存，存储，网络。

最初使用汇编语言写程序的前辈，还是需要指定使用那些硬件资源的，例如指定使用哪个寄存器，放在内存的哪个位置，写入或者读取那个串口等，对于这些资源的使用，需要程序员自己心里非常的清楚，要不然一旦JUMP错了位置，程序就无法运行。这就像运维数据中心的一台台物理机的前辈一样，那个程序放在了哪台机器上，使用多少内存，多少硬盘，都需要心里非常的清楚。

为了将程序员从对硬件的直接操作中解放出来，提升程序设计的效率，从而有了操作系统这一层，实现对于硬件资源的统一管理。某个程序使用哪个CPU，哪部分内存，哪部分硬盘，程序只需要调用API就可以了，由操作系统自行分配和管理，其实操作系统只做了一件事情，就是调度。对应到数据中心，也需要一个调度器，将运维人员从指定物理机或者虚拟机的痛苦中解放出来，这就是Mesos。Mesos即使数据中心操作系统的内核。

在使用操作系统的时候，我们可以开发驱动程序来识别新的硬件资源，可以开发内核模块(例如openvswitch.ko)来干预对于硬件资源的使用，对于Mesos，同样可以开发isolator来识别新的硬件资源例如GPU，也可以开发Executor来干预资源的使用。

在内核之上，就是系统服务，例如systemd，是用来维护进程运行的，如果systemctl enable xxx，则保证服务挂掉后自动重启。对于DC/OS，保持服务long run的是marathon，但是仅仅只有marathon还不够，因为服务是启动在多台机器上的，而且服务之间是有依赖关系的，一个服务挂掉了，在另外一台机器启动起来，如何保持服务之间的调用不需要人工干预呢？这需要另外的技术，称为服务发现，多是通过DNS，负载均衡，虚拟机IP等技术实现的。

使用操作系统，需要安装一些软件，于是需要yum之类的包管理系统，使得软件的使用者和软件的编译者分隔开来，软件的编译者需要知道这个软件需要安装哪些包，包之间的依赖关系是什么，软件安装到什么地方，而软件的使用者仅仅需要yum install就可以了。DC/OS就有这样一套包管理软件，和其他的容器管理平台需要自己编译Docker镜像，自己写yml，自己管理依赖不同，DC/OS的软件使用者只需要dcos package install就可以安装好软件了，软件的配置，节点数目，依赖关系都是有软件编译者设置。

在最外层，DC/OS像普通的操作系统一样，有统一的界面和命令行。通过它们，可以管理富贵论坛
安装包，管理节点，运行任务等。DC/OS不仅仅是运行容器的平台，如果仅仅运行容器，就是容器管理平台，而非数据中心操作系统。通过DC/OS，你可以在每台机器上运行一个命令来进行统一的配置，而无需登录到每台机器上去。你可以运行容器应用和大数据分析应用并共享资源，并且可以相互发现，这更加符合现代互联网应用，微服务和大数据不可分割。而且Mesos的架构非常开放，你可以通过开发Framework, Executor, Modules, Hooks等，轻松干预微服务或者大数据任务的执行过程，来定制化你的应用。这也符合操作系统微内核的概念。

DC/OS的内核模块Mesos

Mesos架构如下

这个图比较的著名了，也有很多文章介绍这个图，详情可以看文章http://mesos.apache.org/documentation/latest/architecture/，这里不做过多的介绍。

从图中可以看到，Mesos有Framework(Framework里面有Scheduler), Master(Master里面有allocator), Agent, Executor, Task几部分组成。这里面有两层的Scheduler，一层在Master里面，allocator会将资源公平的分给每一个Framework，二层在Framework里面，Framework的scheduler将资源按规则分配给Task。

Mesos的这几个角色在一个任务运行的生命周期中，相互关系如下：

Agent会将资源汇报给Master，Master会根据allocator的策略将资源offer给framework的scheduler。Scheduler 可以accept这个资源，运行一个Task，Master将Task交给Agent，Agent交给Executor去真正的运行这个Task。