老肖實錄分享 | 基於 Mesos 打造高可用微服務系統實踐

本文是數人云CTO肖德時在2016全球運維大會·上海站上的演講實錄。乾貨連連！走過容器大會探討完熱門的一容器一IP，接着來運維大會隨小數一塊兒來看一下如何基於Mesos打造高可用微服務架構吧：）

很高興在這裏和你們分享一下如何用開源軟件打造一個高可用以及微服務的架構。Mesos是Apache的一個開源項目，其宗旨是像一臺電腦同樣管理整個集羣，它源於Google的Borg系統，有一套cluster管理平臺對無數臺機器進行管理。Twitter、Airbnb的服務器及蘋果電腦的Siri大數據應用都是跑在Apache Mesos上面，基於Apache Mesos系統咱們也作了一個輕量級PaaS平臺。

高可用

什麼是高可用？將概念縮小到維基百科的簡單定義，能夠看到它有以下幾個特徵。第一，消滅單點問題，系統要把單點支持住；第二能冗餘，HA的架構；第三，快速檢測，失敗可以自動切換。

一開始作這套系統時，咱們想到Load Balance，把系統作一個負載，這樣有了HA的架構，可是裏面Load Balance自己又是一個單點。你們可能會想把Load Balance作成cluster，用DNS的方式去作，可是DNS自己要來回切，切兩個IP之間的輪換，這個自己依然有單點的問題。以一個單數據中心的角度來講，最好有一個能挑的IP， IP最好是固定的。而後在裏面去作Load Balance的Proxy，底下是App Server，再去切換，這樣就是一個高可用的架構不斷的演進過程。

這個過程裏面會涉及到幾個問題，咱們來看一下Mesos系統是怎麼解決這些問題的。首先，在任何高可用的架構裏面，鎖是必須的，可是高可用在當前的發展過程當中，scaling的過程必定要作分佈式系統，因此對於鎖的要求就比較多。第二，要有本身的控制節點，即Mesos的節點，它主要是控制這些資源的提供，這是它的一種基本的架構，實際計算節點在下面，這些Slave節點的特色是即便進程死掉了，也保證任務必定能運行起來。

這也是應用跟集羣之間鬆耦合的過程，Mesos是很是成熟的架構，能夠幫助企業實現高可用的架構。

微服務

微服務咱們也從頭提及。微服務最初是一個Web，一個DB，按照第一個方式走，頂不住的時候開始加Cache。這樣的架構頗有可能變成一個單體，可是內部仍是不能去鬆耦合，雖然加了Cache仍是有依賴，發展到最後，咱們知道構建一個高可用或者智能的架構實際上是一個想象中的過程。實際上須要的模塊應該是一個總體，模塊裏面的東西應該可以水平擴展，作一些精細化的運營，這纔是微服務的一些比較核心的理念。

第三個案例裏，首先要分層，每一層都是能夠支撐的，其運營的難度不會很高，底層DB關了，可是由於有容災的DB，上一層不會受到影響。Mesos高可用的架構是一種具體的實現方法。第二，微服務咱們能夠混合部署，不須要關心部署在什麼地方，只要把有狀態的應用變成無狀態，撒在集羣裏面，讓充分的計算資源來支撐業務，有狀態的業務仍然須要專心管理，可是有狀態和無狀態之間能夠精心地設計。基於Mesos作這種微服務的架構，用混合部署的方式支撐業務，消滅單點，支持容災，還能在出現task出錯以後自動切換。這是分佈式架構應有的一些特性，也是咱們對微服務的一些理解。

系統實踐

數人云是一家創業公司，咱們利用了一些當前比較時髦的一些技術，好比說容器。 Mesos自己是一個集羣系統，但其部署仍較複雜。你們都但願運維可以標準化，通常想到的是Ansible和SaltStack。

Docker標準化鏡像很是方便，因而咱們用Docker的方式把這些組件都標準化，打成image，經過一個DSL的文件撒下去，也一樣實現了這樣的集羣。複製之後，下次再也不須要配置，按照這個方式快速地執行。Ansible和Salt也是同樣的過程，那麼選擇這套方案的緣由是，咱們認爲image的管理比對腳本的管理更方便一點，有倉庫和版本的概念。咱們也利用了Docker的一個先進的理念——應用中心導向的build、ship、run，能把全部的配置信息都用一個DSL寫成一個Json文件下發下去，經過控制器在所有的機器上自動部署。基於Linux自己的四層的路由IPVS進行分化。咱們不用Docker全部的特性，只須要其deliver的特性。

剛纔咱們混合部署了一套微服務的架構，但真正把它部署下去，監控起來也是很是麻煩的。由於每個小的App都有本身的性能的瓶頸，也有本身的指標，如何把它們彙總起來是一個問題，好比說你的十個App，每個都有本身的指標，撒在不一樣的機器上，若是按照正常的模式，原來監控的每個都要監控，而後作匯聚，這與以前Mesos用一臺電腦管理資源是相違背的。

其實咱們並不關心每個節點上App運行的性能，咱們須要的是彙總的性能。一個比較好的方式是經過API網關，內部的交互徹底經過這種Restful的API網關來去控制。沒有達到性能指標，就把它殺掉換在別的機房運行，對外提供統一的定義的這個指標，用網關控制這個指標，咱們用的是eBay的proxy。最簡單的方式能夠用HA proxy去作，可是fabio用go語言來寫，更符合咱們數人云的語言技術棧，因而選擇它作二次開發，控制整個API請求的指標還有響應速度。Mesos自己有本身的容災和調度策略，咱們作了一個自動試錯三次的上限，除了報警之外，不容許它再擴了。

這種方式總體上把微服務全部模塊的組建、全部組件服務的質量都獲得了一個可量化的指標。所以能支持多少個請求都是能夠快速知道，也是可控的，不需再作實時的評測。正常運營過程當中，會在事前作一些壓測，但這個壓測是理論值，生產環境中業務的質量是須要有一個控制，一個總閘。這也是原來微服架構裏面，你們比較容易忽視的地方。

Mesos是一種通用型的架構，由於出來的比較早，當時使用的一致性的鎖是Zookeeper。對於分佈式架構，還有其餘比較優秀的組件，好比Consul，etcd，這些算法自己是一個精簡的算法，並且有很是良好的支撐分佈式的鎖的概念，Apache Mesos也支持這方面功能，咱們以爲徹底不須要去選擇Zookeeper，並非說它很差，而是一個精簡的過程。

在使用Mesos的過程當中，Mesos自己是提供一個資源池，想使用它的時候須要一個入口。咱們基本上按照Mesos推薦的Framework，這裏推薦的是Marathon，用的自己是Scala語言寫的一套系統， Mesos自己的組件已經由原來簡單的protobuf rpc的交互轉變成Restful API，開發一個調度APP或者Framework已經再也不須要mesos依賴庫，如今徹底能夠經過HTTP API的去操做它，所以咱們徹底能夠本身去作開發。Mesos的不少特性，例如針對統一的容器管理，不只僅是針對Docker，Cgroup也支持，GPU也能夠管理，將來會支持虛擬機。然而它不少特性咱們想用可是用不了，沒有這種支持，所以咱們考慮在這方面作開源的項目，把Mesos的特性真正發揮出來。

衆所周知，Twitter、Airbnb以及Apple在使用Mesos的時候，都是使用自研的Framework調度Mesos的資源。分佈式系統裏面最重要的是網絡，它支持了當前最流行的CNI容器化網絡接口。由於這種網絡是池內部的網絡，跟外界的網絡是能夠隔離的，所以這個網絡能夠動態擴縮，也是當前比較時髦的語言， SDN比較推崇的一種技術。它是一個Json定義接口，對接網絡的結構，好比DHCP，咱們能夠分網關給它，來作接入。

在用這套系統的時候，會看到底部是Mesos的池，上面的機器有API網關，這個網關是一個總控，把應用經過這個網關切入，利用這些資源去作資源的統一控制，結構是鬆耦合的過程。上面全部的狀態經過一個Consul分佈式的鎖，進入你的狀態，相似於無狀態的一個平臺，能夠部署多套，下面經過鎖的方式控制schedule，所以它也是一個分佈式的平臺，這就是咱們具體的一個參考實現。

總結

總結一下。第一，咱們認爲Mesos作高可用的分佈式的架構是靠譜的。第二，微服務的架構只是一個理念，它有各類各樣的方式，這種混布的架構方式並非神話，內部並非如你們想象那樣拆成碎片，往裏面一放就能夠了，它是一個系統工程。你能夠在業務層面上去控制API網關，治理下面微服務的使用質量，能夠可控擴縮微服務的架構。

第三，關於DevOps，運營這套系統不能期待它百分百可控，仍是要靠自研，把它作得更好，開源軟件才能發揮其真正的做用，這樣整套系統纔是完整的，能夠容災，沒有單點，符合當前的微服務架構的服務設施理念。咱們數人云最近也開源了一個容器管理的開源項目 Crane，以後會開源更多的基於的Mesos的項目，歡迎你們關注，謝謝你們！

最後隆重推薦一下孫宇聰老師翻譯的《 SRE ： Google 運維解密》，小數已經私藏了好多本啦，這個祕密小數只悄悄告訴你，從此它會在咱們活動中做爲獎品出現哦！