SRE（Site Reliability Engineering）是Google于2003年提出的概念，將軟件研發(fā)引入運維工作。現(xiàn)在漸漸已經(jīng)成為各大互聯(lián)網(wǎng)公司技術(shù)團隊的標配。
美團點評作為綜合性多業(yè)務(wù)的互聯(lián)網(wǎng)+生活服務(wù)平臺，覆蓋“吃住行游購娛”各個領(lǐng)域，SRE就會面臨一些特殊的挑戰(zhàn)。
業(yè)務(wù)量的飛速增長，機器數(shù)量劇增，導(dǎo)致人工維護成本增大；而交易額的增長，對SLA的要求也不斷提高。與此同時，一些新業(yè)務(wù)會面臨大流量沖擊，資源調(diào)度的挑戰(zhàn)也隨之增大。 業(yè)務(wù)類型復(fù)雜多樣、業(yè)務(wù)模型千差萬別，對應(yīng)的技術(shù)方案也多種多樣，因此SRE的整體維護成本大大提高。
根據(jù)上述挑戰(zhàn)，我們需要制定相應(yīng)的解決策略，策略原則主要聚焦在以下三點：
1.穩(wěn)定，這也是SRE工作的核心。 效率，包括云主機交付效率，也包括我們自己內(nèi)部的一些系統(tǒng)效率。 成本，用最少的機器提供最優(yōu)質(zhì)的服務(wù)。
2.在此原則的基礎(chǔ)上，我們開始了對SRE進行的一系列改進。
3.SRE演進之路 手工時代
最早期，我們前端是4層負載均衡，靜態(tài)資源通過Varnish/Squid緩存，動態(tài)請求跑在LAMP架構(gòu)下。這個時候機器很少，需要的流程很少，也沒有區(qū)分應(yīng)用運維、系統(tǒng)運維之類的。運維人員也很少，網(wǎng)絡(luò)、機器和服務(wù)都要負責(zé)。運維的工作大部分都是靠手工，其實當(dāng)時還沒有成型的運維系統(tǒng)，現(xiàn)在很多初創(chuàng)公司都是這種架構(gòu)。
云基礎(chǔ)設(shè)施
隨著業(yè)務(wù)的發(fā)展，我們的架構(gòu)也做出了適當(dāng)?shù)恼{(diào)整。尤其是在步入移動時代以后，移動的流量比重越來越大。接入層不只是Web資源，還包含了很多API接口的服務(wù)。后端的開發(fā)語言也不再局限于PHP，根據(jù)服務(wù)需求引入了Java、Python、C++等，整個業(yè)務(wù)架構(gòu)開始向微服務(wù)化變遷。伴隨業(yè)務(wù)架構(gòu)的變化，底層的基礎(chǔ)架構(gòu)也隨之改變。最大的變化是，2014年中的時候，所有的業(yè)務(wù)已經(jīng)都跑在了云上，如下圖所示。
跑在云上的一個好處是把底層主機和網(wǎng)絡(luò)抽象化，相當(dāng)于云平臺將主機創(chuàng)建、網(wǎng)絡(luò)策略修改等封裝到相應(yīng)的系統(tǒng)內(nèi)，對用戶提供統(tǒng)一的平臺接口。我們在做維護的時候，就能把之前很復(fù)雜的流程串連起來。也是在此時，SRE團隊初步成立，我們對整個運維相關(guān)的工作做了拆分。云計算部分（由美團云負責(zé)）主要負責(zé)主機、網(wǎng)絡(luò)，還有系統(tǒng)相關(guān)的；SRE對接業(yè)務(wù)側(cè)，負責(zé)機器的環(huán)境、業(yè)務(wù)側(cè)的架構(gòu)優(yōu)化以及業(yè)務(wù)側(cè)相關(guān)問題的處理。
問題＆解決方案
接下來介紹一下我們在做云基礎(chǔ)建設(shè)的過程中，遇到的問題和一些解決方案。
如上圖所示，首先是資源隔離的問題，因為這個問題，造成過幾次故障。我們線上VM的CPU、網(wǎng)卡都是共享的，有一次，壓測的流量很高，把主機網(wǎng)卡的帶寬基本上都占光了（當(dāng)時的主機大部分都是千兆的，很容易打滿），同宿主機的資源都被它爭搶了，其它VM上部署的服務(wù)的響時間變得很大，導(dǎo)致當(dāng)時我們買單的一個服務(wù)（買單的VM和壓測的VM部署在了同一個宿主上）直接掛掉了。
針對這個問題，我們做了兩點，一個是對所有的網(wǎng)絡(luò)資源都做了隔離，針對每個VM作相應(yīng)的配額，另外一個是針對業(yè)務(wù)特性將宿主集群做了拆分。離線業(yè)務(wù)，它不考慮CPU的競爭，各個業(yè)務(wù)對于所部署服務(wù)的具體響應(yīng)時間不是很關(guān)注，只要能在一個允許的時間段內(nèi)把業(yè)務(wù)跑完就可以了，我們把這些服務(wù)單獨的放在了一個離線集群。在線業(yè)務(wù)，根據(jù)不同業(yè)務(wù)的重要程度，又劃分成了多個小集群。
第二個問題就是VM打散，這個問題初期的時候暴露得并不是很明顯，當(dāng)時整個線上的業(yè)務(wù)還沒有做細致的服務(wù)化拆分，服務(wù)都部署在一個大集群內(nèi)，這種情況下即使VM沒有打散（同一個服務(wù)的多個VM在同一個宿主），某一個宿主掛掉，深圳論壇空間 香港主機，影響也不是很大。但是隨著業(yè)務(wù)的變化發(fā)展，再做服務(wù)化拆分之后，線上的服務(wù)基本上沒有幾百臺做成一個大集群的情況，都是十幾臺，或者幾十臺這種小集群。如果我們有一個10臺VM的服務(wù)，其中5臺在一個宿主上，那么這個宿主一旦掛掉，服務(wù)整體的承載能力就砍掉了一半，風(fēng)險很高，德國機房主機 波蘭服務(wù)器，高峰期如果掉一半，這個業(yè)務(wù)就癱瘓不可用了。針對這個問題，SRE團隊跟云計算的同學(xué)做了一個持續(xù)了半年多的優(yōu)化，將VM打散率控制到了90%以上，最終在同一個宿主上，同一個服務(wù)，不會多于兩臺VM。
第三個問題，完善調(diào)度成功率。經(jīng)過SRE和云計算同學(xué)的合作努力，現(xiàn)在的成功率已經(jīng)達到了3個9左右。
云計算基礎(chǔ)設(shè)施架構(gòu)
