解密騰訊海量服務之道

一直對騰訊做産品的能力比較敬佩的，我們組做消息推送系統，而騰訊的信鴿就是我們學習的榜樣。京東很多做産品的思想是跟騰訊學的，而京東很多同僚也從騰訊過來的(京東合并了騰訊電商)，耳濡目染學到很多東西。

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

2個價值技術觀, 7個技術手段, 4個意識

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

海量服務的技術價值觀

有損服務

CAP理論

理論式系統基礎理論CAP為分布式的應用提供了理基礎:

C: Consistency，一緻性；包括三種類型(強一緻性，弱一緻性，最終一緻性)

A:Availability，可用性（主要指的是快速擷取資料的能力，即性能）

P:tolerance of network Partition，分區容錯性（亦包括可分布性）

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

ACID事物保證階段(金融，電信，石油，銀行)

特點：通過硬體中間件、資料庫（支援事務）的層層事務保障，提供給使用者非此即彼的服務結果，資料一緻性優先于反應速度。

缺點：系統備援高，架構複雜，開發維護及營運成本非常高。
BASE理論階段(電商)

特點：BASE是Basically Available、Soft state、Eventually consistent三個詞組的簡寫。通過犧牲【強一緻性】，獲得基本可用性和柔性可靠性并要求達到【最終一緻性】

缺點：犧牲部分一緻性，隻能保證最終一緻性。
有損服務階段(UGC)

特點：

a.放棄絕對一緻，追求速度極緻；

b.萬有一失，讓使用者重試；

c.伸縮排程，降級服務；

通過精心細分場景，選擇犧牲一部分一緻性、完整性，以達到通過較低的成本，能夠支援海量服務需求，并且滿足服務基本可用。

動态營運

核心思想就是靈活疊代，所謂小步快跑，對使用者的需求快速反應。簡而言之就是“快速求證對使用者猜想”的過程。

許多偉人都說過類似的話：使用者往往不知道真正想要什麼，而且大多是時間是拿來“試錯”的。動态營運就是快速求證對使用者猜想的過程，這個過程是建立在以”營運”為中心的設計開發驗證模式。

海量服務的7個技術手段

容災

網際網路硬體容災方案：

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

網際網路業務邏輯層容災

獨立邏輯的邏輯層，被接入層負載均衡調用。

通過監控及時擴容，保證系統整體負載能力有備援，一台伺服器當機時，配置系統将其狀态置為不可用，将其上的流量（平均）分給系統中其他伺服器(s)上。
分号段邏輯的邏輯層，每個邏輯層隻能處理指定号段的請求。

n+n容災：1對1容災，比較奢侈，備份系統要麼熱備（平時負擔50%請求）要麼冷備（平時不工作，空跑），事故發生時，備機承擔全部請求。

n+1容災：備機平時冷備，擁有全局号段路由表，任何一台主機死亡後，備機都可以轉成死亡主機的角色，負責相應号段的邏輯工作。

網際網路業務資料層容災

寫唯一式同步

業務寫請求隻發給資料層主機，由主機采用快、慢同步結合的方式同步給各台備機。
同時寫式同步

業務将寫請求發給所有資料層伺服器，得到所有/多數ack才算寫完成。Yahoo的Zookeeper使用多數ack（如5台伺服器有3+台ack）即成功的方式（讀寫都是），這種類似投票表決的方式被驗證過可以嚴格保證資料一緻性，也不用擔心唯一的主機寫失敗，但是實作比較複雜。

過載保護

在分布式叢集系統中，某台裝置故障，會造成系統整體的繁忙不可用；在做營銷推廣時，某個服務單元負載極大的現象會很快蔓延到其它服務單元，最終導緻全部服務的不可用；使用者群越大，系統規模越大，負載超限的情況擴散的就越快，最終會造成系統整體崩潰。上述現象在自然界用一個最直接的名詞就是”雪崩”。

過載保護的四個方法:

輕重分離

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

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

過載保護是立體工程，各個層級都要首先做好自我保護，再考慮對關聯系統的保護。營運時要有容量管理（即容量監控）。一般而言，建議容量管理按照70%預警，過載保護按照90%啟動。
動态調節

動态調節的核心思想是系統營運時通過持續監控業務狀态資料尋找【平衡點】，形成一個正向動态回報的循環：

業務正常狀态-> 過載保護狀态 -> 業務灰階恢複直到完全解除過保。

負載均衡

負載均衡和過載保護機制很像，其實兩者的目地是一樣的，即都有效保護背景服務，減輕背景服務的壓力，但實作的手段和方法是不一樣的。而且即使實作了負載均衡，也是需要提供過載保護機制。負載均衡考慮的是把請求合理配置設定到背景伺服器上。過載保護考慮的是防止後面的伺服器的雪崩。

負載均衡的算法：

輪循均衡（Round Robin）

每一次來自網絡的請求輪流配置設定給内部中的伺服器，從1至N然後重新開始。此種均衡算法适合于伺服器組中的所有伺服器都有相同的軟硬體配置并且平均服務請求相對均衡的情況。
權重輪循均衡（Weighted Round Robin）

根據伺服器的不同處理能力，給每個伺服器配置設定不同的權值，使其能夠接受相應權值數的服務請求。例如：伺服器A的權值被設計成1，B的權值是3，C的權值是6，則伺服器A、B、C将分别接受到10%、30％、60％的服務請求。此種均衡算法能確定高性能的伺服器得到更多的使用率，避免低性能的伺服器負載過重。
随機均衡（Random）

把來自網絡的請求随機配置設定給内部中的多個伺服器。
權重随機均衡（Weighted Random）

此種均衡算法類似于權重輪循算法，不過在處理請求分擔時是個随機選擇的過程。
處理能力均衡

此種均衡算法将把服務請求配置設定給内部中處理負荷（根據伺服器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. 降低對測試的依賴

灰階釋出的次元：

按照特性（内容次元）

每次隻釋出少部分特性、子產品

2.按照對象

白名單

Alpha使用者

公司使用者

使用者等級等級

使用者号段

其他業務邏輯

立體監控

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

按照上述層次劃分，每層需要監控的技術名額如下：

報警

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

海量服務的4個意識

大系統做小

大系統小做的核心思想是将功能複雜較大的系統，化大為小，減少子產品耦合，降低相關聯性，用多個獨立的子產品來實作整體系統的功能。

總的來說，大系統小做采用的是化繁為簡、分而治之，便于開發和迅速實作；同時當某個子產品出了問題時，因為互相獨立，能将影響降到最低，不至于擴大影響範圍。我們在實際工作也經常采用這種方法。

比如電商領域，會把系統分成訂單子產品，商品子產品，售後，物流等子產品，每個子產品獨立實作，互不影響。再如物流的次日達項目，就按照交易線，物流線，結算線分開，每快互相獨立，定義接口，最後把整個系統分解很多小塊。

這樣做本身容易開發，還有一點就是為以後系統的擴充和做灰階更新提供友善。即可以隻灰階釋出某一個子產品，而不用釋出整個子產品。

先抗住再優化

先扛住再優化簡單來說就是先保證業務的正常使用，即先扛住，再來優化。因為在複雜的優化工作傳遞之前，互動中故障模式的數量早就足以磨滅人們的信心。

排隊機制

遊戲滿負荷時，給新來的使用者彈出提示語“伺服器已滿，您前方有XXX個玩家在排隊。伺服器會幫你自動登入，請您耐心等候”。遊戲滿負荷時，讓新進的玩家定向另一款小遊戲去，讓玩家在娛樂中等待。
降壓

QQ相冊。原來的方案是使用者浏覽照片，沒按下一張之前就會預加載下張照片，以便提升使用者體驗。後來發現在高峰期，帶寬不夠用，使用者叫苦連連。現在改為在18:00-20:00時段，取消自動加載照片功能。很快消去了這個封尖。
營運扛法

當初QQ幻想想收費，玩15分鐘扣1個q點。賬戶系統時不時會core，core了以後公司就不能收錢了。但是core的原因一時又沒找到。解決的辦法是添加監控腳本，監控到程式不在了就拉起。

幹幹淨淨

幹幹淨淨可以說是開發人員的一個程式設計态度。

幹幹淨淨對産品而言，我們經常會看到很多産品從初期簡單清晰的功能規劃，不斷疊加産品邏輯、不斷推出新的功能、給使用者更多更全的特性入口。而這些不斷疊加的邏輯、功能、特性，是否是使用者所真正所需要的，往往會被忽視，是以我們需要幹幹淨淨的态度對待産品，善于用減法的思路對待産品。
幹幹淨淨對架構而言，很多産品設計之初的架構都比較容易做到清晰高效，而營運過程中，為了應對一些臨時的活動，或針對一些初期未考慮到的特殊情況，等等，新的差異化于初期架構因素會不斷被引入，架構層次及定位逐漸不再清晰，最終很大程度上造成架構效率的降低。
幹幹淨淨對開發而言，我們會看到在開發不斷交接更替的情況下，程式中會不斷有帶有個人風格的代碼庫、中間件等被引入，在長期發展情況下，不及時清理幹淨，最終會變得臃腫而難以承接。
幹幹淨淨對營運而言，高效的營運需要清晰的營運架構和有序明了的營運環境，實際工作中如因為交替等因素，會造成營運環境中的腳本、目錄，甚至程序、端口處于無序的狀态，這些都會給後續的營運工作帶來很大的風險和低效。

邊重構邊生活

随着業務的發展：

系統變得複雜，功能更加強大；

伺服器/帶寬/成本增加；

營運環境如千絲萬縷，運維難度增加；

代碼風格不一；

使用者數量級不斷增加……

這些因素，當其發展到某個量級時，會變得臃腫不堪，耗費相當的人力成本和伺服器資源，也難以保障服務品質。這就要求我們：要有勇氣和自信重構服務，提供更先進更優秀的系統。

出處：https://baozh.github.io/2015-12/tencent-massive-service-discipline/