美團雲運維：如何承載千萬級雲計算基礎服務

內容來源：2017年6月25日，美團雲基礎設施負責人胡湘濤在「美團雲技術沙龍——千萬日訂單背後的電商運維實戰·上海站」進行《承載新美大的雲計算基礎服務運維》演講分享。IT大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：3969 | 7分鐘閱讀

嘉賓演講視頻及PPT： t.cn/RpQPThL

摘要

做爲美團雲基礎設施的負責人，胡湘濤老師以前一直在CDN從事基礎設施的運維和運維自動化的開發工做。提到基礎設施，你們可能更多的認爲是服務器、IDC，還有網絡。其實爲了承載整個新美大的電商平臺，他們在基礎設施方面，穩定性、可靠性方面也作了很是多的工做。今天就由胡湘濤老師給你們分享一下承載新美大的雲計算基礎設施。

基礎平臺服務

基礎設施這一塊除了咱們的設施之外，還有一個基礎的服務平臺，這樣才能很是高效地將咱們的業務傳遞給客戶。如今新美大全部的業務都承載在美團雲上，有外賣、貓眼、美團、大衆點評等等。

上圖是基礎平臺的結構。第一層是物理層，主要包括服務器、網絡設備和動力環境。動力環境對於你們來講可能會相對比較陌生，它在整個平臺的穩定性方面發揮了比較重要的做用。上一層是IP的控制層，有網絡配置、路由表、路由協議。

要把服務穩定地交付給客戶，主要是在TCP/UDP的負載均衡層和DNS層上作了不少的穩定性工做。

基礎設施

在機房的選型上，基本都是選用T3及以上的標準IDC。要有獨立的低壓配電系統，好比低壓的配電機、UPS的機組、UPS電池、以及柴油發電機。這些都須要針對咱們本身模塊給到獨立的系統，咱們才能對機房的穩定性進行把控。同時在空調製冷方面通常會選用2N或者N+1的系統，這樣在任何一個機組出現問題的狀況下都不會對機房產生任何影響。咱們須要有獨立的物理空間，按照咱們的需求進行定製。

有了高標準的基礎設施後依然未必能保證穩定，在此過程當中運維也是一個很是重要的步驟。

在運維方面咱們有完善的SOP，也就是標準性操做。全部非標準性操做可能都會給機房帶來災難。好比作電力維護時在機房上架標籤的時候，標籤是否一致，均可能對將來的業務形成影響。同時對IDC的風險評估也作了大量的工做。咱們用了機房動力監控，好比UPS的負載、電力的負載以及機房的溫度、溼度。而且還作了24小時人工動環的巡檢。由於咱們有獨立的物理空間，因此須要按期作模擬故障演練。

高可用基礎服務

MGW Session同步

MGW是咱們自研的一套系統，便於與雲平臺進行整合。同時也提供API，很方便地與業務系統進行打通，做爲內部流程的定製化。這樣咱們在業務交付過程當中能高效地完成工做。

咱們目前單臺服務器在鏈接Session方面單節點能達到1200萬。Session的同步是作單臺廣播，一旦出現宕機，Session可以在路由層面進行無縫切換，給用戶提供無中斷的服務。

通過咱們本身測試，百萬級Session切換的miss率爲0。Session採用增量的同步策略，主要經過二層進行同步。一旦有新的Session咱們能快速地同步到同集羣的其它設備上去，這樣在單臺機器出現故障的時候可以很從容地進行切換。

咱們分別作了單臺和多臺機器的故障演練。咱們用了十個不一樣的機器經過MGW請求後端的服務來進行文件下載。咱們在23:37左右的時候，將第一臺MGW關閉。從監控上37分這個時間點來看，業務突發的狀況過了以後，它的流量基本爲零，總體的十個進程在23:37以後沒有波動。同時可能還會面臨多臺機器同時發生故障的問題，那麼這時還可否保證業務交付的持續性呢？

咱們在23:43先關掉了第一臺MGW，它會把流量切換到第二臺藍色的MGW上面。咱們在這個時間點把藍色這臺依然進行模擬的故障將其關閉。你們可以看到第四臺的鏈接數和流量進行了上揚。在23:55的時候第三臺進行關閉，全部的流量都無縫遷移到最後一臺。在切換的時間點上面，十個壓測進程在總體的流量上很是平緩。

在修復了機器以後，咱們會對機器進行從新上線。由於機器在上線前沒有任何鏈接，那麼上線的時候是否會對業務形成干擾呢？

這是咱們故障恢復和擴容的場景。像前面剛剛提到的這些時間段，咱們分別演練了三臺機器所有進行了一次故障。這個時間段先恢復了第一臺MGW，從業務來看基本是沒有任何波動的。在1:03左右的時間點，咱們分別把剩餘的兩臺也進行了恢復和擴容，從併發下載上來看，1:02到1:03是一個相對平緩的過程。特別須要說明的是上圖中有紅框框起來的部分，由於咱們在壓測的時候，它是在作一個4G文件的下載，因此當時的速度都是零。

在我剛剛入行的時候，領導跟我說過一句話，讓我印象特別深入：讓一個網站在地球上消失最好的辦法就是幹掉它的DNS。若是一個機房宕掉了能夠經過機房容災來解決；若是一個區域宕掉了，能夠作跨區域的容災。但DNS出現了故障，那就毫無辦法可言。因此可見DNS是咱們很是重要的基礎服務。一般咱們會在一個IDC裏面至少部署兩臺DNS，服務器就會在文件裏面配上這兩個DNS的IP地址。在遷移到另一個IDC的時候，因爲機房IP地址的惟一性，就要改DNS的地址。

咱們採用了基於AnyCast的DNS架構。你們對這個架構其實並不陌生。咱們使用最多的DNS服務大概是8.8.8.8。要在不一樣地方都使用同一個DNS IP，經過在DNS上和內網核心跑一個路由協議，在這上面每臺機器有本身管理的DNS IP。業務請求過來的時候它是一個等價路由的形式，它會均分地請求到不一樣的機器上。也就方便了咱們作DNS擴容，並且在作跨機房遷移的時候依然能夠用同一個DNS IP。這個主要是在DNS層面作了一層路由的包裝，方便了咱們整個基礎設施架構的部署，簡化了整個運維流程。

基礎網絡質量監控

我一直強調運維的意識決定整個平臺的穩定性。在運維過程當中如何迅速發現異常、判斷問題點，就須要快速直觀的監控體系。

由於咱們的體量相對比較大，三萬+的服務器，幾千個機櫃，每一個機櫃都有TOR。這種狀況下如何作到對全部總體的網絡一目瞭然，快速響應解決發生的問題呢？

這是我剛剛提到的內網超核，全部跨IDC的層面都須要藉助超核進行轉發，這上面分別在三個不一樣的IDC，每一個IDC有兩組內網核心。

咱們會在每一組TOR下面的物理機上佈一個Agent，經過Agent監控全網的IP列表。咱們建了一個sysop基礎設施自動化運維平臺，裏面記錄了基礎設施全部資源信息，經過這個平臺能夠獲取到IDC、交換機、服務器全部信息。

最右邊是消息告警的平臺，根據咱們的策略配置一些消息告警。好比兩臺機器之間有丟包、延時增大等狀況，匹配到咱們的告警策略以後通知相關人員。

咱們收集到的數據是經過InfluxDB進行監控數據的存儲，利用Grafana進行展現。

最核心的是咱們監控的管理平臺Manager。首先咱們每臺服務器部署的時候會把這個Agent推下去，給Manager發請求，獲取到須要監控的IP列表、監控IP的對象、監控IP的數量以及上報的時間。Agent監控生成的數據會上報到Manager模塊，經過模塊處理後存入InfluxDB。

衆所周知，在整個網絡架構當中監控南北向的流向是很是容易實現的，由於每一個服務器到TOR，TOR到核心，再到外網，這是如今最基本的網絡監控。

可是咱們須要看到的是東西向流量。兩個業務之間的請求，一旦出現異常你們可能第一反應是網絡的問題。如何避免這樣的問題，同時爲咱們業務快速定位或縮小問題點，就是這個平臺的價值。

經過這個平臺給到業務和咱們本身，讓咱們能快速地判斷網絡是否有問題，或者當服務端出現報錯的時候，究竟是要第一時間排查網絡仍是DNS，或者是業務服務自己的問題，這樣縮小了問題點，讓業務快速的定位。由於在電商行業一旦出現問題，影響的時間越長，損失的都是交易金額，因此咱們投入了不少的精力來作這一塊的工做。咱們不怕出現問題，一旦出現問題咱們能在最快的時間去解決問題。

這是咱們內網監控的第二期架構。第一期完成了東西向流量端到端網絡監控，可是還不能直觀地監控網絡運行情況。按照上圖中網絡架構，在WJ和DBA的兩個超核，每一個IDC的內網核心有不少線互聯的。兩臺機器互Ping的時候，出現丟包率。

好比說服務器到TOR，TOR到內網核心可能4條線，到超核是16條、32條線，超核到內網核心又是32條線，排查鏈路的時候是一個指數級的增加。可否將每一條鏈路的情況在咱們內網的網絡拓撲圖上面進行展現，這樣咱們可以第一時間在業務以前發生這個問題。

第二期所作的，就是是可以監測到這32條路徑的網絡質量。咱們經過了解廠商的Hash策略和構造數據，讓它人爲地走不一樣鏈路，拿到從TOR到核心這一段每一秒的ping值和波動來了解到每一段的網絡是否有問題。這樣能直觀地瞭解到整個網絡狀況。

咱們經過一個地圖來展現外網網絡質量監控，基於電信、聯通、移動三條線路出口分別進行監控。咱們主動以1秒鐘爲頻率監控到全國每個地級市的網絡狀況。經過這種主動的監控系統探測可以很清晰地知道哪個區域有問題。

平臺發展壯大是源自於用戶的選擇，咱們須要給用戶作到更高質量的服務、更好的用戶體驗。同時這些系統其實在公有云和私有云上覆用，咱們本身用到什麼基礎設施、網絡條件，給美團雲客戶也使用一樣的服務。

多維資源數據運營

咱們會經過監控系統，結合各項數據彙總的指標，針對性的持續優化，最終達到讓運維人員更加高效、讓基礎設施更加的穩定。

在服務器自動化操做方面，咱們申請機器的時候走自動化流程，發起、檢測有沒有系統， CMDB的情況是否正常。若是正常的話，更改成預申請同時部署操做系統，部署以後對主機進行Ping檢測。認爲沒有問題的，最終交付給業務。這些後端都會收集數據，拿到最近30天，流程的總量、成功率、失敗率、正在運行的數量以及平均每一個流程的耗時來針對性的優化。

同時咱們在成本方面也作了必定的考量。好比全部機櫃的房間有多少服務器、有多少交換機，這裏面有效機櫃是多少，針對於每一個機櫃的電力收集的覆蓋率是多少。咱們針對這個機櫃所承載的業務和服務器的功耗進行智能匹配，來提升機櫃的有效率。機櫃的有效率上升了，在IDC平均業務量的租用成本就會下降，這也是數據化運營的方向。一個是提升咱們的穩定性，一個須要下降總體的成本。

如今除了有數據之外，咱們更多強調監控的可視化。

咱們在機房都有相似於探頭來監控環境，好比一些變動。包括除了機房的動力環境之外，咱們本身來監控機房的溫度、溼度是否達標。假如機房一個機器或者空調出現了問題，它並不必定會告訴你。當機房不可控的時候咱們再發現，可能整個機房就死掉了，因此這裏會有一個提早的預警，包括跟機房創建一個長效的溝通機制。咱們在IDC層面，每個Q進行一次巡檢。作一個動力環境的巡檢，檢查基礎設施的利用率是否有超標、是否有風險來完善整個風險的評估體系。

今天的分享到此結束，謝謝你們！