轉自?http://itzoo.info/?p=591

一 如何利用應用自己的數據來保證系統的穩定-淘寶小賭

總體感覺淘寶經過最近這幾年雙十一和雙十二的洗禮，在流量的容量規劃和控制方面做了很多工作：

水位的概念

1	水位=（流量QPS/性能QPS）x?100%

水位這個概念我覺得描述的非常恰當，就是大壩水位的概念一樣。從上面這場PPT圖片可以看出，單機房下70%作為了正常水位線，長期低于60%說明機器資源浪費、高于80%說明需要加機器了。雙機房的正常水位線設定在40%是處于互備的目的考慮，一旦某個機房掛了，可以迅速將流量遷移到互備機房，這樣雙倍的流量需要保持在80%以下。

性能QPS的測量

性能QPS是指集群性能QPS（單機性能QPS x 集群結點數目），性能QPS是指load在num(cpu core)，cpu使用率70%情況下系統所能承受的QPS，num(cpu core)指的是CPU的核數，對于4核機器一般在4到4.5左右。采用這一數值實際上是對load這一指標的深入理解之后做出的。關于load通俗的解釋是系統可以同時處理的任務個數或者處理隊列的長度，理解Linux 的處理器負載均值?這篇翻譯文章解釋的很好，值得一看。

對于性能QPS的評估，淘寶有線上壓測的方式，一般架構最前端都有lvs之類的負載均衡器做流量分發，通過把流量緩慢遷移到某一個應用服務器，可以觀察到QPS以及系統負載的變化。 這種方式有一定的風險，一般站點如果沒有能力控制的話，我建議還是采用tcpcopy等工具將流量復制到測試環境做評估，也可以采用PPT中提到的日志回訪模式，根據訪問日志將實際請求在測試環境中重演一遍得到測試結果。

流量QPS的評估

流量QPS主要是根據實際業務目標進行估算，比如雙十一大促，業務目標是達成200億，可以估算到會有多少訂單，進而可以根據服務之間的依賴關系估算到每個服務的容量（這叫做容量依賴）。

容量依賴估算有兩種方式:

• 一種是可以通過在服務路徑中注入統一的UUID的方式測算到每個子系統的實際容量。
• 一種是根據訪問日志的refer信息估算不同服務間的容量依賴關系。

流量防護

淘寶在流量防護做的工作有限流和服務降級。限流工作由內部代號叫做TMD(Taobao Missile Defense)的系統來完成。據說TMD可以抵擋DDoS攻擊，可以封禁IP和cookie，可以限流（比如detail頁面限流1600QPS），也可以提供驗證碼服務。TMD的工作原理是nginx實時發送日志給TMD Server，TMD server做策略分析，然后控制臺做匯總和控制.我個人對這個系統比較感興趣，淘叔度關于Tengine的一個PPT中提到了TMD,貌似還沒有開源.?

二 新浪微博平臺防御體系-姚四芳

架構圖

從圖上可以看出核心是scribe+storm+dashboard構成。

scribe是facebook開源的日志收集框架。

Scribe is a server for aggregating log data that’s streamed in real time from clients. It is designed to be scalable and reliable.

storm是twitter開源的分布式實時計算引擎。

Storm is a distributed realtime computation system. Similar to how Hadoop provides a set of general primitives for doing batch processing, Storm provides a set of general primitives for doing realtime computation. Storm is simple, can be used with any programming language, is used by many companies, and is a lot of fun to use!

個人認為兩者的組合的確是日志實時分析利器，新浪微博基于這兩個項目搭建健康狀況實時分析平臺真的是多快好省。

特色

• 方法級別的監控粒度和服務降級

  通過注解的方式實現（java代碼），一旦發現某個方法響應時間過長，可以對該方法降級，馬上返回，這也是快速失敗思想的體現。后來在討論環節姚提到了ASM，所以實現方式應該是利用了ASM對所有通過注解標記的方法進行了字節碼動態增強，對方法做了代理。Spring的AOP實現底層也實現了ASM，這個技術挺有用，值得深入研究一下。

• URI接口降級

  新浪微博自己實現的訪問proxy控制URI是否降級，一旦流量超過警戒線，可以對某些不處在關鍵路徑上的URI服務降級，返回503狀態。

• 圖形化的Dashboard

  PPT中的一張圖給我印象深刻，可惜忘了拍了。從他們平臺監控Dashboard上可以看到微博feed區消息渲染這一過程中每個步驟的狀態圖，從圖上可以清晰地看到哪個步驟是性能瓶頸，哪個步驟可能會出問題。這種方式不僅可以做監控，還可以快速定位性能瓶頸，從而做有針對性的代碼優化。

三 如何利用SEDA提高系統的性能和穩定性-小米瞿晉萍

瞿從排隊論切入，指出所有服務端軟件都是排隊服務思想，回顧了常見的并發模型：

首先介紹了基于thrift THsHaServer介紹了傳統的HsHA模型（HALF-SYNC/HALF-ASYNC，半同步半異步模式），這種模型使用一個單獨的線程處理網絡IO，然后把請求丟給worker線程池，每個worker線程負責處理實際的任務，它的缺點是并發處理能力受worker線程池大小影響。

接著介紹了thrift 0.8版本對HsHa模式的改進——TThreadedSelectorServer，這種模型出一個線程池來專門進行網絡IO的處理，所以它比THsHAServer更適合處理網絡IO密集的情況。此外還介紹了twitter的Finagle框架，它也是對HsHA模型的改進。

最后介紹了SEDA(staged event driven architecture),這其實是一種思想，把一個復雜的事件驅動的任務拆解成由多個隊列連接的狀態集合。Host+MQ 就是這種思想的體現，每個Host處理任務的其中一個階段，不同階段的中間結果用消息隊列來連接和協調。隊列的擁塞程度可以反映出該階段的處理能力和狀態。

關于thrift各種服務器server模式，老外做了詳解,這里有篇翻譯文章寫的不錯。HsHa的詳細介紹牛文在這里。SEDA思想也是老外提出的，服務器端的多線程并發處理模型這個領域，老外確實比國人高明不少，基本上所有模式都是人家想的，慨嘆一下，這里面水深坑多，值得深入研究。

http://club.alibabatech.org/salon_detail.htm?salonId=29

轉載于:https://www.cnblogs.com/thomaswu/archive/2013/03/25/2981172.html

總結

以上是生活随笔為你收集整理的淘宝技术沙龙「系统稳定性与性能」的笔记与思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。