Uber如何使用Mesos的？答曰：和Cassandra一塊兒用

過完程序員節吃完蛋糕，讓咱們動力十足地開始新一輪的學習吧！
今天小數爲你們帶來的是一篇Uber海外工程師的演講視頻解讀，讓咱們一邊聽着純正的英語（大霧）一邊看着PPT一邊來了解Uber的容器技術世界吧：）

若是你是Uber公司，你須要存儲司機和乘客APP每30秒發出的位置信息，有大量的實時數據須要實時使用，你該如何作呢？

Uber的解決方案是綜合性的。他們創建了一套系統，將Cassandra跑在 Mesos上面。在一個演講中Uber的軟件工程師很是好的解釋了這個系統（https://www.youtube.com/watch... ，小數表示是很是純正的印度英語）。

現在的開發們老是有太多艱難的決定要作。咱們應該所有都投入到雲嗎？哪個雲？貴不貴？會不會廠商鎖定？咱們是否應該兩條路一塊兒來嘗試而後作個混合架構？由於擔憂平臺毛利達不到50%，咱們是否應該所有自研？

Uber決定打造他們本身的系統，或者說他們打算把當下兩個十分能幹的開源組件結合在一塊兒。讓Cassandra和Mesos一塊兒工做，就是Uber選擇的方式。

Uber作出這個決定並不困難。他們資金充足，有着頂級的人才和資源去開發、維持以及升級這個複雜的系統。

自從Uber的目標肯定爲讓每一個人、每一個地方的運輸實現99.99%的可用，在擴大規模的同時想要控制開銷就變得很是有意義。

用金錢來換時間一般是一筆好交易。用金錢來買技能也經常是頗有必要的。考慮到Uber可靠性的目標，10000個請求只有一個容許失敗，他們須要運做多個數據中心。Cassandra被證實能夠處理數據中心大量的負載和工做，因而數據中心就幫Uber作了這個決定。

若是你想讓運輸系統可靠到達每一個人每一個地方，那麼就須要高效地利用你的資源。這是使用數據中心操做系統例如Mesos背後的想法。經過統計相同機器上的複用服務，就能夠減掉30%的機器，節省了一筆不小的費用。Mesos之因此被選中，是由於在那時它是惟一輩子產環境裏被證明能夠管理數萬集羣的工具，這正是Uber須要的，Uber要作的系統規模確實很大。

還有哪些更有趣的發現呢？

• 你能夠在容器裏運行有狀態的服務。Uber發現幾乎沒有任何差異，對比在裸機上跑Cassandra和在一個由Mesos管理的容器裏跑Cassandra，大概僅有5-10%的差異。

• 性能很優秀：讀延遲均值：13ms；寫延遲：25ms；P99s看起來也不錯。

• 他們能支持的最大集羣每秒有超過一百萬次的寫和十萬左右的讀。

• 敏捷比性能更重要。在這種架構下Uber獲得的是敏捷：很輕鬆地就能夠在集羣上建立和運行工做負載。

最初

• 靜態分區機器橫跨不一樣的服務

• 50臺機器用於API，50臺用於存儲，而且它們絕不重疊。

如今

• 一切都運行在Mesos上面，包括有狀態的服務如Cassandra和Kafka。

• Mesos是數據中心操做系統，可以讓你的數據中心變成一個單個的資源池。

• 在當時Mesos是惟一能夠管理數萬臺機器的工具，如今或許也有了其餘的選擇。

• Uber 在MySQL上創建了他們本身的Sharded數據庫，命名爲Schenmaless。Cassandra和Schenmaless將會成爲Uber的兩個數據存儲選擇。而現有的Riak設備將會移到Cassandra上。

• 一個單獨的機器能夠跑不一樣類型的服務。

• 在同一機器的靜態複用服務能夠帶來減小30%機器使用。這是一個來自Google Borg系統的實驗發現。

• 舉例，一個使用了不少CPU的服務和一個使用了不少存儲或者內存的服務能夠很好地匹配，這兩個服務能夠很效率地跑在同一服務器上，機器利用率獲得了提高。

• Uber如今有20個Cassandra機器，計劃未來增長到100個。

• 敏捷性比性能更重要。你須要有能力管理這些集羣而且在它們上面以一種平滑的方式進行不一樣的操做。

• 爲何在一個容器裏運行Cassandra而不是在整個機器上？

• 你想要存儲數據數千個千兆字節，可是你但願它能在多個機器上覆制甚至跨數據中心。

• 你一樣但願在不一樣的集羣實現資源隔離、性能隔離。

• 很難在一個共享集羣作到上述這些。舉例，若是你建立了一個1000節點的Cassandra集羣，它要麼不能大規模，要麼就會在不一樣集羣之間有性能干擾。

生產環境

• 在兩個數據中心間（東海岸和西海岸）有大約20個的集羣複製。

• 最初有四個集羣，包括中國。可是和滴滴合併後，這些集羣就關閉了。

• 在兩個數據中心有大約300臺機器。

• 最大的兩個集羣：每秒超過一百萬次讀和十萬次寫。

• 其中的一個集羣用來存儲每30秒來自司機和乘客app的位置信息。

• 平均讀延遲：13ms；平均寫延遲：25ms

• 大多數使用LOCAL_QUORUM的一致性級別（即強一致性）。

Mesos

• Mesos從機器中抽象了CPU、內存和存儲。

• 你看到的再也不是單獨的機器，編程的對象是一整個資源池。

• 線性擴展。能夠跑成千上萬臺機器。

• 高可用。Zookeeper被用來在可配置數量的複製中進行leader選舉。

• 容器上可使用Docker containers或Mesos containers。

• 可插拔的資源隔離。好比Linux可用Cgroups memory和CPU isolator。有一個Posix isolator。對於不一樣系統有着不一樣的隔離機制。

• 二級調度。來自Mesos agent的資源被提供給不一樣的framework。Framework在這之上調度他們的任務。

Apache Cassandra

• Cassandra很是適合Uber的用例。

• 水平擴展。讀和寫規模隨着節點增長線性擴展

• 高度可用。容錯率有着可調的一致性水平。

• 低延遲。在同一數據中心維持毫秒級的延遲。

• 操做簡單。它是一種同構集羣。沒有master。集羣中沒有特殊節點。

• 豐富多樣的數據模型。它有column、compositekey、 counter、 secondary index等多種模型。

• 和其餘開源軟件有很好的集成。Cassandra和Hadoop、Spark、Hive都有鏈接。

Dcos-Cassandra-Service

• Uber和Mesosphere合做搭建了mesosphere/dcos-cassandra-service——一個自動化的服務能夠輕鬆部署和管理。

• 在最上面的是WebInterface或者ControlPlane API。你只要說明須要多少節點，須要多少CPU，指定Cassandra配置，而後提交到Control Plane API。

• 在Uber使用部署系統，始於用來跑無狀態服務的Aurora的上面，能夠自啓dcos-cassandra-service framework。

• 在示例中dcos-cassandra-serviceframework有兩個集羣和Mesos master對話。Uber在他們的系統中使用了5個Mesos master。Zookeeper用來leader選舉。

• Zookeeper也用來存儲框架元數據：哪個任務在跑，Cassandra配置，集羣健康等。

• 在集羣中Mesos agent跑在每一臺機器上。Agent爲Mesos master提供資源，master將它們離散地分發出去。分發能夠被framework接受也能夠被拒絕。多Cassandra節點也能夠跑在同一機器上。

• 使用的Mesos Container，而不是Docker。

• 在配置中override 5個端口（storage_port,ssl_storage_port, native_transport_port, rpcs_port, jmx_port），因此多個容器能夠跑在同一機器上。

• 使用了persistent volume，因此數據被存放在沙箱目錄以外。若是Cassandra掛掉，數據仍然在persistent volume，掛掉重啓以後還能夠提供給同一任務。

• 動態預留被用來確保掛掉的任務重啓後資源可用。

• Cassandra服務操做

• Cassandra有一個seed node的理念，當新節點加入集羣時自啓gossip process。建立一個定製的seed provider用來啓動Cassandra節點，讓Cassandra節點在Mesos集羣能夠自動地roll out。

• Cassandra集羣的節點數量可使用一個REST請求來增長。它會啓動附加節點，給它seed nodes，以及自啓附加的Cassandra daemons。

• 全部Cassandra的配置參數均可以改變。

• 使用API，一個掛掉的節點能夠被替換掉。

• 在複製之間同步數據是須要修復的。修復的大體範圍是在一個一個節點的基礎上進行。它並不會影響性能。

• 並不須要清理移走數據。若是節點被加進來，數據會移到新的節點，這時清理被用來刪除被移過來的數據。

• 多數據中心複製經過framework來配置。

• 多數據中心支持

• 在每一個數據中心設置Mesos獨立安裝。

• 在每一個數據中心設置Framework的單個實例。

• Framework互相對話，而且按期交換seed。

• 這些都是Cassandra須要的。經過自啓其餘數據中心的seed，節點能夠gossip拓撲結構，指出這些節點是什麼。

• 數據中心之間ping延遲是77.8ms。

• P50的異步複製延遲：44.69ms；P95: 46.38ms； P99: 47.44 ms。

• 調度執行

• 調度執行被抽象成計劃（plan）、階段（phase）和區塊（block）。一個調度計劃有不一樣的階段，一個階段又有多個區塊。

• 第一階段，一個調度在進行中出現reconciliation時，它會前往Mesos而後指出哪些在運行。

• 有一個部署階段會檢查若是配置中節點的數量已經存在於集羣中，有必要的話就會部署它們。

• 一個block就至關於一個Cassandra節點規格。

• 還有其餘的階段：備份，恢復，清除和修復，根據REST端點觸及的是哪個。

• 集羣能夠每分鐘一個新節點的速度來啓動。

• 每一個節點啓動時間但願能降到30秒。

• 在Cassandra不可以多節點同時啓動。

• 一般給每一個Mesos節點2TB的硬盤空間和128GB的內存。給每一個容器分配100GB，32GB給每一個Cassandra進程（數據並不徹底準確）。

• G1garbage collector被用來替代CMS，沒有任何調優的狀況下它有更好的延遲和性能表現。

文章來源：High Scalability 版權歸原做者全部
http://highscalability.com/bl...