美國西部時間 5 月 2 日下午 7 點，Twitter 公司在舊金山總部舉行了一次技術發布會兼 Meetup。會上，Twitter 計算平臺（Twitter Computing Platform）產品與技術負責人 David McLaughlin 正式宣布，Twitter 的基礎設施將從 Mesos 全面轉向 Kubernetes。

　　Mesos 項目發布于 2009 年，而 Twitter 公司則是 Mesos 項目的早期支持者和使用者之一。作為世界上最成功的社交媒體巨頭之一，Twitter 公司以其龐大的生產集群規模（萬級別節點）而備受關注。2011 年，Twitter 公司開始在 Mesos 項目的基礎上開發 Aurora 項目以便同時管理其內部的在線和離線業務，逐步成為 Mesos 社區的代言人。

　　在持續投入 Mesos 項目近 10 年之后，Twitter 公司為什么突然宣布全面轉向 Kubernetes 體系？在這個令人矚目的決定背后，是什么樣的架構和設計支撐 Twitter 基礎設施 360 度的“華麗轉身”呢？

　　云時代，Twitter 基礎設施面臨新挑戰

　　Twitter 公司創始于 2006 年。時至今日，全世界每天都有至少 5 億條推文產生。在過去十余年飛速成長和海量數據的挑戰下，Twitter 基礎設施架構的演進過程，一直以來都是全世界技術公司眼中的標桿案例。這其中，像 Mesos 這樣優秀的老牌調度框架、 以及像 Aurora 這樣啟發自 Google Borg 配置管理的編排引擎，可謂功不可沒。

　　事實上，在互聯網級別的技術場景下，依托頂級工程師和成熟技術自建基礎設施，一直以來都是一線非云互聯網廠商的架構首選。正是在這個過程中，相對成熟并且工作層次較低的 Mesos 項目收獲到了大量規模級生產環境部署案例。

　　不過，隨著云計算的普及和 Kubernetes 這樣以“云”為核心的容器化基礎設施項目的迅速崛起，這種傳統互聯網基礎技術架構選型方法逐步暴露出很多前所未有的問題。在本次發布會上， David 就以 Twitter 公司當前面臨的挑戰為例，對這些問題作出了簡明扼要的總結：

　　1、存儲系統的多樣化與專業化，使傳統基礎設施復雜度急劇上升

　　相比于傳統技術架構對存儲系統的單一假設（比如一套 Ceph 打天下），云時代的軟件架構為用戶存儲選擇帶來了爆發性增長。僅以阿里云為例，它在公有云上能夠為用戶提供的各種類型的存儲服務就多達 10 余種，其中的細分方案更是數不勝數。隨著互聯網公司的基礎架構和軟件規模的不斷擴張和發展，互聯網軟件本身對存儲的需求也更加細化和專業。

　　比如，在 Twitter，Local Persistent Volume 這種“非典型”存儲訴求，逐漸在平衡性能與成本的過程中成為一種主流方案。作為 CSI（Container Storage Inerface）的提出者，Kubernetes 社區不僅擁有最完善的 Local PV 機制，還能夠憑借標準接口和 PV、PVC 體系，完全為用戶抹平其它數十種不同存儲服務的對接問題。這在互聯網軟件架構日趨復雜和面向多云的發展趨勢中，無疑是至關重要的。

　　2、Mesos 和 Aurora 體系與“云原生”始終漸行漸遠

　　云時代一個重要的技術發展趨勢就是軟件的生命周期會逐步向“生在云上、長在云上”的形態靠攏。這也就意味著作為支撐軟件的核心基礎設施項目，必然要向“發揮云的最大價值”的方向不斷演進。

　　遺憾的是，Mesos 以及 Aurora 項目或許是由于發布較早，始終沒能夠將“云”變成整個基礎設施體系中的“一等公民”。相比之下，Kubernetes 體系從發布伊始就不斷倡導“聲明式 API”、“容器設計模式”、“控制器模型”等各項理念，其實都是為了幫助用戶能夠在云上以“可擴展、可復制、高度自動化”的方式開發、交付和運維軟件。如今，這些頂層架構設計與各種最佳實踐，被廣大開發者們冠名為“云原生”。這也成為 Kubernetes 項目與其它競爭對手相比最大的不同。

　　3、傳統的多云、多集群管理成本居高不下，并在可預見的未來內迅速攀升

　　在傳統的互聯網架構中，自建數據中心和基礎設施體系是整個軟件系統的第一假設。而“云”所扮演的角色，更像是在流量突發時應付峰值的資源“備胎”。

　　在這種以“云”為輔助角色的指導思想下，多云和多集群很難成為整個架構的重中之重。這就使得多云和多集群能力，成為底層資源對接層的職責，而與更重要的應用開發、交付和運維體系失去直接關聯。這種方案短期內固然可以奏效，但長期的維護和迭代成本卻很容易因為上層應用本身千變萬化的形態與高速迭代而超出把控。

　　此外，這種設計的另一個極端是讓整體基礎設施走向“多活”技術深淵：這實際上已經遠遠超出 90% 以上互聯網公司的技術能力。在云原生體系普及之后，“每朵云上都有無數個 Kubernetes 集群”逐漸成為應用基礎設施能夠依賴的新常態。

　　這就為多云和多集群管理提供了一種全新的突破性思路：只要軟件選擇面向 Kubernetes 來進行架構、設計和實現，那么“多云、多集群”就自然而然成為應用基礎設施的默認能力。在 Twitter 的業務越來越多的需要多云、多集群環境交付的趨勢下， Kubernetes 這種從根本上幫助應用迅速向多云交付的“捷徑”，成為 Twitter 選擇變更自身技術體系的另一個重要原因。

　　作為不斷在快速發展和迭代的互聯網公司，高壓力和快節奏背景下的企業往往無暇顧及基礎設施架構的標準化與兼容性問題，這同樣也是 Twitter 公司面臨的主要問題之一。所以，在這次轉型過程中，“Kubernetes Native”成為一個被反復強調的關鍵詞。

　　大規模生產環境的" Kubernetes Native "技術路徑

　　作為不斷在快速發展和迭代的互聯網公司，高壓力和快節奏背景下的企業往往無暇顧及基礎設施架構的標準化與兼容性問題，這同樣也是 Twitter 公司面臨的主要問題之一。所以，在這次轉型過程當中，“Kubernetes Native”成為一個被反復強調的關鍵詞。在發布會上，Twitter 公司公布了選擇 Kubernetes Native 方向的諸多評估依據。

　　1. 良好的開源技術與開源生態；
　　2. 全世界所有的公有云都提供 Kubernetes 服務，不必擔心廠商鎖定；
　　3. 原生具備有狀態業務（Stateful Application）的管理語義；
　　4. 項目本身快速迭代，具有很強創新能力和先進性；
5. 具備標準的存儲對接接口，幫助 Twitter 無縫遷移各種現有存儲服務；

　　最終，Twitter 公司用一句話總結了這次評估的結果：“我們認為，使用 Kubernetes 項目作為 Twitter 公司基礎設施向前演進的核心依賴，將會是一個正確的選擇”。

　　而在這條演進路徑上，Twitter 也公布了多項具體的技術舉措，比如：
　　1. 開發 Twitter 專屬的有狀態應用管理控制器（TwitterSet）；
　　2. 開發滿足 Twitter 場景的節點控制器（NodeController）；
　　3. 自定義 Service Discovery 組件以便同 Twitter 自己的流量管理服務對接；
　　4. 編寫兼容 Aurora 語義的作業管理控制器以便將現有的 Aurora 上的業務進行遷移；
　　5. 開發更豐富的應用發布策略和實例穩定性支持；
　　6. 改造 Aurora 的 DSL 以對接 Kubernetes，集成現有的 CI/CD 系統。

　　David 表示：“Twitter 公司基礎設施的巨大規模一直不是一個秘密，但至少在今天，規模不再是我們的首要擔心，我們能看到像阿里巴巴這樣的社區領導者正在將更大規模的 K8s 集群推向生產環境”。

　　David McLaughlin 宣布整個遷移計劃將從現在開始一直持續到 2020 年。屆時，整個 Twitter 的技術棧都會運行在以 Kubernetes 為基礎的容器化基礎設施之上，并且呈現“內部 K8s 集群 + 公有云 K8s 服務”的多集群組合形態。

　　David 最后對 Twitter 的未來進行總結時強調：在 2020 年，Twitter 自己的軟件棧會以“一部分運行在自有 K8s 集群，另一部分運行在公共云上”的多集群形態進行開發和交付。

　　顯然，在思考“如何通過云來讓自身的基礎設施能力價值最大化，然后讓公司專注于更具價值的核心業務”這件事情上，Twitter 已經得到一個相對清晰而富有遠見的答案。更重要的是，這個選擇，很可能會使公司與得以擁抱 Kubernetes 的 Twitter 工程師們實現真正意義上的共贏。

　　世界級互聯網公司加持的規模化云原生技術

　　不難看到，Twitter 公司這次走向 Kubernetes Native 背后的技術本質，其實是在最大程度的利用 Kubernetes 項目本身的核心概念與可擴展能力取得規模化定制性需求與社區標準之間的平衡。

　　這同樣也是阿里巴巴正在社區倡導的一條關鍵途徑。從 2018 年開始，阿里巴巴聯合 Google， Facebook，Twitter，LinkedIn，Uber，Netflix，Pinterest 等一大批頂級互聯網公司，在美國硅谷開展起了月度 Web-Scale Meetup，以分享自身實際落地實踐的方式，為更多互聯網場景中的社區“觀望者”樹立信心。

　　本次發布會上，Twitter 公司也邀請了來自阿里云容器平臺團隊的工程師李響、張磊、何劍等作為專題演講嘉賓。同時應邀出席發布會的嘉賓還有 Google 公司 Kubernetes 團隊工程技術經理 Jago Macleod 。

　　阿里云容器平臺團隊即將開源Kubernetes 高級作業管理集合

　　發布會上，阿里云容器平臺團隊透露下個月即將開源內部錘煉已久的 Kubernetes 高級作業管理集合（Kubernetes Workloads Advanced) 。Kubernetes 高級作業管理集合會充分利用 Kubernetes 的“聲明式 API” 和“控制器模型”，為用戶提供互聯網場景下“賴以生存”的容器化應用“原地升級”能力，以及更加精細化的業務發布策略。Twitter、Pinterest 以及 Netflix 等世界級團隊，都會加入到這個創新性的“云原生作業管理”項目的合作當中。

　　除此之外，Kubernetes 本身在規模化與性能提升上的不斷演進，也是能夠讓 Twitter 公司最終從“觀望者”變成“實踐者”的另一個技術因素。對此，Google Kubernetes 項目工程技術經理 Jago Macleod 在演講中專門介紹了 Google 公司與阿里巴巴在這個領域上正在進行的攻關與合作。

　　在最近一次嘗試中，雙方工程師正在一起為 K8s 里海量的 WATCH 操作添加“書簽（Bookmark）”，這將使得這些 WATCH 操作的建立者在重啟之后只需要對“書簽”之外的少數歷史變化進行追溯。在特定情況下，K8s APIServer 的性能會被提高 40 倍以上。

　　Kubernetes，以應用為中心的“高速公路”

　　除了技術和架構演進上的考量之外，這次 Twitter 公司向 Kubernetes 的“華麗轉身”，還有一個至關重要的非技術因素。

　　Twitter 公司的快速成長，催生出了其標桿式的基礎軟件團隊，但也反映出一個不得不引起重視的問題：隨著互聯網業務的快速發展，公司的基礎軟件團隊很快就開始超過應有的規模邊界，而相應的投入產出比卻停滯不前。

　　所以，正如 David 在一開始提到的那樣，過去互聯網企業中“自研（In-house）”為主的基礎軟件開發和架構思路，正在伴隨著云計算和云原生理念的普及發生微妙變化。憑借像 Kubernetes 這樣的平臺級項目標準，互聯網公司已經能夠以較小的代價將自身的基礎設施向云遷移。

　　更重要的是，由于 Kubernetes 這個標準層的存在，這種“遷移”本身并不會像 Netflix 與 AWS 那樣形成根深蒂固的廠商鎖定關系，反而會在保留大部分“自研”好處的同時徹底發揮出“云”本身的價值和多集群管理能力。這種變革帶來的優勢，會在一個互聯網公司里的 “AWS 工程師”都變成“K8s 工程師”之后變得尤為凸顯。

　　不難看到，Kubernetes 項目正在以應用為中心，連通“云”、“應用開發者”與“基礎軟件團隊”。這種“高速公路”般的溝通、連接與交付能力，也正是像 Twitter 這樣快速迭代的互聯網公司思考自己基礎設施架構未來演進方向的重要參考。而這種轉變，也使得 Twitter 這樣一個業務迅速增長的商業組織始終維持一個數十人的基礎軟件團隊成為現實。

　　寫在最后

　　從最早 Mesos “代言人”到如今的全面轉向 “Kubernetes Native”，Twitter 的舉動再一次佐證了“Kubernetes 已經成為容器編排事實標準”這一斷言。更為重要的是，Twitter 這次全面擁抱云原生，也有望能夠為業界大規模生產級云原生技術落地提供經典學習范本。

　　阿里巴巴從去年開始在云原生生態中投入了大量技術力量，正在逐步成為 Facebook、Twitter、LinkedIn、Uber、Netflix、Pinterest 等眾多世界級互聯網公司眼中規模化云原生技術落地的一位重要引領者。

　　伴隨著云計算的進一步普及，傳統互聯網基礎技術架構暴露出很多前所未有的問題，以及像 Kubernetes 這樣以“云”為核心的容器化基礎設施項目的迅速崛起，都在促使越來越多的世界級企業開始思考如何借助“云”以及云原生技術來擁抱開源生態和開放的技術標準，準備迎接一個具備強勁的迭代能力的、面向“云”的數字未來。

總結

以上是生活随笔為你收集整理的Twitter 宣布抛弃 Mesos，全面转向 Kubernetes的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。