【編者的話】 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，歸于云操作系統。