內容來源：2017年6月25日，美團雲基礎設施負責人胡湘濤在“美團雲技術沙龍——千萬日訂單背後的電商運維實戰·上海站”進行《承載新美大的雲端計算基礎服務運維》演講分享。IT大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。
閱讀字數：3969 | 7分鐘閱讀
摘要
作為美團雲基礎設施的負責人，胡湘濤老師之前一直在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進行一次巡檢。做一個動力環境的巡檢，檢查基礎設施的利用率是否有超標、是否有風險來完善整個風險的評估體系。
今天的分享到此結束，謝謝大家！