《解密騰訊海量服務之道》講座筆記

轉自：https://baozh.github.io/2015-12/tencent-massive-service-discipline/

 

一直對騰訊作產品的能力比較敬佩的，咱們組作消息推送系統，而騰訊的信鴿就是咱們學習的榜樣。京東不少作產品的思想是跟騰訊學的，而京東不少同事也從騰訊過來的(京東合併了騰訊電商)，耳濡目染學到不少東西。

前幾天前騰訊的同事給咱們分享了《解密騰訊海量服務之道》，講了幾個騰訊開發產品的經驗原則，比較受益，遂總結下。

2個價值技術觀, 7個技術手段, 4個意識
騰訊的海量服務之道是由2個價值技術觀和7個技術手段，4個意識組成。技術價值觀是整體思想，意識是咱們的態度，技術手段是實現技術價值觀的手段或者方法。

海量服務的技術價值觀

有損服務

CAP理論
理論式系統基礎理論CAP爲分佈式的應用提供了理基礎:
C: Consistency，一致性；包括三種類型(強一致性，弱一致性，最終一致性)
A:Availability，可用性（主要指的是快速獲取數據的能力，即性能）
P:tolerance of network Partition，分區容錯性（亦包括可分佈性）

**有損服務經歷了3個階段的演變: **

1. ACID事物保證階段(金融，電信，石油，銀行)
   特色：經過硬件中間件、數據庫（支持事務）的層層事務保障，提供給用戶非此即彼的服務結果，數據一致性優先於反應速度。
   缺點：系統冗餘高，架構複雜，開發維護及運營成本很是高。

2. BASE理論階段(電商)
   特色：BASE是Basically Available、Soft state、Eventually consistent三個詞組的簡寫。經過犧牲【強一致性】，得到基本可用性和柔性可靠性並要求達到【最終一致性】
   缺點：犧牲部分一致性，只能保證最終一致性。

3. 有損服務階段(UGC)
   特色：
   a.放棄絕對一致，追求速度極致；
   b.萬有一失，讓用戶重試；
   c.伸縮調度，降級服務；

經過精心細分場景，選擇犧牲一部分一致性、完整性，以達到經過較低的成本，可以支持海量服務需求，而且知足服務基本可用。

動態運營

核心思想就是敏捷迭代， 所謂小步快跑，對用戶的需求快速反應。簡而言之就是「快速求證對用戶猜測」的過程。

許多偉人都說過相似的話：用戶每每不知道真正想要什麼，並且大可能是時間是拿來「試錯」的。動態運營就是快速求證對用戶猜測的過程，這個過程是創建在以」運營」爲中心的設計開發驗證模式。

海量服務的7個技術手段

容災

互聯網硬件容災方案：

事故	容災方法
光纖斷/機房停電	異地部署
服務器硬件故障死機	熱備
網絡環境惡劣	異地部署就近服務
黑客攻擊	DNS建設
程序core	自動拉起
服務雪崩	負載均衡、流量擁塞控制、頻率控制

互聯網業務邏輯層容災

1. 獨立邏輯的邏輯層，被接入層負載均衡調用。
   經過監控及時擴容，保證系統總體負載能力有冗餘，一臺服務器死機時，配置系統將其狀態置爲不可用，將其上的流量（平均）分給系統中其餘服務器(s)上。

2. 分號段邏輯的邏輯層，每一個邏輯層只能處理指定號段的請求。
   n+n容災：1對1容災，比較奢侈，備份系統要麼熱備（平時負擔50%請求）要麼冷備（平時不工做，空跑），事故發生時，備機承擔所有請求。
   n+1容災：備機平時冷備，擁有全局號段路由表，任何一臺主機死亡後，備機均可以轉成死亡主機的角色，負責相應號段的邏輯工做。

互聯網業務數據層容災

1. 寫惟一式同步 
   業務寫請求只發給數據層主機，由主機採用快、慢同步結合的方式同步給各臺備機。
2. 同時寫式同步
   業務將寫請求發給全部數據層服務器，獲得全部/多數ack纔算寫完成。Yahoo的Zookeeper使用多數ack（如5臺服務器有3+臺ack）即成功的方式（讀寫都是），這種相似投票表決的方式被驗證過能夠嚴格保證數據一致性，也不用擔憂惟一的主機寫失敗，可是實現比較複雜。

 

過載保護

在分佈式集羣系統中，某臺設備故障，會形成系統總體的繁忙不可用；在作營銷推廣時，某個服務單元負載極大的現象會很快蔓延到其它服務單元，最終致使所有服務的不可用；用戶羣越大，系統規模越大，負載超限的狀況擴散的就越快，最終會形成系統總體崩潰。上述現象在天然界用一個最直接的名詞就是」雪崩」。

過載保護的四個方法:

1. 輕重分離
   輕重分離的主旨是對服務的內容進行細分，按照高內聚低耦合的方式部署服務，使得局部的過載不擴散到整個系統。

2. 及早拒絕
   問題解決的階段越早，成本越低，影響越小。所以咱們一個系統的設計原則：【前端保護後端，後端不信任前端】，在發現系統有過載趨勢時，前端系統就要開始拒絕新的用戶請求接入。

3. 量力而爲
   過載保護是立體工程，各個層級都要首先作好自我保護，再考慮對關聯繫統的保護。運營時要有容量管理（即容量監控）。通常而言，建議容量管理按照70%預警，過載保護按照90%啓動。

4. 動態調節
   動態調節的核心思想是系統運營時經過持續監控業務狀態數據尋找【平衡點】，造成一個正向動態反饋的循環：
   業務正常狀態-> 過載保護狀態 -> 業務灰度恢復直到徹底解除過保。

 

負載均衡

負載均衡和過載保護機制很像，其實二者的目地是同樣的，即都有效保護後臺服務，減輕後臺服務的壓力，但實現的手段和方法是不同的。並且即便實現了負載均衡，也是須要提供過載保護機制。負載均衡考慮的是把請求合理分配到後臺服務器上。 過載保護考慮的是防止後面的服務器的雪崩。

負載均衡的算法：

1. 輪循均衡（Round Robin）
   每一次來自網絡的請求輪流分配給內部中的服務器，從1至N而後從新開始。此種均衡算法適合於服務器組中的全部服務器都有相同的軟硬件配置而且平均服務請求相對均衡的狀況。

2. 權重輪循均衡（Weighted Round Robin）
   根據服務器的不一樣處理能力，給每一個服務器分配不一樣的權值，使其可以接受相應權值數的服務請求。例如：服務器A的權值被設計成1，B的權值是3，C的權值是6，則服務器A、B、C將分別接受到10%、30％、60％的服務請求。此種均衡算法能確保高性能的服務器獲得更多的使用率，避免低性能的服務器負載太重。

3. 隨機均衡（Random）
   把來自網絡的請求隨機分配給內部中的多個服務器。

4. 權重隨機均衡（Weighted Random）
   此種均衡算法相似於權重輪循算法，不過在處理請求分擔時是個隨機選擇的過程。

5. 處理能力均衡
   此種均衡算法將把服務請求分配給內部中處理負荷（根據服務器CPU型號、CPU數量、內存大小及當前鏈接數等換算而成）最輕的服務器，因爲考慮到了內部服務器的處理能力及當前網絡運行情況，因此此種均衡算法相對來講更加精確，尤爲適合運用到第七層（應用層）負載均衡的狀況下。

負載均衡算法的實現有軟件和硬件兩種，這裏重點分析軟件的實現負載均衡的反向代理方式：
反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的鏈接請求，而後將請求轉發給內部網絡上的服務器，並將從服務器上獲得的結果返回給internet上請求鏈接的客戶端，此時代理服務器對外就表現爲一個服務器。

反向代理負載均衡能以軟件方式來實現，如nginx、apache等，也能夠在高速緩存器、負載均衡器等硬件設備上實現。反向代理負載均衡能夠將優化的負載均衡策略和代理服務器的高速緩存技術結合在一塊兒，提高靜態網頁的訪問速度，提供有益的性能；因爲網絡外部用戶不能直接訪問真實的服務器，具有額外的安全性。

 

柔性可用

在有損服務價值觀支撐下的一種作法：重點接口重點保障，次要接口有損保障，並提供緊急時刻的降級能力，同時在前端設計時，即便降級也能保證用戶體驗。即不保證完美體驗，對非關鍵路徑進行有損，提高系統的可用性。
實現上會結合用戶使用場景，根據資源消耗，調整產品策略，設計幾個級別的、不一樣的用戶體驗。最大程度的保證關鍵服務的可用性。對應互聯網服務來講就是要實現兩點:

• 要儘量成功返回關鍵數據
• 要儘量正常接收請求，不能堵死

 

分SET部署

Set化部署主要爲海量服務的運營和部署提供支持，爲業務部署創建統一的衡量標準和規則。

• 從業務層面來看到是一組服務器的處理能力，處理能力有兩個量來描述，PCU（萬人/在線）和存儲（GB）。
• 來自於成本層面，即這一組服務器有多少臺機器和外網帶寬。綜合評估設定合理的單位服務支撐能力。

SET模型的一個重要特色是較強的自給自足能力，或者說，SET模型在很大程度上是自治的。從這個意義上說，SET模型與集團軍也很具備可比性。

SET模型的特色：

• 通常來講，一個SET模型部署在一個IDC以內。
• 高內聚，或者說自治系統——這是模塊化的體現。
• 同一業務的不一樣SET間通訊：SET間專線窄帶化。這是下降業務對專線帶寬佔用，同時也是下降專線抖動對業務的影響，提升業務的專線抖動免役力。
• 即便SET間專線故障，獨立SET也應至少提供基礎服務，而不致停服。

Set化部署的例子：
Qzone日誌TDB倉庫設定180A1+20B5+20C1+2B2+23A3爲一個Set。

 

灰度發佈

互聯網行業的變化不少很快，致使代碼發佈也不少，於是引入bug的可能性也大了很多，與服務系統的穩定性造成了突出的矛盾。如何解決這個矛盾？如何既能基本保障服務穩定性，又能進行靈活反應、快速發佈？

灰度發佈的優點：

1. 灰度發佈能下降發佈出問題的影響
2. 下降發佈正常時的用戶感知
3. 下降對測試的依賴

灰度發佈的維度：

1. 按照特性（內容維度）
   每次只發布少部分特性、模塊

2.按照對象
白名單
Alpha用戶
公司用戶
用戶等級等級
用戶號段
其餘業務邏輯

 

立體監控

立體監控是對一個業務或者系統進行完整的監控，而業務從系統層次上又能夠分爲接入層，邏輯層，數據層。或者從基礎的資源到用戶實際體驗來劃分：

按照上述層次劃分，每層須要監控的技術指標以下：

報警
有了監控，還須要有效的通知方式。目前用的最多的是設置告警了。當某個監控指標不正常時，經過向相關負責人發送告警，以便及時處理。但告警不宜設置過多，非關鍵的或者重複的告警須要考慮去掉，以避免告警過多，接收人會對告警不敏感。

海量服務的4個意識

大系統作小

大系統小作的核心思想是將功能複雜較大的系統，化大爲小，減小模塊耦合，下降相關聯性，用多個獨立的模塊來實現總體系統的功能。
總的來講，大系統小作採用的是化繁爲簡、分而治之，便於開發和迅速實現；同時當某個模塊出了問題時，由於相互獨立，能將影響降到最低，不至於擴大影響範圍。咱們在實際工做也常常採用這種方法。
好比電商領域，會把系統分紅訂單模塊，商品模塊，售後，物流等模塊，每一個模塊獨立實現，互不影響。 再如物流的第二天達項目，就按照交易線，物流線，結算線分開，每快互相獨立，定義接口，最後把整個系統分解不少小塊。
這樣作自己容易開發，還有一點就是爲之後系統的擴展和作灰度升級提供方便。便可以只灰度發佈某一個模塊，而不用發佈整個模塊。

先抗住再優化

先扛住再優化簡單來講就是先保證業務的正常使用，即先扛住，再來優化。由於在複雜的優化工做交付以前，交互中故障模式的數量早就足以磨滅人們的信心。

1. 排隊機制
   遊戲滿負荷時，給新來的用戶彈出提示語「服務器已滿，您前方有XXX個玩家在排隊。服務器會幫你自動登陸，請您耐心等候」。遊戲滿負荷時，讓新進的玩家定向另外一款小遊戲去，讓玩家在娛樂中等待。

2. 降壓
   QQ相冊。原來的方案是用戶瀏覽照片，沒按下一張以前就會預加載下張照片，以便提高用戶體驗。後來發如今高峯期，帶寬不夠用，用戶叫苦連連。如今改成在18:00-20:00時段，取消自動加載照片功能。很快消去了這個封尖。

3. 運營扛法
   當初QQ幻想一想收費，玩15分鐘扣1個q點。帳戶系統時不時會core，core了之後公司就不能收錢了。可是core的緣由一時又沒找到。解決的辦法是添加監控腳本，監控到程序不在了就拉起。

乾乾淨淨

乾乾淨淨能夠說是開發人員的一個編程態度。

1. 乾乾淨淨對產品而言，咱們常常會看到不少產品從初期簡單清晰的功能規劃，不斷疊加產品邏輯、不斷推出新的功能、給用戶更多更全的特性入口。而這些不斷疊加的邏輯、功能、特性，是不是用戶所真正所須要的，每每會被忽視，因此咱們須要乾乾淨淨的態度對待產品，善於用減法的思路對待產品。

2. 乾乾淨淨對架構而言，不少產品設計之初的架構都比較容易作到清晰高效，而運營過程當中，爲了應對一些臨時的活動，或針對一些初期未考慮到的特殊狀況，等等，新的差別化於初期架構因素會不斷被引入，架構層次及定位逐漸再也不清晰，最終很大程度上形成架構效率的下降。

3. 乾乾淨淨對開發而言，咱們會看到在開發不斷交接更替的狀況下，程序中會不斷有帶有我的風格的代碼庫、中間件等被引入，在長期發展狀況下，不及時清理乾淨，最終會變得臃腫而難以承接。

4. 乾乾淨淨對運營而言，高效的運營須要清晰的運營架構和有序明瞭的運營環境，實際工做中如由於交替等因素，會形成運營環境中的腳本、目錄，甚至進程、端口處於無序的狀態，這些都會給後續的運營工做帶來很大的風險和低效。

邊重構邊生活

隨着業務的發展：系統變得複雜，功能更增強大；服務器/帶寬/成本增長；運營環境如千絲萬縷，運維難度增長；代碼風格不一；用戶數量級不斷增長……這些因素，當其發展到某個量級時，會變得臃腫不堪，耗費至關的人力成本和服務器資源，也難以保障服務質量。這就要求咱們：要有勇氣和自信重構服務，提供更先進更優秀的系統。