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

轉自：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. 干干凈凈對運營而言，高效的運營需要清晰的運營架構和有序明了的運營環境，實際工作中如因為交替等因素，會造成運營環境中的腳本、目錄，甚至進程、端口處於無序的狀態，這些都會給后續的運營工作帶來很大的風險和低效。

邊重構邊生活

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