基于Mesos的操作系统之RogerOS

【编者的话】本篇译文将介绍基于Mesos的RogerOS。其已成为Moz工程技术发展的基础，并将开发人员生产力与资源使用效率提升至新的高度。数人云是国内基于Mesos的云操作系统。在设计思路上，和RogerOS有着异曲同工之妙。同样的思路，解决类似的问题，再次说明Mesos是云操作系统（数据中心操作系统）的内核首选。

内容简介

一年之前，我们为Moz Engineering设立了一个新的平台构建项目。项目的目标非常简单——打造下一代平台，将其作为Moz工程技术发展的基础并将开发人员生产力与资源使用效率提升至新的高度。尽管目标如此单纯，但实际操作起来却困难重重。而今天的博文就将向大家展示我们在推进项目开发当中的心路历程。

背景情况

过去十年以来，技术领域的发展变化可谓迅猛且影响深远。软件创新已经成为一股不可回避的浪潮，而且有越来越多行业开始利用软件作为其主要创新实现手段，这意味着软件系统已经在全球经济增速放缓的时代背景下逆流而上、继续保持着可观的发展进度。

计算基础设施在发展速度方面已经将“迅猛”一词作为常态。我们也由以往的内部、专有、耦合、单一性的平台转向开源、分布式且松散耦合性质的新环境。与此同时，世界的发展脚步也可谓一刻不肯停歇。不过相比之下，基础设施系统的更新周期往往无法同这种前进节奏相匹配，这意味着对于大多数企业而言，让新型软件同现有基础设施进行对接已经成为运营工作当中的核心挑战之一。

在Moz公司，我们当然也遇到了同样的难题。对产品核心进行持续创新已经成为我们在Moz的主要任务，而我们的客户也应当能够享受到由此带来的各类成果。不过正如在去年的一篇博文中所提到，我们的现有系统已经处于负载能力的临界点。其带来的最为直观的影响体现在我们的开发速度领域。目前产品的迭代周期变得越来越长，而工程师们则需要耗费更多时间来打理整套系统。另外一些外部问题也开始凸显，这意味着我们获得尝试新鲜技术成果所必需的原始资源开始变得愈发困难。实验是创新的生命基础，而我们也希望能让自己的工程师及产品经理尽可能多地尝试其新鲜想法。由于缺少对资源的支配空间，这就意味着整个团队需要继续“坚守”现有资源——即使其尚未得到充分利用——并在这一有限的范畴之内满足各类潜在的未来需求。

对于我们的技术运维团队而言，这项工作绝不简单。他们需要对数量惊人的各类语言、框架、数据库以及其它种种组件加以支持。从规划的角度来看，来自开发团队的每一项资源请求都会成为运维工作中既有资源使用习惯的恐怖噩梦。举例来讲，某个团队可能需要大量内存与计算核心资源，但却无需使用规模可观的高速磁盘驱动器——这样的要求与传统采购习惯显然完全背离。而且实际情况是，硬件采购是个耗时极长的过程——至少从软件开发周期的角度来衡量是这样。虽然Amazon Web Services等按需平台的出现能够在很大程度上解决此类难题，但着眼于Moz的业务规模，运行自己的硬件体系显然更具成本效益。而从运维工作的角度出发，理想的场景则是将采购划分成数个大规模批次，从而统一硬件规格与具体交货日期。但这种作法显然直接损害了开发人员的实际要求，他们更希望能够以频繁且种类各异的方式在极短的交货周期之内获得自己需要的资源。

另外，与初创企业不同，我们没有那种从零开始的能力或者说可能性空间。任何一套解决方案都必须能够同时应对新型开发项目与传统工作负载，且拥有足以适应Moz未来需求的出色灵活性。

RogerOS

RogerOS正是我们在面对上述问题时给出的答案。这一名称其实是种误读，因为其事实上并不算是真正的操作系统。不过它确实与操作系统存在着一定程度的相似之处。在开发过程当中，我们选择了这个名称并认为其完全能够代表这套平台的特性。开发团队参考了ClusterOS（DCOS）之类的项目。而且与桌面操作系统一样，RogerOS也会对物理硬件进行抽象化处理，并在用户面前体现为一套统一的高级界面——ClusterOS在数据中心或者设备集群当中也扮演着同样的角色，即对集群硬件加以抽象并提供一套特殊的高级界面。这种概念并不是什么新生事物，类似的系统也已经拥有相当长的发展历史。事实上，RogerOS还从谷歌公司的Borg系统当中汲取到了大量设计灵感。

以下几个章节将详细介绍这套系统的具体细节。

设计目标

其实第二篇博文才负责对设计目标的相关细节进行说明，不过幸运的是我们在这里可以先对其加以总结。我们希望能够为开发人员提供一套系统，从而帮助他们：

*在五分钟以内在笔记本设备上实现代码运行或者在数据中心内启动原型设计。

*在一天之内将能够正常运行的原型方案转化为能够接受一定程度外部流量的进阶版本。

*在一周之内将以上进阶版本转化为一套完全成熟的生产系统。

*能够在十分钟之内完成新版本的部署工作。

*不会对系统之上实际运行的具体工作负载类型做出限制，这意味着其能够彻底替代那些只能够承载虚拟机、容器或者批量工作负载的传统系统方案。

*尽可能多的专注于应用程序代码。这套系统应该能够对运行当中的应用程序进行各类必要处理，具体包括负载均衡、监控、日志记录、故障处理以及规模伸缩等等。

设计

RogerOS的核心为Apache Mesos。考虑到既定设计目标以及对该系统的灵活性要求，Mesos可以说是目前惟一合适的可选项目。不过Mesos的核心定位是一套通用型资源调度工具。要想真正实现RogerOS项目的既定目标，我们需要围绕Mesos建立起完整的生态系统。Mesos在以下架构示意图当中对应的是“ClusterOS Kernel”。

上图展示的是完整架构。正如我们提到，从核心角度来看，RogerOS采用Mesos调度机制，但同时又整合进大量协同服务并与之紧密集成。本系列博文的第二篇对这些设计细节做出了进一步说明。

使用体验

通过以上叙述大家应该能够想见，RogerOS是一款非常复杂的系统，而且已经经历了相当长的开发周期。在着手构建之初，我们其实并不太确定选择Mesos作为系统核心是否正确。当时我们已经通过实践证明了Mesos的适用性，不过其在Moz这类混合型环境下的表现却让我们有点担心。不过幸运的是，我们最终还是选择了Mesos，这一决定让我们至今都相当自豪。其不仅实现了既定承诺，还为我们带来更多惊喜。事实上，我们在系统稳定性、可扩展性以及性能表现方面都没有遇到任何问题。另外，Mesos还允许我们利用一小部分开发资源分步实现目标。目前，一套小型设备集群已经足以为Moz运行多种应用程序。关于这方面内容的具体细节，还请大家参阅本系列的第二篇博文。

开发人员对这套系统的反馈也相当积极。Moz Content项目就是从零开始在RogerOS之上打造而成的，开发团队对于这套平台给出了极高评价。具体来讲，通过硬件抽象与高级服务交付，RogerOS能够让开发团队将精力集中在对产品本身的琢磨之上。另外，除了各类新产品之外，相当一部分传统产品也已经能够在这套系统当中成功运行。

总结

总体而言，RogerOS已经成为Moz一个极具野心的项目，而且其能够满足很大一部分我们在立项之初为其设定的发展目标。当然，发展完善的道路仍然漫长，但我们对于目前获得的成果感到相当满意！

另外同样重要的是，我们要向各位为当前成果做出贡献的参与者表示感谢：Jord Sonneveld、Manish Ranjan、Amit Bose、Chris Whitten、Josh Gummersal、Evan Battaglia、Tyler Murray以及整个Moz Content团队，谢谢你们！没有你们的参与，RogerOS根本不可能实现如今的成就。

点击查看英文原文

对RogerOS的详细技术架构感兴趣？关注我们，本周会推出第二篇文章，为您详细介绍RogerOS。