【编者的话】 HubSpot是营销自动化领域的独角兽。其技术团队基于Mesos打造了一套开源系统SINGULARITY。期间发现Mesos对Hubspot的最大好处是能够将其数据中心中的众多设备抽象化为了一台大型计算机，便于资源的共享和动态分配。借用Hubspot的一句话来说明Mesos的价值：我们将过去的一年总结为“一切应用归于Mesos”，那么在新的一年中，我们的座右铭也许可以汇总成“剩下的一切也归于Mesos”。
Hubspot拥有庞大数量的应用服务组件
HubSpot是一套面向企业的市场营销与销售平台，且几乎能够承载一切工作类型——从博客到分析再到客户关系管理通通不在话下。这款产品拥有可观的面向范畴，也因此包含多种独立的可移动组件：约170个单页面Web应用、300项RESTful Web服务、380种后台工作程序、260个cron任务以及400种一次性任务，且全部可以独立方式加以部署。
我们的HubSpot开发团队始终以速度为优先考量。开发人员每天需要完成近300次相关操作，具体涵盖代码提交、变更测试以及生产环境部署。这在很大程度上要归功于我们的平台即服务（简称PaaS）团队，他们的优先目标在于找到相关途径并借此减少开发人员可能遇到的障碍及摩擦。我们在过去一年当中凭借着将越来越多工作负载运行在Mesos——以及我们自主研发的Singularity PaaS方案——之上而获得了巨大收益，同时也给我们的软件、堆栈乃至文化带来了可喜的影响。
当人们问起Mesos给HubSpot带来怎样的切实助益时，他们预期的答案往往是“节约成本”或者“实现自动规模伸缩”之类的结论。诚然，这些都是切实存在的助益；我们节约了可观的资金，因为Mesos允许我们在大型设备之上承载密度更高的工作负载。另外，只需要几次简单点击，我们就能够对任意服务的容量规模进行扩展或者缩减。然而，Mesos的最大助益在于为我们带来了理想的便捷性——具体来讲，它能够将我们数据中心之内的众多设备抽象化为一台大型计算机。
采用Mesos之前的状态
在采用Mesos之前，我们的基础设施需要大量人为因素进行干预。无论是对新设备加以配置还是替换原有硬件都以全人工且容易出错的方式进行。作为传统层面的功能堆栈拥有者，因为托管其服务的设备出现了突发故障，开发人员们往往需要加班加点进行抢修。当然，我们也遭遇过一些单点故障状况，例如开发人员将所有cron任务运行在同一台设备之上。当这些“cron”设备发生问题，随之而来的更换与重新部署工作绝对令人头痛欲裂。
我们的基础设施在透明性方面做得也不够好。我们当然拥有良好的用于警示目的的遥测数据分析机制（例如服务标准与运行状态检查），但开发人员要想从他们的服务当中提取数据（例如提取转储记录或者上周的全部服务日志），则必须以手动方式查询每台设备——这自然带来了可怕的时间浪费。很明显，我们需要一套更简单且更安全的解决方案，使得开发人员能够轻松访问其服务的相关数据，同时又不至于对其它服务造成影响。
步入Singularity的世界
我们转向Mesos的理由是让我们的开发人员能够真正从事其所擅长的工作：编写软件，而不必对隐藏在引擎盖之下的HubSpot技术堆栈各个层面拥有全面理解。当我们踏上这段Mesos之旅时，我们首先以调查性方式尝试将Chronos（负责处理cron任务）与Marathon（负责处理Web服务与后台工作程序）纳入部署流程。而Singularity这一名称也因此而来（意为奇异点）——其初始设计目的在于充当一套Mesos框架以处理一次性任务，当时Chronos与Marathon还不具备此类支持能力。
我们最终决定放弃这条初始设计路线，转而将Singularity转化为一套更像是“开箱式PaaS”的解决方案。这意味着它只是单独一项服务，能够处理数据中心之内的大部分常见工作负载类型。大家可以将它视为一种面向数据中心的打包Heroku。
我们还为Singularity开发出了其它一些独特的功能，旨在应对现实世界中的具体需要：
- 能够通过“退役”机制正常中止运行在Mesos从节点上的全部任务（即将以反向启发方式在Apache Mesos当中出现）。
- 能够在任意Mesos cgroup之外操作的人工下载服务。虽然有些反直觉，但这确实是在某些内核遭遇高磁盘I/O时非常有效的OOM中止手段。
- 这是第一项尝试对超出对应内存分配区任务进行顺畅关停的出色OOM关闭服务。
- 这也是一项通用型S3上传服务，能够处理长期日志记录以及与任务相关的其它数据存储操作。
- 一款自定义执行工具，能够面向任务提供强化报告与日志回旋。
重启与恢复
Mesos能够对设备加以抽象，从而轻松应对2014年发生的Amazon“大规模重启”事件。尽管很多其它企业（也包括HubSpot内部的一些未使用Mesos基础设施的团队）都希望抢在自动重启之前对受影响实例进行更换，我们的PaaS团队则选择了启动新Mesos从节点并让受影响设备进行“退役”的作法。Singularity能够自动将进程迁移至正常运行的设备之上，这就意味着我们的开发人员能够继续正常完全日常工作——而不会遭遇到任何故障。
他们无需面临任何停机时间，也根本不知道曾经出现过这次差点给其造成重大影响的灾难。
Singularity这种可以快速对服务规模进行伸缩调整的能力已经多次发挥了作用。有时候，其负责应对预期当中的流量峰值，例如当我们的某位客户出现在《创智赢家》节目当中时。也有些时候，其负责响应我们后端服务所遇到的巨大压力，例如当规模可观的批量邮件一次性排入队列的状况。
在拥抱Mesos之前，这些应对举措需要耗时数十分钟。但如今整个过程只需要几十秒，这意味着我们的平均恢复时间得到了大幅改善。
自诞生之时即选择开源
Singularity之所以成为HubSpot基础设施核心体系中的独特组成部分，是因为它从诞生之日起就坚持走开源路线。如今，包括Groupon、Opentable以及EverTrue等在内的企业都开始使用Singularity，而我们的团队则在使用这款框架的同时为其添加更多实际价值。我们会强化组件、构建功能并在其给其它企业造成大麻烦之前进行漏洞排查。
它已经成为Mesos生态系统当中极具价值的闪亮新星。它不仅能够改进我们的现有基础设施，而且能够在不知不觉当中帮助其它企业拥有更为轻松愉快的日常运营状态。
下一步，我们的目标是将HubSpot基础设施当中的其它新组件迁移到Mesos当中，从而进一步扩大当前已经享受到的种种助益。其中包括Memcache、Kafka、Spark、Hadoop以及MySQL。如果我们将过去的一年总结为“一切应用归于Mesos”，那么在新的一年中，我们的座右铭也许可以汇总成“剩下的一切也归于Mesos”。当然，在数人云上可以快速部署Spark，Kafka，Hadoop …… ，一起努力让一切归于Mesos，归于云操作系统。
